Subject: Re: [dhcwg] DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

From: Pekka Savola <[email-masked]>
Date: Thu, 1 Dec 2005 15:00:49 +0200 (EET)

On Wed, 30 Nov 2005, David W. Hankins wrote:
> On Sat, Nov 26, 2005 at 04:27:27PM +0200, Pekka Savola wrote:
>> I have one major issue with 'Resolution of FQDN Conflicts among DHCP
>> Clients', the first issue below.  It fails to properly describe the
>> threats caused by DHCP clients requesting updating non-DHCP FQDN's
>> (like a random host from example.com requesting "www.example.com").
>> While this may not be a problem if DHCP clients belong to different
>> zones from non-DHCP clients, this is not discussed at all in the
>> document -- except ruled out of scope.
>
> The WG felt that it was necessary to include language in the document
> that gives implementors freedom to use alternative algorithms.  This
> is one such case...where the 'example algorithm' the document set out
> to describe handles the condition you describe easily (without a need
> for security consideration) because the existence of an A record
> without a DHCID results in update failure and the client is given a
> unique name instead.
...
> Now, perhaps RFCs shouldn't read like "Choose your own Adventure"
> novels.
...
> Perhaps the document should have documented one algorithm, noted
> the possible existence of others only, and continued to document
> exactly one algorithm implementing exactly one administrative
> policy consistently throughout.

My problem is that the spec leaves the algorithm completely open. 
There is at least one simple algorithm (just blindly update if there's 
no DHCID) has severe problems in certain kinds of zones.  This doc 
should discourage or disallow that algorithm by default.  As for the 
rest, I don't really care (though as a user, it would likely have been 
nice if the behaviour between different vendors would have been 
consistent, but we aren't going to get that it seems..).

>> 6.3.2.  DNS UPDATE When FQDN in Use
>>
>>    2.  A delete of the existing AAAA RRs on the FQDN if the updater does
>>        not desire AAAA records on the FQDN or this update is adding an
>>        AAAA and the updater only desires a single IP address on the
>>        FQDN.
>>
>> ==> how does the code know whether the updates only desires a single IP
>> address on the FQDN or not?   AFAICS, there's no way to signal this from the
>> DHCP client!
>
> That's correct, this is the operator's decision, which may be made
> for them by software of specific manufacture (or defaults of same).

This is exactly the problem: the software choosing what's best for the 
user.

> A system administrator may preside over an array of DHCP clients, let us
> imagine, that do not tell the DHCP server to RELEASE their lease prior
> to being uncerimoniously removed from the networks to which they are
> attached.
>
> In this case, it is desirable for the clients to be treated as though
> they only ever have a single address.  The old addresses are stale, and
> continued resolution of them in the DNS only produces timeouts (or
> failure to operate if the software can't seek to the working address).
>
> A client or server implementation may elect to simply delete all old
> A/AAAA records whenever it updates.

That would be unfortunate.  Wouldn't it be sufficient that the server 
removes the DNS records after the lease expires?  Then if the user 
doesn't reconnect anywhere else prior to lease expiry, all is cool.

>>     Through the use of the client
>>    FQDN option, DHCP clients and servers can negotiate the client's FQDN
>>    and the allocation of responsibility for updating the DHCP client's A
>>    and/or AAAA RRs.
>>
>> ==> also PTR records, not just A/AAAA..
>
> No.  Only A/AAAA.  The PTR is always updated by the server.  Hence
> the responsibility of updating the A/AAAA is the only thing that's
> negotiated in the FQDN option.

Re-read the spec. The client can tell the server NOT to update the 
PTR record, though the spec is written so that the server can update 
it anyway if it wants to (a 'MAY').

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 1 Dec 2005 09:29:37 -0800

> consistent, but we aren't going to get that it seems..).

I think we should take this one back to the WG.  Find out how many
algorithms there are which people actually want to use, within each
how many "administrative policies" there are (and name them all), and
who is interested in each one (more importantly, which One Bernie still
has the strength to document, if any).

Split up and go our separate ways, make new documents for the
additional algorithms (or don't if the interested parties don't
feel a need to).

> This is exactly the problem: the software choosing what's best for the 

Welcome to DHCP?  I'm sorry, that wasn't fair.

When, for example, at an IETF, where the systems operators are
engineers of similar character and capability as the clients (IETF
attendees), this solution can mix like water and oil.  Especially if
any of the involved individuals have opinions on "how things should
work", and choose to share them, which is about like applying a match
to the solution.  An IETF Molotov cocktail, if you will.

But, on a campus of some 100,000 Windows boxes, for example, where
the system operator has very limited experience with networks much
less DHCP much less DNS (because this is a job they give 'the new guy'),
and a drinking problem to boot, and the users surprise us daily by their
ability to mimic human speech, even forming rudimentary sentences such
as "I want net!" or "Fix magic electric box now!", this is ultimately the
only sane approach.

Obviously, between those two there are a variety of equally painful
scenarios, and we hope a bell curve where reasonably skilled operators
are asked to preside over reasonably computer literate client users.
Only some skeptics say the bell is upside-down.

Software will exist that is tailored to at least those two extremes,
if not more.  I suspect most software (or most widely used software)
will need to be readily adaptable to either.

So the draft really needs to document both ends of the spectrum.

> > [looks like I oversnipped bits about A/AAAA genocide]
> 

That is one approach, but it is the road generally not taken.

Lease times in campuses are often 24 hours, or more (I've seen 3-month
lease times, although they are rare...1 week is fairly common.  Also
let us not forget that RFC2131 explicitly has a special-case value
(all-ones) for the lease-time that is defined to mean "infinite"...there
are some actual field cases where this is used (I get patches from these
people).  Is it wise to leave forward records up indefinitely?

One operational impact of lease time is frequency of interruption for
the client.  Some clients either return to INIT state immediately should
the renewal time out (so brief interruptions in the DHCP service are
painful for some sysops), and some are known to 'hang' the IP layer
while the renewal is underway (painful for the user, more painful when
the systems administrator gets phonecalls asking why).

And in my own experimentation, I was able to consistently crash an
array of Windows 95, 98, and 2000 boxes simply by using a 30 second
lease time.

Wether these behaviours are in the spirit of the RFCs or not is
immaterial to an operator.

Add to this that larger times result in lower rate of activity on a
DHCP server (or cluster of same) in the center of a large campus.

So, larger lease times are preferred by admins.  Generally the
question is "how much advance notice are you required to give for
network downtime?"  Often 24, or 48 hours.

Letting these large times expire isn't tractable if the client has a
need to be reached by its name (which would be the whole point of DDNS
via DHCP - not mere vanity we would hope).

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg