Colleagues,
First expanding on something Ed said, then commenting on Dave's draft and then getting back to Bill, all in one thread.
On Jul 18, 2006, at 1:46 AM, Edward Lewis wrote:
This seems to be in conflict with the iab-dns-choices document. One reason I brought up the existence of that document in the meeting in Montreal was situations like this - if the WG wants to recommend "prefixing names" it wouldn't be too wise to have the IAB saying "don't do that" at the same time.
Well... my reading of dns-choices is a bit different. Choices is intended to provide the arguments and considerations to make a trade- off; it does not say "don't do [TXT|underscores|*]", it just states a very strong preference for using new RR types. I think that the editors of that document most clearly pointed that out on page 11 of choices:
Given the various issues described in this note, we believe that:
o there is no magic solution which allows a completely painless
addition of new data to the DNS, but
o on the whole, the best solution is still to use the DNS type
mechanism designed for precisely this purpose, and
o of all the alternate solutions, the "obvious" approach of using
TXT RRs is almost certainly the worst.
This especially for the two reasons outlined above (lack of
semantics
and its implications, and size leading to the need to use TCP).In other words if people choose to use prefix names they should demonstrate (to whoever does the review of their documents) that they considered other options as well and that the use of a prefix does satisfy their needs and architecture best. In that context I think it would be useful for people who write internet-drafts that define use of prefixes or TXT RRs to add a DNS considerations section where they describe their trade-offs.
I think that whoever does the review of documents that 'extend' the DNS should have a very critical look to see if trade-offs have been made and if those trade offs have solid arguments.
Back to the matter at hand: http://tools.ietf.org/html/draft-crocker-dns-attrleaf describes:
Recent additions have defined DNS leaves that contain a reserved leaf node name, beginning with an underscore. The underscore construct is used to define a semantic scope for the name, within which the choiceof valid RRs is limited to a defined set. Hence the underscore construct defines a basic paradigm modification to the DNS. Withinthe scope of a defined underscore leaf, the specific uses of specificresource records can be formally defined and constrained. An established example is the SRV record,[RFC2782] which generalizes concepts long-used for email routing in the MX record.[RFC0974][RFC2821] The use of special DNS names has significant benefits and detriments
Focus on: "The underscore construct is used to define a semantic scope for the name, within which the choice of valid RRs is limited to a defined set."
I think this is the wrong way around (hence including Dave in the CC). I read the text above as: once one has a domain name with an underscored label that name gets a semantic scope and only a limited number of RRs are allowed to be used with that name. I think it is wrong to assign a semantic scope to a label and then restrict the set of RRs and/or assume that other RRs will comply to the same semantic scope.
So I would rather see that turned around: Within the context of specific resource records underscore labels can define a semantic scope. In other words a domain name with an underscored label only has specific semantic scope when used in combination with a RR type for which the semantics are described/defined.
For instance: an underscored label in the owner name of an RRSIG or NSEC record does not have any semantics whatsoever. Another example is the use of TXT RRs as comments.
_sip._tcp.example.com 86400 IN SRV 20 0 5060 backupbox.example.com. _sip._tcp.example.com 86400 IN NSEC foo.example.com SRV NSEC RRSIG *._tcp.example.com 86400 IN TXT "I only care for sip"Here the underscored labels do not have any relevance to the TXT record. Besides the same TXT RR would show up were a dns client to query for a tcp service other than sip.
The use of underscore labels with a particular RR is just convention and the chances of folk not sticking to the convention (and creating interop problems) becomes more problematic when the RR type has a more general use. In other words there are still good reasons to specify new RRs for specific use.
Oops.. I side tracked again...
How to move forward? In a way, it's a question of one registry or two. If draft-crocker-dns-attrleaf intends to have all protocols and services used in SRV records as well as the other contents, it could serve as both. However, given the history, I think SRV records need a little bit different registration rules, so it may make sense to split them out into a different registry. The question there would be whether it's just the top-most prefixed label that gets registered in draft-crocker-dns-attrleaf or all of them.
Could you elaborate on that history and why you think you need different registration rules?
If a registry as proposed by Dave were to be established I would also register for which RRs the particular underscored label has semantic scope. I don't have particular strong feelings but I also think I am missing some background wrt the SRV history.
hatless, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/
PGP.sig
Description: This is a digitally signed message part
