Jim Reid wrote:
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
well, I do understand "better label copmpression" but I don't understand "streamlined names". What's the real benefit of those?
there's an increased likelihood of not getting all the glue in a referral response with that approach. Or have I missed something? I
It comes back to the question for what reason the ROOT applies a wide glue policy as opposed to a narrow one which many TLDs do.
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?
We know that multiple PTRs are protocolly correct but don't work well in practice, i.e. they give intermittent results. That's also about consistency and setting examples.
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
"prettier"? Name servers are objects in the DNS which are pointed at due to their special function. Just using their names as "aliases" to some address misses the point. Why not get rid of these domain names in the NS RDATA and point to IP addresses directly (sounds familiar, eh)?
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?
All "glue" is equal, but some "glue" is more equal than other. And yes, it's additional info, not "glue".
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?
There might be actual operators to confuse.
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
So, why would all this new wisdom only apply to TLDs? -Peter