ietf
[Top] [All Lists]

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

2005-12-01 06:34:40
    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..

No.  Only A/AAAA.  The PTR is always updated by the server.  Hence
the responsibility of updating the A/AAAA is the only thing that's
negotiated in the FQDN option.

Re-read the spec. The client can tell the server NOT to update the 
PTR record, though the spec is written so that the server can update 
it anyway if it wants to (a 'MAY').

The "N" bit is used by a client to request that the server *NOT* perform
any updates on its behalf. That is AAAA *AND* PTR.

   The "N" bit indicates whether the server SHOULD NOT perform any DNS
   updates.  A client sets this bit to 0 to request that the server
   SHOULD perform updates (the PTR RR and possibly the AAAA RR based on
   the "S" bit) or to 1 to request that the server SHOULD NOT perform
   any DNS updates.  A server sets the "N" bit to indicate whether the
   server SHALL (0) or SHALL NOT (1) perform DNS updates.  If the "N"
   bit is 1, the "S" bit MUST be 0.

The idea here was that there may be clients that don't want anything in
the DNS and this is a way they can request this. This is not negotiating
the responsibility for the PTR; it is negotiating for whether the server
does any updates ("S" bit must be 0 which means the server won't do AAAA
as well).

Note that not supplying a FQDN option is not usually sufficient to do
this; the DHCP server may well add entries to the DNS server on the
clients behalf even if the client doesn't supply the FQDN option.

It is not viewed as likely that clients would be given access to perform
DNS Updates on the reverse zones -- they won't have the security
credentials (mainly because in most cases the address the client will
get can not be known in advance).

If this text is really so offensive to you, we can use the wording from
the abstract:

Abstract:

   This document specifies a new Dynamic Host Configuration Protocol for
   IPv6, DHCPv6, option which can be used to exchange information about
   a DHCPv6 client's fully-qualified domain name and about
   responsibility for updating DNS RRs related to the client's address
   assignments.

So, 1. Introduction, 2nd paragraph, becomes:

   The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5]
   provides a mechanism by which a host (a DHCPv6 client) can acquire
   certain configuration information, along with its stateful IPv6
   address(es).  This document specifies a new DHCPv6 option, the Client
   FQDN option, which can be used by DHCPv6 clients and servers to
   exchange information about the client's fully-qualified domain name
   and who has the responsibility for updating DNS RRs related to the
   client's address assignments.

- Bernie

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

<Prev in Thread] Current Thread [Next in Thread>
  • RE: [dhcwg] DHCP and FQDN conflicts [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard], Bernie Volz \(volz\) <=