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