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

[Mark Andrews <[e-mail]>]

In message <CADZyTk==[e-mail]>, D
aniel Migault writes:
> 
> 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).

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.

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

Continuation is between search list elements and to/from as entered.
 
> 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?

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).
 
> Thanks!
> Daniel
> 
> 
> 
> 
> On Tue, Apr 15, 2014 at 4:20 AM, Mark Andrews <[e-mail]> wrote:
> 
> >
> > In message <CADZyTkn2Wau99zfQR+jjwHVr4Jnq3Eo=Ht+OEScbvKBLc=
> > [e-mail]>
> > , Daniel Migault writes:
> > >
> > > 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
> > > [phone]
> > >
> >
> > 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: [phone]                 INTERNET: [e-mail]
> >
> 
> 
> 
> -- 
> Daniel Migault
> Orange Labs -- Security
> [phone]
> 
> --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:=
> [e-mail]" target=3D"_blank">[e-mail]</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:[e-mail]">[e-mail]</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"[phone]">+=
> 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"[phone]">+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:[e-mail]">[e-mail]</a><br>
> </font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Daniel Mi=
> gault<br>Orange Labs -- Security<br>[phone]
> </div>
> 
> --047d7b5d28583a909f04f717852f--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]