Re: Deke on NS Records for Authority...

[Dikran Kassabian <[e-mail]>]

Unfortunately, we now have some of this conversation taking place
in dhcp-v4, some in dhcp-dns, and some in private mail.  I apologize
for letting this happen.  I suggest we move all of it to dhcp-dns.
Paul? Yakov? Jim?  (You guys responded in dhcp-v4, everybody else in
dhcp-dns).

PLEASE SEND ALL FOLLOW-UPS TO [e-mail] ONLY!

On Nov 4,  1:18pm, Paul A Vixie wrote:
| > 
| > 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.

Great.  There was some confusion on this point, I think (mine as
well as others :-)

I've asked several questions since.  See below.  I'm still hoping to
round all this up into one thread in one mailing list...

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

Yes.  Point taken.  Your example applies to upenn.edu as well as to
vix.com (foo.bar.upenn.edu is actually in zone upenn.edu, not
bar.upenn.edu) and I do understand the distinction you make.  My 
wording may have been misleading.  Thanks for the clarification.


---Excerpt from private mail I sent to Jim Bound
| [...] A point I want to make here: I'm unsure about building the
| guts of dynDNS with the idea in mind that DHCP is the only dynamic
| address assignment mechansim, though.  By specifying that the DHCP
| server be responsible for the PTR record update, you may have done
| something along those lines.  An abstraction of the concept to a
| standalone dyndns client might make it possible for a client to
| participate in dyndns even if he got his address via IPCP in PPP (which
| seems like an important case) or even from a gatorbox or similar
| gateway (arguably less important).  A counter argument is that PPP and
| protocol gateways should abandon their homegrown approaches and use
| DHCP.  A third possibility would be for them to build in the extensions
| proposed for DHCP to allow them to handle the dynDNS pieces necesary to
| make the PTR record updates.

The above is why I'm wondering whether dyndns should be tied up
with dhcp.....


Paul Vixie wrote:
| i suggest that draft-ietf-dnsind-tsig-00.txt might clear things up for you.
|

Thanks!  I grabbed a copy and have tried to understand as much as I
could quickly.  It will require a few more re-readings.


Something I said on on the dhcp-dns list the other day:
| What stops my laptop (the client) from telling the upenn server to
| associate the wrong MIT address with my FQDN in its A record?
| 
| What stops the client from performing the DHCP request with client FQDN
| option specified as a upenn FQDN for which he has no right (and no
| credentials) but then doing the update with the upenn server with the
| appropriate FQDN (for which he really does have credentials)?
| 
| In other words, what stops the client from telling lies?

This still seems like an important question.  So far it isn't clear to
me that any proposal for the use of KEYs or TSIGs are "checking with
the other side" of a two sided update.  Have I just missed it?

-------
Deke Kassabian, Manager, Network Engineering 
Information Systems and Computing, University of Pennsylvania
Voice:215-898-9293   FAX:[phone]   Email: <[e-mail]>