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

[Olaf Kolkman <[e-mail]>]

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

_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf