Re: Deke on NS Records for Authority...

[Paul A Vixie <[e-mail]>]

> I've re-read draft-ietf-dhc-dhcp-dns-02.txt and also
> draft-ietf-dnsind-dynDNS-09.txt.
> 
> 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.
> 
> For example, can I visit MIT and boot up my laptop using DHCP (talking
> to some MIT DHCP server) to acquire the address but then specify a 
> upenn.edu FQDN?

that is the intent as i understood the dyndns/dhcp interaction draft.

> I'd specify foo.upenn.edu in my DHCP client FQDN option, and the ZNAME
> in the Zone Section of the DNS update would be upenn.edu.  

not necessarily.  draft-ietf-dnsind-dynDNS-09.txt says:

   4.1. From a requestor's point of view, any authoritative server for the
   zone can appear to be able to process update requests, even though only
   the primary master server is actually able to modify the zone's master
   file.  Requestors are expected to know the name of the zone they intend
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   to update and to know or be able to determine the name servers for that
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   zone.
   ^^^^^

it is *not* reasonable for a dhcp server to assume that the zone name is the
same as the parent domain of the host name being updated.  consider my own
host name, GW.HOME.VIX.COM, which is in zone VIX.COM -- there are no rr's at
domain HOME.VIX.COM.

finding the zone name if all you know is a domain name is not impossible, but
we elected not to explain the precise algortyhm in the UPDATE spec, in favour
of the text you see above.  the precise algorythm, for the record, is to make
normal, recursive queries for successively smaller tails of the domain in
question.  try it with dig:

	% dig gw.home.vix.com ns | grep NS
	% dig home.vix.com ns | grep NS
	% dig vix.com ns | grep NS
	vix.com.        96150   NS      UUCP-GW-1.PA.DEC.COM.
	vix.com.        96150   NS      UUCP-GW-2.PA.DEC.COM.
	vix.com.        96150   NS      GW.HOME.vix.com.
	vix.com.        96150   NS      NS.UU.NET.

and yes, you do need to start with the domain name in question, since it is
possible that it is a hostname (A RR) _and_ a zone root (NS and SOA present).

it's important to properly parse presentation level names, too.  if there is
a quoted dot ("\." in some encodings) this is not a "label separator" and you
would not use it to offset a prospective tail.

> 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.

i suggest that draft-ietf-dnsind-tsig-00.txt might clear things up for you.

[jim bound]
> 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.

in passing, i would like to point out that the complexities i helped with
are in DNS not BIND.  the only reason we pay attention to BIND is that it's
the installed base and there are some things older versions do horribly wrong
and we have to design with that in mind.  the thing that dynamic update hits
hardest is the fundamental invariants of the DNS, not implementation noodles
inside BIND.