Subject: [DNSOP] draft-mglt-dnsop-search-list-processing-00.txt

From: Daniel Migault <[email-masked]>
Date: Mon, 14 Apr 2014 21:41:10 +0200

Hi folks,

Please find draft-mglt-dnsop-search-list-processing-00.txt [1]  This draft
comes in the context of generic TLD with possible naming collision. In
order to keep naming resolution stable and reliable, it describes 1) how
resolver should generate their search list, 2) how resolver should
distinguish a name resolution that needs to be associated with a search
list and 3) how a resolver should perform a resolution involving search
list.

Feel free to comment/review.

BR,
Daniel

[1] http://tools.ietf.org/html/draft-mglt-dnsop-search-list-processing-00

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Apr 2014 12:20:26 +1000

In message <CADZyTkn2Wau99zfQR+jjwHVr4Jnq3Eo=Ht+OEScbvKBLc=[email-masked]>
> [1] http://tools.ietf.org/html/draft-mglt-dnsop-search-list-processing-00

Firstly there is unqualified, partially qualified, fully qualified and
absolutely names in use today.

	unqualified - single label
	partially qualified  - multi label intended to be fully qualified
			by use of searching.
	fully qualified - multi label not intended to be fully qualified
			by the use of searching.
	absolutely qualified - period at the end (not supported by all
			protocol elements)

	ndots is used to distingish which order to treat a multi
	label input in libresolv/libbind and was added as a response
	to RFC 1535.

	unqualified - search list then as entered.
	partially qualified - search list then as entered.
	fully qualified - as entered then search list.
	absolutely qualified - as entered.

	Additionall there is search continuation on SERFVAIL, NOTIMP
	and NOERROR NO DATA responses to consider.

One also needs to look at RFC 1535 which discourages the use of
automatically constructed search lists.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Tue, 15 Apr 2014 18:44:58 +0200

Thanks for the clarification. I will use these classifications for names
and rewrote the draft with these.

If I understand correctly, your last remark is: Suppose a resolver proceeds
to a resolution using a search list L= label-1, label-2, ...,  label-n. The
resolution goes from label-i to label-j only and only if the returned codes
are SERFVAIL or NOTIMP or NOERROR or NO DATA (I assume NO DATA is
NXDomain).

Is that correct to understand search continuation as going from one label
to another? More specifically, it does not mean to switch from search list
resolution to DNS resolution.

In addition, this also means that a 1) NOERROR does not necessarily end the
resolution. and 2) other RCODEs ends the resolution. Is that correct?

Thanks!
Daniel

On Tue, Apr 15, 2014 at 4:20 AM, Mark Andrews <[email-masked]> wrote:

> > [1]
> http://tools.ietf.org/html/draft-mglt-dnsop-search-list-processing-00
> >
> > --
> > Daniel Migault
> > Orange Labs -- Security
> > +33 6 70 72 69 58
> >
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Apr 2014 13:05:41 -0400 (EDT)

On Mon, 14 Apr 2014, Daniel Migault wrote:

> Please find draft-mglt-dnsop-search-list-processing-00.txt

It states:

   In order to make systems end up with the same search list, here are
    our recommendations:

    - 1)  If the search list results from a manual configuration, then
       DHCP Options MUST NOT automatically affect the search list.  More
       specifically, Domain Name derived from DHCPv4 Domain Name Option
       [RFC2132] or DHCPv6 Client FQDN Option [RFC4704] and DHCP Domain
       Search Option [RFC3397], [RFC3646] are ignored for the concerned
       of search list generation.  This follows the recommendations of
       [RFC3397] and [RFC3646].

    - 2)  If the search list is not manually configured, then DHCP
       Options MAY be considered.  DHCP Domain Search Option [RFC3397],
       [RFC3646] are considered.  If considered, the search list is only
       defined by these options and only these options.

    - 3)  In the absence of DHCP Domain Search Options, the search list
       is derived from the Domain that is the DHCPv4 Domain Name Option
       [RFC2132] or DHCPv6 Client FQDN Option [RFC4704].  If so, the
       search list is only constituted of the Domain name of the host.

    - 4)  If none of these options are provided, then the search list is
       empty and resolution are directly performed over the public DNS.

While I don't disagree that this has been historically the case, with
DNSSEC on the stubs we have new issues to tackle. In the old days, we
could use the DHCP obtained DNS server for resolving, so local names
would just work. Now we don't, so that approach needs additional
configuration. So I do not believe we can keep the above listed old
behaviour intact.

If I hook into a LAN internal.nohats.ca in the office, people expect
that to become part of their search domain. And obviously at a
coffee shop with open wifi, we really do not want to add anything
to the search domain. This is all closely related to interaction with
forwarders, and what we decide to forward (local name to local
nameservers only or everything?).

For a long discussion, see:

https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Apr 2014 13:07:33 +1000

In message <CADZyTk==[email-masked]>, D
> are SERFVAIL or NOTIMP or NOERROR or NO DATA (I assume NO DATA is

Searches currently continue on SERFVAIL, NOTIMP, NOERROR (data does not exist)
and NXDOMAIN.  The *only* safe condition to continue on to a additional search
element is NXDOMAIN.  The list I wrote initially was all the bad choices in
current software.

> resolution to DNS resolution.

Continuation is between search list elements and to/from as entered.
 
> resolution. and 2) other RCODEs ends the resolution. Is that correct?

NOERROR should ALWAYS stop searches.  It currently doesn't.
NXDOMAIN should be the only rcode which causes a search to continue as
apposed to finding a working nameserver (REFUSED, NOTIMP, SERVFAIL are
all good reasons to move to a different nameserver).
 
> --047d7b5d28583a909f04f717852f
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><div><div><div>Thanks for the clarification. I will use th=
> ese classifications for names and rewrote the draft with these.<br><br></di=
> v>If I understand correctly, your last remark is: Suppose a resolver procee=
> ds to a resolution using a search list L=3D label-1, label-2, ...,=C2=A0 la=
> bel-n. The resolution goes from label-i to label-j only and only if the ret=
> urned codes are SERFVAIL or NOTIMP or NOERROR or NO DATA (I assume NO DATA =
> is NXDomain). <br>
> <br>Is that correct to understand search continuation as going from one lab=
> el to another? More specifically, it does not mean to switch from search li=
> st resolution to DNS resolution.<br><br>In addition, this also means that a=
>  1) NOERROR does not necessarily end the resolution. and 2) other RCODEs en=
> ds the resolution. Is that correct?<br>
> <br></div>Thanks!<br></div>Daniel =C2=A0 <div><div><br><br></div></div></di=
> v><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Apr=
>  15, 2014 at 4:20 AM, Mark Andrews <span dir=3D"ltr">&lt;<a href=3D"mailto:=
> [email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex"><br>
> In message &lt;CADZyTkn2Wau99zfQR+jjwHVr4Jnq3Eo=3DHt+OEScbvKBLc=3D<a href=
> =3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>
> <div><div class=3D"h5">, Daniel Migault writes:<br>
> &gt;<br>
> &gt; Hi folks,<br>
> &gt;<br>
> &gt; Please find draft-mglt-dnsop-search-list-processing-00.txt [1] =C2=A0T=
> his draft<br>
> &gt; comes in the context of generic TLD with possible naming collision. In=
> <br>
> &gt; order to keep naming resolution stable and reliable, it describes 1) h=
> ow<br>
> &gt; resolver should generate their search list, 2) how resolver should<br>
> &gt; distinguish a name resolution that needs to be associated with a searc=
> h<br>
> &gt; list and 3) how a resolver should perform a resolution involving searc=
> h<br>
> &gt; list.<br>
> &gt;<br>
> &gt; Feel free to comment/review.<br>
> &gt;<br>
> &gt; BR,<br>
> &gt; Daniel<br>
> &gt;<br>
> &gt; [1] <a href=3D"http://tools.ietf.org/html/draft-mglt-dnsop-search-list=
> -processing-00" target=3D"_blank">http://tools.ietf.org/html/draft-mglt-dns=
> op-search-list-processing-00</a><br>
> &gt;<br>
> &gt; --<br>
> &gt; Daniel Migault<br>
> &gt; Orange Labs -- Security<br>
> &gt; <a href=3D"tel:%2B33%206%2070%2072%2069%2058" value=3D"+33670726958">+=
> 33 6 70 72 69 58</a><br>
> &gt;<br>
> <br>
> </div></div>Firstly there is unqualified, partially qualified, fully qualif=
> ied and<br>
> absolutely names in use today.<br>
> <br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 unqualified - single label<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 partially qualified =C2=A0- multi label intende=
> d to be fully qualified<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0 =C2=A0 by use of searching.<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 fully qualified - multi label not intended to b=
> e fully qualified<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0 =C2=A0 by the use of searching.<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 absolutely qualified - period at the end (not s=
> upported by all<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0 =C2=A0 protocol elements)<br>
> <br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ndots is used to distingish which order to trea=
> t a multi<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 label input in libresolv/libbind and was added =
> as a response<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 to RFC 1535.<br>
> <br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 unqualified - search list then as entered.<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 partially qualified - search list then as enter=
> ed.<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 fully qualified - as entered then search list.<=
> br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 absolutely qualified - as entered.<br>
> <br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Additionall there is search continuation on SER=
> FVAIL, NOTIMP<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 and NOERROR NO DATA responses to consider.<br>
> <br>
> One also needs to look at RFC 1535 which discourages the use of<br>
> automatically constructed search lists.<br>
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> --<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INTE=
> RNET: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> </font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Daniel Mi=
> gault<br>Orange Labs -- Security<br>+33 6 70 72 69 58
> </div>
> 
> --047d7b5d28583a909f04f717852f--