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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf