Subject: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt

From: James Carlson <[email-masked]>
Date: Tue, 11 Jan 2011 12:12:15 -0500

I read this draft with some interest, as I've run into this sort of
problem many times myself.

I'm curious, though, about the architectural implications of the
described design.  In particular, the use of DHCPv6 to convey
suffix/prefix information means that the DHCP server needs to be updated
as various suffixes/prefixes change within a network, and clients need
(somehow) to know to refresh that information as it changes.

For example, suppose my DNS is configured with a set of ip6.arpa
mappings representing my current networks.  I configure my DHCPv6 server
to list these suffixes as part of OPTION_DNS_SERVER_SELECT, so that
clients will know that my DNS server contains this information.

Now I deploy a few new IPv6 networks within my organization.  I have to
update DNS, of course, with the new ip6.arpa entries.  But because I'm
using the feature described in this draft, I now have to update DHCPv6
as well, and I have to make sure that the clients all "refresh" their
DHCP-derived information.  If I don't, then clients will suffer with
incorrect filters (and thus failed look-ups) until they restart.

So, my question is this: did you consider placing the required
suffix/prefix information into DNS itself?  As a simple example -- not
intended to be a complete design -- you could add a new TXT entry to DNS
that contains the same data as the "DNS suffixes and prefixes"
information in this draft.  Clients could then get DNS server addresses
through the existing DHCPv6 mechanisms, and then query the server to get
this new TXT record.  If present, then it gives the same information as
in this draft, *plus* it includes the normal DNS lifetime data and
caching behavior.  If absent, then the client just assumes that the
server contains all data, just as specified in the existing draft, and
just as it should today.

If you did it based on DNS instead of DHCPv6, then you'd have the
following benefits:

  1.  The DNS server's existing caching behavior would cover both
      changes to the suffix/prefix list and to the actual data served,
      so the administrator would have a single point of control.

  2.  Clients would not be forced to refresh DHCPv6 data when the
      contents of the DNS server (the list of suffixes/prefixes
      served) changes.

  3.  If DNSSEC is in use, it would protect the suffix/prefix list;
      something that's missing from the DHCPv6 approach.

  4.  The same approach would work seamlessly for IPv4 and IPv6.

I can see no obvious negative aspects of such a design, though I
certainly admit that I could be missing key issues.

Did you consider this sort of design?  If so, why was a DHCPv6 extension
chosen instead?

-- 
James Carlson         42.703N 71.076W         <[email-masked]>

---

From: <[email-masked]>
Date: Thu, 13 Jan 2011 14:22:37 +0000

Hi James,

My thinking evolved from DNS search list option defined in RFC3646, hence using DHCPv6 seemed like a logical choice.

Additionally collecting information required for multi-homing configuration into one place (DHCPv6) seemed useful: this option, DHCPv6 Route Option (draft-ietf-mif-dhcpv6-route-option), and Distributing Address Selection Policy using DHCPv6 (draft-ietf-6man-addr-select-opt). I.e. single point of control but different point than what you propose below. DHCPv6 can also support node specific configurations.

Addition of information refreshing considerations is a good proposal. The RFC4242, "Information Refresh Time Option", can be utilized for this purpose. Well include considerations of this.

About packet integrity protection.. I have thought the same level of integrity protection we have for other DHCPv6 configuration options would suffice. 

About IPv4 and IPv6. Generally multi-homing for IPv4 is a lost cause due serious problems caused by overlapping private addresses and subnets. I will consider IPv4 multi-homing only if really really necessary. (This reminds me of v6ops discussion about whether IPv4 should be declared historic and hence no new work (save security fixes) would need to be done for IPv4 in IETF:)

Best regards,

Teemu

> -----Original Message-----
> From: ext James Carlson [mailto:[email-masked]]
> Sent: 11. tammikuuta 2011 19:12
> To: Savolainen Teemu (Nokia-MS/Tampere); [email-masked]
> Cc: [email-masked]
> Subject: draft-savolainen-mif-dns-server-selection-06.txt
>

---

From: James Carlson <[email-masked]>
Date: Thu, 13 Jan 2011 10:53:06 -0500

> My thinking evolved from DNS search list option defined in RFC3646, hence using DHCPv6 seemed like a logical choice.

The two seem quite distinct to me.  The existing search list option
provides a global setting for the client, and is intended to affect how
unqualified (or partially-qualified) names are resolved.  The new option
proposed in this draft isn't global; it specifies what domains are known
or expected to resolve properly with the given server (and/or network
and/or interface; that detail is somewhat unclear to me).

But, ok, I see the motivation.

> Addition of information refreshing considerations is a good proposal. The RFC4242, "Information Refresh Time Option", can be utilized for this purpose. Well include considerations of this.

OK.

So, operationally, how do I get the DHCPv6 refresh time to line up
usefully with the DNS cache limits, so that I can make changes when I
need to?  This is typically easy when modifying the usual sort of SOA
entry, but it's less clear to me when DHCPv6 is in the mix.  Is the
administrator for the DHCPv6 server assumed to be the same as for the
DNS system?

It still seems quite a bit more complex to use in practice than the
alternative I suggested.

What about nodes that don't use DHCPv6 but do have DNS?  It seems to me
that providing information directly to the DNS client about what domains
ought to resolve is a bit more flexible and independent than vectoring
it through DHCPv6 first.

And, though I agree it's a bit out of scope for the IETF, what about
implementation considerations?  There'll need to be a new way of getting
this data from the DHCPv6 client over to the DNS resolver.  It seems
simpler if this were just an integrated behavior of the resolver.

I suppose the one positive attribute of the DHCPv6 scheme I can see is
that (in many implementations) the data would be forced into a
configuration file or database somewhere, and that would promote caching
and reuse.  (Though with the usual concerns about timeliness of the
information, RFC4242 notwithstanding.)

> About packet integrity protection.. I have thought the same level of integrity protection we have for other DHCPv6 configuration options would suffice. 

Except that they're distinct, I suppose that's true.  DNSSEC protects
the name resolution information, and that's exactly what's at risk if
the list of "official" domains supported is compromised.

> About IPv4 and IPv6. Generally multi-homing for IPv4 is a lost cause due serious problems caused by overlapping private addresses and subnets. I will consider IPv4 multi-homing only if really reall…

I'm not sure I see how names and subnets are so inextricably linked.
The name search problems in the two cases appear to me to be essentially
the same.

But I do understand the lack of interest in v4, although that's how this
whole conversation's been held.  ;-}

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 12:06:35 +0000

Hi,

> Sent: 13. tammikuuta 2011 17:53
> To: Savolainen Teemu (Nokia-MS/Tampere)
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-savolainen-mif-dns-server-selection-06.txt
> 
> > My thinking evolved from DNS search list option defined in RFC3646,
> hence using DHCPv6 seemed like a logical choice.
> 
> unqualified (or partially-qualified) names are resolved.  

Right, but the same information could originally have been designed to be configured through DNS servers. But for some historical reasons, which I am not aware of, DHCP was chosen.

In the deployment scenario I could be on right now, the DNS search list option content might almost equal the content of what the DNS server selection option would contain (see Appendix A.2 of our draft).

> The new
> option

Well, DHCP is used to configure both local and global information (and conflicts with "other global information" learned via other interfaces need to be resolved..).

> administrator for the DHCPv6 server assumed to be the same as for the

At least for the deployment scenarios we are looking at you would anyway have to update DHCPv6 with corresponding IPv6 routing information delivery. I.e. if one deploys private names the chances are that those names map to non-globally reachable IP-addresses. I mean if a name maps to a globally reachable IP address, why the name would not be globally resolvable via DNS?

About lining up times.. I don't have much experience on network operations, but maybe you could do something like adding the entries to DHCPv6 some time before making changes to DNS, hence decreasing set of hosts that will end up have old information. Hosts that attach through VPN or cellular connections probably do information refreshes quite often.

In case of common changes you can also ensure your DNS server is the highest priority default server.

> ought to resolve is a bit more flexible and independent than vectoring

Maybe such nodes would not need advanced multihoming feature at first place, as in that case they would also miss e.g. the routing information option and distributed address selection policies:)

Stateless DHCPv6 is fairly simple protocol to implement.

> simpler if this were just an integrated behavior of the resolver.

You mean each time a new DNS server address would be learned by some means (DHCPv6, RA, "well-known", provisioning, manual configuration, L2 means) the DNS resolver would contact said DNS server(s) to fetch new information. Well, either way the DNS resolver must do the DNS server selection based on the information it has obtained by some means. We prefer delivering that information via DHCPv6 at the same time with other configuration information required for multihoming.

Btw in the demos we've shown to people at IETF#78 and IETF#79 we used ISC's unmodified BIND running on a host with a small tool creating named.conf dynamically based on the information delivered via DHCPv6. However, it is not possible to have all the features currently described in the draft done with such a setup. For full function the used resolver has to be really modified.

> the list of "official" domains supported is compromised.

I didn't follow. If the suffix list is compromised the node may end up sending questions to malicious DNS servers, but as the responses from there will not validate, the node will retry with other DNS servers and should end up talking to someone who does not lie. Or do you refer to a case where only the suffix list would be validated with DNSSEC, but DNSSEC would not be used for actual DNS resolution queries?

> > About IPv4 and IPv6. Generally multi-homing for IPv4 is a lost cause
> due serious problems caused by overlapping private addresses and
> subnets. I will consider IPv4 multi-homing only if really really
> necessary. (This reminds me of v6ops discussion about whether IPv4
> should be declared historic and hence no new work (save security fixes)
> would need to be done for IPv4 in IETF:)
> 

With that comment I stepped out our of DNS discussion and went to general discussions:) Sorry for confusion.

One of the significant reasons (but not the main one) why your favorite handset does not usually do WLAN and cellular at the same time is the fact that it may get same NATted IP address from both network interfaces. That complicates things quite a lot.

Also getting this solution into market will take some time, and by that time (at least in cellular domain) IPv4 usage ought to be in the  decline. Hence I think we do not necessarily need feature parity between address families for all new features:) This is of course for MIF WG to decide.

> The name search problems in the two cases appear to me to be
> essentially the same.

Yes.

> But I do understand the lack of interest in v4, although that's how
> this whole conversation's been held.  ;-}

:) Design of the new technologies is often done with old tools:-) 

Teemu

---

From: James Carlson <[email-masked]>
Date: Fri, 14 Jan 2011 09:00:36 -0500

> Right, but the same information could originally have been designed to be configured through DNS servers. But for some historical reasons, which I am not aware of, DHCP was chosen.

Possibly.  I believe that when the DNS resolver portion of this was
being designed, it was assumed that choice of a default domain for
unqualified names was a local matter -- one system administrator might
choose one, and another might choose a different one.  So, it was just a
local configuration option rather than a part of the DNS server.

As yet another local configuration option that could be centralized, it
got swept up into a DHCP option, and there we are.

I believe these two -- search lists and served domain lists -- are
qualitatively different.  Having hints that a particular DNS server is
good for particular queries is quite different from knowing that the
simple name "foobar" should be resolved as "foobar.example.com."

To put it another way, if I hear through this new mechanism that some
DNS server will handle requests for "example.com.", that does *NOT*
imply in any way that I want bare names to be resolved by that server
preferentially.  Perhaps I do -- but perhaps I don't.  That's what the
search list is for.

> In the deployment scenario I could be on right now, the DNS search list option content might almost equal the content of what the DNS server selection option would contain (see Appendix A.2 of our…

I don't think that's generally true, though I can see how it might be
true in some cases.

One of the things this draft addresses is the problem that when a
multi-homed client receives multiple DNS server addresses, it doesn't
know where to send the queries.  This solution fixes that problem by
providing clues about direction.  But merely knowing where to send a
full query does _not_ tell the client what domains it should assume when
only a simple name is given.

> Well, DHCP is used to configure both local and global information (and conflicts with "other global information" learned via other interfaces need to be resolved..).

I don't know of any information provided by DHCP that's "local" in the
sense that you're saying.

The DHCP information concerning the IP addresses of DNS servers is
"global" in the sense that the client system's resolver can use it to
form a list of servers to query.  There's just one list required.

This new information is quite different, because it's *per* DNS server.
 Each server has a different string that specifies what it will resolve.

A case that illustrates how different these things are would be one
where the DHCPv6 server provides the IP addresses of two different DNS
servers.

There'd still be just one search list to contend with.  And one list of
IP addresses for the DNS servers.  But you'd need to have two of these
selection lists -- one for each of the DNS servers to describe what
domains each server is able to resolve.

> At least for the deployment scenarios we are looking at you would anyway have to update DHCPv6 with corresponding IPv6 routing information delivery. I.e. if one deploys private names the chances ar…

Any of a number of situations can cause that.  Some networks have areas
that don't resolve "outside" the area for testing or security-related
reasons.

At least with the large networks where I have some experience, the folks
handling routing are completely separate from the ones handling name
services.  In fact, they're even employed by different companies.

> In case of common changes you can also ensure your DNS server is the highest priority default server.

I don't think I follow that, because I'm not sure I see how priority
works into the prefix/suffix lists used for DNS server selection.

> Stateless DHCPv6 is fairly simple protocol to implement.

Indeed; it's not difficult.  But is it operationally necessary?

> You mean each time a new DNS server address would be learned by some means (DHCPv6, RA, "well-known", provisioning, manual configuration, L2 means) the DNS resolver would contact said DNS server(s)…

The algorithm used by the resolver might be something like:

resolve_name(name):
    if "name" is cached and unexpired:
	just return that
    for each known server address:
	if server has unexpired domain-list and "name" matches:
	    try this server; return on success
    for each known server address:
	if no cached domain-list entry or entry is expired:
	    query server for domain-list and cache result
    for each known server address in priority order:
	if no domain-list or if "name" matches list:
	    try this server; return on success

It's similar to the algorithm required for this draft, except that it
has logic to refresh the domain lists when necessary.  (That's off the
cuff; I'm sure a good designer with more time could do a better job.  ;-})

> Btw in the demos we've shown to people at IETF#78 and IETF#79 we used ISC's unmodified BIND running on a host with a small tool creating named.conf dynamically based on the information delivered vi…

Sure; both my suggestion and yours require resolver modifications.  And
neither one actually requires changes in the DNS server.

The draft, though, does require DHCP changes.

> I didn't follow. If the suffix list is compromised the node may end up sending questions to malicious DNS servers, but as the responses from there will not validate, the node will retry with other…

I don't think that's complete.

If I have a malicious DHCPv6 server, I can set up a prefix/suffix list
for one of the valid DNS servers that says that server doesn't handle
any domain I want, including the default "." domain.  If this is done,
then the resolver will never attempt to query the "right" server.

In that case, it doesn't matter whether there are any malicious DNS
servers.  In fact, there might not be any at all.

And my malicious DHCPv6 server won't bother with the refresh option, so
the client is nailed until he manually restarts.

Or are you saying that there are cases where the resolver should just
ignore the prefix/suffix list from DHCPv6, and should send out queries
to servers it doesn't think can answer them, just in case the list is wrong?

Or should the resolver somehow "know" whether the DHCPv6 information is
"secure," for whatever "secure" means?  And how would it know that the
information is as valid as the DNSSEC information?

> One of the significant reasons (but not the main one) why your favorite handset does not usually do WLAN and cellular at the same time is the fact that it may get same NATted IP address from both n…

Nah, the main reason is that my favorite handset is a plain old phone.
It barely does SMS, let alone fancy data.  ;-}

I understand that problem.  I think what you're really saying is that
you want nothing to do with NATs (and the implications of them), and
since NATs are common with v4 and not with v6, you're doing v6-only.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jan 2011 09:10:28 -0500

> information is as valid as the DNSSEC information?

This is, of course, the key problem.   The resolver has no way, a priori, to know that the information from the DHCPv6 server is valid.   It has to validate it somehow, or else the answer it is providing to the end-user is potentially harmful.

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 14:28:18 +0000

This is a generic feature of DHCPv6, right? 

Teemu

> From: ext Ted Lemon [mailto:[email-masked]]
> Sent: 14. tammikuuta 2011 16:10
> To: James Carlson
> Cc: Savolainen Teemu (Nokia-MS/Tampere); [email-masked]; [email-masked]
> Subject: Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt
> 
> This is, of course, the key problem.   The resolver has no way, a
> priori, to know that the information from the DHCPv6 server is valid.
> It has to validate it somehow, or else the answer it is providing to
> the end-user is potentially harmful.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jan 2011 09:35:36 -0500

> This is a generic feature of DHCPv6, right? 

What is?

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 14:58:01 +0000

Lack of trust on information contained in all options?

Teemu

> Sent: 14. tammikuuta 2011 16:36
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 15:09:21 +0000

> preferentially.  Perhaps I do -- but perhaps I don't.  That's what the

You can ignore the option and talk to the DNS server of your preference. You can also choose to listen for the option only from one or more trusted sources.

> full query does _not_ tell the client what domains it should assume
> when only a simple name is given.

A bare name would unlikely find match from the suffix list. You could ask resolution for the bare name from your favorite default.

After appending the bare name with some suffix from your search list you could look for match from DNS server selection list.

Of course there could be multiple search list from different interfaces. In such case you could prioritize the search lists by some means and start walking through the suffixes when resolving bare name.

> > Well, DHCP is used to configure both local and global information
> (and conflicts with "other global information" learned via other
> interfaces need to be resolved..).
> 

>From my viewpoint DNS server address is a perfect example of local information, which is valid only on the interface it was learnt on (rarely you can contact DNS server via other interfaces). The host of course may put these pieces of local information in a form of global list to go through, but that list then easily becomes an interface preference list and *essentially* host chooses first the interface to use and then DNS server from there (assuming IP packets to DNS server are sent over the interface DNS server address was learnt).

> domains each server is able to resolve.

Would you rather prefer DHCPv6 option that does not specify DNS server addresses, only suffix list? I.e. in that case the suffix list would be interface specific? That is something we could discuss about.

> that don't resolve "outside" the area for testing or security-related

But the IP addresses of the services pointed by names remain globally reachable?

> cuff; I'm sure a good designer with more time could do a better job.

This sounds quite like what we have, except that domain-list is fetched with DHCPv6 and not on-demand as shown above (and also DNSSEC to validate before declaring success).

> The draft, though, does require DHCP changes.

Well, trouble to add new option to DHCP config files is not a big challenge. I used ISC's DHCPv6 server and it supported custom options - the option content was easy to write to dhcp config.

On the client side, be it resolver or dhc client, they need to modify asking of the information. In the case of DHC that was easy as well.

> then the resolver will never attempt to query the "right" server.

You mean attacker could use DHCPv6 on one interface to remove/disturbing DNS information learnt on other interfaces? 

That is part of conflict resolution: more trusted interfaces should take precedence (and e.g. on WLAN hotspot filled with hacker you might not even want to query this option). 

> to servers it doesn't think can answer them, just in case the list is

The draft talks about walking through available DNS servers and trust levels of interfaces. The host may always ask other servers if the one preferred does not yield answer.

After all, many IETF people seem to be happy for sending queries to all DNS servers of all interfaces always:-)

Anyway, we could have it also so that if the most preferred DNS server does not give positive validatable reply in half a second the node resends the query out on all interfaces to all DNS servers like a lightning storm. That would ensure the common case does not require DNS storming, but in case of trouble the user experience would remain good.

> since NATs are common with v4 and not with v6, you're doing v6-only.

That's mostly true, but I do fancy properties made possible by the large address space that are not possible in public IPv4 (or were, if people were given large chunks of IPv4 addresses:).

Best regards,

Teemu

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jan 2011 10:13:12 -0500

> Lack of trust on information contained in all options?

Right.   Generally, we assume that the higher-level protocol will have some sort of security mechanism--e.g., DNSSEC.   Or we assume that the environment in which DHCP is being done is one in which there is no easy opportunity for attack (e.g., cable modem connection, or secured home WiFi).

The problem with this proposal is that it creates a new, generic mechanism which depends on the data from the DHCP server being trustworthy.  If the data is not trustworthy, the mechanism doesn't fail.

The question is, is there some way to give you what you want, without creating a generic mechanism that has the property of assuming trustworthiness without proof of trustworthiness.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Jan 2011 10:40:04 -0500

> You can ignore the option and talk to the DNS server of your preference. You can also choose to listen for the option only from one or more trusted sources.

I'm really unclear about this "trusted sources" thing, though.  Is
that "trust only if you're on a trusted network"?  Because I think the
problem basically is that there's no sDHCP, right?

> Of course there could be multiple search list from different interfaces. In such case you could prioritize the search lists by some means and start walking through the suffixes when resolving bare…

This is all a little hand-wavy.  "Some means" sounds like the road to
user-surprise-perdition.  Bare names are already a bugbear, and I
don't think we want to make them even more surprising.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 15:53:25 +0000

I have to admit one thing I have not really understood is why the level of concern here is so deep.

If I now have e.g. multihomed Linux, often or usually the /etc/resolv.conf points to the DNS server address learned most recently via some mean (RA, DHCPv6). But people are not too worried what is the content of that file? I.e. attacker could just send new RA with DNS server address option and cause problems by drawing DNS traffic to that server?

Shouldn't we work e.g. on securing all DHCPv6 signaling?

Teemu

> Sent: 14. tammikuuta 2011 17:13
> Right.   Generally, we assume that the higher-level protocol will have
> some sort of security mechanism--e.g., DNSSEC.   Or we assume that the
> environment in which DHCP is being done is one in which there is no
> easy opportunity for attack (e.g., cable modem connection, or secured
> home WiFi).
> 
> The problem with this proposal is that it creates a new, generic
> mechanism which depends on the data from the DHCP server being
> trustworthy.  If the data is not trustworthy, the mechanism doesn't
> fail.
> 
> The question is, is there some way to give you what you want, without
> creating a generic mechanism that has the property of assuming
> trustworthiness without proof of trustworthiness.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jan 2011 11:00:28 -0500

> If I now have e.g. multihomed Linux, often or usually the /etc/resolv.conf points to the DNS server address learned most recently via some mean (RA, DHCPv6). But people are not too worried what is…

The level of concern is that we are just getting to the point where we have a DNSSEC infrastructure that can be used to detect fraudulent DNS information.   And this proposal puts that at risk by providing a mechanism for subverting DNSSEC.   It does this because the whole point of the proposal is to prevent unnecessary duplication of effort: doing DNS lookups against all proposed DNS servers.

So the point is not that it makes things worse than the status quo, but rather that it potentially prevents a solution to a problem in the status quo that we thought we'd developed.

> Shouldn't we work e.g. on securing all DHCPv6 signaling?

Possibly, although it's not clear what the security model for such a thing would be, nor even if there is a single security model that would work.   That's why we've never successfully solved this problem.   We have mechanisms for securing the transport, but that says nothing about trustworthiness of information provided by the server.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Jan 2011 11:01:20 -0500

> Shouldn't we work e.g. on securing all DHCPv6 signaling?

I would say so, yes.

But note that this particular option makes it easier to target one
domain in particular.  That's a more directed attack, so it seems to
me to be a little more serious than "capture all the traffic".  It's
hard to spoof the entire Internet.  It might not be so hard to spoof
mycompany.com.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 16:01:35 +0000

> > You can ignore the option and talk to the DNS server of your
> preference. You can also choose to listen for the option only from one
> or more trusted sources.
> >
> 

E.g. by definition. Implement this only if you are a CPE or if you are 3GPP handset and then only for this class of interface. Or such. Those two scenarios are my main focus. Not believe what CoffeeShopFreeAP tells.

> > Of course there could be multiple search list from different
> interfaces. In such case you could prioritize the search lists by some
> means and start walking through the suffixes when resolving bare name.
> >
> 

I say some because I have not considered domain search list conflict resolution problem before this thread.

Well, if the host is openly multihomed and somewhere comes name "server", you could append it with all suffixes you know of and try resolve then all in parallel, connect in order of successful resolution:) .. if you don't know any difference between your interfaces.

Teemu

---

From: James Carlson <[email-masked]>
Date: Fri, 14 Jan 2011 11:10:49 -0500

> If I now have e.g. multihomed Linux, often or usually the /etc/resolv.conf points to the DNS server address learned most recently via some mean (RA, DHCPv6). But people are not too worried what is…

A rogue DHCPv6 server can add entries to that file, but can't delete
them.  Thus, it's possible for a bad DHCPv6 server to make life annoying
for a client, but (at least for DNS) it can't prevent the client from
eventually working.

The option (as described in this draft) effectively "deletes" addresses
from the list, by associating each address with a list of domains.
Having that list present for a given server but with no domain match
means no query will be sent to that server (or only "inappropriate"
queries sent) -- as though it were removed.

The shotgun approach you suggested in another reply may well fix that
problem, but isn't in the current draft.

Anyway, I don't seem to be making a great deal of headway, and I've
certainly got other things to do.  So, I've said my piece.  Drive on.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Jan 2011 11:58:23 -0500

On Fri, Jan 14, 2011 at 04:01:35PM +0000, [email-masked] wrote:
> 
> E.g. by definition. Implement this only if you are a CPE or if you
> are 3GPP handset and then only for this class of interface. Or
> such. Those two scenarios are my main focus. Not believe what
> CoffeeShopFreeAP tells.

And why, if you are a CPE, should you believe what you get via DHCP
either?  Lord knows I have seen rogue DHCP announcements on cable
modems.

Moreover, even supposing that's solved, how is the device supposed to
know when it is attached to CoffeeShopFreeAP and when it's attached to
SuperGoodWellMaintainedISPNet?  Isn't it completely ignorant at this
point?

> Well, if the host is openly multihomed and somewhere comes name
> "server", you could append it with all suffixes you know of and try
> resolve then all in parallel, connect in order of successful
> resolution:) .. if you don't know any difference between your
> interfaces.
 
My first response is ick, but that's my first response to all barename
resolution answers[1], so that's not a good test.  I think this is an
area where text is undoubtedly needed.  I'll think about it more, but
I urge others to do the same.

A

[1] The right answer is, of course, "Stop that," but the horse has
fled, the barn burned down, and the horse died years ago.  

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: <[email-masked]>
Date: Mon, 17 Jan 2011 10:29:44 +0000

In the current state a host with multiple interfaces would roughly randomly send DNS query over one interface to primary DNS server of that interface. The order may be determined e.g. by the order in which the interfaces were opened (if e.g. the DNS server learn first or last is preferred over others). 

Hence from DNS system point of view a current truly multi-homed host may already ask questions from any DNS server, and it will not ask from all.  

This option directs a host to ask question from some of the servers it could have anyway send its question to. How DNSSEC cannot manage to secure DNS queries in that case?

Best regards,

Teemu

> Sent: 14. tammikuuta 2011 18:00
> > If I now have e.g. multihomed Linux, often or usually the
> /etc/resolv.conf points to the DNS server address learned most recently
> via some mean (RA, DHCPv6). But people are not too worried what is the
> content of that file? I.e. attacker could just send new RA with DNS
> server address option and cause problems by drawing DNS traffic to that
> server?
> 
> The level of concern is that we are just getting to the point where we
> have a DNSSEC infrastructure that can be used to detect fraudulent DNS
> information.   And this proposal puts that at risk by providing a
> mechanism for subverting DNSSEC.   It does this because the whole point
> of the proposal is to prevent unnecessary duplication of effort: doing
> DNS lookups against all proposed DNS servers.
> 
> So the point is not that it makes things worse than the status quo, but
> rather that it potentially prevents a solution to a problem in the
> status quo that we thought we'd developed.
> 
> Possibly, although it's not clear what the security model for such a
> thing would be, nor even if there is a single security model that would
> work.   That's why we've never successfully solved this problem.   We
> have mechanisms for securing the transport, but that says nothing about
> trustworthiness of information provided by the server.

---

From: <[email-masked]>
Date: Mon, 17 Jan 2011 10:29:45 +0000

That particular case I have been told is protected against by using DNSSEC, which ensures the host will detect the fraudulent answer to this directed attack and will fall back to use other DNS server (or fail)...

If the host would have been single-homed, it would have send all its queries to the interface this attacker has control over.

Teemu

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Andrew Sullivan
> Sent: 14. tammikuuta 2011 18:01
> To: [email-masked]
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: <[email-masked]>
Date: Mon, 17 Jan 2011 10:29:46 +0000

> them.  Thus, it's possible for a bad DHCPv6 server to make life
> annoying for a client, but (at least for DNS) it can't prevent the client from
> eventually working.

The rogue DHCPv6 server can insert its DNS server as the preferred one. This server can then silently drop all DNS queries except the selected ones. In such case the resolver would silently fallback to use legitimate secondary DNS servers in all other cases except then in the one attacker is targeting at. Hence similar attack could be launched as with DNS server selection option.
 
> queries sent) -- as though it were removed.

I will address this risk.

> problem, but isn't in the current draft.

Luckily there are plenty of digits left for updates:)

Thank you for discussion!

	Teemu

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 17 Jan 2011 08:06:22 -0500

> That particular case I have been told is protected against by using DNSSEC, which ensures the host will detect the fraudulent answer to this directed attack and will fall back to use other DNS serv…

Right.  But I guess I'm confused: I thought you were arguing that
DNSSEC wasn't needed.

> If the host would have been single-homed, it would have send all its queries to the interface this attacker has control over.

Correct.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jan 2011 08:54:05 -0500

> This option directs a host to ask question from some of the servers it could have anyway send its question to. How DNSSEC cannot manage to secure DNS queries in that case?

Your assertions about the state of the art in DNS resolver implementations is probably correct.   However, essentially what you are proposing is to take this broken behavior as a standard, and then build new functionality on it.   The problem is that the behavior is broken, and shouldn't be a basis for building new functionality.   I don't disagree with your motivation for building the new functionality; the question is whether there's a way to do it that is not, like the status quo, broken.

The way your proposal breaks DNSSEC is by allowing an attacker to convince your resolver to treat a pre-arranged server as the authority for certain named zones.

Hm.   Okay, so the reason this is an issue is that I'm assuming the resolver doesn't do its own validation.   And you're right that if it doesn't do its own validation, it's not much worse off using this option than not using it; the degree to which its worse off is that this option allows the attacker to deterministically attack certain domains, whereas without the use of this option the attacker would, in a best-case scenario, be relying on chance to succeed in its attack.

If the resolver *does* validate to a known trust anchor, then it will discover any provable lie a perverted name server tells, even if it does the entire query through the perverted name server, because the perverted name server can't spoof the trust anchor (we *hope*)!

This actually makes me feel a lot better about the proposal.   I'd like to see the proposal require that the resolver validate any query itself if it uses the option; otherwise we're going to see interoperability problems with this option once resolvers *do* start validating, because people will have set their internal zones up wrong.

I think you also need to document the signing architectures that will work with this option: either don't sign the zone that contains referrals for the internal zone, or else sign two copies of the zone; one that's visible from outside and contains no referrals, and a second one that's visible from inside, and contains referrals.

The validating resolver obviously must use the substitute server for the entire query, not just for the queries in that subdomain, or it will get the wrong information from its query for the referral to the internal zone.

I realize this may not be agreeable to you, but if it is, I could attempt to write text for it.   I am not an expert on DNSSEC, so someone who is probably ought to read the text and criticize it.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 17 Jan 2011 09:22:56 -0500

On Mon, Jan 17, 2011 at 08:54:05AM -0500, Ted Lemon wrote:
 
> Hm.  Okay, so the reason this is an issue is that I'm assuming the
> resolver doesn't do its own validation.  And you're right that if it
> doesn't do its own validation, it's not much worse off using this
> option than not using it; the degree to which its worse off is that
> this option allows the attacker to deterministically attack certain
> domains, whereas without the use of this option the attacker would,
> in a best-case scenario, be relying on chance to succeed in its
> attack.

If the resolver doesn't do its own validation, then it is not allowed
to treat the AD bit as meaningful unless it can trust the DNS server
handing it that bit:

   In any case, a security-aware stub resolver MUST
   NOT place any reliance on signature validation allegedly performed on
   its behalf, except when the security-aware stub resolver obtained the
   data in question from a trusted security-aware recursive name server
   via a secure channel. 

(RFC 4035, section 4.9.3).  Presumably, then, the stub needs somehow
to have authenticated the DNS server in question otherwise before
accepting the claims about signature validation.  I can't think of any
way to do this under DHCP, but maybe I don't know the protocol well enough.
 
> I think you also need to document the signing architectures that
> will work with this option: either don't sign the zone that contains
> referrals for the internal zone, or else sign two copies of the
> zone; one that's visible from outside and contains no referrals, and
> a second one that's visible from inside, and contains referrals.

This is the point I was trying to make over on mif: I think that
there's a potential issue here with "closest TA" validation
strategies, but I suspect that we're going to need different TAs for
these "internal zone" cases.  Or something like that.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jan 2011 09:25:51 -0500

> way to do this under DHCP, but maybe I don't know the protocol well enough.

No, you know the protocol well enough.   This discussion has been making more and more clear to me the need for a DHCP security architecture document.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 17 Jan 2011 06:34:32 -0800

> No, you know the protocol well enough.   This discussion has been making more and more clear to me the need for a DHCP security architecture document.

Why bother?  IMO A better approach is NOT to try to patch DHCP/IPv6 Route Advertisements/ARP etc, but just ACCEPT these as insecure.  [1]

On a local broadcast network, the attacker is always a trivial MitM.  Securing DHCP, IPv6 Router Advertisements, ARP, etc, won't stop the attacker anyway.  The only thing that stops the attacker is application protocols which work in the face of a MitM.

Yet now its the same issue with DNSSEC for A records against a MitM who's also a MitM on final traffic:  The application is a customer of the final result from DNS/DHCP/ARP/etc....  And that application is either trivially vulnerable to a MitM OR doesn't actually need to care that DHCP, ARP, DNS, etc are secure, because such insecurity is no different than any other MitM.

[1] Not to mention it may be impossible to make these secure, since they are usually 'no initial point of trust bootstrap protocols'....

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jan 2011 09:59:14 -0500

> Why bother?  IMO A better approach is NOT to try to patch DHCP/IPv6 Route Advertisements/ARP etc, but just ACCEPT these as insecure.  [1]

Right, but people keep trying to treat them as if they conveyed some sort of trustworthiness.   Hence the need for a security architecture document.

> Yet now its the same issue with DNSSEC for A records against a MitM who's also a MitM on final traffic:  The application is a customer of the final result from DNS/DHCP/ARP/etc....  And that applic…

The application needs to get the address of a service to *try* before it can validate its trustworthiness.   If DNS is successfully spoofed, the application will, at best, simply fail, and at worst, it will reveal sensitive information to an attacker or cause damage (or both).

There are really four levels of security we could reasonably aspire to having:

- None: the DHCP server and/or DNS server can lie to the client with impunity, because it does not attempt to validate DHCP and/or DNS responses that it gets.
- Some: the DHCP server and/or DNS server's lies will be detected, but the client has no way to get the truth, so the lies amount to DoS attacks.
- Some more: the DHCP client and/or DNS resolver can detect rogue servers and can re-try the protocol using different servers in hopes of getting a working network connection, using cached information.
- Some more still: the DHCP client is configured with keys that it knows belong to trusted DHCP servers, and hence when it receives multiple offers, some of which come from trusted servers and some of which do not, can entirely avoid DoS attacks by using  a trusted server.

As you can see, none of these levels of security reliably protect the application layer, yet all of them except the first are clear usability improvements over the first.   So to say that there is no value in doing validation in these protocols is simply nonsense.   You could argue that there isn't enough value to justify going to the trouble, but there is value.

---

From: <[email-masked]>
Date: Wed, 19 Jan 2011 09:11:39 +0000

Hi,

> Your assertions about the state of the art in DNS resolver
> implementations is probably correct.   However, essentially what you
> are proposing is to take this broken behavior as a standard, and then
> build new functionality on it.   The problem is that the behavior is

Well, if the only standard is de facto standard then I think one must build on top of that:)

> The way your proposal breaks DNSSEC is by allowing an attacker to
> convince your resolver to treat a pre-arranged server as the authority
> for certain named zones.

No, this option is not intended to say a DNS server has any authority. This essentially says if lacking better information the pointed DNS server might be a good pick. And after your comments I have clarified to the draft that the host should not stick only to this DNS server, but can try also others.
 
> domains, whereas without the use of this option the attacker would, in
> a best-case scenario, be relying on chance to succeed in its attack.

Correct.

> This actually makes me feel a lot better about the proposal.   I'd like
> to see the proposal require that the resolver validate any query itself
> if it uses the option; otherwise we're going to see interoperability
> problems with this option once resolvers *do* start validating, because
> people will have set their internal zones up wrong.

Sounds good, will include in -01. Actually I assumed host validation already, but I didn't spell it out in the draft. 

Going off-topic a bit, maybe someone here could tell me in which case a host *can* trust DNS server to do the validation, save the case where host talks to DNS server over trusted access (e.g. VPN/IPsec or cellular)?

> I think you also need to document the signing architectures that will
> work with this option: either don't sign the zone that contains
> referrals for the internal zone, or else sign two copies of the zone;
> one that's visible from outside and contains no referrals, and a second
> one that's visible from inside, and contains referrals.

This makes me feel even more so that the draft should have co-author with deep DNSSEC expertise.. 

> The validating resolver obviously must use the substitute server for
> the entire query, not just for the queries in that subdomain, or it
> will get the wrong information from its query for the referral to the
> internal zone.
 
Let try to follow this. If resolver gets CNAME/DNAME reply, it must send following queries to the same DNS server?

> I realize this may not be agreeable to you, but if it is, I could
> attempt to write text for it.   I am not an expert on DNSSEC, so
> someone who is probably ought to read the text and criticize it.

I would very much welcome you, or someone with better DNSSEC knowledge than I do, to co-author the document. By the time of IETF#80 deadline should be just fine.

Anyhow, it is MIF that will eventually decide what is agreeable, as this is now MIF WG doc. However, for me personally it is easier to judge when we have text in I-D rather than on hundred emails:)

Teemu