[linux-elitists] a lame query
Seth David Schoen
Thu Aug 10 21:32:38 PDT 2000
Rick Moen writes:
> begin Seth David Schoen quotation:
> > I think those host records are used to produce glue records in the
> > root zone.
> Interesting. But:
> I may be missing something, but it seems to me that those DNS-host
> FQDNs remain a basically superfluous level of indirection, even in the
> records you cited. This line:
> > linuxmafia.com. 2D IN NS NS1.linuxmafia.com.
> ...could just as easily have directly cited 22.214.171.124, instead of
> necessitating this line:
> > NS1.linuxmafia.com. 2D IN A 126.96.36.199
> ...to derive the IP, which is what you need to reach a nameserver.
OK, so one issue is why we delegate by name instead of by IP address.
This is presumably so that name server administrators can move their
name servers around easily, without needing the help of their
For instance, when Nick moved zork.net, and changed the DNS entries
for ns.zork.net, I didn't need to change the NS records which I had
made pointing to zork.net. This is actually true both of authority NS
records and of delegations.
If I had used an IP address, I would have had to make more changes to
my zones which said "foo IN NS zork.net." when zork's address changed.
So, although that indirection is redundant, it seems it could be
useful in some cases, which must be why it's common.
The other issue is the use of glue records by the root zone.
In principle, the root zone would only have to contain an extremely
tiny number of A records for non-root name servers. It needs A
records as glue for name servers whose canonical names are within
domains for which those name servers are themselves authoritative;
_DNS and BIND_, 3rd ed., p. 211. It also needs some A records in
order to provide a base case for cycles like
myfriend.com. IN NS ns.niceguy.net.
niceguy.net. IN NS foo.myfriend.com.
(Those cycles might contain many elements; maybe I do DNS for Nick,
Nick does DNS for you, and you do DNS for me, or something.)
In order to allow actual queries to happen, we need an A record
somewhere. (If the root servers have an A record for ns.niceguy.net,
then they can return it, and then ns.niceguy.net can be queried for
the address of foo.myfriend.com.)
No doubt in order to simply root zone administration and avoid some
"buck-passing" arguments ("You register a glue record with the
InterNIC!" "No, _you_ register a glue record with the InterNIC!"),
NSI has had the habit of maintaining a glue record for _every_ server
which receives a delegation from the root zone -- since the creation
of gtld-servers.net, a glue record for every server which receives a
delegation from a GTLD zone.
We can certainly prove that many of those glue records are
superfluous, although, when they are kept up to date, they make the
DNS work faster and more reliably. (If all of the superfluous glue
records were purged from GTLD zones, then some queries for information
within a second-level domain might require 8 or 10 or 20 preliminary
queries just to locate an authoritative name server's IP address!)
You noticed the exact same problem I did, though: NSI makes it really
hard to keep those records current!
> That is the aforementioned host record, associated with my nameserver's
> current IP. I believe NetSol still retains a fux0red-up, automatically
> generated host record for its former IP, 188.8.131.52, over which
> NetSol mistakenly assigned to Don Marti, rather than me, causing me all
> sorts of grief.
> In fact, because of this NetSol system, any IP with an associated host
> record becomes effectively a damaged IP address, because it effectively
> cannot be cited for new DNS service under a new admin's authority until
> the existing host record gets deleted (in order for a new host record
> to be permitted).
Exactly! I have been having the same problem for a year and a half
with ISHMA-HST (ishmael.geecs.org, formerly 184.108.40.206). NSI's
facilities for deleting obsolete host records or changing host
records' IP addresses are _badly_ broken, and make all kinds of dumb
So it's really hard to keep that information current, and the
consequences of not keeping it current are very painful.
> The first line you cite (above) could have been less baroquely
> linuxmafia.com. 2D IN NS 220.127.116.11
> ...eliminating the need for the second one you cited. In fact, I
> believe that that's what _used_ to be done, though I can't claim to have
> reconstructed the details.
I think NS records pointed at names rather than addresses have been
around as long as DNS itself, but I don't want to look through RFCs (I
want to give my wrists a break). The Linux DNS documentation from the
LDP, the BIND documentation, and _DNS and BIND_ (at least 2nd and 3rd
eds., probably 1st ed., which I've never seen) use host names as NS
Seth David Schoen <firstname.lastname@example.org> | And do not say, I will study when I
Temp. http://www.loyalty.org/~schoen/ | have leisure; for perhaps you will
down: http://www.loyalty.org/ (CAF) | not have leisure. -- Pirke Avot 2:5
More information about the linux-elitists