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

[Daniel Migault <[e-mail]>]

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 <[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]