[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Sam Trenholme" <namedroppers@artemas.reachin.com>
Cc: <dnsop@cafax.se>
From: "Cricket Liu" <Cricket@verisign.com>
Date: Sat, 21 Apr 2001 12:03:33 -0600
Sender: owner-dnsop@cafax.se
Subject: Re: Tips for DNS zone administration

Hi, Sam.

> I am writing up a page on DNS zone administration.  The page can be found
> here:
>
> http://www.maradns.org/dns_admin_tips.html
>
> I was wondering what other tips people have, and what improvments can be
> made to the tips here.

See below for some suggestions.

> For people withour ready web access, here is the page:
>
> Some DNS zone management tips
>
>      * The TTL for a host entry should be the same size or larger than
>        the SOA Minimum TTL for the zone.

No, that's not right.  The SOA "minimum" has never been implemented as
a minimum, and RFC 2308 codifies that.  There are good reasons to have
a TTL on an individual RR that's lower than the default TTL for the zone;
for example, if you're planning on moving a single host.

>      * Just because the offending data is no longer in your zone does not
>        mean other people can contact the site in question: The old record
>        will float around in other caches for a while.
>      * Never have the same computer names used for NS records for your
>        domain be used for anything else, such as MX records or CNAME
>        records.

Why?

>      * If possible, make the TTLs for the NS records for your domain as
>        long as possible (604800 seconds--one week, is a good number).
>        This will speed up accesses to your domain, since caches will not
>        have to query the root servers as often before querying your name
>        servers.
>      * Never have a MX point to a CNAME records. Some MTAs refuse to send
>        mail if the domain is so configured.

This can also cause mail loops.

>      * Never have a CNAME record and any other record use the same host
>        name. This will confuse caching nameservers, which usually assume
>        that a CNAME record applies to all record types for a given host
>        name.

They generally "assume" that because that's how CNAME records are
defined to work.

>      * Avoid using CNAME records--they can increase the number of DNS
>        queries needed to resolve a given host name.

I think there are some good reasons to use CNAME records, and CNAME
records that point from one domain name in a zone to another domain name
in the same zone doesn't increase the number of queries required to look up
a domain name.

>      * MX, NS, and CNAME records should point to host names, not IPs.
>        Something like "example.com IN MX 10 192.168.0.64." will not work
>        with BIND. Note, however, that both DjbDNS and MaraDNS support
>        this kind of construct.

How exactly do they support those constructs?  If these name servers dole
out

example.com.    IN    MX    10 192.168.0.64

how do they also prevent the mailer that looked up the record from trying to
look up the A RR for the domain name 192.168.0.64?

>      * Try to have one NS server for your domain be "in baliwick". If you
>        have the domain "example.com", for example, then it is best if one
>        of the NS servers is "ns.example.com", or, DJ Bernstein's favorite
>        "a.ns.example.com". Today, this is only a real issue if, for
>        example, you have "example.com" with the name servers
>        "a.ns.example.com.ar" and "b.ns.example.com.ar". These NS entries
>        slow down access to your domain--a resolver with an empty cache
>        now requires 7 instead of 3 queries to resolve names in the
>        domain--more if example.com.ar uses out-of-baliwick NS servers.

It's "bailiwick."

cricket


Home | Date list | Subject list