datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

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

No Objection
(was Discuss)
(was Discuss, No Objection)
(was Discuss)
(was Discuss)
(was Discuss, No Objection)

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

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

[Allison Mankin]

Comment (2006-03-15 for -)

The hash function they implemented in the dhcid is fine now (updating
my old comment).

[Bert Wijnen]

Comment (2006-03-16 for -)

In: draft-ietf-dnsext-dhcid-rr-12.txt

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

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

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

[Brian Carpenter]

Comment (2006-03-06 for -13)

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:
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-dnsext-dhcid-rr-10-alvestrand.txt
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-dhc-ddns-resolution-10-alvestrand.txt

[David Kessens]

Comment (2006-03-16 for -13)

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].
   The
   DHCID RR is only defined in the IN class.  DHCID RRs cause no
   additional section processing.  The DHCID RR is not a singleton
   type.

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
normative.

   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
   the
   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
000001457811a1e592b6f52a81e6a7767281fb4b1379fbf2cc9645d5a2ffc9b1dd54f7

The input I used, exactly following the description in the example is
as follows (base 16 string):

00000101020304050606636c69656e74076578616d706c6503636f6d00

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)
                   06636c69656e74076578616d706c6503636f6d00

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
0000016388f0e5221a5faa6b109dab9bdd4c2f1a3408d59c3c60b8fb45c5b6e4f0ed94

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
option
   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       10.0.12.99
     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
   match.

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
   MAY
   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
   about
   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
   this
   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
   propose
   one.

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
   the
   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
   client's
   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 ?

[Jon Peterson]

Comment (2005-11-30 for -)

nit: dhc-ddns-resolution, Security Considerations, first sentence: "where or
not" should be "whether or not"?

[Scott Hollenbeck]

Comment (2005-11-29 for -13)

draft-ietf-dhc-ddns-resolution: Reserved domains from RFC 2606 might be better
than "org.nil" in the examples.

[Ted Hardie]

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.