[dns-wg] TLD delegation trade-offs

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.