Fwd: Impending publication: draft-iab-dns-choices-05

[Olaf Kolkman <[e-mail]>]

I wrote that I CC-ed the message to DNSEXT and used the wrong address.
Here is a forward.


Begin forwarded message:

> From: Olaf Kolkman <[e-mail]>
> Date: March 8, 2008 6:28:22 PM EST
> To: Phillip Hallam-Baker <[e-mail]>
> Cc: Patrik Fältström <[e-mail]>, IETF-Discussion Discussion  
> <[e-mail]>, "[e-mail] IAB" <[e-mail]>, [e-mail]
> Subject: RE: Impending publication: draft-iab-dns-choices-05
>
>
> Dear Philip,
>
> You referred to draft-hallambaker-xptr-00.txt and wrote:
>
>> The list of comments does not include my core objection made in the  
>> 'Domain Centric Administration' and XPTR drafts, that it is in fact  
>> possible to create 'midpoint' wildcards of the form  
>> '_prefix.*.example.com' by the simple measure of introducing a  
>> layer of indirection. This may be implemented by defining semantics  
>> for the existing PTR record in the forward DNS or by introducing  
>> one new RR to deal with the issue as is suggested in XPTR.
>>
>> [U] If you want to construct this wildcard you may use:
>>
>> *.example.com                    PTR  _wildcard.example.com
>> _prefix1._wildcard.example.com   TXT     "Text"
>> _prefix2._wildcard.example.com   SRV     blah...
>> _prefix3._wildcard.example.com   NAPTR   blah...
>>
>> The search strategy is then quite simple, if a search for the  
>> record itself returns no answer you look for the PTR record at the  
>> node to be queried, if that exists you concatenate the prefix to  
>> the result of the PTR indirection and do a lookup there.
>>
>
> This strategy is one that may work. I'd argue that defining an XPTR  
> RR is probably cleaner than the re-use of a pointer record because  
> the semantics of PTR might be hardcoded somewhere outside of your  
> control.
>
> An observation of more fundamental nature is that you are moving  
> away from a query-response model to a search strategy. And the first  
> tradeoff you make there is one of performance and load on the system  
> as a whole. It is easy to argue that the DNS can deal with the extra  
> load, but I note that your proposed  strategy involves an extra  
> query _every_ time that you do not get a response to a query to the  
> direct name. Obviously not a problem during the onset of the  
> deployment (your proposal has the nice property of incremental  
> deployment) but if the approach gets ubiquitous then we have pushed  
> significant costs to the system as a whole. I am of the opinion that  
> taking NO (NXDOMAIN) for an answer is, IMHO, an important property  
> of the scalability of the DNS and we need to think very deep about  
> the consequences of these extra queries.
>
>
>> The strategy always completes in two or three lookups, there is  
>> never a requirement to do tree climbing. A DNS server can  
>> efficiently predict the optimum responses to send as additional  
>> records. It is fully compatible with other DNS extensions.
>
> The above paragraph suggests a strategy to deal with the performance  
> issue. Note however that this means that your proposal relies on  
> special processing that will will need to be implemented in  
> authoritative and recursive nameservers. That makes this performance  
> optimization is subject to the same arguments you use to counter the  
> arguments that one cannot rely on the ubiquitous support for unknown  
> resource records. Also there are reasons not to rely on the results  
> provided in the additional sections (in absence of DNSSEC).
>
> There have been proposals to do some sort of pre-processing to  
> generate the nodes that should match _bla._foo.*.example.com. Such  
> proposals will not be able to generate each an every combination for  
> the wild-card but that may be sufficient for the use cases at hand.
>
> All and all, I am not convinced if your proposal is _the_ solution  
> to the wildcard problems at hand. My main problem with it is the  
> "extra query after an NXDOMAIN". I think that the DNSEXT working  
> group is a better place to discuss the proposal and I've CC-ed them  
> on this note.
>
> Having said all this, I do agree with your point that the "RR-type"  
> space is not infinite. The question if that is a problem can only be  
> answered by the Crystal Ball of the proper brand.  I think it would  
> be fair to suggest some text to deal with that issue.
>
> Also, although I know I'm biased, and can blame English to be my  
> second language, I have always read the dns-choices document as a  
> series of considerations and trade-offs. If you could point out the  
> fragments of text that come across as  degrading that would help the  
> editor. In that context the request to "send text" is fair.
>
> In the spirit of the send-text and the above discussion I would  
> suggest text along the following line:
>
>
> Somewhere around the section where the wildcard arguments are made:
>
> --
> There have been proposals to deal with the problem that DNS wild- 
> cards are always terminal records. These proposals introduce an  
> additional set of trade-offs that would need to be taken into  
> account when assessing which extension mechanism to choose. Aspects  
> of extra response time needed to perform the extra queries, costs of  
> pre-calculation of possible answers, or the costs induced to the  
> system as a whole come to mind. At the time of writing none of these  
> proposals has been published as standards tracks RFCs.
> --
>
> And we probably need to mention explicitly that the RRTYPE code  
> space is finite. I think that somewhere in section 5 we can add a  
> paragraph along the following lines:
>
> --
> There is a drawback to defining new RR types that is worth  
> mentioning. The RRTYPE is a 16 bit value and hence a a limited  
> resource. In order to prevent herding the registry has a review  
> based allocation policy [RFC2929bis], however this may not be  
> sufficient if extension of the DNS by addition of new RR types takes  
> up significantly and the registry starts nearing completion. In that  
> case the trade-offs with respect to choosing an extension mechanism  
> may need to change.
> --
>
>
> To the last paragraph one could add a suggestion for a future IAB to  
> review the trade-offs when the allocation rate suggests completion  
> of the registry in a decade.
>
>
> Kind regards, without hats,
>
> --Olaf
>