The Role of Wildcards in the Domain Name System
draft-ietf-dnsext-wcard-clarify-11
Yes
(Margaret Cullen)
No Objection
(Alex Zinin)
(Allison Mankin)
(Bill Fenner)
(Russ Housley)
(Scott Hollenbeck)
(Ted Hardie)
Note: This ballot was opened for revision 11 and is now closed.
Margaret Cullen Former IESG member
Yes
Yes
()
Alex Zinin Former IESG member
No Objection
No Objection
()
Allison Mankin Former IESG member
No Objection
No Objection
()
Bert Wijnen Former IESG member
No Objection
No Objection
(2006-02-01)
In the example on page 8, I See: host1.example. 3600 A 192.0.4.1 The IP address probably better be in the range reserved for examples (as per RFC3330), nameley something like 192.0.2.1
Bill Fenner Former IESG member
No Objection
No Objection
()
Brian Carpenter Former IESG member
No Objection
No Objection
(2006-01-27)
Non-blocking comment from Gen-ART review by Harald Alvestrand. This could be considered if the draft is revised for some other reason: There is a slight logical inconsistency between section 4.2, which says it can't forbid NS records at a wildcard name because it's not clear what "forbidding" a record in the DNS is, and section 4.4, which (justifiably) says that DNAME records at wildcards shold be outlawed, without going into the same details found troublesome in section 4.2.1. But I believe the recommendations are operationally reasonable, and that's the most important thing to me.
David Kessens Former IESG member
No Objection
No Objection
(2006-02-02)
I was very close to putting a DISCUSS on this document after my own review, the comments that I read by other ADs and the reviews that I received from Pekka Savola frm the Ops Directorate. I don't believe any of the issues that are brought up are blocking from an indvidual point of view, but the collection of issues is large enough that I would very much appreciate an update to this document before sending it to the rfc editor although I will not require it. Please see below for the comments that I received from Pekka Savola from the Ops Directorate: This seems to be in an OK shape, though personally I'd probably have organized it in a slightly more different way. But there is one thing I don't understand from the closest encloser spec and example. Maybe someone (Rob?) can explain whether the closest encloser definition is lacking or I'm just not getting something? section 3.3.1 says: The closest encloser is, by definition, an existing name in the zone. The closest encloser might be an empty non-terminal or even be a wild card domain name itself. In no circumstances is the closest encloser to be used to synthesize records for the current query. .. section 2.2.1 has, host1.example. 3600 A 192.0.4.1 _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> .. and section 3.3.2 says: QNAME Closest Encloser Source of Synthesis host3.example. example. *.example. _telnet._tcp.host1.example. _tcp.host1.example. no source _telnet._tcp.host2.example. host2.example. no source _telnet._tcp.host3.example. example. *.example. ... ==> I don't understand why the closest encloser of '_telnet._tcp.host2.example.', using the definition above, is not _tcp.host2.example.com. -- the definition says that it can be an empty non-terminal which '_tcp.host2.example.com.' as well as 'host2.example.com.' seem to be unless I'm mistaken. Did I miss something? If not, should the definition of the closest encloser be more restricted (if the example is correct), or the example changed? mostly editorial comments ------------------------- .................. ==> the ID-nits tool says: * There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ==> multiple times, you use both 'wild card' and 'wildcard'. If there is no specific reason for this, I'd pick one and apply it consistently. of wild card domain names, but the restriciton as stated still ==> s/restriciton/restriction/ host1.example. 3600 A 192.0.4.1 ==> s/192.0.4.1/192.0.2.1/ (so it's a valid RFC3330 address..) The domain name space is a tree structure. Nodes in the tree either own at least one RRSet and/or have descendants that collectively own at least one RRSet. A node may exist with no RRSets only if it has descendents that do, this node is an empty non-terminal. ==> the last sentence might read better with slight rewording after ',' or replacing "," with a ";". Comments on this document can be sent to the editor or the mailing list for the DNSEXT WG, namedroppers@ops.ietf.org. ==> remove? This probably won't be relevant 10 years from now, and I don't think this kind of info has typically been put in RFCs (though it has been recommended for I-D's) E.g., If an SRV record is: _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. *.example is a wild card domain name and although it is the Name of the SRV RR, it is not the owner (domain name). The owner domain name is "_foo._udp.*.example." which is not a wild card domain name. ==> it might be useful to actually spell out what the answer would be for a query such as '_foo.udp_.bar.example. SRV' -- you're not saying it right out. 9. Others Contributing to the Document This document represents the work of a large working group. The editor merely recorded the collective wisdom of the working group. ==> is this an 'Acknowledgements' or a 'Contributors' section? In any case, both courtesy and legalese *) IMHO call for a bit more explicit list of contributors and/or acknowledgees. *) RFC3978 says: 3.4. Representations and Warranties With respect to each Contribution, each Contributor represents that to the best of his or her knowledge and ability: a. The Contribution properly acknowledges all major Contributors. A major Contributor is any person who has materially or substantially contributed to the IETF Contribution.
Russ Housley Former IESG member
No Objection
No Objection
()
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Ted Hardie Former IESG member
No Objection
No Objection
()