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 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
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
