At 10:20 +0200 6/7/05, Mohsen Souissi wrote:
years. Btw I don't think this technique is "outdated" today as Ed said since the alternative he mentioned (Anycast) is not widely deployed yet by TLDs (only a few TLDs are anycast today and still some political and technical issues to be solved... Just think for instance at IPv6 allocation policy which does't allow yet TLDs in the RIPE region to get an "unfiltered" block... Yes I know, a new proposal is underway to be adopted by the RIPE address-policy wg...). IMHO, the name compression popularity relies on two facts today:
I would say the concerns are outdated as far as protocol considerations, but I do agree that there are some bureaucratic road blocks that it still helps you get around. My answer to that though is to remove the bureaucratic road blocks.
- it addresses and mitigates new technical issues which didn't use to occurr frequently a decade ago, such as riskk of glue dropping due to new "greedy" RRs such as AAAA or DNSSEC-related RRs. So compression may save a large amount of bytes which may be transformed in a new NS deployment (icluding its A/AAAA glues);
One AAAA record, with a compressed owner name would need, what 12+128/8=28 bytes. If all of the nameservers were named [a-f].nic.fr, then you would need to compress 4 name servers names for each additional AAAA record you could squeeze in. (That's 4 label compressions saving the "nic.fr." portion.) An RRSIG is, for .fr as signer name, going to need 12+22+1024/8 (assuming RSA 1024). That's about 40 name compressions needed. Now, I suppose that the savings calculation I am presenting isn't completely accurate and am willing to go back and do a more realistic calculation for a particular TLD and proposed naming system to see if the numbers are right. The point I am trying to make is that name compression savings pale in comparison to the size of the records we are looking to add. (Note, for DNSSEC, EDNS0 is required...further muddying the debate.)
- TLDs which are not yet deploying DNS anycast are endeavouring to get a suitable level of redundancy and load distribution among their deployed NS's. As the number of deployed NS's grows, it becomes very practical and interesting to have a naming plan easing the readability and consequently the operation of name service...
I'll yield to the point that (learning) anycast is a challenge in operations. But in the long run, it will be more powerful than trying to shave bytes here and there.
Hence, it is seen by a number of TLDs today that name compression is a good and workable technique, in the absence of a better technique (yet to be easily deployable)...
"Today" yes. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.