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

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

On Sep 8, 2011, at 4:43 PM, Andrew Sullivan wrote:

> Dear colleagues,
> 
> On Mon, Aug 29, 2011 at 03:31:39PM +0800, Hui Deng wrote:
>> 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
> 
> 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
> ajs@anvilwalrusden.com
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif