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

[Mark Andrews <[e-mail]>]

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]