The Role of Wildcards in the Domain Name System
draft-ietf-dnsext-wcard-clarify-11
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
(Margaret Cullen; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Allison Mankin; former steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
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 steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
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 steering group member) No Objection
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 steering group member) No Objection
(Scott Hollenbeck; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection