> >> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf