Re: draft-ietf-dhc-dhcp-dns-02.txt

[[e-mail]]

>Is there a separate list for discussion of DHCP interaction with DNS
>and the dynamic updates to DNS?  Is this really a question for the
>namedroppers list?  Please pardon me if I'm asking this in the wrong place.

Yep.  Ralph responded also I think your question should be sent to
namedroppers too.  Your asking the real hard subtle questions and
possbily we need to be more clear in the draft?  Are you on namedroppers
and can you send it there or I can forward it as I think they need to
see your mail?

>draft-ietf-dnsind-dynDNS-09.txt.

Cryptic and intense isn't it.  But this is what it took for consensus.

>I'm trying to convince myself one way or the other that there is
>provision for a DHCP client to specify a client FQDN option in the DHCP
>transaction which is for a DNS zone other than the zone usually
>associated with the address assigned by the DHCP server itself, and
>that under the right circumstances that request can be honored.

The answer is no.  The reason is that the only way to do this is with an
additional NS or glue record.  Right now an NS record does not transfer 
authority to the server. Glue records have the same property.
But I don't think we have done a good job of specifying clearly this
issue.  WHich is why we need this input on namedroppers?

>Setting policies aside for the moment, what is wrong with this model?
>Looks to me like the two DNS servers involved must authenticate and
>authorize the request.  Perhaps this is possible given Domain Name
>System Security Extensions (I'm still reading and re-reading
>draft-ietf-dnssec-secext-10.txt and draft-ietf-dnssec-update-02.txt
>to get a better understanding).  I briefly wondered whether this
>wouldn't actually be easier if the DHCP client was responsible for
>both the A and PTR record updates.  But that perhaps creates as
>many problems as it solves.

When Yakov, Sue, and I first architected this we got input that we
needed to permit both models.  A client should be able to implement dyn
upds to dns or a server should be able to on behalf of the client. Paul
Vixie then came on board and helped us rewrite the draft based on the
complexities of the BIND implementation and thats where the authority
issues became apparent and permitting what you ask is a very hard
implemntation problem.

But, from the beginning the working group did not want to support
referrals for dyn upds to DNS and if we permit you to use an NS server
other than at the site you are at in essence creates a referral and
thats not permitted either abstractly.

Anyway I think this should be taken to namedroppers. 

>Pointers to the right reading material and lists would be greatly
>appreciated.  Commentary from the draft authors, of course, would
>be wonderful.

For DHCP I am not sure for DHCPv4 if its in the drafts yet but for
DHCPv6 read the extensions draft and check out how we are doing it now,
but for that responding to the DHCPv6 mail list would be useful.

I think your reading all the right drafts.

/jim