Subject: Re: [mif] Last Call for MIF DNS server selection document

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Sep 2011 16:07:55 +1200

Hi,

Has this document been reviewed in DNSEXT and DNSOP?

If not, I would strongly recommend that before asking the AD
to review it in detail. I would expect considerable discussion of
the following text and its consequences:

>    In deployments where multiple namespaces are present, selection of
>    correct route and destination and source addresses for the actual IP
>    connection is crucial as well, as the resolved destination's IP
>    addresses may be only usable on the network interface over which the
>    name was resolved on.

Regards
   Brian Carpenter

On 2011-08-29 19:31, Hui Deng wrote:
> Hello all,
>  
> Based on the last IETF mif meeting, we are issueing working group last call for the document:
> http://tools.ietf.org/id/draft-ietf-mif-dns-server-selection-03.txt
>  
> This is a 2 week LC, it will finish on September 12,
> Please send substantive review and editorial comments to [email-masked], 
>  
> thanks,
>  
> Margaret and Hui
>   		 	   		  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 06:16:07 +0000

Brian,

Thank you for review. I agree it is a good idea to consult those WGs (and

> >    addresses may be only usable on the network interface over which the

I wrote that as I thought it would be useful to talk a little about bigger
picture of some deployments (like in the demo we had few IETFs back -
without presence of DHCPv6 more specific route options the system would not
have worked properly) .. but if that text creates an unwanted link or
dependency or confusion, I think we can drop the text just as well and focus
on the document just to the new options and leave this kind of additional
system-level consideration out of the doc.

Best regards,

Teemu

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 8 Sep 2011 16:43:30 -0400

Dear colleagues,

> http://tools.ietf.org/id/draft-ietf-mif-dns-server-selection-03.txt

I have read this document, and previous drafts.

I have some comments.

First, about nits: there are several places where the document needs a
good once-over for correct usage, grammar, and spelling.  Articles
seem to be missing in many places.  It'd be good to sort this out, but
I can understand the document without this being fixed & I'm sure the
RFC Editor will fix it anyway.  I'm not going to send a list of nits
just now because I have too many substantive comments.

As an overall comment, there are sections of the document that explain
the motivation and background, and sections of the document that
prescribe steps to be taken.  The former are informative, and the
latter normative.  I suggest including near the beginning an overview
stating what sections are informative and what are normative, and
breaking those sections cleanly (i.e. no explanatory text in the
normative sections). 

At the beginning of the draft we have this:

   When multiple namespaces are visible for a node, some DNS servers
   have information other servers do not have.  Because of that, a
   multi-homed node cannot assume every DNS server is able to properly
   answer for any query, but instead the node must be able to ask right
   server for the information it needs.

I've had a hard time expressing why this text has been bothering me,
but I think I understand what it is: that text is not explicit enough
that it is starting from the premise that the DNS is not a unified
global namespace.  I think it needs another sentence, at the
beginning, along the following lines:

    We start from the premise that operators sometimes include private
    namespaces in the answers they provide from DNS servers, and that
    those private namespaces are at least as useful to clients as the
    answers from the public DNS.

The next paragraph is not really convincing as it stands:

   An example of an application that benefits from multi-homing is a web
   browser that commonly accesses many different destinations and needs
   to be able to dynamically communicate over different network
   interfaces.

I think what that actually means is this:

   An example of an application that benefits from multi-homing is a
   web browser that commonly accesses many different destinations,
   each of which is available only on one network.  The browser
   therefore needs to be able to communicate over different network
   interfaces, depending on the destination it is trying to reach.

The key point here, I think, is that the networks are disparate and
not actually all available via the public network.  By making these
adjustments, it makes the document more open-handed about the fact
it's trying to address: there are all kinds of pockets on the
Internet, and you have to connect to different pockets via different
means.

In section 4.1, we have this:

   When a DNS query needs to be made, the resolver SHOULD give highest
   precedence to the DNS servers explicitly known to serve matching
   suffixes or prefixes.

I really dislike the term "suffix" here, and I'm not sure "prefix" is
what you want either.  I think "suffix" really means "domain", right?
That is, if I offer a DNS server that is high-priority for
example.com, it can answer for anything from example.com all the way
down.  No?  Similarly, you might just want "networks" for the reverse
tree, since "prefix" doesn't exactly get it right: the network address
is turned around in the DNS query.  (This also appears elsewhere in
the draft, but I won't mention it again unless I'm proposing text.)
"Prefix" is probably fine if you make it clear that you're providing
the prefix of a network, and that it's the client's job to do the
right thing with that prefix in order to formulate reverse-tree DNS
queries.

Next,

   However, the resolver SHOULD take into account
   different trust levels of pieces of DNS server selection information
   the resolver may have received from node's network interfaces.  The
   resolver SHOULD prefer DNS servers of trusted interfaces.

Why isn't this MUST?  This entire procedure is hard for me to follow,
in fact.  It seems to me that we have two different meanings of
"trust" here, and I think that may be part of the problem.  The first
meaning (trust1) is "a setting that comes with the information that
DNS server S on interface I provides namespace N with trust-level T".
This is a trust-value that is metadata provided by the provider of the
name server address-interface binding.  The second meaning (trust2) is
how much you, the client, believe the data you got: did you get the
trust1 data in a way that you can be sure it's legitimate?  It seems
to me that combining trust1 and trust2 into a single scale might be
wrong, and I think that the last row in Figure 4 suggests this.  If I
simply don't know whether the data I get on interface B is real or
spoofed, why would I ever use that, even if it's "medium priority",
over the data I can be sure is an unspoofed answer on interface A?

Also, I think this sentence is missing an "un" before some "trusted":

   The DNS servers of trusted interfaces may be of highest priority
   only if trusted interfaces specifically configure DNS servers to be
   of low priority.

I think the discussion just after Figure 4 about revealing information
about ongoing communications is total nonsense, and should be removed.
If you want to put names in the DNS, they're never going to be secret.
The attempts to use split-brain DNS and so on for hiding network
resources are a completely misguided attempt at security by obscurity,
and I don't think the draft should include any text that even implies
this technique works.  Private DNS names leak all over the place, and
if you think otherwise you're dreaming.

Later, we have

   Because DNSSEC provides cryptographic assurance of the integrity of
   DNS data, data that can be validated under DNSSEC is necessarily to
   be preferred over data that cannot be.  It follows that, if
   validation is not performed by the host making the decision about
   whether to trust the DNS data from a given interface, it cannot make
   a decision to prefer data from any interface with any great
   assurance: any response could be forged, and there is no way to
   detect it without DNSSEC.

That isn't true.  If you have a cryptographically strong connection to
a DNS server and you know that it is doing DNS validation (because,
for instance, your corporate overlords told you, "We do validation on
the VPN DNS server"), you do in fact have a reason to prefer the
answers from that server.  You might set DO and not CD, and get back
the AD bit on your answer, giving you evidence that the validation was
done by the server.  I think the paragraph can be rewritten this way
(although this includes some explanatory material and some normative
material; as I suggested above, perhaps that ought to be split).

   Because DNSSEC provides cryptographic assurance of the integrity of
   DNS data, data that can be validated under DNSSEC is necessarily to
   be preferred over data that cannot be.  There are two ways that a
   host can determine that data is valid under DNSSEC.  The first is
   to perform DNSSEC validation itself.  The second is to have a
   secure connection to an authenticated DNS server, and to rely on
   that DNS server to perform DNSSEC validation (signalling that it
   has done so using the AD bit).  If a DNS response is not proven to
   be unmolested using DNSSEC, then a host cannot make a decision to
   prefer data from any interface with any great assurance: any
   response could be forged, and there is no way to detect the forgery
   without DNSSEC.  Therefore, a DNSSEC-aware resolver MUST NOT
   proceed with a reply that cannot be validated using DNSSEC if DNS
   queries sent to other servers are still pending.

This instruction seems to contradict the previous text:

   In the case of a trusted DNS server replying negatively to a question
   having matching suffix, it will be for implementation to decide
   whether to consider that as a final response, or whether to ask also
   from other DNS servers.  The implementation decision may be based,
   for example, on deployment or trust models.

Instead of "matching suffix", we could say something like "from a DNS
server that can provide answers for the queried name".  But I think
what this is saying is that, if you get a validated NXDOMAIN from an
interface, you're allowed to go on and ask other servers.  Even if the
answer can't be validated?  If so, this seems to contradict the
passages before it, and it's clearly an attack vector on DNSSEC's
provable non-existence.  Some people think that feature is dumb, but
it's part of what DNSSEC offers now, and it would be strange to
introduce a way to turn it off.  I'd add a reference here to the
"different trust anchor" discussion in Appendix B.  See also below.

I can't see anything you can do about cases where a DNS server always
lies to you.  On the other hand, if you do DNSSEC, those servers will
always fail validation anyway, so we can hope they'll meet the fate
they deserve.

In section 4.2, I don't understand, "IPv6 prefixes should cover all
the DNS suffixes configured in this option."  Maybe I've actually
misunderstood the use of "prefix" and "suffix" in this document?

In section 4.5, I find this odd:

   The OPTION_DNS_SERVER_SELECT is designed to coexist with
   OPTION_DNS_SERVERS defined in [RFC3646].  The DNS servers configured
   via OPTION_DNS_SERVERS MUST BE considered as default name servers
   with medium preference.  When both options are received from the same
   network interface and the OPTION_DNS_SERVER_SELECT contains default
   DNS server address, the resolver MUST make the decision which one to
   prefer based on preferences.

I read that to mean that, if you get both options and the
OPTION_DNS_SERVER_SELECT contains a default DNS server address, then
the behaviour is up to you (i.e. undefined).  Why is that a MUST?  Why
isn't it just "... the resolver MAY use whichever option it likes"?

In the same section, does this

   If both OPTION_DNS_SERVERS and OPTION_DNS_SERVER_SELECT contain the
   same DNS server(s) IPv6 address(es), only one instance of each DNS
   servers' IPv6 addresses shall be added to the DNS server list.

mean "only add the same address of a DNS server to the server list
once"?  The passage as it is reads to me as though you might throw
away some addresses you get.

In section 4.6., I think that it needs to be made clear that a bare
name is first treated as a pre-DNS hostname before it encounters the
DNS search list.  (Frankly, that entire mechanism is broken, and it
would suit me just fine if the document said, "This algorithm is
incompatible with the DNS search list and the OPTION_DOMAIN_LIST
feature."  But I know people would scream about it.  It's still
broken.)

In 4.7, what about other things that could do context-sensitive
referrals, like SRV?

In A.1, the same discussion about revealing information as above
pertains.

Appendix B is interesting because it addresses a concern I have about
what to do when validation succeeds on an NXDOMAIN, as discussed above
under section 4.1.

I hope these comments are useful.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Sep 2011 09:02:26 +1200

Teemu,

> system-level consideration out of the doc.

As Andrew pointed out, the draft starts

   "...from the premise that operators sometimes include private
    namespaces in the answers they provide from DNS servers, and that
    those private namespaces are at least as useful to clients as the
    answers from the public DNS."

I believe that you will discover during IETF LC that many people have
strong feelings about this premise; as Andrew implied, conceptually
the DNS is a unified global namespace. This draft is a backdoor
way of legitimising an ambiguous namespace. I don't think that will
have an easy time in IETF LC, especially if it is dropped as a surprise
into the DNS community. It's your choice, but I would suggest that
exposing it to the DNS WGs now would be a smart move.

It goes further. The IETF has a longstanding issue with technology
that encourages walled gardens. See for example RFC 3002. I think
there will be quite some discussion, and this will definitely
happen even if you try to remove the "system-level" considerations,
because they are strongly implied anyway.

Personally I'm not sure what I think about this, but it needs
to be discussed in the community IMHO.

    Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 8 Sep 2011 17:14:50 -0400

> exposing it to the DNS WGs now would be a smart move.

I'll mention that I did draw the attention of DNSEXT to this WGLC.  I
also mentioned it in a recent teleconference I had with some others.
Sorry I didn't get the note out sooner: August turned out to be a
rather trying month on the personal front, and I wasn't following many
lists.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 8 Sep 2011 18:22:17 -0400

> exposing it to the DNS WGs now would be a smart move.

Frankly, I consider this very nearly a showstopper, in the sense that MIF needs an extremely good reason to do this, and I haven't seen even a hint of such a reason.    You may recall that I raised this issue in Quebec, though perhaps I was too polite about it.  (Since I hadn't read the document yet, and was coming late into the discussion, I wanted to give the group the benefit of the doubt.)

I'm quite surprised that MIF was able to get this far with the document without the issue being raised.    I'm shocked that this issue appears to be a surprise to the WG.  I think that by itself is likely a sign of a serious process or management failure.

> to be discussed in the community IMHO.

+1.

Keith

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 8 Sep 2011 20:11:01 -0400

On Thu, Sep 08, 2011 at 06:22:17PM -0400, Keith Moore wrote:
> 
> I'm quite surprised that MIF was able to get this far with the document without the issue being raised.

Have I really been so polite that this qualifies as "not raised"?  I
apologise to everyone, then.  But I've been uneasy about this since
early in my work on the DNS64 drafts.  I'm getting perhaps too adept
at nose-holding.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Sep 2011 13:31:55 +1200

> early in my work on the DNS64 drafts.  I'm getting perhaps too adept

DNS64 doesn't damage the logical structure of the namespace itself.
As soon as you admit that not all DNS servers serve the exact same
namespace, and that a host may be able to see more than one
DNS server, the total namespace cannot be guaranteed unique.
There could be two totally unrelated entries for host.example.com.
Introducing ambiguity in the DNS namespace, having already
done so in the IPv4 address space, is a very serious step indeed.

If you want a citation, see clause 4.2 in RFC 1958.

This could be fixed by a BCP describing appropriate constraints
on names that only resolve within a limited scope, I think,
but it should not be just a by-product of the draft under review.

   Brian

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 06:15:13 +0000

Keith, Brian,

The problem this draft is addressing has been acknowledged in the
draft-ietf-mif-problem-statement-15.txt section 4.1. The problem statement
is already at the RFC editor's queue.

Based on the acceptance of the problem, this WG was chartered with a goal
of:
--
  1) DNS server selection solution: a specification for describing a way
  for a network to communicate to nodes information required to perform
  advanced DNS server selection at name resolution request granularity
  in scenarios involving multiple namespaces. The specification shall
  describe the information to be delivered for nodes and the protocol to
  be used for delivery.
--

This draft is the solution that has been accepted as a WG work item.

The topic has been discussed for a quite long time and I don't think there
are any such surprises you refer to (except perhaps for individuals who just
now start following the work).

Furthermore, I cannot easily buy the argument (I hope I read your points
right) that a solution should not be developed for an acknowledged problem
out of fear of "legitimizing" the problematic behavior.

I do agree BCP or similar might be nice to have, but would such BCP really
make any difference e.g. if the network administrator just does not want
names to be resolvable on the public Internet.

Best regards,

	Teemu

> -----Original Message-----
> From: ext Keith Moore [mailto:[email-masked]]
> Sent: 09. syyskuuta 2011 01:22
> To: Brian E Carpenter
> Cc: Savolainen Teemu (Nokia-CTO/Tampere); [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [mif] Last Call for MIF DNS server selection document
> 
> 
> >> Thank you for review. I agree it is a good idea to consult those WGs
> >> (and DHC as well I suppose), but what makes you so concerned of this
> text:
> >>
> >> I wrote that as I thought it would be useful to talk a little about
> >> bigger picture of some deployments (like in the demo we had few IETFs
> >> back - without presence of DHCPv6 more specific route options the
> >> system would not have worked properly) .. but if that text creates an
> >> unwanted link or dependency or confusion, I think we can drop the
> >> text just as well and focus on the document just to the new options
> >> and leave this kind of additional system-level consideration out of the
> doc.
> >
> > the DNS is a unified global namespace. This draft is a backdoor way of
> > legitimising an ambiguous namespace. I don't think that will have an
> > easy time in IETF LC, especially if it is dropped as a surprise into
> > the DNS community. It's your choice, but I would suggest that exposing
> > it to the DNS WGs now would be a smart move.
> 
> 
> Frankly, I consider this very nearly a showstopper, in the sense that MIF
> needs an extremely good reason to do this, and I haven't seen even a hint
of
> such a reason.    You may recall that I raised this issue in Quebec,
though
> perhaps I was too polite about it.  (Since I hadn't read the document yet,
and
> was coming late into the discussion, I wanted to give the group the
benefit
> of the doubt.)
> 
> I'm quite surprised that MIF was able to get this far with the document
> without the issue being raised.    I'm shocked that this issue appears to
be a
> surprise to the WG.  I think that by itself is likely a sign of a serious
process or
> management failure.
> > there will be quite some discussion, and this will definitely happen
> > even if you try to remove the "system-level" considerations, because
> > they are strongly implied anyway.
> >
> > Personally I'm not sure what I think about this, but it needs to be
> > discussed in the community IMHO.
> 
> +1.
> 
> Keith

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 06:16:35 +0000

Brian,

The predecessors of this draft have been presented for the first time almost 
three years ago in 6man WG at IETF#73, but also in dnsop WG at IETF#78, and of 
course many times in mif WG (IETF#75,#77,#78,#79,#80,#81) and we also have had 
public demonstration of interoperability of two implementations at the 
IETF#79. That demo was announced at least in v6ops WG mailing list.

Hence I would say we've been (at least trying to) drawing attention from 
community and soliciting feedback for WGLC from other WGs at this point is 
also just fine. I'm just not sure if we should first update the draft 
according to Andrew's comments, and only after that solicit feedback from 
beforementioned WGs.

Best regards,

	Teemu

> From: ext Brian E Carpenter [mailto:[email-masked]]
> Sent: 09. syyskuuta 2011 00:02
> To: Savolainen Teemu (Nokia-CTO/Tampere)
> Cc: [email-masked]; [email-masked]; [email-masked]
> > (and DHC as well I suppose), but what makes you so concerned of this text:
> >
> > unwanted link or dependency or confusion, I think we can drop the text
> > just as well and focus on the document just to the new options and
> > leave this kind of additional system-level consideration out of the doc.
>
> I believe that you will discover during IETF LC that many people have strong
> feelings about this premise; as Andrew implied, conceptually the DNS is a
> unified global namespace. This draft is a backdoor way of legitimising an
> ambiguous namespace. I don't think that will have an easy time in IETF LC,
> especially if it is dropped as a surprise into the DNS community. It's your
> choice, but I would suggest that exposing it to the DNS WGs now would be a
> smart move.
>
> It goes further. The IETF has a longstanding issue with technology that
> encourages walled gardens. See for example RFC 3002. I think there will be
> quite some discussion, and this will definitely happen even if you try to
> remove the "system-level" considerations, because they are strongly implied
> anyway.
>

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 06:34:56 +0000

About DNS64.

I agree DNS64 does not damage the logical structure of the namespace itself.

The main DNS64 related issue there is, I think, is just that the synthetic
responses should not be retained in possible host local cache over movement
from one network interface to another (oh well, WKP using synthetic
addresses can work in different points of network attachment, if there just
is WKP using NAT64 present:-). 

In the case of multiple parallel interfaces the NSP-using synthetic
addresses of course are usable only on the interface learned on, but I
believe the routing should take care of that with longest matching prefix
rules and so. But once a point of attachment changes, records using NSP of
course should be cleared (and also WKP using prefixes as those cannot be
guaranteed to work on new IPv6-enabled point of attachment, and may actually
be source of delays (ref happy eyeballs and non-working IPv6 paths)).

Best regards,

	Teemu

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Brian E Carpenter
> Sent: 09. syyskuuta 2011 04:32
> To: Andrew Sullivan
> Cc: [email-masked]
> without the issue being raised.
> >
> namespace, and that a host may be able to see more than one DNS server,
> the total namespace cannot be guaranteed unique.
> Introducing ambiguity in the DNS namespace, having already done so in the
> IPv4 address space, is a very serious step indeed.
> 
> This could be fixed by a BCP describing appropriate constraints on names
> that only resolve within a limited scope, I think, but it should not be
just a by-
> product of the draft under review.
> 
>    Brian

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 10:07:46 +0000

Hi Andrew,

Quite a review, thank you. Responses inline:

> ext Andrew Sullivan
> Sent: 08. syyskuuta 2011 23:44
> To: [email-masked]
good
> once-over for correct usage, grammar, and spelling.  Articles seem to be
> missing in many places.  It'd be good to sort this out, but I can
understand

I know, that is mostly due imperfections in my English skills and lack of
easy access to proofreaders:)  I think language is best handled once the
document is otherwise acceptable (e.g. by RFC Editor).

> As an overall comment, there are sections of the document that explain the
> motivation and background, and sections of the document that prescribe
> steps to be taken.  The former are informative, and the latter normative.
I
> suggest including near the beginning an overview stating what sections are
> informative and what are normative, and breaking those sections cleanly
(i.e.
> no explanatory text in the normative sections).

I have started writing -04 version, and added to the introduction section:
--
        Informative background information about problem descriptions and
example deployment scenarios are 
        included in sections 2 and 3. Section 4 contains all normative
descriptions 
        for DHCP options and required node behavior. Informative section 5
illustrates behavior of a node implementing
        functionality described in the section 4. Sections 6 and 7 contain
informational considerations about scalability
        and network operations. Informational section 10 summarizes
identified security considerations.
--

Furthermore, I ensured that no normative keywords are outside of section 4
and because of that moved following text from section 10 to 4.1:
--
A node that accepts DNS server selection rules from non-trusted interfaces
and implements DNSSEC validation SHOULD send queries also to (all) other
known DNS servers in case a non-validatable response is received from the
preferred DNS server. This protects against possible redirection attacks.
--

> I've had a hard time expressing why this text has been bothering me, but I
> think I understand what it is: that text is not explicit enough that it is
starting
> from the premise that the DNS is not a unified global namespace.  I think
it
> needs another sentence, at the beginning, along the following lines:
> 

I migrated the nice text you proposed, removed some old, and the paragraph
looks now as following:
--
We start from the premise that network operators sometimes include private
namespaces in the answers they provide from DNS servers, and that those
private namespaces are at least as useful to nodes as the answers from the
public DNS. When private namespaces are visible for a node, some DNS servers
have information other servers do not have. The node ought to be able to ask
right server for the information it needs.
--

>    interfaces, depending on the destination it is trying to reach.

Copied as proposed.

> The key point here, I think, is that the networks are disparate and not
> actually all available via the public network.  By making these
adjustments, it
> makes the document more open-handed about the fact it's trying to address:
> there are all kinds of pockets on the Internet, and you have to connect to
> different pockets via different means.

Agree, Internet is a network of networks, after all.

> I really dislike the term "suffix" here, and I'm not sure "prefix" is what
you
> want either.  I think "suffix" really means "domain", right?

Suffix means domain, yes. Prefix is about IPv6 address prefix..

> That is, if I offer a DNS server that is high-priority for example.com, it
can
> answer for anything from example.com all the way down.  No?  Similarly,

Yes.

> you might just want "networks" for the reverse tree, since "prefix"
doesn't
> exactly get it right: the network address is turned around in the DNS
query.

And IPv4 was also added, hence prefix does not suit for that too well
either. 

> (This also appears elsewhere in the draft, but I won't mention it again
unless
> I'm proposing text.) "Prefix" is probably fine if you make it clear that
you're
> providing the prefix of a network, and that it's the client's job to do
the right
> thing with that prefix in order to formulate reverse-tree DNS queries.

In the -04 I switched using "domain" and "network". In the beginning of 4.1
I try to introduce those now as follows:
--
To build the list in an optimal way, a node SHOULD ask with DHCP which DNS
servers of each network interface are most likely able to successfully serve
forward lookup requests matching to specific domain suffixes or reverse (PTR
record) lookup requests matching to specific network addresses (later
referred as "domain" and "network").
--
This changed e.g. the text your referred above to look as follows:
--
When a DNS query needs to be made, the resolver SHOULD give highest
precedence to the DNS servers explicitly known to serve matching domain or
network.
--

Is it better to talk about "DNS domain" or just "domain"?

> Why isn't this MUST?  

Because a node implementation might not want to care about security (at this
layer) for some reason. I mean it is of course easy to say why the node
really SHOULD care about trust, but the DNS server selection itself should
work just fine even if the node does not take security into account (it just
may result in unwanted DNS server being used when under attack, but maybe
said node is able to recover from that by some other means). 

In the past I've encountered MUSTs too often that are not applicable in some
scenarios and therefore I personally hesitate using MUST unless that is
absolutely required. To some extent this is matter of taste and hence I'm
totally open for WG input.

>This entire procedure is hard for me to follow, in fact.
> It seems to me that we have two different meanings of "trust" here, and I
> think that may be part of the problem.  The first meaning (trust1) is "a
setting
> that comes with the information that DNS server S on interface I provides
> namespace N with trust-level T".
name
> server address-interface binding.  The second meaning (trust2) is how much
> you, the client, believe the data you got: did you get the
> trust1 data in a way that you can be sure it's legitimate?  It seems to me
that
> combining trust1 and trust2 into a single scale might be wrong, and I
think
> that the last row in Figure 4 suggests this.  If I simply don't know
whether the
> data I get on interface B is real or spoofed, why would I ever use that,
even if
> it's "medium priority", over the data I can be sure is an unspoofed answer
on
> interface A?

The idea is that the node by magic knows what interfaces can be trusted and
what cannot (trust2). This results that trust1 is absolute if interface was
trusted (trust2 is there), and ~none if interface was not trusted (trust2 is
not there).

In case of untrusted information not being in conflict with the trusted one,
I thought one could just as well follow that information. Just like in the
street you "trust" navigation guidance given by strangers when lost:)
Another clear implementation alternative is simply to ignore untrusted
interfaces.

This makes me think about Brian's concern about "legitimizing" private
namespaces. If this document would state that only trusted interfaces can
configure DNS server selection rules, would that mitigate the "legitimizing"
concern as then this tool would not be used in environments where network
operator cannot configure nodes trust levels enough to make them request &
listen the configuration message? I.e. that might help limit usage of the
tool to scenarios where we have seen need for it.

I did not update text on this area yet, waiting for discussion to progress.
 
>    only if trusted interfaces specifically configure DNS servers to be

Yes, should be:"The DNS servers of untrusted interfaces.."

> I think the discussion just after Figure 4 about revealing information
about
> ongoing communications is total nonsense, and should be removed.

Not everyone agrees on that one I believe. From folks following BroadBand
Forum the message in some past discussion was that they do not want to
broadcast DNS queries to all interfaces for this reason (I hope I recall
that right). Also I believe in classic split-tunnel VPN case corporate IT
would prefer not to provide all names to hostile hotspot DNS server, while
they may not be able to totally block that (e.g. host probably sends DNS
queries out also when VPN is not running).

> If you want to put names in the DNS, they're never going to be secret.

That's why they are private namespaces - you can't learn even existence of
private names from the Internet. From the node you can of course, and the
node (esp. if compromised) may of course leak them forward.

> The attempts to use split-brain DNS and so on for hiding network resources
> are a completely misguided attempt at security by obscurity, and I don't
think
> the draft should include any text that even implies this technique works.
> Private DNS names leak all over the place, and if you think otherwise
you're
> dreaming.

Should one not try to minimize that leak? I.e. avoid "unnecessary" revealing
of information that does not have to be revealed.

Would it satisfy your concern if we drop the:" unnecessary reveal
information about ongoing communications" away? And hence would have just:
--
The resolver SHOULD avoid sending queries to different interfaces in
parallel as that may waste resources such as energy.
--
Again SHOULD, as in some cases implementation does not care and could behave
differently (and some cases the energy conservation is really important).

> That isn't true.  If you have a cryptographically strong connection to a
DNS
> server and you know that it is doing DNS validation (because, for
instance,
> your corporate overlords told you, "We do validation on the VPN DNS
> server"), you do in fact have a reason to prefer the answers from that
server.
> You might set DO and not CD, and get back the AD bit on your answer,
giving
> you evidence that the validation was done by the server.  I think the
> paragraph can be rewritten this way (although this includes some
> explanatory material and some normative material; as I suggested above,
> perhaps that ought to be split).

That piece of text came directly from you:
http://www.ietf.org/mail-archive/web/mif/current/msg01058.html
...
But I agree with you and let's use the new text you proposed instead:
--
--

> Instead of "matching suffix", we could say something like "from a DNS
server
> that can provide answers for the queried name".  But I think what this is
> saying is that, if you get a validated NXDOMAIN from an interface, you're
> allowed to go on and ask other servers.  Even if the answer can't be
> validated?  If so, this seems to contradict the passages before it, and
it's
> clearly an attack vector on DNSSEC's provable non-existence.  Some people
> think that feature is dumb, but it's part of what DNSSEC offers now, and
it
> would be strange to introduce a way to turn it off.  I'd add a reference
here
> to the "different trust anchor" discussion in Appendix B.  See also below.

So something along lines:
--
In the case of validated NXDOMAIN response being received from a DNS server
that can provide answers for the queried name a node MUST NOT accept
non-validated replies from other DNS servers (see Appendix B for
considerations related to multiple trust anchors).
--

> I can't see anything you can do about cases where a DNS server always lies
> to you.  On the other hand, if you do DNSSEC, those servers will always
fail
> validation anyway, so we can hope they'll meet the fate they deserve.
> 
> In section 4.2, I don't understand, "IPv6 prefixes should cover all the
DNS
> suffixes configured in this option."  Maybe I've actually misunderstood
the
> use of "prefix" and "suffix" in this document?

With new terms it says:"IPv6 networks should cover all the DNS domains..".
It means that configuration should be such that one could do reverse queries
successfully for all the domains that are configured (and vice versa).
 
> the behaviour is up to you (i.e. undefined).  Why is that a MUST?  Why
isn't it
> just "... the resolver MAY use whichever option it likes"?

It should say that node must not select randomly, but use the preference
value on OPTION_DNS_SERVER_SELECT. If the preference in _SERVER_SELECT is
default (i.e. same preference for both), then the node SHALL use the server
received via _SERVER_SELECT option. I.e. if both options are present, DNS
server from OPTION_DNS_SERVERS is used by default only if
OPTION_DNS_SERVER_SELECT contains low default preference.

> mean "only add the same address of a DNS server to the server list once"?
> The passage as it is reads to me as though you might throw away some
> addresses you get.

"If both OPTION_DNS_SERVERS and OPTION_DNS_SERVER_SELECT contain the same
DNS server(s) IPv6 address(es), a node SHALL add the same address of a DNS
server to the server list only once. " ?

> In section 4.6., I think that it needs to be made clear that a bare name
is first
> treated as a pre-DNS hostname before it encounters the DNS search list.
> (Frankly, that entire mechanism is broken, and it would suit me just fine
if the
> document said, "This algorithm is incompatible with the DNS search list
and
> the OPTION_DOMAIN_LIST feature."  But I know people would scream about
> it.  It's still broken.)

I'm not sure what you mean with "pre-DNS" hostname..

> In 4.7, what about other things that could do context-sensitive referrals,
like
> SRV?

Hmm.. what should we write about those? Any record type that contains domain
names shall fall under this server selection logic?
 
> In A.1, the same discussion about revealing information as above pertains.

Would it be ok then if this is dropped:
--
            <t>Another downside is revealing to all DNS servers the names a
host is connecting to.
            For example, a DNS server of a public hotspot could learn all
the private names host
            is trying to connect on other interfaces. </t>
--

> I hope these comments are useful.

They were very useful.

Additionally, for -04 under works, I corrected reference of
draft-ietf-v6ops-multihoming-without-nat66 to
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat.

I also fixed some nits I encountered while going through these comments..

Will wait for discussion to proceed before doing additional updates.

Best regards,

	Teemu

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Sep 2011 14:16:59 -0400

Hi,

Thanks for your response.  More inline.

> Is it better to talk about "DNS domain" or just "domain"?

I think "domain" is fine, myself.

> said node is able to recover from that by some other means). 

I guess I don't think this is a 2119 SHOULD, then.  If it's really
just a matter of taste, it's not SHOULD, in my reading of the
keywords.  SHOULD means "you'd better have a pretty good reason not to
do this", and I don't think "I don't wanna" qualifies.  Perhaps MAY?

> what cannot (trust2). 

Oh.  That wasn't clear to me at all: I thought trust2 came from being
able to validate the answers or else from having an authentecated and
secure connection to the upstream resolver.
 
> tool to scenarios where we have seen need for it.

While I understand the "legitimizing" worry, I think the DNS community
has been pig-headed about this in much the way the wider community
once tried to respond to NAT: "Lalalalala I can't hear you."  Even if
we really hate it, private namespaces are a fact on the network.  We
can either tell people, "Here is how to do this bad thing in the least
bad way possible," or we can endure the even worse ways that people
think of to do that bad thing.  So far, we seem to have been going for
"endure", but I think it's a failure.

Now, while I like this suggestion of yours, I worry about the
potential to fail to address some use case we think we have.  I
haven't thought of a way it does, but maybe others can think about
that too.

> queries out also when VPN is not running).

Yes, I know that lots of people think they can have a private
namespace in their DNS servers, and that it won't leak.  They're just
wrong about this.  Just because people believe in the Tooth Fairy
doesn't mean that she exists, and just because people think that their
private name space is secret because they only use it on the VPN
doesn't mean that it really is secret.  See above about bad ideas and
even worse ones.  I know of at least one large government where one
department has 6 layers of NAT in an attempt to keep their sooper
secret names inside the network.  They still end up writing incident
reports every time one of those names leaks, but leak they do.  The
DNS is _designed_ to leak this way.

> information about ongoing communications" away? And hence would have just:

Yeah, this works for me.

> > That isn't true.

> That piece of text came directly from you:

Could be :)  I'm not always terribly bright.

> So something along lines:

Works for me.

> successfully for all the domains that are configured (and vice versa).

Hrm.  I don't think this is a realistic requirement.  First, there is
no guarantee in the first place that the reverse tree will actually be
maintained -- and there are people who have strong feelings that it is
entirely optional.  For your amusement, I can show you sometime the
scourge marks I got from trying to get a draft through DNSOP that by
last call said, in effect, "You can use the reverse tree, or not,
depending on what you like."  It still failed.

But in any case, even if the reverse tree was fully maintained, the
forward and reverse don't line up exactly.  For instance, a CNAME in
the forward tree is entirely likely not to be reflected in the
reverse.  I think you can probably cut this text (although I don't
feel that strongly about it).

> OPTION_DNS_SERVER_SELECT contains low default preference.

Ok, I see.

Yes.

> I'm not sure what you mean with "pre-DNS" hostname..

I.e. an RFC 952 hostname.  The DNS search list is really a hack that
was partly an attempt to make things work more like the old host name
syntax (and partly to give local scoping).  When you put something in
/etc/hosts, what you're really doing is preventing the DNS from
getting involved by using the hostname mechanism.  Unfortunately, no
naming technlogy on the Internet ever goes away.  It just gets more
cruft layered on top.

> names shall fall under this server selection logic?

That would include NS records.  But actually, now that I think about
it, this should probably just say that any follow-up queries that are
performed on the basis of an answer received on an interface MUST
continue to use the same interface, irrespective of the DNS server
selection settings on any other interface.  This is required because
of the assumption that different DNS servers possibly provide
different namespaces.  (I want to go lie down after having written
that.)

> Would it be ok then if this is dropped:

Yes, I'd get rid of it.

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Sep 2011 09:01:19 +1200

Teemu,

I think the reference to multiple namespaces in the requirements draft
is too short to really generate discussion, and in any case it's only
an Informational document.

However, I was trying to be quite careful in what I wrote.

>> if the network administrator just does not want

That is one thing, and an *ambiguous* namespace is another.

I guess I would like to see some MUSTs or MUST NOTs in the MIF
draft or elsewhere that make it clear that any domains that
are not globally resolvable must nevertheless be globally
unique. That needs to be expressed a bit more precisely
and there might have to be an exception for .local. However,
if a host can see a DNS server from example.com, a rule could
be: that server MUST NOT resolve any domains that are not
globally resolvable and are not subdomains of example.com.

I am sure there is a better way to express this. It just needs
to guarantee a strict hierarchy in the namespace.

Regards
   Brian Carpenter

---

From: Keith Moore <[email-masked]>
Date: Fri, 9 Sep 2011 17:29:20 -0400

> Based on the acceptance of the problem, this WG was chartered with a goal

Selecting a name server is one thing.  Standardizing a behavior that assumes that DNS name servers are specific to networks, is something else entirely.  It's a violation of the DNS architecture, which clearly assumes that DNS queries are location-independent.  (Otherwise, it would not allow caching of query results without some awareness of the scope in which they are valid.)

I realize that this is a slippery slope that IETF and the Internet have been sliding down for many years, given two-faced DNS,  SiteFinder and other criminal acts, DNS interception proxies imposed by ISPs, certain dubious uses of LLMNR, DNS64, and several other things that break the architecture.   DNS is almost as polluted these days as IPv4 is.   But at some point it goes too far.   

(It's an even worse problem with DNS than with IPv4, because by now everyone should realize that IPv4 is on the way out, but we're stuck with DNS for the foreseeable future.)

Sometimes I think that people forget that the goal of these efforts is (or should be) to provide a predictable environment for applications.  Part of being "predictable" is location-independence.  An application shouldn't have to act differently in one part of the network, than in another part of the network, in order to function properly.

One of the implications is that a DNS name needs to mean the same thing, even to the point of having the same RRs associated with it, from everywhere on the network.  

Now, some may think that it's mostly harmless, or even beneficial, to say that addresses that aren't reachable from some part of the network need not appear in DNS responses received in that part of the network.   Some people may think that v4-v6 transition is so important that it warrants having DNS proxies lie to applications about what a domain's resource records are.   Then again, some parties think that their ability to sell advertisements or to work around customer misconfiguration of hosts is so important that they can also lie about a domain's resource records, even though that practice breaks applications.   Again, it's a slippery slope.  IMO, all of this behavior is broken, and none of this behavior should be considered acceptable for standardization according to RFC 2026's criteria ("no known technical omissions").  

I realize that MIF was just trying to recognize "reality" of NATted networks, two-faced DNS, and other hacks.   Sometimes that's appropriate when designing an API.    But such second-guessing can also degrade the predictability of the network environment as viewed by applications.    

IETF keeps moving away from an Internet that is _engineered_ to work because the interactions between components have been analyzed and found to work correctly, to an Internet that relies on guesswork, empirical measurement, incomplete analysis, and luck in order to allow applications to work.    Again, the problem isn't at all specific to MIF, but THIS NEEDS TO STOP.  

> This draft is the solution that has been accepted as a WG work item.

Indeed, that's precisely the problem.    How did the WG go so far down this path without significant pushback, or without the architectural question being raised and discussed in a wider or more appropriate forum?  Why was this decision not subject to extensive review, not just within DNS WGs but also cross-area review, long before the MIF WG made its decision?

> now start following the work).

Again, why should applications developers who might be concerned about pollution of DNS and harm to the DNS architecture, have to follow the work of the MIF working group in order to do damage control?

> out of fear of "legitimizing" the problematic behavior.

You might not buy it, but I do.    Again, MIF isn't the first contributor to the problem, so I don't exclusively blame that WG.  I see it as more of a structural and process problem within IETF - IETF is frequently failing to maintain the Internet architecture and hoping that somehow everything will work out.  But I also think that the MIF work needs to be fixed somehow to avoid encouraging further pollution of DNS.

Keith

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Sep 2011 19:01:15 -0400

On Fri, Sep 09, 2011 at 05:29:20PM -0400, Keith Moore wrote:
> 
> Selecting a name server is one thing.  Standardizing a behavior that
> assumes that DNS name servers are specific to networks, is something
> else entirely.  It's a violation of the DNS architecture, which
> clearly assumes that DNS queries are location-independent.
> (Otherwise, it would not allow caching of query results without some
> awareness of the scope in which they are valid.)

First, I fully agree with this.  At the same time, in point of fact we
walked off the cliff some time ago.

> I realize that this is a slippery slope that IETF and the Internet
> have been sliding down for many years, given two-faced DNS,
> SiteFinder and other criminal acts, DNS interception proxies imposed
> by ISPs, certain dubious uses of LLMNR, DNS64, and several other
> things that break the architecture.  DNS is almost as polluted these
> days as IPv4 is.  But at some point it goes too far.

The problem that I see is that we _already_ see techniques in the wild
where people have broken the architecture, and are charging ahead and
doing their thing.  We can try to say, "This is too far," but we'll be
right back where we were with NAT many years ago.  Once we started
split-brain DNS, we were just doomed to the eventual state of affairs
where the exact same question asked of servers in different networks
would give different answers.  We can't change the past. 

> Indeed, that's precisely the problem.    How did the WG go so far down this path without significant pushback, or without the architectural question being raised and discussed in a wider or more ap…

Actually, the DNS Directorate has been paying active attention to this
work, and part of the reason I did the review I did was precisely
because of that interest.  The problem we DNS weenies have is that we
know it's a horrible disastrous mess, but people are _doing it
anyway_, and the only option left to us now is to try to contain
damage.  I hate DNS64.  I hate this server selection stuff, too.  But
no matter how much I shout at the tide, still it comes in.  Better
that I should try to help build the dike.

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Sep 2011 11:33:28 +1200

> doomed to the eventual state of affairs

As long as the reply for a given query is always NXDOMAIN
*except* for the one name server serving the particular offshoot
of the namespace that the location-dependent domain is in,
we have not broken the uniqueness of the namespace.

Hence the suggestion in my previous message, quoted here for
the benefit of the IESG that someone added in CC:

"I guess I would like to see some MUSTs or MUST NOTs in the MIF
draft or elsewhere that make it clear that any domains that
are not globally resolvable must nevertheless be globally
unique. That needs to be expressed a bit more precisely
and there might have to be an exception for .local. However,
if a host can see a DNS server from example.com, a rule could
be: that server MUST NOT resolve any domains that are not
globally resolvable and are not subdomains of example.com."

Regards
   Brian Carpenter

---

From: Keith Moore <[email-masked]>
Date: Fri, 9 Sep 2011 20:02:25 -0400

> walked off the cliff some time ago.

Who's this "we" of which you speak? :)

> that I should try to help build the dike.

People often do things that violate the standards.  That doesn't mean that IETF should endorse such practices.   Nor does it mean that IETF should ignore them.

Sometimes when people do things that violate the standards, it's a sign of a deficiency in the architecture that should be remedied.  And sometimes it means that they're just being shortsighted and what IETF needs to do is to say "here's why this is a Bad Idea".

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 9 Sep 2011 20:03:54 -0400

> we have not broken the uniqueness of the namespace.

Actually, I disagree.  NXDOMAIN means "this domain does not exist".     Applications should be able to rely on that.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Sep 2011 13:58:17 +1200

> Actually, I disagree.  NXDOMAIN means "this domain does not exist".     Applications should be able to rely on that.

Well, that's the point: they can't. As far as I can see, ever since
the first deployment of split DNS, you have to qualify that
meaning with "as far as I know."

I don't mean to imply that I'm happy with this.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 9 Sep 2011 22:10:23 -0400

> meaning with "as far as I know."

People who deploy split DNS need to understand that the consequence of doing so is that if some application just happens to query the "wrong" server, or the "wrong" side of the server, that it's going to get an NXDOMAIN error, and that application is going to (quite properly) report that the domain does not exist - even if that domain does exist, and even if that application happens to have access to a network that lets it query the "right" server.

The notion that the network tells the host what DNS server to use (via DHCP or whatever means), and that the host should do what the network tells it to do, has always been suspect.  The existence of multiple active interfaces on hosts just makes the problem more obvious.

Keith

---

From: <[email-masked]>
Date: Mon, 12 Sep 2011 08:08:27 +0000

Brian,

I agree with that very reasonable suggestion. I think the problem described in 
section 2.3 is one symptom of issues caused by non-uniqueness (and for which I 
have not figured out automated solution).

I mostly rewrote (for the -04 draft version) section 7 "Considerations for 
network administrators" as follows. Would that address this concern?
--
Network administrators deploying private namespaces should assist advanced 
nodes in their DNS server selection process by providing information described 
within this document.

Private namespaces MUST be globally unique in order to keep DNS unambiguous 
and henceforth avoiding caching related issues and destination selection 
problems (see section 2.3). An exception to this rule are domains utilized for 
local name resolution (such as .local).

Private namespaces MUST only consist of subdomains of the domains communicated 
for nodes (e.g. subdomains of example.com). This means that a DNS server MUST 
NOT resolve any domains that are not globally resolvable and are not 
subdomains of said communicated domains.

To mitigate against attacks against local namespaces, administrators utilizing 
this tool SHOULD deploy DNSSEC for their zone.
--

The .local remains open issue though, I encountered this also in homenet 
mailing list.. well it works fine as long as node is not connected to multiple 
local networks at the same time... If node is, then I guess the application 
must be able to select the right local network interface to use..

Best regards,

Teemu

> Sent: 10. syyskuuta 2011 00:01
> Cc: [email-masked]; [email-masked];
> I think the reference to multiple namespaces in the requirements draft is 
> too
> short to really generate discussion, and in any case it's only an 
> Informational
> document.
>
> >> if the network administrator just does not want names to be
> >> resolvable on the public Internet.
>
> I guess I would like to see some MUSTs or MUST NOTs in the MIF draft or
> elsewhere that make it clear that any domains that are not globally
> resolvable must nevertheless be globally unique. That needs to be expressed
> a bit more precisely and there might have to be an exception for .local.
> However, if a host can see a DNS server from example.com, a rule could
> be: that server MUST NOT resolve any domains that are not globally
> resolvable and are not subdomains of example.com.
>
> I am sure there is a better way to express this. It just needs to guarantee 
> a
> strict hierarchy in the namespace.
>
> Regards
>    Brian Carpenter
>
> > draft-ietf-mif-problem-statement-15.txt section 4.1. The problem
> > statement is already at the RFC editor's queue.
> >
> > The topic has been discussed for a quite long time and I don't think
> > there are any such surprises you refer to (except perhaps for
> > individuals who just now start following the work).
> >
> > right) that a solution should not be developed for an acknowledged
> > problem out of fear of "legitimizing" the problematic behavior.
> >
> > I do agree BCP or similar might be nice to have, but would such BCP
> > really make any difference e.g. if the network administrator just does
> > not want names to be resolvable on the public Internet.
> >
> > Best regards,
> >
> > 	Teemu
> >
> >>>> Thank you for review. I agree it is a good idea to consult those
> >>>> WGs (and DHC as well I suppose), but what makes you so concerned of
> >>>> this
> >> text:
> >>>>>>   correct route and destination and source addresses for the
> >>>>>> actual
> > IP
> >>>>>>   addresses may be only usable on the network interface over
> >>>>>> which
> > the
> >>>>>>   name was resolved on.
> >>>> bigger picture of some deployments (like in the demo we had few
> >>>> IETFs back - without presence of DHCPv6 more specific route options
> >>>> the system would not have worked properly) .. but if that text
> >>>> creates an unwanted link or dependency or confusion, I think we can
> >>>> drop the text just as well and focus on the document just to the
> >>>> new options and leave this kind of additional system-level
> >>>> consideration out of the
> >> doc.
> >>> I believe that you will discover during IETF LC that many people
> >>> have strong feelings about this premise; as Andrew implied,
> >>> conceptually the DNS is a unified global namespace. This draft is a
> >>> backdoor way of legitimising an ambiguous namespace. I don't think
> >>> that will have an easy time in IETF LC, especially if it is dropped
> >>> as a surprise into the DNS community. It's your choice, but I would
> >>> suggest that exposing it to the DNS WGs now would be a smart move.
> >>
> >> Frankly, I consider this very nearly a showstopper, in the sense that
> >> MIF needs an extremely good reason to do this, and I haven't seen
> >> even a hint
> > of

---

From: <[email-masked]>
Date: Mon, 12 Sep 2011 12:47:44 +0000

Hi Andrew,

> Sent: 09. syyskuuta 2011 21:17
> To: [email-masked]

Fine for  me, changed in draft (for now at least).

> > layer) for some reason. I mean it is of course easy to say why the
> > node really SHOULD care about trust, but the DNS server selection
> > itself should work just fine even if the node does not take security
> > into account (it just may result in unwanted DNS server being used
> > when under attack, but maybe said node is able to recover from that by
> some other means).
>
> I guess I don't think this is a 2119 SHOULD, then.  If it's really just a 
> matter of
> taste, it's not SHOULD, in my reading of the keywords.  SHOULD means
> "you'd better have a pretty good reason not to do this", and I don't think 
> "I
> don't wanna" qualifies.  Perhaps MAY?

Well...MAY sounds too weak for me especially after hearing so many complaints 
emails about possible new attack vectors.

On the other hand.. maybe it could be MUST, and then it would be up to node 
implementation (or other SDOs) to determine what interface is judged to be 
trusty enough. Changed the sentences into:
--
The resolver MUST take into account differences in trust levels of DNS server 
selection information the resolver has received. The resolver MUST prefer DNS 
servers of trusted interfaces. The DNS servers of untrusted interfaces may be 
of highest priority only if trusted interfaces specifically configure low 
priority DNS servers.
--

> > The idea is that the node by magic knows what interfaces can be
> > trusted and what cannot (trust2).
>
> Oh.  That wasn't clear to me at all: I thought trust2 came from being able 
> to
> validate the answers or else from having an authentecated and secure
> connection to the upstream resolver.

I added following text, would it clarify this?
--
Trustworthiness of an interface and configuration information received over 
the interface is implementation and/or node deployment dependent. Trust may be 
based on, for example, on the nature of an interface. For example, an 
authenticated and encrypted VPN or layer 2 connection to a trusted home 
network may be considered as trusted, and an unauthenticated and unencrypted 
connection to an unknown visited network may be considered as untrusted.</t>
--

> government where one department has 6 layers of NAT in an attempt to
> keep their sooper secret names inside the network.  They still end up 
> writing
> incident reports every time one of those names leaks, but leak they do.  The

Right... first design a network that should withstand a nuclear war and then 
complain when data actually finds paths around "damaged sections":)

> Yeah, this works for me.

Ok, changed.

> > It means that configuration should be such that one could do reverse
> > queries successfully for all the domains that are configured (and vice
> versa).
>
> Hrm.  I don't think this is a realistic requirement.  First, there is no 
> guarantee
> in the first place that the reverse tree will actually be maintained -- and 
> there
> are people who have strong feelings that it is entirely optional.  For your
> amusement, I can show you sometime the scourge marks I got from trying to
> get a draft through DNSOP that by last call said, in effect, "You can use 
> the
> reverse tree, or not, depending on what you like."  It still failed.
>
> But in any case, even if the reverse tree was fully maintained, the forward
> and reverse don't line up exactly.  For instance, a CNAME in the forward 
> tree
> is entirely likely not to be reflected in the reverse.  I think you can 
> probably
> cut this text (although I don't feel that strongly about it).

Cut the "IPv6 networks.." paragraph fully away? And just let admins configure 
whateevr they think is best/needed for the network part? My original thinking 
was that e.g. an ISP could configure here very large network, like their full 
single /32 or so.

> > > the OPTION_DOMAIN_LIST feature."  But I know people would scream
> > > about it.  It's still broken.)
> >
> I.e. an RFC 952 hostname.  The DNS search list is really a hack that was 
> partly
> an attempt to make things work more like the old host name syntax (and
> partly to give local scoping).  When you put something in /etc/hosts, what
> you're really doing is preventing the DNS from getting involved by using the
> hostname mechanism.  Unfortunately, no naming technlogy on the Internet
> ever goes away.  It just gets more cruft layered on top.

So something like this:
--
4.6. Interactions with OPTION_DOMAIN_LIST and pre-DNS hostnames

A node may be configured with DNS search list with OPTION_DOMAIN_LIST.

A bare name (a name without any dots) MUST be first treated as a pre-DNS 
hostname, and only after that the name SHALL be appended with suffix(es) and 
improved DNS server selection be utilized.

Resolution for the name containing any dots SHOULD first be attempted with DNS 
servers of all interfaces as is described above. Only if the resolution fails 
the node SHOULD append the name with search list suffix(es) and then again 
utilize improved DNS server selection algorithm to decide which DNS server(s) 
to contact.
--

> > > referrals,
> > Hmm.. what should we write about those? Any record type that contains
> > domain names shall fall under this server selection logic?
>
> That would include NS records.  But actually, now that I think about it, 
> this
> should probably just say that any follow-up queries that are performed on
> the basis of an answer received on an interface MUST continue to use the
> same interface, irrespective of the DNS server selection settings on any 
> other
> interface.  This is required because of the assumption that different DNS
> servers possibly provide different namespaces.  (I want to go lie down after
> having written
> that.)

Something like:
--
4.7 Considerations on follow-up queries

Any follow-up queries that are performed on the basis of an answer received on 
an interface MUST continue to use the same interface, irrespective of the DNS 
server selection settings on any other interface. For example, if a node 
receives a reply with a canonical name (CNAME) or delegation name (DNAME) the 
follow-up queries MUST be sent to DNS server(s) of the same interface, or to 
same DNS server, irrespectively of the FQDN received. Otherwise referrals may 
fail.
--
I'm not sure this is too difficult to implement - a stub resolver ought to see 
the DNS server who provided the answer, and hence it should be quite trivial 
to send follow-up queries to the same server. Or can that

Thank you again for your suggestions and efforts to find least evil 
solutions..

Teemu

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Sep 2011 08:54:05 -0400

On Sep 12, 2011, at 8:47 AM, <[email-masked]> <[email-masked]> wrote:

> [...]

I don't think it makes sense to impose a MUST requirement in conjunction with something that's so imprecisely defined.

Also, the notion that trustworthiness of an interface and trustworthiness of a DNS server are somehow related strikes me as dubious.

Keith

---

From: <[email-masked]>
Date: Mon, 12 Sep 2011 13:17:30 +0000

Hi,

Well, SHOULD was my original intent there, but let's try to find agreement.

"Also, the notion that trustworthiness of an interface and trustworthiness
of a DNS server are somehow related strikes me as dubious." This was not my
intended meaning, but instead trustworthiness of domain configuration
information received from DHCP server of trusted interface. I.e. I was
suggesting that if a node for example trust a cellular network, it can trust
the DHCPv6 option from DHCPv6 server on cellular interface telling
"operator.com" domain is to be resolved via DNS servers of that interface as
high preference. I was not trying to that node could trust actual responses
from said DNS servers at all (DNSSEC is still needed for that). I can
clarify this.

Teemu

From: ext Keith Moore [mailto:[email-masked]] 
Sent: 12. syyskuuta 2011 15:54
To: Savolainen Teemu (Nokia-CTO/Tampere)
Cc: [email-masked]; [email-masked]
Subject: Re: [mif] Last Call for MIF DNS server selection document

On Sep 12, 2011, at 8:47 AM, <[email-masked]>
<[email-masked]> wrote:

The resolver MUST take into account differences in trust levels of DNS
server 
selection information the resolver has received. The resolver MUST prefer
DNS 
servers of trusted interfaces. The DNS servers of untrusted interfaces may
be 
of highest priority only if trusted interfaces specifically configure low 
priority DNS servers.
--
[...]
--
Trustworthiness of an interface and configuration information received over 
the interface is implementation and/or node deployment dependent. Trust may
be 
based on, for example, on the nature of an interface. For example, an 
authenticated and encrypted VPN or layer 2 connection to a trusted home 
network may be considered as trusted, and an unauthenticated and unencrypted

 

I don't think it makes sense to impose a MUST requirement in conjunction
with something that's so imprecisely defined.

Also, the notion that trustworthiness of an interface and trustworthiness of
a DNS server are somehow related strikes me as dubious.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Sep 2011 13:15:56 +1200

Teemu,

I think that is the best approach in order to get this document out
without launching a war about the integrity of the DNS namespace.

>> for nodes (e.g. subdomains of example.com)

I'm wondering whether that doesn't have to be a bit more elaborated.
Something like:

Private namespaces MUST only consist of subdomains of domains for which the
relevant operator provides authoritative name service. Thus, subdomains
of example.com are permitted in the private namespace served by an operator's
DNS servers only if the same operator provides an SOA record for example.com.

Thanks

   Brian

---

From: <[email-masked]>
Date: Tue, 13 Sep 2011 08:49:21 +0000

Brian,

Sounds good for me - included now for the next update.

Thank you,

	Teemu

> Sent: 13. syyskuuta 2011 04:16
> [email-masked]; [email-masked]; [email-masked]
> I think that is the best approach in order to get this document out without
> launching a war about the integrity of the DNS namespace.
>
> >> Private namespaces MUST only consist of subdomains of the domains
> >> communicated for nodes (e.g. subdomains of example.com)
>
> Private namespaces MUST only consist of subdomains of domains for which
> the relevant operator provides authoritative name service. Thus, subdomains
> of example.com are permitted in the private namespace served by an
> operator's DNS servers only if the same operator provides an SOA record for
> example.com.
>
> Thanks
>
>    Brian
>
> > I agree with that very reasonable suggestion. I think the problem
> > described in section 2.3 is one symptom of issues caused by
> > non-uniqueness (and for which I have not figured out automated solution).
> >
> > I mostly rewrote (for the -04 draft version) section 7 "Considerations
> > for network administrators" as follows. Would that address this concern?
> > --
> > Network administrators deploying private namespaces should assist
> > advanced nodes in their DNS server selection process by providing
> > information described within this document.
> >
> > Private namespaces MUST be globally unique in order to keep DNS
> > unambiguous and henceforth avoiding caching related issues and
> > destination selection problems (see section 2.3). An exception to this
> > rule are domains utilized for local name resolution (such as .local).
> >
> > Private namespaces MUST only consist of subdomains of the domains
> > communicated for nodes (e.g. subdomains of example.com). This means
> > that a DNS server MUST NOT resolve any domains that are not globally
> > resolvable and are not subdomains of said communicated domains.
> >
> > To mitigate against attacks against local namespaces, administrators
> > utilizing this tool SHOULD deploy DNSSEC for their zone.
> > --
> >
> > The .local remains open issue though, I encountered this also in
> > homenet mailing list.. well it works fine as long as node is not
> > connected to multiple local networks at the same time... If node is,
> > then I guess the application must be able to select the right local 
> > network
> interface to use..
> >
> > Best regards,
> >
> > Teemu
> >
> >> I think the reference to multiple namespaces in the requirements
> >> draft is too short to really generate discussion, and in any case
> >> it's only an Informational document.
> >>
> >> I guess I would like to see some MUSTs or MUST NOTs in the MIF draft
> >> or elsewhere that make it clear that any domains that are not
> >> globally resolvable must nevertheless be globally unique. That needs
> >> to be expressed a bit more precisely and there might have to be an
> exception for .local.
> >> I am sure there is a better way to express this. It just needs to
> >> guarantee a strict hierarchy in the namespace.
> >>
> >> Regards
> >>    Brian Carpenter
> >>
> >>> really make any difference e.g. if the network administrator just
> >>> does not want names to be resolvable on the public Internet.
> >>>
> >>> Best regards,
> >>>
> >>> 	Teemu
> >>>
> >>>>>> WGs (and DHC as well I suppose), but what makes you so concerned
> >>>>>> of this
> >>>> text:
> >>>>>>>>   In deployments where multiple namespaces are present,
> >>>>>>>> selection
> >> of
> >>>>>> I wrote that as I thought it would be useful to talk a little
> >>>>>> about bigger picture of some deployments (like in the demo we had
> >>>>>> few IETFs back - without presence of DHCPv6 more specific route
> >>>>>> options the system would not have worked properly) .. but if that
> >>>>>> text creates an unwanted link or dependency or confusion, I think
> >>>>>> we can drop the text just as well and focus on the document just
> >>>>>> to the new options and leave this kind of additional system-level
> >>>>>> consideration out of the
> >>>> doc.
> >>>>> conceptually the DNS is a unified global namespace. This draft is
> >>>>> a backdoor way of legitimising an ambiguous namespace. I don't
> >>>>> think that will have an easy time in IETF LC, especially if it is
> >>>>> dropped as a surprise into the DNS community. It's your choice,
> >>>>> but I would suggest that exposing it to the DNS WGs now would be a
> smart move.
> >>>> Frankly, I consider this very nearly a showstopper, in the sense
> >>>> that MIF needs an extremely good reason to do this, and I haven't
> >>>> seen even a hint
> >>> of
> >>>>> happen even if you try to remove the "system-level"
> >>>>> considerations, because they are strongly implied anyway.
> >>>>>
> >>>>> Personally I'm not sure what I think about this, but it needs to
> >>>>> be discussed in the community IMHO.
> >>>> +1.
> >>>>
> >>>> Keith

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 13 Sep 2011 06:15:13 -0400

> Sounds good for me - included now for the next update.

I like this too.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 13 Sep 2011 07:56:32 -0400

Hi Andrew,

Thank you for this careful review, and your very helpful comments.  The draft authors should address these issues before the draft moves forward.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 13 Sep 2011 08:00:09 -0400

Hi Brian,

> Has this document been reviewed in DNSEXT and DNSOP?

No, but this is a good thought...  I will talk to Jari and Hui about how best to get good review of this draft by DNS experts.  I'm not sure if we should just send mail to the DNSEXT and DNSOP WGs, or if we should ask for a DNS Directorate review.  Jari and Hui, what do you think?

>>   addresses may be only usable on the network interface over which the

I think there is a lot more acceptance, now, that these sorts of deployments do exist in the real world and need to be handled properly (otherwise they cause real-world problems) than there used to be in the IETF in the past.  We'll see how the discussion goes, but I'm expecting a lot less controversy on this point than we would have seen 5+ years ago.

Margaret

---

From: Hui Deng <[email-masked]>
Date: Wed, 14 Sep 2011 09:02:47 +0800

Hi Margaret,
 
I have seen the draft updated for 04 version, this has been a not small changes, we may can make a last call again for the new draft posting across multiple working groups such as MIF, DNSEXT and DNSOP, require theirs review?
 
Anyway, Andrew and Keith have already made lots of significant comments about alignment with Internet DNS architecture.
 
-Hui

> From: [email-masked]
> Date: Tue, 13 Sep 2011 08:00:09 -0400
> CC: [email-masked]; [email-masked]; [email-masked]
> To: [email-masked]
> 
> 
> Hi Brian,
>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 13 Sep 2011 22:05:39 -0400

Posting the new version ASAP, and having a new LC for the new version makes sense to me.

Maybe we should talk to the DNSEXT and DNSOP chairs before sending the LC to their mailing lists, to see what they think?

Margaret

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Sep 2011 02:40:29 +0000

On Sep 13, 2011, at 10:05 PM, Margaret Wasserman wrote:
Maybe we should talk to the DNSEXT and DNSOP chairs before sending the LC to their mailing lists, to see what they think?

Also, sorry to say, probably DHC, since it's a DHCP option.

---

From: Hui Deng <[email-masked]>
Date: Wed, 14 Sep 2011 10:41:18 +0800

Sure, thanks Ted
 
-Hui

From: [email-masked]
To: [email-masked]
CC: [email-masked]; [email-masked]
Subject: Re: [mif] Last Call for MIF DNS server selection document
Date: Wed, 14 Sep 2011 02:40:29 +0000

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 14 Sep 2011 01:51:35 -0400

> Maybe we should talk to the DNSEXT and DNSOP chairs before sending the LC to their mailing lists, to see what they think?

I did in fact send a note to the dnsext list asking people to come
over here and review or comment.  AFAIK, this had no effect, but I
could be wrong.  

If you want us to run a formal LC on the document in dnsext, I'm
certainly willing to do it.  Note that we have a policy that we need
at least five positive reviews (this is a necessary but not sufficient
condition) for WG consensus in favour to be declared, and we have had
serious problems in DNSEXT in getting sufficient review even for
documents we have actually adopted as WG items.  So be careful what
you ask for.

A

-- 
Andrew Sullivan
[email-masked]