There are quite a few message to respond in the thread, I'll stick to questions indicating that my comments need clarification... At 0:45 +0100 6/7/05, Jim Reid wrote:
On Jun 6, 2005, at 22:00, Edward Lewis wrote:
What I find interesting is the trade-off of:
The gain in packet compression by using similar names plus the operational advantage of streamlining the names
vs
The gain by spreading name server names under other TLDs plus the logging convenience of only needing one PTR record per address
Ed, I'm not sure I understand the second part of your trade-off. The benefits of better label compression and streamlined names seem clear enough. Spreading name server names under other TLDs appears unwise: there's an increased likelihood of not getting all the glue in a referral response with that approach. Or have I missed something? I note Neustar doesn't spread the TLD NS RRsets for .biz and .us like that. :-) And as for reverse lookups, I doubt anybody or anything cares about what name (singular) should be returned for the address of some TLD server. The operator of that server will care of course, but why would anyone or anything else even need to care?
Let's say my TLD is "tld", that my two options for name server sets are {a.nic.tld, b.nic.tld} and {a.nic.example, b.nic.tld}, and the query is for "www.jim.tld A". With option 1, if the query goes to the root and the iterative resolver is BIND, the queries for the addresses of a.nic.tld and b.nic.tld will follow. If there is a problem with the tld zone, and perhaps the glue at the root isn't completely right, we will have problems. With option 2, a problem with the tld zone isn't an issue if the copy of the zone on a.nic.example is in good enough condition. In summary, by using a different TLD, there's one more place to get the address of a name server. It could be that the fault that makes this a true advantage has almost no chance of happening in isolation. My supposition that spreading name servers among domains is based on watching how BIND does its resolution (via packet sniffing). I don't have access to other (popular) implementations to see how they go about their business. As you descend the tree, it's clearer than spreading name servers among domains (even different tlds) has a benefit. Because there are more moving parts as you descend the tree, there's more chance something goes wrong, so you want to build in resiliency. I can see that in the case of TLDs, there really aren't many options in case of a some failures. And, as far as what I call glue space savings isn't seen in the root zone as all name servers are in the root domain. Given that BIND chases the authoritative version of the glue it receives, and that there are a lot of BIND name servers (if not a majority), I think there's a gain in spreading the name servers over different TLDs. NeuStar's name servers are all in the same TLD. Internally, well, we just haven't seen a justification for trying "something new." It's like this, it works as is, its an industry norm, and tinkering with operational systems should not be taken lightly. I'd say that I have a hunch that there is a gain to mixing name servers over TLDs, and this is based on my thoughts about how enterprises should think. Hunches are not always right. (Recall I'm writing as an individual, not a company representative.) As far as reverse lookups - I think there are a lot of folks who do care. I've seen the issue more with routing discussions, traceroute is often cited as a tool that cares what it sees in the PTR record. Security analysis too - they rely on logging data.
1) Compression to insert more name servers or more glue records into a response is an advantage that I think is becoming outdated.
With EDNS0 out there, I tend to agree. But there are lots of name servers deployed that don't and won't support EDNS0. And even if EDNS0 was ubiquitous, I'd prefer to see NS RRsets use a clean set of target names. It's prettier. And it reduces the protocol overheads: fewer CPU cycles encoding/decoding DNS packets as well as saving precious bytes we're going to need for DNSSEC RRtypes. :-) Even with EDNS0. :-(
I wasn't even considering EDNS0. I was thinking anycast. EDNS0 is good, but some non-DNS security devices still don't understand it. That needs fixing, and is out of scope for the thread and wg. I don't see how CPU cycles are reduced by using "a clean set" of names. A label pointer reference is the same, regardless of where it goes.
3) I would think that having servers listed under other TLDs (as we are looking at a ccTLD here) would be a good thing. Just for the fact that we are spreading the servers about (in DNS, not just topology). In addition, these servers don't count against the glue space hit in the response.
Could you please expand on this Ed? There are things I simply do not understand here. What's gained by spreading the hostnames for 8 (say) name servers for some TLD across .tld0, .tld1, ... .tld7? And how does the extra space needed for these names not "count against the glue space hit" in a referral?
Going back to my fictional tld above and the two options, here is what the root can minimally send back: option 1 answer: authority: tld NS a.nic.tld tld NS b.nic.tld additional: a.nic.tld A 1.1.1.1 b.nic.tld AAAA ::1 option 2 answer: authority: tld NS a.nic.example tld NS b.nic.tld additional: b.nic.tld AAAA ::1 The reason I say these are minimal is that any query for the records in the additional section would wind up with the same answer. In option 2, the next query to the root would be for "a.nic.example A" (and AAAA) from a BIND resolver. The response to that would be a referral to the example TLD servers. In option 2, the out-of-baliwick server does not count the needed glue. Of course, in reality, the root server is probably responding with it, as the server is under the root domain. Perhaps I am seeing a gain that is possible, but is not realized in practice because of the tools we are using and are used to.
Hmm. Nobody mentioned PTR records in this discussion. I'm struggling to see how this matters. Is there a name server implementation that does reverse lookups of the IP addresses in a referral, compares them with the hostnames in the NS RRset and gets upset if there's a mismatch?
I thought that the main problem was that IANA wasn't permitting multiple hosts to point to one IP address. Back in prehistoric times, this restriction was also in place in .com and .net. I ran into this - and the technical glitch that caused the restriction was that the registry software couldn't support multiple PTRs in a set. My supposition was that this might have been the cause of concern with IANA - I can't imagine any other reason to be concerned. Besides (potentially) faulty registry software, the main reason why multiple PTR records in a set are denigrated by some is that application software generally assumes a host has only one name. (I think multiple PTRs are fine, I'm just relating the arguments levied against them.) My experience with one dynamically updating DHCP server would treat the forward and reverse differently. When it created a lease with a vanity name, it would add the vanity name to the forward, supplementing what was already there. When updating the reverse, it deleted all previous records and out in the PTR with the vanity name. This is an application problem, not a DNS one. The only time that the reverse of a name server has ever been called out is in some DNS checking packages. I don't know why it's an issue, but DNS set ups were graded on that.
The part of the trade-off I haven't addressed is:
The gain by using unique name server names for each delegation
vs
The need for extra IP addresses in light of a one name per address policy
This confuses me too Ed. AFAICT there is no one name per address policy. Even if this was the case for TLD delegations, we'd still only be talking about wasting around 4000 IPv4 addresses, assuming each TLD has around 20 NS records. There are plenty of far more blatant examples of wasteful usage of IPv4 address space: the /8s that Stanford and MIT have for instance.
During the RIPE NCC presentation in the WG at RIPE 50, I thought the criticism was that the slave server names using unique addresses was considered wasteful and ironic that an RIR was doing this. I thought that this was proposed in response to the "problems" with IANA as described in the draft. It could be that my wires are crossed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.