Since this looks like the beginning of a new thread on this discussion, it's only fair the Subject: header gets changed.... 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?
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. :-(
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?
4) Multiple name per address is one of those topics that gets bashed back and forth. At times we find it distasteful to have multiple PTR records in a set, for instance, this makes traceroutes and logs list potentially "wrong" names. Other times we are reminded that it is perfectly natural to allow more than one PTR record in a set. Maybe this is a "it's good for servers but not good for routers" situation.
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?
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.
Nevertheless, what I've debated above doesn't seem to be the point of the document. It seems the document is presenting discomfort with the response.
I'm not sure that's right either. I read Olivier's document as an abridged history of what happened and where things stand today. People are of course welcome to interpret that document in whatever way best suits their standpoint. The questions about transparency and process at IANA remain unanswered though Doug has promised to respond to them. It looks like these questions won't go away until they are answered. IMO, it would be better to see them answered here instead of in a more formal setting such as an ICANN meeting.