Subject: Re: Impending publication: draft-iab-dns-choices-05

From: Patrik Fältström <[email-masked]>
Date: Wed, 5 Mar 2008 22:09:03 +0100

As editor of thie IAB document, I have here collected the comments  
that have come so far. If I have missed some, please let me know. I  
will discuss these with the IAB.

[A] It might be helpful to discuss the use of the Hesiod class at MIT  
in the past.

[B] There is a typo on the front page of version -05, it says  
"standards track".

[C] Explain more why so many people have used TXT records.

[D] "fighting spam" is not a correct summary

[E] It is not explained what "splitting an RRSet" implies when it is  
stated that it is a protocol violation

[F] Clarification (due to a reference): Do you plan to publish draft- 
iab-dns-choices-05 before 2929bis?

[G] The tone of the paper reflects very badly on the IAB and that it  
is not appropriate to second guess or assume the mental processes of  
designers.

[H] draft-hallambaker-xptr-00.txt(*) should be referenced.

[I] Objection: RRs are a finite resource, the mechanism does not scale.

[J] Objection: Legacy infrastructure support is a real concern

[K] Objection: Wildcard support is not a major concern

[L] Objection: Wildcard support in legacy DNS is no less  
unsatisfactory under the proposed approach

[M] Explain for example the design thinking that took place in the  
DKIM wg (that lead to use TXT records)

[N] The following is unclear: "This implies that some other selection  
mechanism has to be applied as well..."

[O] Change "This Resource Record Type can either be a..." in section  
3.3 in a similar way as in section 3.2

[P] Change text around "kitchen sink record" in a way similar to [O].

[Q] Change sentence "The reason for this is that there is nothing to  
prevent collisions..." in section 5.

[R] Sentence "that would probably need to be upgraded in any case as  
part of supporting a new application" is confusing.

[S] Make more clear (specifically in section 6) when one talk about  
DNS software (as in DNS servers etc) and applications that originates  
the DNS queries. Example around "deployed DNS software today should  
support DNSSEC"

[T] Argument "...but most such software is old enough and insecure  
enough that it should be updated for other reasons in any case..." is  
not clear.

On top of this there are some pure editorial suggestions.

    Patrik

(*) http://quimby.gnus.org/internet-drafts/draft-hallambaker-xptr-00.txt

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Mar 2008 14:24:06 -0800

>[C] Explain more why so many people have used TXT records.

This could be expanded on by giving deployment experience with IETF 
standards that use TXT records, such as DKIM, RFC 4871. There is over 
a dozen implementers of various types who have implemented and 
deployed it, and they can certainly talk about deploying the DKIM TXT 
records and limitations that they encountered (if any).

--Paul Hoffman, Director
--VPN Consortium

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 6 Mar 2008 06:03:17 -0800

I have changed the subject line to reflect the fact that the IAB chair informs me that this is in fact a consultation period and not as was indicated in the original subject line a report of a decision already taken.

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. 

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.

This is not a small objection as the entire argument for using a new RR rather than overloading SRV, TXT or NAPTR is that midcard wildcards do not work. The paper wrongly concludes that creating new RRs is the only alternative to the 'tree searching' approaches that are potentially damaging to the core DNS infrastructure.

[V] Even if the legacy DNS infrastructure becomes 100% capable of transmitting new RRs it will still be necessary for DNS administrators to update their server software to create new RRs. This is likely a good business model for the providers of standalone DNS servers but hardly practical for a platform vendor that issues new server platform upgrades in a 5 year deployment cycle. The proposed fixes for this problem are not applicable to providers of GUI based interfaces.

The reason that I have let the XPTR draft expire is that I am waiting for the registration process for new RRs to be published. Before letting the draft expire I checked the status of choices and noted that it had been expired for 8 months and its author was no longer on the IAB. The minutes of the IAB meetings did not indicate that it was still a live issue so I and others assumed it to be withdrawn.

Providing protocol designers with a viable architectural approach that avoids the need to do tree walking is a very useful and important thing for the IAB. Choices does not describe a viable approach.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Patrik Fältström
Sent: Wednesday, March 05, 2008 4:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Impending publication: draft-iab-dns-choices-05 

As editor of thie IAB document, I have here collected the comments that have come so far. If I have missed some, please let me know. I will discuss these with the IAB.

[A] It might be helpful to discuss the use of the Hesiod class at MIT in the past.

[B] There is a typo on the front page of version -05, it says "standards track".

[E] It is not explained what "splitting an RRSet" implies when it is stated that it is a protocol violation

[G] The tone of the paper reflects very badly on the IAB and that it is not appropriate to second guess or assume the mental processes of designers.

[L] Objection: Wildcard support in legacy DNS is no less unsatisfactory under the proposed approach

[M] Explain for example the design thinking that took place in the DKIM wg (that lead to use TXT records)

[N] The following is unclear: "This implies that some other selection mechanism has to be applied as well..."

[Q] Change sentence "The reason for this is that there is nothing to prevent collisions..." in section 5.

[R] Sentence "that would probably need to be upgraded in any case as part of supporting a new application" is confusing.

[S] Make more clear (specifically in section 6) when one talk about DNS software (as in DNS servers etc) and applications that originates the DNS queries. Example around "deployed DNS software today should support DNSSEC"

[T] Argument "...but most such software is old enough and insecure enough that it should be updated for other reasons in any case..." is not clear.

    Patrik

---

From: Olaf Kolkman <[email-masked]>
Date: Sat, 8 Mar 2008 18:28:22 -0500

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.
>
> 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

---

From: Olaf Kolkman <[email-masked]>
Date: Sat, 8 Mar 2008 18:34:18 -0500

A minute ago I wrote:

> I think that the DNSEXT working group is a better place to discuss  
> the proposal and I've CC-ed them on this note.

I used the wrong address in the CC line. Be aware of that if you want  
to continue the discussion on DNSEXT: [email-masked] is the  
proper address of that WG.

--Olaf