I haven't seen any replies in this corner of the thread. Apologies
if this has been covered elsehwere.
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.
Admittedly, this makes the document 'mosey' a bit.
But it would be foolhardy to ask the authors to document every single
possible security implication of every single possible alternate
algorithm, including the alternative possibilities the WG discussion
asked it to explicitly permit.
I think the security section would rapidly become larger than the
document in total.
Now, perhaps RFCs shouldn't read like "Choose your own Adventure"
novels.
And asking the authors to mud the language to endorse alternative
algorithms was a waste of their time.
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.
And leave all else to future work.
I seem to recall someone actually saying that in the WG traffic on
the subject. I think it was the author. Perhaps we should have
listened, or more of us should have agreed.
Overall, that's probably healthier for the DHCP-accessed dynamic
DNS universe...that the "RFCfoo compliant" text on each product
be the same only on those products that are actually intercompatible,
not merely those who once met the algorithm described in the draft
in a subway.
I've got to agree on this tangent with Pekka here.
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).
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.
Or it may elect to teardown the previous records prior to updating (ISC
DHCP "one-lease-per-client true;" syntax for example).
Or, if it believes both addresses are actually in use or at least leaves
it up to the client to release their leases if they aren't, it can
allow multiple addresses.
So if the 'updater', be that client or server, be that software of ISC
or Kame or Cisco or Nominum manufacture, be that Fred or George's
system, chooses, it can do what it pleases.
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.
--
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
pgpT06xNrEOmR.pgp
Description: PGP signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf