Subject: Tips for DNS zone administration

From: Sam Trenholme <[email-masked]>
Date: Sat, 21 Apr 2001 00:35:02 -0700 (PDT)

Hello there,

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.

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.
     * 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.
     * 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.
     * 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.
     * Avoid using CNAME records--they can increase the number of DNS
       queries needed to resolve a given host 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.
     * 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.

---

From: Randy Bush <[email-masked]>
Date: Sat, 21 Apr 2001 07:31:37 -0700

>        domain be used for anything else, such as MX records or CNAME

by "computer name" i presume you mean "dns label" or "fqdn"

and why?

foo.   soa ()
       ns     @
       a      42.7.13.11
       mx  42 @

looks perfectly legal to me.

randy

---

From: Mats Dufberg <[email-masked]>
Date: Sat, 21 Apr 2001 17:28:54 +0200 (CEST)

>        domain be used for anything else, such as MX records or CNAME

I know that CNAME must not be combined with MX or NS in the same node, but
what combinations of NS and MX are bad?

>        have to query the root servers as often before querying your name

If you do remember to set it down well before any changes... I think that
TTL's over 1-2 days should be well motivated before use.

Instead, recommend a long expire. I've seen 1 hour in zones... A week or
two is usually good.

>        that a CNAME record applies to all record types for a given host

A "host name" is a node in the domain tree which has an A record, isn't
it? -- "Never have a CNAME record and any other record in the same node."

>        queries needed to resolve a given host name.

"In the same zone it is usually better to let several names have A records
pointing at the same IP addresses."

Mats

-----------------------------------------------------------------
Mats Dufberg                                     +46-8-545 857 06
[email-masked]                           fax: +46-8-545 857 29

---

From: "Cricket Liu" <[email-masked]>
Date: Sat, 21 Apr 2001 12:03:33 -0600

Hi, Sam.

> I was wondering what other tips people have, and what improvments can be

See below for some suggestions.

>        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.

>        domain be used for anything else, such as MX records or CNAME

Why?

>        mail if the domain is so configured.

This can also cause mail loops.

>        that a CNAME record applies to all record types for a given host

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

>        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.

>        with BIND. Note, however, that both DjbDNS and MaraDNS support

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?

>        domain--more if example.com.ar uses out-of-baliwick NS servers.

It's "bailiwick."

cricket

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sat, 21 Apr 2001 21:26:44 +0200

Good evening to you.
    
    Hello there,

    

Lots of improvements can be made. Maybe you should first look into
RFC 1912 ``Common DNS Operational and Configuration Errors'' and
similar documents (RFC 's, but also RIPE doucemnts) before you roll
your own which upto now includes suggestions to be not compliant
width RFC 1035.

	jaap

---

From: Robert Elz <[email-masked]>
Date: Sun, 22 Apr 2001 14:07:35 +0700

Date:        Sat, 21 Apr 2001 17:28:54 +0200 (CEST)
    From:        Mats Dufberg <[email-masked]>
    Message-ID:  <[email-masked]>

  | On Sat, 21 Apr 2001, Sam Trenholme wrote:
  | 
  | >      * 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.
  | 
  | I know that CNAME must not be combined with MX or NS in the same node, but
  | what combinations of NS and MX are bad?

There's nothing illegal about having NS records use the same names as
anything else (including the name of the domain itself, as Randy showed
in his reply) - except that of a CNAME of course.

On the other hand, I agree with the advice, it turns out that updating the
value of an NS record can be hard (it can appear as glue in all kinds of
weird places) and can sometimes take a long time to achieve.   It can often
be better to simply abandon an old NS name (value of the RDATA of an NS
record) and invent a new one.   That's pretty easy if the name is used for
nothing other than the NS record, much harder if it is also used for all
kinds of other purposes (expecially when it is used for human visible 
purposes).

This may not be as difficult now as it used to be (changes in nameserver
habbits) - but I know that I renumbered a whole lot of a campus just to
avoid changing munnari.oz.au's IP address(es) when it moved on the internal
network (a few years ago now) - just to avoid these problems.  (If I was
setting things up now knowing what I now know, rather than what I knew 15
years ago, I never would have used that name in NS records).

kre

---

From: Mats Dufberg <[email-masked]>
Date: Sun, 22 Apr 2001 11:01:05 +0200 (CEST)

> kinds of other purposes (expecially when it is used for human visible

I still don't get what combination is bad. I guess that you do not mean

namn.se. soa ()
         ns     ns.namn.se.
         mx     mail.namn.se.

Do you mean that is bad to have

namn.se. soa ()
         ns  jox.namn.se.
         mx  jox.namn.se.
jox      a   192.0.2.10

or do you mean

namn.se. soa ()
         ns  namn.se.
         mx  namn.se.
         a   192.0.2.10

Mats

---

From: Mans Nilsson <[email-masked]>
Date: Sun, 22 Apr 2001 12:15:09 +0200

> I still don't get what combination is bad. I guess that you do not mean
 
I interpret that as "good" too. (given that A records are added, of course)
 
> Do you mean that is bad to have

Both, I would guess -- and this not from a DNS tech standpoint but from a
sysdamin / user interaction point. We all know the hassle of renumbering
your resolver machine, having to find all hosts that might resolve via
it and then convincing the admins/users that changing /etc/resolv.conf
is a Good Thing Right Now Or Your Lookups Will Fail...

"Overloading" names means that you tie lots of important functions to one
single node, which means that any change to that node will affect many
services. Better then to have different names (even if the finally resolve
to the same host, either via CNAME or multiple A) something like this:

namn.se.	SOA ()
		NS	ns
		NS	host.upstream.isp.
		MX	1 mail
ns		A	192.0.2.2
burk		A	192.0.2.2
mail		A	192.0.2.2
www		CNAME	burk
ntp		CNAME	burk
smtp		CNAME	burk	; this is the smtp relay for 
				; outbound mail; we type 'smtp.namn.se.'
				; in users MUA configs.

Now I've bored you with obviousities enough!

-- 
Måns Nilsson		Systems Specialist
+46 70 681 7204		KTHNOC
			MN1334-RIPE

I want another RE-WRITE on my CAESAR SALAD!!

---

From: Robert Elz <[email-masked]>
Date: Sun, 22 Apr 2001 16:53:22 +0700

Date:        Sun, 22 Apr 2001 11:01:05 +0200 (CEST)
    From:        Mats Dufberg <[email-masked]>
    Message-ID:  <[email-masked]>

  | Do you mean that is bad to have
  | 
  | namn.se. soa ()
  |          ns  jox.namn.se.
  |          mx  jox.namn.se.
  | jox      a   192.0.2.10

I probably wouldn't use the word "bad" for any of these, perhaps
"less than ideal".   Of all the cases, sharing an MX name and a NS
name is probably the least of a problem, as neither is known by
anything but the DNS, so both can easily be discarded if needed.

That is, if you wanted to change the IP address of your nameserver,
but couldn't make the 192.0.2.10 address vanish from who knows where,
you could just change "jox" to "sox" in the NS and MX records, create
a new A record, fix the delegation at the parent, and you're done.

  | or do you mean
  | 
  | namn.se. soa ()
  |          ns  namn.se.
  |          mx  namn.se.
  |          a   192.0.2.10

That one, along with

	namn.se. soa (...)
		 ns  www.nanm.se.
	www	 a   192.0.2.10

are about the two worst examples, as there there's no possibility at all
to change the name if the old address simply won't go away (people keep
getting 192.0.2.10 as the A record long after you've changed it, and you
can't work out why).  That is, apart from abandoning namn.se - and that's
certainly a sub-optimal solution.

NS records are the one that causes the most of these problems, as they're
the RR type that causes (legitimate) permanent caching of the A record
(glue) in other nameservers.  If you give the NS record a throwaway name,
you can throw it away whenever convenient, and just create a new name.
Then any ancient glue A records that float around the DNS won't cause anyone
any problems (they relate only to old nameserver names that are no longer
used by anyone for anything).

kre

---

From: Randy Bush <[email-masked]>
Date: Sun, 22 Apr 2001 06:20:55 -0700

> to the same host, either via CNAME or multiple A) something like this:

if you wish your work to actually be useful, as opposed to a polemic, you
may want to stick to what is technically correct, as opposed to your
particular view of what is operationally useful and advisable.

randy

---

From: Robert Elz <[email-masked]>
Date: Sun, 22 Apr 2001 21:47:35 +0700

Date:        Sun, 22 Apr 2001 06:20:55 -0700
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | if you wish your work to actually be useful, as opposed to a polemic, you
  | may want to stick to what is technically correct, as opposed to your
  | particular view of what is operationally useful and advisable.

By which Randy means, I think, don't use CNAME...

kre

---

From: Randy Bush <[email-masked]>
Date: Sun, 22 Apr 2001 08:00:41 -0700

> By which Randy means, I think, don't use CNAME...

not at all.

use cname where it is legal and you need it.

use ns, a, and mx for the same label where you need it.

...

randy

---

From: Mans Nilsson <[email-masked]>
Date: Sun, 22 Apr 2001 17:41:30 +0200

> particular view of what is operationally useful and advisable.

Oh, excuse me. I was just relating some of my limited experience. I will
now go shut up again.

In Newark the laundromats are open 24 hours a day!

---

From: Randy Bush <[email-masked]>
Date: Sun, 22 Apr 2001 09:30:47 -0700

experiences vary widely, as do needs.

e.g. on the ns==a==mx issue.  i know *many* simple sites where there is one
server.  they see no reason to create multiple fake names, or worse fake
interfaces, for all the services; it just makes more cruft, clutter to
maintain, etc.  on the other hand, larger sites have multiple servers,
backup mx, separate nameservers, ...

the technical protocols are the bounds of the box.  within those bounds lies
the design space.  and there are all sorts of needs and tradeoffs in that
space.  e.g. it took liman and crew at least a year to settle on the ripe
document describing ripe-192 <http://www.ripe.net/ripe/docs/ripe-192.html>,
dns setup for the minimal site.

this stuff is not simple or easy.  and there is no one right way.  and prof
wirth taught us that both the previous sentences should be false <sigh>.

randy

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 22 Apr 2001 10:09:40 -0700

> if you wish your work to actually be useful, as opposed to a polemic,
> you may want to stick to what is technically correct, as opposed to
> your particular view of what is operationally useful and advisable.

A lot of the problems with DNS are administrative in nature, and it's
pretty good advice to suggest avoiding admin traps. The technology working
right on poorly-managed names still causes lookups to fail.

EG, making www.example.com an NS for example.com is technically allowable,
but registering the IP address of www.example.com as a host record in a
delegation parent is a bad idea from an administrative POV. You will not
be able to change the glue data and the in-zone data at the same time, and
some servers out there still use delegation data as answer data even
though they shouldn't, so www.example.com may still show up in answers for
a week or so until you get it fixed and the TTLs expire.

If you had used some other machine for the NS delegation, you could move
www.example.com much easier. You still have to wait for TTLs to expire,
but you don't have to go through the rigamarole of getting NSI or whoever
to update the host entries for your web server. Also, you have better
control over TTLs when the records only appear in your zone.

These admin problems DO interfere with the technology's usability. They
should be clearly defined as admin problems though.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Havard Eidnes <[email-masked]>
Date: Sun, 22 Apr 2001 19:07:11 +0200

>   | or do you mean
>   |
>   | namn.se. soa ()
>   |          ns  namn.se.
>   |          mx  namn.se.
>   |          a   192.0.2.10
>
> That one, along with
>
> 	namn.se. soa (...)
> 		 ns  www.nanm.se.
> 	www	 a   192.0.2.10
>
> are about the two worst examples, as there there's no
> possibility at all to change the name if the old address simply
> won't go away (people keep getting 192.0.2.10 as the A record
> long after you've changed it, and you can't work out why).

Isn't this in some sense putting the cart before the horse?

I mean, the actual problem is being able to track down where glue
records are being maintained.  If folks only maintained "required"
glue records, it would be a simple matter of tracing the zone path
from the name of the name server itself to the root of the DNS
hierarchy and update any glue records there, and that is, IMHO, as
easy as this ought to be.

Besides, reasonably modern versions of name server software already
discard glue records which are not in a child zone, which should at
least in theory alleviate this problem.

Just my $0.02.

- Håvard

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 22 Apr 2001 10:29:43 -0700

> If you do remember to set it down well before any changes... I think
> that TTL's over 1-2 days should be well motivated before use.

If an authoritative DNS server does get renumbered, then full-service
resolvers which are unable to reach that server at its cached address will
flag it as unreachable, and will use the other servers which are listed as
being authoritative for the zone. In those situations, the loss of
connectivity for one of the Name Servers will likely cause some minor
hiccups, but it should not trigger any fatal errors unless zone
replication is also prevented (if all of the copies of the zone expire
because the primary master server was unreachable for an extended period
of time, major problems will definitely occur). But for lookups, large
TTLs on NS RRs are fine, since other servers will just stop querying them.

Also, the delegation glue from the gTLDs is 2 days, so the in-zone
versions of the NS *and* A RRs should definitely be at least that long (if
your zone is in one of those portions of the namespace). In other words,
the TTL of the NS (and the associated A) RRs for your in-zone list should
be longer than the parent delegation RRs. Both the NS and A RRs should
have the same TTL, otherwise deadlocks can occur.

> Instead, recommend a long expire. I've seen 1 hour in zones... A week
> or two is usually good.

Short TTLs and long expires for non-NS hosts is an excellent suggestion

---

From: Sam Trenholme <[email-masked]>
Date: Sun, 22 Apr 2001 00:09:03 -0700 (PDT)

> TTL's over 1-2 days should be well motivated before use.

I can think of two reasons for this thinking:

* Care needs to be taken to lower the TTL before changing any information.

* Some nameservers do not have a cap on the number of records they store
  in their cache.

- Sam

---

From: Sam Trenholme <[email-masked]>
Date: Sun, 22 Apr 2001 00:01:56 -0700 (PDT)

Thanks a lot for all of the excellent suggestions.  I have incorporated
them in to the web page in question.  BTW, I initially learned to set up a
zone and nameserver from the first edition of "DNS and BIND".

> >        domain be used for anything else, such as MX records or CNAME

The reason for this is because, if one ever changes the IP of one of the
name servers, and has a critial service (such as a web page or incoming
MTA) pointing to the machine in question, they have to wait for their
registrar to change the IP for the nameserver in question before that
service will function again.

I was bitten by this once.

> in the same zone doesn't increase the number of queries required to look up

True enough, with BIND.  Both DjbDNS and MaraDNS (my name server) do not
currently have this behavior.  And yes, in the comments of MaraDNS, I have
this noted as something MaraDNS needs to do.  It's about 20 lines of code
I need to write up.  More if I bother with a bailiwick check.

> look up the A RR for the domain name 192.168.0.64?

Well, both Qmail and Postfix know that a host name in that form means "the
DNS admin was clueless and meant to put in an IP".  Both DjbDNS' caching
nameserver (DjbDNS has two programs--a caching-only and an authoritative
only DNS server)  and MaraDNS will synthesize an A record whenever they
are asked for a host name in this form.  Of course, since MaraDNS is
currently only an authoritative nameserver, its kinda useless with MaraDNS
right now, but may become useful when she becomes caching.  And, yes,
MaraDNS does warn the admin whenever she sees this kind of construct.

- Sam

---

From: Robert Elz <[email-masked]>
Date: Mon, 23 Apr 2001 15:01:18 +0700

Date:        Sun, 22 Apr 2001 19:07:11 +0200
    From:        Havard Eidnes <[email-masked]>
    Message-ID:  <[email-masked]>

  | Isn't this in some sense putting the cart before the horse?

Yes.   But sometimes you just have to go backwards.

  | I mean, the actual problem is being able to track down where glue
  | records are being maintained.  If folks only maintained "required"
  | glue records, it would be a simple matter of tracing the zone path
  | from the name of the name server itself to the root of the DNS
  | hierarchy and update any glue records there, and that is, IMHO, as
  | easy as this ought to be.

Absolutely - though even there, you have to get that glue updated even
when it is maintained correctly, and no matter how hard you try, with
the exception of the cases where you are also your own parent (ie: the
same person runs both zones) you can't get the glue updated as quickly,
nor with all the procedures, as you can the data in your own zone file.

Do you really think that the com zone file is going to lower the TTL on
the glue A records for you on request, and lower the refresh time in the
COM SOA, and go through all the rigmarole needed to really achieve a
clean (brief) transition of the A records?   And they're going to do all of
that for all of the millions of delegations they're running?

Somehow I think not - using a different name for the NS record simply
makes more sense, even for the tiny setups that Randy mentioned.   It
certainly isn't required, and some of those may not care about a few days
outage when they renumber things (they probably get more than that quite
regularly due to ISP problems anyway).   But the best advice, from an
operational standpoint, is certainly "don't do that".

kre