ietf
[Top] [All Lists]

DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

2005-11-26 07:32:03
On Mon, 14 Nov 2005, The IESG wrote:
The IESG has received a request from the Dynamic Host Configuration WG to
consider the following documents:

- 'A DNS RR for Encoding DHCP Information (DHCID RR) '
  <draft-ietf-dnsext-dhcid-rr-10.txt> as a Proposed Standard
- 'Resolution of FQDN Conflicts among DHCP Clients '
  <draft-ietf-dhc-ddns-resolution-10.txt> as a Proposed Standard
- 'The DHCP Client FQDN Option '
  <draft-ietf-dhc-fqdn-option-11.txt> as a Proposed Standard
- 'The DHCPv6 Client FQDN Option '
  <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard

I have one major issue with 'Resolution of FQDN Conflicts among DHCP Clients', the first issue below. It fails to properly describe the threats caused by DHCP clients requesting updating non-DHCP FQDN's (like a random host from example.com requesting "www.example.com"). While this may not be a problem if DHCP clients belong to different zones from non-DHCP clients, this is not discussed at all in the document -- except ruled out of scope.

This discussion needs to be included.

.......

6.3.3.  FQDN in Use by another Client

   As the FQDN appears to be in use by another client or is not
   associated with any client, the updater can decide (based on some
   administrative configuration outside of the scope of this document)
   whether to let the existing owner of the FQDN keep that FQDN, and to
   (possibly) perform some FQDN disambiguation operation on behalf of
   the current client, or to replace the RRs on the FQDN with RRs that
   represent the current client.  [...]

==> this is the biggest short-coming in this specification.  The choice of
this "administrative configuration outside the scope of this document" has
enermous security implications which have not been discussed at all in
Security Considerations section or here.

Specifically, consider the scenario:

1) www.example.com is manually configured (no DHCP) to point to 1.1.1.1,
   hence has no DHCID records.
2) a node in example.com zone uses DHCP, and purports its name is
   "www.example.com".  The DHCP server may nor may not perform the update
   based on the "admin config outside the scope of this document".

When reading the specification, this specific danger should be very clearly
explained, and this should be reflected in the document.  I'd also suggest
that by default, the server MUST NOT (or SHOULD NOT) perform updates if
there is no DHCID RR.

...

6.3.2.  DNS UPDATE When FQDN in Use

   2.  A delete of the existing AAAA RRs on the FQDN if the updater does
       not desire AAAA records on the FQDN or this update is adding an
       AAAA and the updater only desires a single IP address on the
       FQDN.

==> how does the code know whether the updates only desires a single IP
address on the FQDN or not?   AFAICS, there's no way to signal this from the
DHCP client!

5.  DNS RR TTLs

==> this section describes which TTLs to use in DNS RRs with DHCP.  This has
nothing to do with conflict resolution, though it's convenient to specify
this (which applies to both DHCPv4 and DHCPv6) here instead of duplicating
the same text in both DHCPv4/v6 specifications.  But should this still be
moved there?


semi-editorial
--------------

   There are two DNS update situations that require special
   consideration in DHCP environments: cases where more than one DHCP
   client has been configured with the same FQDN and cases where more
   than one DHCP server has been given authority to perform DNS updates
   in a zone.

==> the first point is actually more generic than that (though you cover it
as well in section 6.3.3), but rewording would be useful.  How about:

   There are two DNS update situations that require special
   consideration in DHCP environments: cases where more than one node is
   configured with the same FQDN and cases where more
   than one DHCP server has been given authority to perform DNS updates
   in a zone.

(and similar, "s/DHCP clients/nodes/" throughout -- it's sufficient that one
node uses DHCP, the others don't need to..)


editorial
---------

   FQDN, or Fully Qualified Domain Name, is the full name of a system,
   rather than just its hostname.  For example, "venera" is a hostname
   and "venera.isi.edu" is an FQDN.  See RFC 1983 [7].

==> use "example.com", please.

    Through the use of the client
   FQDN option, DHCP clients and servers can negotiate the client's FQDN
   and the allocation of responsibility for updating the DHCP client's A
   and/or AAAA RRs.

==> also PTR records, not just A/AAAA..

When either a client or server
   adds A, AAAA, or PTR RRs for a client, it also adds a DHCID RR that
   specifies a unique client identity, based on data from the client's
   DHCPREQUEST message.

==> seems to use DHCPv4-specific terminology, also add DHCPv6 wording?

   The most important consideration in removing DNS entries is be sure
   that an entity removing a DNS entry is only removing an entry that it
   added, or for which an administrator has explicitly assigned it
   responsibility.

==> s/be/being/ ?

9.2.  Informative References

   [5]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.

   [6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", RFC 3315, July 2003.

==> These should likely be normative references.

   Sites that wish to permit a single FQDN to contain both A and AAAA
   RRs MUST make use of DHCPv4 clients and servers that support using
   the DHCP Unique Identifier (DUID) for DHCPv4 client identifiers such
   that this DUID is used in computing the RDATA of the DHCID RR by both
   DHCPv4 and DHCPv6 for the client, see Node-Specific Client
   Identifiers for DHCPv4 [14].

==> [14] should likely be a normative reference.  The good news is that it's
already in RFC editor's queue! :)

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard], Pekka Savola <=