To:
Shane Kerr <shane@ripe.net>
cc:
dnsop@cafax.se
From:
Robert Elz <kre@munnari.OZ.AU>
Date:
Thu, 31 May 2001 19:41:29 +0700
In-Reply-To:
<Pine.BSI.4.05L.10105311148580.26280-100000@x17.ripe.net>
Sender:
owner-dnsop@cafax.se
Subject:
Re: Should a nameserver know about itself?
Date: Thu, 31 May 2001 12:29:09 +0200 (CEST) From: Shane Kerr <shane@ripe.net> Message-ID: <Pine.BSI.4.05L.10105311148580.26280-100000@x17.ripe.net> | 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