Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 3 Jan 2011 12:17:50 -0800

Hello Hui,

I have reviewed the mailing list discussion about this draft and I think that Ted Lemon makes a valid point that in its current form it is not a good solution because it introduces security vulnerabilities that can cause harm.

As a result I do not think we should adopt this draft prior to reaching an agreement on the mailing list as to how the security vulnerabilities introduced by the draft in its current form are to be addressed.

I believe that Ted has made one such proposal (implementation of this specification MUST use DNSSEC) but so far there was no agreement reached. This has to be worked out now, not when the document is held back by a bad SECDIR review.

Thanks,

--julien

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hui Deng
Sent: Tuesday, December 21, 2010 7:03 PM
To: MIF Mailing List; Margaret Wasserman
Subject: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection

Hello,

Based on the last Beijing meeting, we have received one major concern for the dns draft.
After the meeting discussion, it seems it has made the progress with the major people involved.

And historically, this drat has received support as well, based on that
we are now asking the mailing list about adoption of this draft.

If we don't hear any objection by next wednesday, then we are going to
adopt this darft as the working group document,

Thanks

-Hui

---

From: <[email-masked]>
Date: Mon, 3 Jan 2011 22:54:21 +0000

Hi Julien,

We would also like to actually progress with this document, not wait forever for comments or proposals that may never arrive. I more than welcome suggestions that improve the document.

My personal opinion is that DNSSEC should not be MUST, as it does not appear to be MUST in the Internet for the time being (or it would be as strong MUST as the IPsec was MUST in IPv6 requirements RFC). Also, there are tighly controlled deployment scenarios, where it is hard to imagine DNSSEC brings much additional security. E.g. the CPE case with two uplink VLAN interfaces and receiving server selection rules from trusted gateways, alongiside with routing rules and other information.

My understanding at this point is that the DNSSEC SHOULD (or MUST, if WG so chooses) to be used in the general Internet access case, but in tightly controlled environments deviation from DNSSEC use should continue to be possible. But I am happy to leave this for the working group to decide, I'm just pointing that MUST is not black and white here. After all, security level is often implementation decision.

Furthermore, wouldn't the discussion of whether DNSSEC is MUST or SHOULD be part of the working group process after the document has been adopted - to be decided before WG sends the doc to IESG. After all, we do have charter that specifies that DHCPv6 based solution shall be defined.

Best regards,

Teemu

________________________________
From: [email-masked] [[email-masked]] on behalf of ext Laganier, Julien [[email-masked]]
Sent: Monday, January 03, 2011 10:17 PM
To: Hui Deng; MIF Mailing List; Margaret Wasserman
Cc: Ted Lemon
Subject: Re: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection

Hello Hui,

Thanks,

--julien

Hello,

Thanks

-Hui

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 3 Jan 2011 15:39:22 -0800

Hi Teemu,

I do not see why the discussion on how the proposed mechanism can be secured would have to be deferred to the WG until after the document has been adopted. On the contrary, and as explained at length by Ted earlier, the mechanism in its current form is not acceptable unless provided with adequate security.

Thus the question of whether the mechanism you propose is fit for this WG to standardize is contingent to this WG finding an agreement on how it can be secured.

Thus this is what we should do first: discuss how to do what you want to do securely, because if we can't find an agreement on that, maybe we shouldn't be doing what you want to do in the first place.

As to DNSSEC being a MUST or not in the tightly controlled environment you evocate, I feel it might be OK to not require DNSSEC in those insofar an implementation (S/W stack) can securely determine if it is in such an environment.  Although "security level is often implementation decision", from my perspective security is not optional :)

Best,

--julien

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 03, 2011 2:54 PM
To: Laganier, Julien; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection

Hi Julien,

Best regards,

Teemu

Thanks,

--julien

Hello,

Thanks

-Hui

---

From: <[email-masked]>
Date: Tue, 4 Jan 2011 07:07:18 +0000

Hi Julien,

I'm not proposing we should defer the discussion of how to secure things, I'm saying we should not continue postpone progress of this work indefinitely waiting for discussion not taking place. E.g. during the past two months since Beijing I haven't seen any discussion on this list about this.

We can discuss now for sure.

I would like to discuss the real severity of the attack vector in more depth. As far as I understood the concern was that the attacker selects a small subset of names (e.g. a single name) that it wants to give malicious DNS reply. As the subset of names being attacked would be small, it would be nontrivial to see attack is ongoing (or pending - most of the private names would resolve just fine).

Now what if instead of this technology the node's implementation would be such that it always sends DNS queries to all DNS servers (at least one server per interface). In the usual case it could happen that it gets positive replies for questions (for *.corporate.com) sent over VPN, and NXDOMAIN when sent to DNS server of the visited WLAN (for example). Now couldn't the attacker on WLAN currently do it so that when the question to this specific server name comes, the visited network's DNS server would not reply NXDOMAIN, but positive answer instead? And as the visited networks DNS server is likely faster to reply than the server behind the VPN, similar redirection attack could be accomplished?

Or what if the attacker provides malicious RFC3646 search list option having "attacker.com" and reply NXDOMAIN until host asks for "targeted.server.corporate.com.attacker.com" and reply that with positive answer and hence take the traffic? (This is explained in section 6 of RFC3646). In that case even DNSSEC does not help.

If the DNSSEC is the only concern you have, can't we just make a call to WG on who thinks it should be MUST and who thinks it should be SHOULD? But in presence of other DNS attacks, couldn't you separate DNSSEC requirement from individual tools, and just mandate DNSSEC implementation to cover all kinds of threats?

Best regards,

Teemu

________________________________
From: ext Laganier, Julien [[email-masked]]
Sent: Tuesday, January 04, 2011 1:39 AM
To: Savolainen Teemu (Nokia-MS/Tampere); [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection

Hi Teemu,

Thus this is what we should do first: discuss how to do what you want to do securely, because if we can’t find an agreement on that, maybe we shouldn’t be doing what you want to do in the first place.

As to DNSSEC being a MUST or not in the tightly controlled environment you evocate, I feel it might be OK to not require DNSSEC in those insofar an implementation (S/W stack) can securely determine if it is in such an environment.  Although “security level is often implementation decision”, from my perspective security is not optional :)

Best,

--julien

Hi Julien,

Best regards,

Teemu

Thanks,

--julien

Hello,

Thanks

-Hui

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 5 Jan 2011 22:49:15 +0900

Hi,

> Thus the question of whether the mechanism you propose is fit for this WG to standardize is contingent to this WG finding an agreement on how it can be secured.

From wg progress aspect, as of mif wg charter, we expect that the wg doc will be appeared in this January, along with milestone in the charter.
So,

> Thus this is what we should do first: discuss how to do what you want to do securely, because if we can’t find an agreement on that, maybe we shouldn’t be doing what you want to do in the first pla…

I thinks that the first thing we should do is that adopting wg doc if any other solution doesn't come up with attractive technology.
The PS document of mif already stated about this. This is well known issue.

>  
> As to DNSSEC being a MUST or not in the tightly controlled environment you evocate, I feel it might be OK to not require DNSSEC in those insofar an implementation (S/W stack) can securely determine if it is in such an environment.  Although “security level is often implementation decision”, from my perspective security is not optional J
>  

From technical aspect, this is proposal for DNS "Server" selection. Anybody who want to use DNSSEC can use it because using DNSSEC depends on DNS server and client. It means that any dhcpv6 option cannot force or avoid to use DNSSEC. Of course this is not obstacle to use DNSSEC.

I think that there is no show stopper of the adoption.

Best regards,

--
Satoru Matsushima

---

From: Zhen Cao <[email-masked]>
Date: Thu, 6 Jan 2011 11:56:16 +0800

Hi Julien,

I do not agree with you and would like to support the adoption of this
draft in current form. The solution in the draft is straightforward
and tackles the problem of the current environment where DNSSEC is not
de-facto.  DNSSEC considerations can be put into the security analysis
section which is informational enough.

Regards,
Zhen
On Tue, Jan 4, 2011 at 4:17 AM, Laganier, Julien <[email-masked]> wrote:
> Hello Hui,
>
>
>
> I have reviewed the mailing list discussion about this draft and I think
> that Ted Lemon makes a valid point that in its current form it is not a good
> solution because it introduces security vulnerabilities that can cause harm.
>
>
>
> As a result I do not think we should adopt this draft prior to reaching an
> agreement on the mailing list as to how the security vulnerabilities
> introduced by the draft in its current form are to be addressed.
>
>
>
> I believe that Ted has made one such proposal (implementation of this
> specification MUST use DNSSEC) but so far there was no agreement reached.
> This has to be worked out now, not when the document is held back by a bad
> SECDIR review.
>
>
>
> Thanks,
>
>
>
> --julien
>
>
>
> Subject: [mif] Confirm call for
> adoption:draft-savolainen-mif-dns-server-selection
>
>
>
> Hello,
>
>
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>
>

-- 
Best regards,
Zhen

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 6 Jan 2011 19:02:10 +0100

I support the WG adoption of this draft.

Regards,
Woj.

On 6 January 2011 04:56, Zhen Cao <[email-masked]> wrote:

> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hui
> > Deng

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 6 Jan 2011 15:14:12 -0800

Hi Teemu,

> I'm not proposing we should defer the discussion of how to secure things, I'm
> saying we should not continue postpone progress of this work indefinitely
> waiting for discussion not taking place. E.g. during the past two months
> since Beijing I haven't seen any discussion on this list about this.

I don't think we're stalled: The period straight after an IETF meeting is
usually pretty quiet because everyone has to catch up with the other business
that wasn't taken care of during the meeting, and then there was the holiday
season. 

I also do not equate adoption as WG draft to progress. This work can progress
(a lot) without this specific draft being a WG draft by having the WG coming to
consensus on how to do this DHCP-based DNS server selection securely. This will
be a pre-requisite for publication anyway.

> We can discuss now for sure. 

Right, almost everybody should be back from holidays by now so let's do just
that...

> I would like to discuss the real severity of the attack vector in more depth.
> As far as I understood the concern was that the attacker selects a small
> subset of names (e.g. a single name) that it wants to give malicious DNS
> reply. As the subset of names being attacked would be small, it would be
> nontrivial to see attack is ongoing (or pending - most of the private names
> would resolve just fine). 

I am not sure the subset of names necessarily needs to be small. An attacker
could inject on the WLAN a DHCPv6 DNS selection option with .com or '.' (i.e. global)
as a prefix and declare itself as high preference and be able to divert all
of that traffic if the other interface has no DHCP server sending such a DNS selection
option.

> Now what if instead of this technology the node's implementation would be
> such that it always sends DNS queries to all DNS servers (at least one server
> per interface). In the usual case it could happen that it gets positive
> replies for questions (for *.corporate.com) sent over VPN, and NXDOMAIN when
> sent to DNS server of the visited WLAN (for example). Now couldn't the
> attacker on WLAN currently do it so that when the question to this specific
> server name comes, the visited network's DNS server would not reply NXDOMAIN,
> but positive answer instead? And as the visited networks DNS server is likely
> faster to reply than the server behind the VPN, similar redirection attack
> could be accomplished?

Right. Which is why if you have DNSSEC you'd wait for all answers from all 
interfaces first before returning to the application. Alternatively, if the
stack knew that one of the interface (WWAN) is more trusted than the other
(unauthenticated WLAN) it would wait for the answer from the more trusted
interface to return to the application.

> Or what if the attacker provides malicious RFC3646 search list option having
> "attacker.com" and reply NXDOMAIN until host asks for
> "targeted.server.corporate.com.attacker.com" and reply that with positive
> answer and hence take the traffic? (This is explained in section 6 of
> RFC3646). In that case even DNSSEC does not help.

RFC3646 specically says: 

   2. Resolve a name that contains any dots by first trying it as an
      FQDN and if that fails, with the names in the searchlist appended.

If there are indeed multiple alternative DNS servers on different network
interfaces providing multiple search lists, I would interpret the above
"resolve a name that contains any dots by first trying it as an FQDN on all
interfaces, and if that fails, with the names in the search list for the
respective interface appended." That seems to be to be the sensible way to
extend the 3646 provision to a multi-interfaced host.

> If the DNSSEC is the only concern you have, can't we just make a call to WG
> on who thinks it should be MUST and who thinks it should be SHOULD? But in
> presence of other DNS attacks, couldn't you separate DNSSEC requirement from
> individual tools, and just mandate DNSSEC implementation to cover all kinds
> of threats?

No offense but in the end, whatever the WG rough consensus is, if it does
introduce security vulnerabilities the draft is going to held on by the SEC AD. 

DNSSEC is not the only concern I have, I have actually outline another way to use that option in a less problematic manner than currently proposed: 

> > As to DNSSEC being a MUST or not in the tightly controlled environment you
> > evocate, I feel it might be OK to not require DNSSEC in those insofar an
> > implementation (S/W stack) can securely determine if it is in such an
> > environment.  

So maybe we ought to say that when receiving a DNS server selection option
from an untrusted network interface (e.g., unauthenticated WLAN, as opposed
to corporate WLAN or WWAN), the node MUST tries to resolve FQDN through DNS
servers on each of the interface to try to obtain DNSSEC protected DNS replies. 

This way DNSSEC isn't a MUST, but if it is deployed, the node is in a position
to avoid the DNS redirection attack that Ted originally outlined.

What do you think?

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 6 Jan 2011 15:33:38 -0800

Hi,

On 2011/01/04, at 8:39, Laganier, Julien wrote:
>  
> > I do not see why the discussion on how the proposed mechanism can be
> > secured would have to be deferred to the WG until after the document has
> > been adopted. On the contrary, and as explained at length by Ted earlier,
> > the mechanism in its current form is not acceptable unless provided with
> > adequate security.
> > 
> > Thus the question of whether the mechanism you propose is fit for this WG
> > to standardize is contingent to this WG finding an agreement on how it can
> > be secured.
>
> From wg progress aspect, as of mif wg charter, we expect that the wg doc will
> be appeared in this January, along with milestone in the charter.
> So,

>From my perspective the fact that a work item is late and about to miss one of 
its milestones is not a reason to rush WG adoption of a document that has 
security issues pointed out by WG participants.
 
> > Thus this is what we should do first: discuss how to do what you want to do
> > securely, because if we can't find an agreement on that, maybe we shouldn't
> > be doing what you want to do in the first place.
> 
> I thinks that the first thing we should do is that adopting wg doc if any 
> other solution doesn't come up with attractive technology.

The first thing you should do is propose a solution that seems to be adequate
and does not introduce security vulnerabilities. Let's not allow the cure to
be worse than the disease.

> > environment.  Although "security level is often implementation decision",
> > from my perspective security is not optional J
>
> From technical aspect, this is proposal for DNS "Server" selection. Anybody
> who want to use DNSSEC can use it because using DNSSEC depends on DNS server
> and client. It means that any dhcpv6 option cannot force or avoid to use
> DNSSEC. Of course this is not obstacle to use DNSSEC.
>

As I have outlined in my other note to Teemu, it seems to me that this option
would defeat DNSSEC in case an attacker is able to inject such a DNS server
selection option with high priority. I have also outlined some strawman on how
the DNS server selection option could be made acceptable by treating it
differently depending on whether it comes from a trusted (authenticated) or
untrusted (unauthenticated) network.  At this point my position is that this
can and should be captured in the document before I feel comfortable endorsing
it.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 6 Jan 2011 15:38:34 -0800

Woj,

> I support the WG adoption of this draft.

Would you care to explain on the mailing list the reasons you support adoption of a solution in spite of that solution defeating DNSSEC in some situations?

--julien

---

From: <[email-masked]>
Date: Fri, 7 Jan 2011 00:21:52 +0000

Hi Julien,

> of that traffic if the other interface has no DHCP server sending such

If you would not have the new option, then you would have an implementation randomly picking DNS server from one interface or form another, hence being vulnerable for this attack (but less systematically, I admit).

If the implementation is not randomly picking DNS servers, but prefers DNS servers of interfaces it considers more trustworthy (e.g. VPN or cellular), then maybe such implementation should choose to listen for this new option only on the interfaces it trusts (and in fact, not use the hotspot WLAN's honey pot DNS server at all if possible (ah so fast but results are .. something)).

> interfaces first before returning to the application. 

I'm not sure I see how this relates to point I was making... The DNSSEC indeed helps with the new option as well - if you get DNSSEC validation failure you can fallback to use another DNS server.

>Alternatively, if
> the

I think I had something in revision -03 of my draft, but I got then some negative feedback for that approach:
--
   1.  Managed tunnel interfaces (such as VPN) considered most
       trustworthy

   2.  Managed networks being on the middle

   3.  Unmanaged networks having lowest priority

   Now, for example, if all of the three abovementioned networks would
   advertise 'corporation.com' DNS suffix, the host would prefer the VPN
   network interface for related DNS resolution requests.
--

I admit that version did not take into account the case you made: no conflict to resolve but interface with attacker is luring DNS traffic that should've been sent out of another interface (but the another interface did not advertise anything). 

>       FQDN and if that fails, with the names in the searchlist

Right, but couldn't an attacker who can compromise DHCPv6 server on the access network also change the DNS server address host gets to his own, and then from that DNS server reply with NXDOMAIN or whatever to the basic FQDN resolution request, and thus forcing host to go to searchlist procedures, and then answer positively to FQDN containing the appended suffix that validates ok with DNSSEC?

> extend the 3646 provision to a multi-interfaced host.

But see, we don't want to sent queries always to all interfaces. Only once to right interface.

> introduce security vulnerabilities the draft is going to held on by the

I definitely do prefer sorting out issues sooner or later:) 

Maybe pointing out vulnerabilities in other possible approaches doesn't help so much to progress.. 
 
> DNSSEC is not the only concern I have, I have actually outline another
> way to use that option in a less problematic manner than currently
> proposed:

Let's see..

> to avoid the DNS redirection attack that Ted originally outlined.

Let me think, do you mean that in the case of DNS server of the untrusted network interface would have the highest priority (when node thinks about where to send a query), node should additionally send queries also to trusted interfaces and then collect replies? But for the queries where the DNS server of a trusted interface would have highest priority, node could send DNS query just over the trusted interface?

Could you implement that also so that whatever untrusted network tells you, you prioritize it lowest. I.e. if DNS queries would be sent out in series rather than parallel, first query would go to the default DNS server of trusted interface, and only if that fails query would go to specific server of untrusted interface?

What do you think about the case when untrusted but preferred interface (say WLAN) has no new options (just the old DNS configuration option), and the trusted but otherwise less preferred interface (say 3G) has also default DNS server option, but additionally some high priority rules with new option. The queries matching high priority rules would go to trusted interface for usre, but what about the "default" queries? Where those should be sent?

In more general terms, should the default queries always be sent over the most trusted interface first (if you don't want to use all interfaces)? This is actually the case already today if you would have device with WLAN and cellular IPv4/IPv6 interfaces. Which do you use for DNS (I guess currently it oftentimes happens that the interface last opened would be used - but wouldn't that be a security risk)? 

Should existing multihomed device send DNS queries always over the most trusted interfaces, even if that results in latency penalty?

Best regards,

Teemu

---

From: <[email-masked]>
Date: Fri, 7 Jan 2011 00:28:32 +0000

> can and should be captured in the document before I feel comfortable

I will work tomorrow to see if I can grab enough input from your last email (and your possible reply to my reply) to do improvements, and we can then see how the result would look like (i.e. on Monday, if things go well). 

We also have "just" two authors on the document currently. I do welcome direct textual contributions as well:-)

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Fri, 7 Jan 2011 12:33:55 +0000

Hi all,

I worked out today -06 version of the draft, please see how it looks on security aspects.

http://www.ietf.org/id/draft-savolainen-mif-dns-server-selection-06.txt

Changes focused on section 3 as the normative text is there. But there were some changes here and there in order to be more consistent and also to do some other fixes (e.g. reference to OPTION_ORO). Security Considerations section was rewritten and I collected some of the discussions and considerations there

Please also comment if you think some of the changes caused by increased security considerations here and there takes work to wrong direction.

Best regards,

Teemu

> -----Original Message-----
> Savolainen Teemu (Nokia-MS/Tampere)
> Sent: 07. tammikuuta 2011 02:22
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> > could inject on the WLAN a DHCPv6 DNS selection option with .com or
> '.'
> > (i.e. global)
> > as a prefix and declare itself as high preference and be able to
> divert
> > all
> > of that traffic if the other interface has no DHCP server sending
> such
> > a DNS selection
> > option.
> 
> If you would not have the new option, then you would have an
> implementation randomly picking DNS server from one interface or form
> another, hence being vulnerable for this attack (but less
> systematically, I admit).
> 
> If the implementation is not randomly picking DNS servers, but prefers
> DNS servers of interfaces it considers more trustworthy (e.g. VPN or
> cellular), then maybe such implementation should choose to listen for
> this new option only on the interfaces it trusts (and in fact, not use
> the hotspot WLAN's honey pot DNS server at all if possible (ah so fast
> but results are .. something)).
> 
> > Right. Which is why if you have DNSSEC you'd wait for all answers
> from
> > all
> I'm not sure I see how this relates to point I was making... The DNSSEC
> indeed helps with the new option as well - if you get DNSSEC validation
> failure you can fallback to use another DNS server.
> 
> >Alternatively, if
> > the
> I think I had something in revision -03 of my draft, but I got then
> some negative feedback for that approach:
> --
> I admit that version did not take into account the case you made: no
> conflict to resolve but interface with attacker is luring DNS traffic
> that should've been sent out of another interface (but the another
> interface did not advertise anything).
> 
> > > Or what if the attacker provides malicious RFC3646 search list
> option
> > having
> Right, but couldn't an attacker who can compromise DHCPv6 server on the
> access network also change the DNS server address host gets to his own,
> and then from that DNS server reply with NXDOMAIN or whatever to the
> basic FQDN resolution request, and thus forcing host to go to
> searchlist procedures, and then answer positively to FQDN containing
> the appended suffix that validates ok with DNSSEC?
> 
> > "resolve a name that contains any dots by first trying it as an FQDN
> on
> > all
> > respective interface appended." That seems to be to be the sensible
> way
> > to
> > introduce security vulnerabilities the draft is going to held on by
> the
> > SEC AD.
> 
> > > > implementation (S/W stack) can securely determine if it is in
> such
> > an
> > > > environment.
> >
> > to corporate WLAN or WWAN), the node MUST tries to resolve FQDN
> through
> > DNS
> > servers on each of the interface to try to obtain DNSSEC protected
> DNS
> > replies.
>  >
> Let me think, do you mean that in the case of DNS server of the
> untrusted network interface would have the highest priority (when node
> thinks about where to send a query), node should additionally send
> queries also to trusted interfaces and then collect replies? But for
> the queries where the DNS server of a trusted interface would have
> highest priority, node could send DNS query just over the trusted
> interface?
> 
> Could you implement that also so that whatever untrusted network tells
> you, you prioritize it lowest. I.e. if DNS queries would be sent out in
> series rather than parallel, first query would go to the default DNS
> server of trusted interface, and only if that fails query would go to
> specific server of untrusted interface?
> 
> What do you think about the case when untrusted but preferred interface
> (say WLAN) has no new options (just the old DNS configuration option),
> and the trusted but otherwise less preferred interface (say 3G) has
> also default DNS server option, but additionally some high priority
> rules with new option. The queries matching high priority rules would
> go to trusted interface for usre, but what about the "default" queries?
> Where those should be sent?
> 
> In more general terms, should the default queries always be sent over
> the most trusted interface first (if you don't want to use all
> interfaces)? This is actually the case already today if you would have
> device with WLAN and cellular IPv4/IPv6 interfaces. Which do you use
> for DNS (I guess currently it oftentimes happens that the interface
> last opened would be used - but wouldn't that be a security risk)?
> 
> Should existing multihomed device send DNS queries always over the most
> trusted interfaces, even if that results in latency penalty?
> 
> Best regards,
> 
> Teemu