Subject: [mif] some questions about dns-server-selection

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Nov 2012 14:04:23 -0500

Thank you to the MIF WG for sending out spores to other WG this week to
tell us about your work.  

I realize that dns-server-selection-12 is in the RFC editor queue, but I
had some questions about it.  I found the document to be well written,
relatively clear, and I found that the security discussion was informed
and appropriate.  

Why does the IPv6 DHCP option have a single DNS recursive server listed,
while the IPv4 one has a primary and secondary?

What is the preference for a DNS server learnt from a DHCP server that
does not send the DNS_SERVER_SELECT option? I guess section 4.6 talks
about this, but I felt was a bit buried.

I think that this document is very good example of why DNS64 *should*
have provided signaling that DNS64 was occuring in DHCP and RA :-)
That would have informed a host better as to which interface to use
for better service. 

Also, the document keeps saying "network interface".   I understand that
to mean a specific device, e.g. "wlan0".   I think, however, that really
it should be read to understand "wlan0"+"specific ESSID" for the wifi
case, and perhaps "specific APN" for the cellular case.  It's funny that
wired, has no such "sub-interface" naming system...

Why are only DHCP methods documented? what about RA options?

I found the section: 
   As the DHCP by itself cannot tell whether it is using secure, trusted
   channel, or whether the client on a node is performing DNSSEC
   validation, this option cannot be used without being explicitly
   enabled.  The functionality can be enabled for an interface via
   administrative means, such as by provisioning tools or manual
   configuration.  Furthermore, the functionality can be automatically
   enabled by a client on a node that knows it is performing DNSSEC
   validation, or by a node that is configured or hard-coded to trust
   certain interfaces (see Section 9.2).

so, basically, please never use this protocol unless you know what you
are doing, in which case, you should just vi /etc/resolv.conf instead?
That DNSSEC is required to even think about using this is instructive,
because it means that actually, recursive DNS lookups are local already.

-- 
Michael Richardson
-on the road-

---

From: <[email-masked]>
Date: Mon, 12 Nov 2012 08:49:46 +0000

> while the IPv4 one has a primary and secondary?

On this I have to confess I don't recall a particular reason (this draft has been in works for four years, and the early days are getting blurry in my memory). Do you see this as a serious issue that REALLY should be addressed before publication? 

> What is the preference for a DNS server learnt from a DHCP server that does
> not send the DNS_SERVER_SELECT option? I guess section 4.6 talks about
> this, but I felt was a bit buried.

Medium, quote from document:
--
   The RDNSSes learned via other tools than OPTION_DNS_SERVER_SELECT
   MUST be handled as default RDNSSes, with medium preference, when
   building a list of RDNSSes to talk to (see Section 4.1).
--

> I think that this document is very good example of why DNS64 *should* have
> provided signaling that DNS64 was occuring in DHCP and RA :-) That would
> have informed a host better as to which interface to use for better service.

This is sidetrack for MIF and DNS server selection, right? (More for Behave). Anyhow, I don't think DHCP/RA should be involved in DNS64/NAT64, but instead it *would* have been nice if DNS64 would have included e.g. EDNS0 options to indicate (for modified hosts) that synthesis is taking place. It would've also helped in Pref64::/n discovery, see: http://datatracker.ietf.org/doc/draft-korhonen-edns0-synthesis-flag/ 

Too late for that, though.

> it should be read to understand "wlan0"+"specific ESSID" for the wifi case,
> and perhaps "specific APN" for the cellular case.  It's funny that wired, has no
> such "sub-interface" naming system...

Terminology... Maybe "point of network attachment" would have been better choice of working?

> Why are only DHCP methods documented? what about RA options?

That would be a topic for another document, for someone who wants this to RA (I volunteer to coauthor if someone wants to pursue that, but I don't have time to be the lead author for that piece of work).

> so, basically, please never use this protocol unless you know what you are
> doing, in which case, you should just vi /etc/resolv.conf instead?
> That DNSSEC is required to even think about using this is instructive, because
> it means that actually, recursive DNS lookups are local already.

You should check the zillion emails about security discussions related to this draft.

If you are not sure about security, use OPTION_DNS_SERVERS.

But please read carefully the text you quoted:" using secure, trusted channel, ". This means that if a channel from a host to the DHCP server is trusted, DNSSEC is not needed. These kinds of environments exist e.g. in 3GPP domain, where the cellular connection is considered trusted enough for this purpose.

Best regards,

	Teemu

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2012 13:08:19 -0500

>>>>> "teemu" == teemu savolainen <[email-masked]> writes:
    teemu> On this I have to confess I don't recall a particular reason
    teemu> (this draft has been in works for four years, and the early
    teemu> days are getting blurry in my memory). Do you see this as a
    teemu> serious issue that REALLY should be addressed before
    teemu> publication?

No.

    >> so, basically, please never use this protocol unless you know
    >> what you are doing, in which case, you should just vi
    >> /etc/resolv.conf instead?  That DNSSEC is required to even think
    >> about using this is instructive, because it means that actually,
    >> recursive DNS lookups are local already.

    teemu> You should check the zillion emails about security
    teemu> discussions related to this draft.

I figured as much.

    teemu> But please read carefully the text you quoted:" using secure,
    teemu> trusted channel, ". This means that if a channel from a host
    teemu> to the DHCP server is trusted, DNSSEC is not needed. These
    teemu> kinds of environments exist e.g. in 3GPP domain, where the
    teemu> cellular connection is considered trusted enough for this
    teemu> purpose.

okay, an existence proof of this kind of enough for me.

-- 
Michael Richardson
-on the road-