Re: Should a nameserver know about itself?

[Robert Elz <[e-mail]>]

    Date:        Thu, 31 May 2001 12:29:09 +0200 (CEST)
    From:        Shane Kerr <[e-mail]>
    Message-ID:  <[e-mail]>

  | But I suspect this is exactly what Bruce is suggesting!

My impression was that Bruce was imagining something different than what
is actually being suggested here.

  | Looking at the in-addr.new file from ARIN reveals that there are less
  | than 25000 unique servers, a nearly trivial number of lookups to perform
  | to get glue information.

If that's possible, then great - to make this work rationally with a
"classic BIND" all that's needed is to allow the server to handle recursive
queries when they come from magic box A (equipment run by the RIR), and
then have A issue queries for all of those 25000 server names, directed
at (all of the) relevant in-addr.arpa servers, and then from the answers it
gets, repeat the queries as soon as the TTLs have expired (any sooner
than that and the server will just answer from its cache, that isn't of
benefit to anyone).   That will prime the cache of the servers with all
of the glue records, and BIND will then return those as additional info
with the NS records.

That's fine, fairly easy, and is likely to be of some benefit.

But it has nothing at all to do with whether the registry will enter
necessary glue information when it is required - that glue must be manually
entered into the zone file - by definition, it is required only if there's
no way to obtain it using normal DNS methods, ie: you hit a circular
dependency, you can't get the A record for X without first finding the A
record for X...

  | A scan by each RIR, perhaps based on one of the TTL values in the SOA
  | record with a reasonable minimum refresh time (wouldn't want to query
  | NEC.COM every 2 hours, for instance) could probably achieve the goal of
  | inserting glue records, although not in the way that the
  | ns.x.y.z.in-addr.arpa A record fans want.  :)

Exactly (without counting myself as a fan of that scheme...).   The two
things are totally unrelated.

  | This would also have the side benefit of being a nice reference for
  | broken delegations, in case the Internet community wanted to pursue
  | more proactive means of improving in-addr.arpa delegation.

This is a long way from achieving that (it would find only the comparatively
few cases where a totally bogus name is listed as an NS).   To do more
than that, which I think would be valuable, would require going out to
actually query all of those servers for all of the delegated domains that
they're supposed to handle, and see if they're reporting sane answers or
not.  But that is a totally different discussion.

  | This is probably so for a large number of cases, but not true for ISP's
  | that have lots of disjoint IP space.

I have no idea at all how that ever became relevant to anything.   The
issue here relates to a single delegation, and how the RIRs handle that
request.

Whether it makes sense for an ISP to actually use this method to arrange
the delegation for 10000 in-addr.arpa domains that they handle is another
question entirely.  (Personally I don't think so, but that's a question
for each ISP to answer for itself).

The question isn't whether this is a sane way to delegate things, but that
given it is a legal way, why is it not being supported by the registries?

It is somewhat ironic that the in-addr.arpa registries won't insert glue
when it is needed, and the COM (etc) registries (or maybe it is the root)
insist on inserting glue when it isn't...

  | There is also the issue of educating administrators on this methodology,

There is no need.   No-one is proposing requiring anything like this
(I hope).   If people don't understand it, then they won't use it, and
that will harm no-one (IMO).

The only issue here is whether it is possible, not whether it should be
advocated.   Or at least, that's the only one worth discussing.

kre