In message <CADZyTkn2Wau99zfQR+jjwHVr4Jnq3Eo=Ht+OEScbvKBLc=7...@mail.gmail.com>
, 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]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
