In message <CADZyTk==qg6yf81px4k+t5rn7usgz3xglw7xiubes2dvrs7...@mail.gmail.com>, 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 <[email protected]> wrote: > > > > > In message <CADZyTkn2Wau99zfQR+jjwHVr4Jnq3Eo=Ht+OEScbvKBLc= > > [email protected]> > > , 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 > > > +33 6 70 72 69 58 > > > > > > > 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 protected] > > > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > > --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"><<a href=3D"mailto:= > [email protected]" target=3D"_blank">[email protected]</a>></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 <CADZyTkn2Wau99zfQR+jjwHVr4Jnq3Eo=3DHt+OEScbvKBLc=3D<a href= > =3D"mailto:[email protected]";>[email protected]</a>><br> > <div><div class=3D"h5">, Daniel Migault writes:<br> > ><br> > > Hi folks,<br> > ><br> > > Please find draft-mglt-dnsop-search-list-processing-00.txt [1] =C2=A0T= > his draft<br> > > comes in the context of generic TLD with possible naming collision. In= > <br> > > order to keep naming resolution stable and reliable, it describes 1) h= > ow<br> > > resolver should generate their search list, 2) how resolver should<br> > > distinguish a name resolution that needs to be associated with a searc= > h<br> > > list and 3) how a resolver should perform a resolution involving searc= > h<br> > > list.<br> > ><br> > > Feel free to comment/review.<br> > ><br> > > BR,<br> > > Daniel<br> > ><br> > > [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> > ><br> > > --<br> > > Daniel Migault<br> > > Orange Labs -- Security<br> > > <a href=3D"tel:%2B33%206%2070%2072%2069%2058" value=3D"+33670726958">+= > 33 6 70 72 69 58</a><br> > ><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 protected]";>[email protected]</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-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
