Skip to main content

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 () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection (2006-02-01) Unknown
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 () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2006-01-27) Unknown
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) Unknown
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 () Unknown

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection () Unknown