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