[Top] [All Lists]

Re: LAST CALL on: draft-iab-dns-choices-05

2008-03-06 07:05:00
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.*' 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:

*                    PTR   TXT     "Text"   SRV     blah...   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 

[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 

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: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Patrik Fältström
Sent: Wednesday, March 05, 2008 4:09 PM
To: ietf(_at_)ietf(_dot_)org
Cc: iab(_at_)iab(_dot_)org
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 

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



IETF mailing list
IETF mailing list