Subject: [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Aug 2001 11:03:20 -0400

(Please follow up to [email-masked] mailing list. - RD)

>Subject: Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt> 
>Date: Mon, 27 Aug 2001 10:52:30 -0400
>From: Ted Lemon <[email-masked]>
>
>
>> >If when you say, "If a client ... wants to be responsible for updating
>> >... then the client MUST ..." you're not talking about my machine as the
>> >"client", but specifically only the DHCP code on the machine, then the
>> >"if" clause is trivially false. My DHCP code only ever sends and receives
>> >DHCP packets. Any code on my machine that sends and receives DNS Update
>> >packets is by definition DNS Update code, not DHCP code.
>> 
>> The DHCP client and server are exchanging information about the local 
>> administrative domain, the one where the host is booting. If your DHCP 
>> client wanted to maintain the name in the fqdn option, a name in a local 
>> zone, it would have to comply with this requirement. Since it doesn't, it 
>> doesn't.
>
>My client _always_ sends grosse.fugue.com in the FQDN option.  I
>thought that was how the FQDN option was supposed to be used.  It also
>always updates my DNS server.  It would be wrong for the DHCP server
>to tell me not to update grosse.fugue.com, unless it was administered
>by me (I own the fugue.com domain).  However, it's quite possible that
>it might do this anyway.  It could do this because it can't be
>configured to selectively permit or deny updates based on whether or
>not the client sent an FQDN, and the administrator wants to prevent
>the latter case (Microsoft Win2k clients will otherwise attempt to do
>the update in the local domain, causing errors to be logged by the
>local name server).   It might also be the case that the server
>administrator is not willing to let you set up a working PTR/A pair,
>and is trying to signify that by saying you shouldn't do an update.
>
>I don't think I am out of conformance with the spec if I ignore the
>no-client-update bit in the FQDN option - if I am, then you should
>probably change the relevant MUST to a SHOULD.   I have a feeling that
>that would address Stuart's objections... :'}
>
>                               _MelloN_

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

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 27 Aug 2001 14:04:58 -0700

>At the London meeting, your client did not have credentials
>(I'm betting) that would have allowed it to update "ietf.org" or
>"meetings.ietf.org", and the DNS primary for ietf.org probably
>would not have accepted unauthenticated updates from your laptop.

Why would that have been useful? What's the point of having a constant 
well-know host name if that host name keep changing every time you move?

If my laptop is called "something.ietf.org." when I'm at an IETF meeting, 
and "something.apple.com." when I'm at work, and 
"something.stanford.edu." when I'm at Stanford, what use is that?

My host *did* have various names of the form 
"host217-33-141-85.ietf.ignite.net" while I was at the meeting, which had 
both valid forward and reverse mappings. If my host is going to have some 
name which it cannot control and which no one else knows, then who cares 
whether it was dynamically updated or not?

>You downloaded a separate application that performs dns updates for you. 

A protocol specification should specify packets on the wire, not how the 
software is packaged.

>What your dhcp client must not do is initiate updates for the name
>in the fqdn option if the server tells it not to.

If the DNS administrator doesn't want me to initiate updates, then that's 
achieved simply by not giving my client the cryptographic credentials 
necessary to do the updates. If I don't have the credentials, then I 
can't do the update, and the question of whether my client obey's the 
DHCP server or not becomes a moot point.

>no one is interested in 'arbitrary domain names'.

That text about 'arbitrary domain names' was quoted from your draft.

>The host name option already has deployed behavior,

Which works fine.

>and specifies an ascii encoding.

Which works fine.

>can't exchange information about who should perform the update,

Then perhaps the draft should be specifying a "who wants to do the 
dynamic DNS update?" option, not an Fully Qualified Domain Name option.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 27 Aug 2001 16:56:02 -0500

I think in Ted's case the server would not return the same FQDN option if it wasn't
a fugue.com server. Ted's saying that his client would always send the FQDN with
grosse.fugue.com, but that's not necessarily what the server would send back. Hence,
if the server sends back some other domain (such as blah.ietf.org if he was at an
IETF meeting), his client will go ahead and update the grosse.fugue.com domain anyway.
I think that is OK. The client must just do what the server wants it to do about the
FQDN supplied by the server, it can't say what to do about the FQDN supplied by the
client.

Or, am I wrong about this?

- Bernie

-----Original Message-----
From: Mark Stapp [mailto:[email-masked]]
Sent: Monday, August 27, 2001 12:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>

Ted,
I agree with you about the purpose of the bit, but I'm a little confused by 
your last paragraph. Do you mean that even if the server was configured by 
you, and it asked your client not to update grosse.fugue.com, you'd like 
your client to update that zone anyway? I guess I don't see the point of 
that: if the dns and dhcp share administration, the 'don't update' bit 
tells the client that the administrators don't want the client to do the 
update for the fqdn in the option. If you get to ignore that bit, why don't 
the win2k clients get to ignore it too, and fire updates into your zone?

-- Mark

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 27 Aug 2001 15:32:20 -0700

> whether it was dynamically updated or not?

In this scenario, what is the tradeoff between:
    laptop.example.com IN CNAME host217-33-141-85.ietf.ignite.net
and laptop.example.com IN A 217.33.141.85 ?

Also, what are the consequences of the 6to4 address:
    laptop.example.com IN AAAA 2002:D921:8D55:0001:1234:5678:90AB:CDEF ?
(This address being derived from 217.33.141.85.)

-- Christian Huitema