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

[<[e-mail]>]

Hi Andrew,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> ext Andrew Sullivan
> Sent: 09. syyskuuta 2011 21:17
> To: [e-mail]
> Subject: Re: [mif] Last Call for MIF DNS server selection document
>
> > Is it better to talk about "DNS domain" or just "domain"?
>
> I think "domain" is fine, myself.

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

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

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
> DNS is _designed_ to leak this way.

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

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

Ok, changed.

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

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.

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

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

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

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