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


To: Havard Eidnes <he@runit.no>
cc: dufberg@nic-se.se, namedroppers@artemas.reachin.com, dnsop@cafax.se
From: Robert Elz <kre@munnari.OZ.AU>
Date: Mon, 23 Apr 2001 15:01:18 +0700
In-reply-to: Your message of "Sun, 22 Apr 2001 19:07:11 +0200." <20010422190711H.he@runit.no>
Sender: owner-dnsop@cafax.se
Subject: Re: Tips for DNS zone administration

    Date:        Sun, 22 Apr 2001 19:07:11 +0200
    From:        Havard Eidnes <he@runit.no>
    Message-ID:  <20010422190711H.he@runit.no>

  | 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


Home | Date list | Subject list