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
Attachment:
pgpSO7TVUDHM4.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
