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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Bernie Volz (volz)
Pekka:

Regarding your one major issue, the updater is NOT the entity that gets
to decide whether to allow any DNS update to occur or not. It is the DNS
server that restricts who can do updates and what they can update.

We're assuming that the most likely entity to be given fairly open
access to a zone is the DHCP server and that is where the administrative
policy comes in.

A few more comments inline below (prefixed by BV>).

- Bernie

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Pekka Savola
> Sent: Saturday, November 26, 2005 9:27 AM
> To: [hidden email]
> Cc: [hidden email]; [hidden email]
> Subject: [dhcwg] DHCP and FQDN conflicts [Re: Last Call:
> 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed
> Standard]
>
> On Mon, 14 Nov 2005, The IESG wrote:
> > The IESG has received a request from the Dynamic Host
> Configuration WG to
> > consider the following documents:
> >
> > - 'A DNS RR for Encoding DHCP Information (DHCID RR) '
> >   <draft-ietf-dnsext-dhcid-rr-10.txt> as a Proposed Standard
> > - 'Resolution of FQDN Conflicts among DHCP Clients '
> >   <draft-ietf-dhc-ddns-resolution-10.txt> as a Proposed Standard
> > - 'The DHCP Client FQDN Option '
> >   <draft-ietf-dhc-fqdn-option-11.txt> as a Proposed Standard
> > - 'The DHCPv6 Client FQDN Option '
> >   <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard
>
> 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.
>
> This discussion needs to be included.
>
> .......
>
> 6.3.3.  FQDN in Use by another Client
>
>     As the FQDN appears to be in use by another client or is not
>     associated with any client, the updater can decide (based on some
>     administrative configuration outside of the scope of this
> document)
>     whether to let the existing owner of the FQDN keep that
> FQDN, and to
>     (possibly) perform some FQDN disambiguation operation on behalf of
>     the current client, or to replace the RRs on the FQDN
> with RRs that
>     represent the current client.  [...]
>
> ==> this is the biggest short-coming in this specification.  
> The choice of
> this "administrative configuration outside the scope of this
> document" has
> enermous security implications which have not been discussed at all in
> Security Considerations section or here.
>
> Specifically, consider the scenario:
>
> 1) www.example.com is manually configured (no DHCP) to point
> to 1.1.1.1,
>     hence has no DHCID records.
> 2) a node in example.com zone uses DHCP, and purports its name is
>     "www.example.com".  The DHCP server may nor may not
> perform the update
>     based on the "admin config outside the scope of this document".
>
> When reading the specification, this specific danger should
> be very clearly
> explained, and this should be reflected in the document.  I'd
> also suggest
> that by default, the server MUST NOT (or SHOULD NOT) perform
> updates if
> there is no DHCID RR.
>
> ...
>
> 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!

Agreed. That is why the language is the way it is. As a DHCP server is
likely to be doing the updates, it would be the entity to implement the
policy. In most DHCPv4 environments today, it is just a single A record
that is allowed.

If the client is doing the updates, it is aware of what it has and
therefore can do the correct thing.

>
> 5.  DNS RR TTLs
>
> ==> this section describes which TTLs to use in DNS RRs with
> DHCP.  This has
> nothing to do with conflict resolution, though it's
> convenient to specify
> this (which applies to both DHCPv4 and DHCPv6) here instead
> of duplicating
> the same text in both DHCPv4/v6 specifications.  But should
> this still be
> moved there?
>
>
> semi-editorial
> --------------
>
>     There are two DNS update situations that require special
>     consideration in DHCP environments: cases where more than one DHCP
>     client has been configured with the same FQDN and cases where more
>     than one DHCP server has been given authority to perform
> DNS updates
>     in a zone.
>
> ==> the first point is actually more generic than that
> (though you cover it
> as well in section 6.3.3), but rewording would be useful.  How about:
>
>     There are two DNS update situations that require special
>     consideration in DHCP environments: cases where more than
> one node is
>     configured with the same FQDN and cases where more
>     than one DHCP server has been given authority to perform
> DNS updates
>     in a zone.
>
> (and similar, "s/DHCP clients/nodes/" throughout -- it's
> sufficient that one
> node uses DHCP, the others don't need to..)
>
>
> editorial
> ---------
>
>     FQDN, or Fully Qualified Domain Name, is the full name of
> a system,
>     rather than just its hostname.  For example, "venera" is
> a hostname
>     and "venera.isi.edu" is an FQDN.  See RFC 1983 [7].
>
> ==> use "example.com", please.
>
>      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..
>
> When either a client or server
>     adds A, AAAA, or PTR RRs for a client, it also adds a
> DHCID RR that
>     specifies a unique client identity, based on data from
> the client's
>     DHCPREQUEST message.
>
> ==> seems to use DHCPv4-specific terminology, also add DHCPv6 wording?
>
>     The most important consideration in removing DNS entries
> is be sure
>     that an entity removing a DNS entry is only removing an
> entry that it
>     added, or for which an administrator has explicitly assigned it
>     responsibility.
>
> ==> s/be/being/ ?
>
> 9.2.  Informative References
>
>     [5]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
>           March 1997.
>
>     [6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
> C., and M.
>           Carney, "Dynamic Host Configuration Protocol for IPv6
>           (DHCPv6)", RFC 3315, July 2003.
>
> ==> These should likely be normative references.
>
>     Sites that wish to permit a single FQDN to contain both A and AAAA
>     RRs MUST make use of DHCPv4 clients and servers that support using
>     the DHCP Unique Identifier (DUID) for DHCPv4 client
> identifiers such
>     that this DUID is used in computing the RDATA of the
> DHCID RR by both
>     DHCPv4 and DHCPv6 for the client, see Node-Specific Client
>     Identifiers for DHCPv4 [14].
>
> ==> [14] should likely be a normative reference.  The good
> news is that it's
> already in RFC editor's queue! :)
>
> --
> 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
> [hidden email]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

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

Pekka Savola
On Sun, 27 Nov 2005, Bernie Volz (volz) wrote:
> Regarding your one major issue, the updater is NOT the entity that gets
> to decide whether to allow any DNS update to occur or not. It is the DNS
> server that restricts who can do updates and what they can update.
>
> We're assuming that the most likely entity to be given fairly open
> access to a zone is the DHCP server and that is where the administrative
> policy comes in.

I'm sure the zone administrators would like to have policy controls of
their own.  But as you say above, the assumption is that the DHCP
server can be given "fairly open access" to the zone.  In most cases
this might imply (taking BIND9 as an example) "allow-update" from DHCP
servers and "update-policy self" from hosts themselves.

Because DHCP server is assumed to be given fairly liberal access at
least in some scenarios, I believe it's justified to be more open
about the threats of having too open policy and discouraging against
a particular update scenario.

...

>> ==> 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!
>
> Agreed. That is why the language is the way it is. As a DHCP server is
> likely to be doing the updates, it would be the entity to implement the
> policy. In most DHCPv4 environments today, it is just a single A record
> that is allowed.
>
> If the client is doing the updates, it is aware of what it has and
> therefore can do the correct thing.

This does not address the scenario where a host has multiple AAAA
records and the DHCPv6 server is performing the updates -- and hence
ends up deleting all except one record, right?

In that case, the DHCP(v6) server should possibly refuse to do any
forward DNS updates because it might end up deleting something it
should not.

--
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
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

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

Bernie Volz (volz)
In reply to this post by Bernie Volz (volz)
> This does not address the scenario where a host has multiple AAAA
> records and the DHCPv6 server is performing the updates -- and hence
> ends up deleting all except one record, right?
>
> In that case, the DHCP(v6) server should possibly refuse to do any
> forward DNS updates because it might end up deleting something it
> should not.

You can have DHCPv4 servers such as those likely in wide deployment
today that assume one address per client and thus remove anything that's
there already. This works well even when a host moves between networks
(as the DHCP client will interact with the server whenever it connects
to a network).

Ideally, when DHCPv6 (IPv6) is added, the DHCPv4 servers would ideally
not touch the AAAA records when updating A records -- they'd just remove
all A RRs and add the current.

For DHCPv6 servers, depending on policy (such as if it is the only
server or if there is a one address/client policy) it may delete
everything and add back those that are current or may just do
add/removes. It really all depends on what the updater's policy is and
whether it is the only updater or not. I suspect that the DHCPv6 is more
likley to do adds/removes of individual RRs.

Do we really need to get into this level of specificity around this?

- Bernie

> -----Original Message-----
> From: Pekka Savola [mailto:[hidden email]]
> Sent: Monday, November 28, 2005 3:37 AM
> To: Bernie Volz (volz)
> Cc: [hidden email]; [hidden email]; [hidden email]
> Subject: RE: [dhcwg] DHCP and FQDN conflicts [Re: Last Call:
> 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed
> Standard]
>
> On Sun, 27 Nov 2005, Bernie Volz (volz) wrote:
> > Regarding your one major issue, the updater is NOT the
> entity that gets
> > to decide whether to allow any DNS update to occur or not.
> It is the DNS
> > server that restricts who can do updates and what they can update.
> >
> > We're assuming that the most likely entity to be given fairly open
> > access to a zone is the DHCP server and that is where the
> administrative
> > policy comes in.
>
> I'm sure the zone administrators would like to have policy
> controls of
> their own.  But as you say above, the assumption is that the DHCP
> server can be given "fairly open access" to the zone.  In most cases
> this might imply (taking BIND9 as an example) "allow-update"
> from DHCP
> servers and "update-policy self" from hosts themselves.
>
> Because DHCP server is assumed to be given fairly liberal access at
> least in some scenarios, I believe it's justified to be more open
> about the threats of having too open policy and discouraging against
> a particular update scenario.
>
> ...
> >> ==> 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!
> >
> > Agreed. That is why the language is the way it is. As a
> DHCP server is
> > likely to be doing the updates, it would be the entity to
> implement the
> > policy. In most DHCPv4 environments today, it is just a
> single A record
> > that is allowed.
> >
> > If the client is doing the updates, it is aware of what it has and
> > therefore can do the correct thing.
>
> This does not address the scenario where a host has multiple AAAA
> records and the DHCPv6 server is performing the updates -- and hence
> ends up deleting all except one record, right?
>
> In that case, the DHCP(v6) server should possibly refuse to do any
> forward DNS updates because it might end up deleting something it
> should not.
>
> --
> 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
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

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

Sam Hartman-5
>>>>> "Bernie" == Bernie Volz (volz) <[hidden email]> writes:

    Bernie> For DHCPv6 servers, depending on policy (such as if it is
    Bernie> the only server or if there is a one address/client
    Bernie> policy) it may delete everything and add back those that
    Bernie> are current or may just do add/removes. It really all
    Bernie> depends on what the updater's policy is and whether it is
    Bernie> the only updater or not. I suspect that the DHCPv6 is more
    Bernie> likley to do adds/removes of individual RRs.

    Bernie> Do we really need to get into this level of specificity
    Bernie> around this?


You need to get sufficiently specific that in practice, the
implementation of this option is not influencing addressing plans.
For example if servers tend to get this wrong in a way that makes it
difficult for me to have multiple addresses for client then you were
not specific enough.

--Sam


_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

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

David W. Hankins
On Mon, Nov 28, 2005 at 01:13:43PM -0500, Sam Hartman wrote:
> You need to get sufficiently specific that in practice, the
> implementation of this option is not influencing addressing plans.
> For example if servers tend to get this wrong in a way that makes it
> difficult for me to have multiple addresses for client then you were
> not specific enough.

In practice, at least one implementation today will fail (logging an
error) if more than one A record on a given FQDN is present.

Will more specific text change that?


It's actually the current wording of the drafts that first imparted to
me the contrary, and the means to acheive that, and you might see a
future version of ISC DHCP moving in that direction as a consequence.

So, in my unreliable opinion, it's fine the way it is.

--
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
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg