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
Attachment:
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf