Subject: [dhcwg] DDNS FQDN Registration - PTR records

From: "Keasey, Adrian" <[email-masked]>
Date: Wed, 27 Nov 2002 09:10:26 -0600

I have a question on the DHCP Client FQDN Option for registering DDNS
records. We have a commercial DHCP server which is configured to register
the client's A record with the FQDN listed in the Domain field of Option 81
in the DHCP Request packet. This registration works correctly.

However, the DHCP server is registering the client's PTR record with the
clients hostname, but a different DNS domain - i.e. not the FQDN listed in
the Domain field of Option 81 in the DHCP Request packet. This creates a
situation where the client has a different FQDN listed in the PTR record and
the A record.

I assume that this is not expected behaviour, but "The DHCP Client FQDN
Option"
(http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-05.txt
<http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-05.txt> )
does not explicitly state that the PTR registration SHOULD / MUST / MAY use
the FQDN that the client responds with.

Regards,

Adrian Keasey

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Mark Stapp <[email-masked]>
Date: Wed, 27 Nov 2002 17:45:11 -0500

Adrian,

It's often useful for there to be an A and PTR 'pair', in which the PTR 
associated with an address names the A whose data is the address. That 
said, it's entirely an administrator's decision whether or not to configure 
the dhcp and dns servers to make that happen. And of course, it's entirely 
up to implementors to determine what combinations to support in their software.

In some win2k deployments, dhcp clients are encouraged to update one 
forward zone while the server updates another. In these cases, the server 
probably prefers a PTR which reflects the forward name that it is managing 
along with the dhcp lease, over the name that the client is responsible for.

The FQDN option draft specifies how the client and server exchange 
information about the fqdn, and some information about the dns updating 
that's going to happen. It's not a general-purpose dns update proxy option, 
and it's also explicitly not a set of restrictions on administrators' 
configurations. There are some more-detailed operational recommendations in 
draft-ietf-dhc-ddns-resolution-*.txt.

Regards,
Mark