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

[Andrew Sullivan <[e-mail]>]

Hi,

Thanks for your response.  More inline.

On Fri, Sep 09, 2011 at 10:07:46AM +0000, [e-mail] wrote:
> 
> Is it better to talk about "DNS domain" or just "domain"?

I think "domain" is fine, myself.

> >    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?  
> 
> 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). 

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?
 

> 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.
 
> 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.

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.

> > 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).

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.

> 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.
> --

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:
> --
> 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).
> --

Works for me.

> 
> 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).

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).

> 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.

Ok, I see.

> "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. " ?

Yes.

> > 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..

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.

> > 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?

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:
> --
>             <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>
> --

Yes, I'd get rid of it.




-- 
Andrew Sullivan
[e-mail]