A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
RFC 4701

Note: This ballot was opened for revision 13 and is now closed.

(Margaret Cullen) Yes

(Brian Carpenter) (was Discuss) No Objection

Comment (2006-03-06)
re draft-ietf-dhc-fqdn-option-11.txt

Comments from Gen-ART review by Harald Alverstrand:

A smaller piece of missing material is this, from section 3.3.1 of the v4 document:

  Clients and servers SHOULD follow the character-set recommendations
  of RFC 1034 [2] and RFC 1035 [3].  However, implementers SHOULD also
  be aware that some client software could be using UTF-8 [10]
  character encoding.  This specification does not require any support
  for UTF-8.

Given DNS experts' insistence that the DNS protocol does not place any limits on character sets, it would be good to have a clearer pointer to what recommendations are intended here.
Given that it's in section 3.3.1 (Deprecated ASCII encoding), one can assume that this refers to a character set recommendation for characters in the ASCII encoding; a DNS encoded name should probably be used "as is", no matter what it contains (although it would be good if the doc said so).

It's also unclear from the text whether or not there's a trailing dot on the name in the deprecated ASCII encoding (there's no need for one, since a non-FQDN name can only be one component, but other fields of use have done this in the past, so it's best to be clear that this field does not do so).


Many lesser comments on the document set at these URLs:

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2005-11-28 for -)
In the introduction to fqdn-option, the document says:

DNS ([2], [3]) maintains (among other things) the information about
   the mapping between hosts' Fully Qualified Domain Names (FQDNs) [8]
   and IP addresses assigned to the hosts.  The information is
   maintained in two types of Resource Records (RRs): A and PTR.

Obviously, there are AAAA records as well.  Since they are being treated
together, an informative pointer from this document to dhcpv6-fqdn seems like
a good idea, especially since the ddns-resolution doc cites consistency among
A, AAAA, and PTR records as one of its issues.

In draft-ietf-dhc-ddns-resolution, the language in 6.3.2 was hard to follow for
the case where a DHC client has multiple interfaces and wishes to associate
AAAA or records containing the same fqdn with the v6 or v4 addresses associated
with those interfaces.

(Sam Hartman) (was Discuss) No Objection

(Scott Hollenbeck) (was Discuss, No Objection) No Objection

Comment (2005-11-29)
draft-ietf-dhc-ddns-resolution: Reserved domains from RFC 2606 might be better than "org.nil" in the examples.

(Russ Housley) (was Discuss) No Objection

(David Kessens) (was Discuss, No Objection) No Objection

Comment (2006-03-16)
I received a few very detailed reviews from the DNS review team. The number of isssues is that large that I believe that a revised ID is warranted. However,
I don't believe that any issue in itself is enough to block this document, there 
are just too many of them that can easily fixed with RFC editor notes or
in 48 hours.

Therefore, my DISCUSS is as follows:


Please consider the reviews form the DNS review team and update the documents where you believe it makes sense. I explicitly am not requiring you to make the 
proposed changes, I only want you to consider them and make the updates where you believe it makes sense.

I actually ran out of space here to include all reviews so I am going to forward them to you seperately. 

I am also willing to clear my DISCUSS with the condition that the shepherding
AD will take this issue up and deal with the revised ID.


I received the following comments from the DNS review team by Roy Arends that you might want to consider:

This is a review of draft-ietf-dnsext-dhcid-rr-12:

 In general, an informative reference needs to be fixed. Terminology             
 and examples need to be fixed, and the input construction for the               
 digest algorithm is not clear.  

Review of draft-ietf-dhc-ddns-resolution-11:                                    
 There is some wording that needs to be fixed, i.e. "update query" and           
 the likes. Some references need to be fixed.

Review of DRAFT-IETF-DHC-FQDN-OPTION-12:                     
 In general, draft-ietf-dhc-dhcpv6-fqdn-04.txt is mostly the same as            
 this document. As I only review this wrt DNS, my comments will                 
 apply to both documents.


Detailed review draft-ietf-dnsext-dhcid-rr-12:

   1.  Terminology                                                              
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",          
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this         
   document are to be interpreted as described in RFC 2119 [2].                 
please put terminology after intro.

   The DHCID RR is defined with mnemonic DHCID and type code [TBD].             
   DHCID RR is only defined in the IN class.  DHCID RRs cause no                
   additional section processing.  The DHCID RR is not a singleton              
The term "singleton type" is not a DNS term. Where is it defined ?

  In DNS master files, the RDATA is represented as a single block in           
   base 64 encoding identical to that used for representing binary data         
   in RFC 3548 [7].                                                             
There are two alphabets in RFC3548 for base 64. Which one is used here ?  

   The DHCID RR Digest Type Code is an identifier for the digest                
   algorithm used.  The digest is calculated over an identifier and the         
   canonical FQDN as described in the next section.                             
Is it ? How do I exactly calculate the digest ? See next section for            
more comments.

   The input to the digest hash function is defined to be:                      
       digest = SHA-256(< identifier > < FQDN >)                                
what is <identifier> ?                                                          
This is terribly unclear.                                                       
   The FQDN is represented in the buffer in unambiguous canonical form          
"unambiguous canonical form" is a pleonasm. Please use "Canonical               
Wire Format"                                                                    
   as described in RFC 4034 [8], section 6.1.                                   
RFC 4034 section 6.1 deals with canonical ordering of names. Please             
refer to 6.2. 

   The identifier type code                                                     
   and the identifier are related as specified in Section 3.3: the              
   identifier type code describes the source of the identifier.                 
   A DHCPv4 updater uses the 0x0002 type code if a Client Identifier            
   option is present in the DHCPv4 messages and it is encoded as                
   specified in [12].                                                           
[12] is informative, not normative. If one is required to know the              
encoding to determine a type-code, please refer to the encoding as              

   the client.  The DHCID RDATA is composed by setting the two type             
   octets to zero, the 1-octet digest type to 1 for SHA-256, and                
   performing an SHA-256 hash computation across a buffer containing            
   Ethernet MAC type octet,                                                     
What is the Ethernet Mac type octet ? is that "htype, chaddr from a             
DHCPv4 client's DHCPREQUEST" ? 

  If the DHCID RR type is not supported, the RDATA would be encoded            
   [13] as:                                                                     
     \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283          
             fffedeb3f75e6 )                                                    
I tried to this, and this is my result:                                         
\# 35                                                                           
The input I used, exactly following the description in the example is           
as follows (base 16 string):                                                    
Which breaks down to  0000 identifier type code                                                      
     01 digest type                                                             
       010203040506 The six octets of the mac address                           
and the wireformat of client.example.com, which is                              
                  (6)c l i e n t(7)e x a m p l e(3)c o m(0)                     
When I follow the construction as specified in the previous chapter,            
I do not need to use the identifier type code and the digest type as            
input for the hash function.                                                    
 I tried that too, but again, different results from what you have:             
\# 35                                                                           
Please tell me what I did wrong.                                                
  type to 1 for SHA-256, and performing a SHA-256 hash computation             
   across a buffer containing the seven octets from the client-id               
   and the FQDN (represented as specified in Section 3.5).                      
In this example, the input buffer does not contain the identifier               
type and the digest type, which seems correct to me.                            
     chi.example.com.      A                                   
     chi.example.com.      DHCID   ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW          
                                     L3b/NaiUDlW2No= )                          
   If the DHCID RR type is not supported, the RDATA would be encoded            
   [13] as:                                                                     
     \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd          
             6a2503956d8da )                                                    
Okay, perfect. I got the same result.   


Detailed review draft-ietf-dnsext-dhcid-rr-12:

   of the DNS data is entirely dependent on the accuracy of the                 
   configuration procedure.  Sites that deploy Secure DNS [11] may              
[11] (rfc 2535) reference is updated by rfc 4033/4034/4035                      
   configure credentials for each client and its assigned FQDN in a way         
   that is more error-resistant, as both the FQDN and credentials must          
rfc 2535 and its replacements deal with origin authentication and               
data integrity. This is, the actual DNS data. If you mean                       
"transaction security" such as SIG(0) and TSIG for dynamic updates,             
please refer to Secure Dynamic Update [10].                                     
   Certain RCODEs defined in RFC 2136 [3] indicate that the destination         
Nit: Don't use names and references together.  please just say                  
"Certain RCODEs defined in [3] indicate that the destination"                   
   Because these errors may indicate a           
   misconfiguration of the updater or of the DNS server, the updater            
   attempt to signal to its administrator that an error has occurred,           
   e.g. through a log message.                                                  
What about errorcodes specific for TSIG or SIG(0) ?

   5.3.  Adding A and/or AAAA RRs to DNS                                        
   When a DHCP client or server intends to update A and/or AAAA RRs, it         
   starts with the update query in Section 5.3.1.                               
A DNS message is either a Request or Response. The Request has an               
opcode. This opcode can be UPDATE or QUERY. So update query is                  
confusing. This should be update request.                                       

Detailed review DRAFT-IETF-DHC-FQDN-OPTION-12:                     

   This document specifies a Dynamic Host Configuration Protocol for           
   IPv4, DHCPv4, option which can be used to exchange information              
   a DHCPv4 client's fully-qualified domain name and about                     
   responsibility for updating the DNS RR related to the client's              
   address assignment.                                                         
I understand this option already exists, and this document updates             
and extends its use. I would rephrase this to:                                 
This document updates and extends the DHCP Client FQDN option for the          
Dynamic Host Configuration Protocol IPv4.  This option can be used to          
exchange information about the a DHCPv4 client's fully qualified               
domain name. This information includes the FQDN and information about          
the responsibility for updating the DNS RR related to the client's             
address assignment.

Please put terminology after the introduction.                                 
   1.  Terminology                                                             
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",         
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in                    
   document are to be interpreted as described in RFC 2119 [1].                
   In any case, whether a site permits all, some, or no DHCP                 
   servers and                                                                    
   clients to perform DNS updates into the zones which it controls is          
   entirely a matter of local administrative policy.                           
Please rephrase to:                                                            
It is considered local policy to permit DHCP clients and servers to            perform DNS updates to zones.                                                

   This document does                                                          
   not require any specific administrative policy, and does not                
Yet, the document continues to specify a range of possible policies:           
    The range of possible policies is very broad, from sites where         
    only the DHCP servers have been given credentials that the DNS              
    servers will accept, to sites where each individual DHCP client has         
    been configured with credentials which allow the client to                  
    modify its                                                                     
   own domain name.  Compliant implementations may support some or all         
   of these possibilities.  Furthermore,                                       
I'd delete the previous paragraph.  
   This document describes a new DHCP option which a client can use to         
Is it new ? If it is new, why are there deprecated elements ?                  
   convey all or part of its domain name to a DHCP server.  Site-              
   specific policy determines whether DHCP servers use the names that          
   clients offer or not, and what DHCP servers may do in cases where           
   clients do not supply domain names.                                         
Note that a 'part of its domain name' is not a FQDN.                           

      client sends the Client FQDN option in its DHCPDISCOVER message, it         
   MUST send the option in subsequent DHCPREQUEST messages though the          
   contents of the option MAY change.                                          
   Only one Client FQDN option MAY appear in a message.                        
What if a client has more than one name ? It is possible to have               
more than one PTR per address.                                                 
   The code for this option is 81.  Its minimum length is 3 (octets).          
To avoid ambiguity, please specify that the length is excluding the            
Code and Len field.

        Code   Len    Flags  RCODE1 RCODE2   Domain Name                       
       |  81  |   n  |      |      |      |       ...                          
Please state somewhere that the above convention restrict name                 
lengths to 253. In DNS, a name has a maximum length of 255.  

   MUST send the option in subsequent DHCPREQUEST messages though the          
   contents of the option MAY change.                                          
   Only one Client FQDN option MAY appear in a message.                        
What if a client has more than one name ? It is possible to have               
more than one PTR per address.                                                 

   The format of the Client FQDN option is:                                    
        Code   Len    Flags  RCODE1 RCODE2   Domain Name                       
       |  81  |   n  |      |      |      |       ...                          
Please state somewhere that the above convention restrict name                 
lengths to 253. In DNS, a name has a maximum length of 255.                    
   The format of the 1-octet Flags field is:                                   
        0 1 2 3 4 5 6 7                                                        
       |  MBZ  |N|E|O|S|                                                       
The order of the flags below is not as it appears in the field.                
Does "S" indicate "Server" ?                                                   
Please be consistent in using "Flags" or "Bits"                                

   in the reply from the server indicates the action to be taken by            
   server; if 1, the server has taken responsibility for A RR updates          
   for the FQDN.                                                               
Does "O" indicate "Override" ?

   The "O" bit indicates whether the server has overridden the                 
   preference for the "S" bit.  A client MUST set this bit to 0.  A            
   server MUST set this bit to 1 if the "S" bit in its reply to the            
   client does not match the "S" bit received from the client.                 
What does "N" indicate ?

(Allison Mankin) No Objection

Comment (2006-03-15 for -)
The hash function they implemented in the dhcid is fine now (updating
my old comment).

(Jon Peterson) No Objection

Comment (2005-11-30 for -)
nit: dhc-ddns-resolution, Security Considerations, first sentence: "where or not" should be "whether or not"?

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

Comment (2006-03-16 for -)
In: draft-ietf-dnsext-dhcid-rr-12.txt

- sect 3.6.1.
     client.example.com.   A
  IP address in examples ought to be from range as
  per RFC3330

- sect 3.6.2
   A DHCP server allocates the IPv4 address to a client which
     chi.example.com.      A
  Same here, IP address should be from range as per

- Sect 3.6.4
    A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
     chi.example.com.      A
  IPv6 addresses in examples should be in the  2001:DB8::/32 range as
  per RFC3849.

(Alex Zinin) No Objection