Stephane Bortzmeyer wrote:
that might be a useful thing to do -- documenting the issues caused
by search lists [...] and that IETF technologies shouldn't rely on

That's certainly a better proposal than the initial one (banning
search lists).

there's a huge unspecified middle and edge of dns, which is the presentation layer. even with RFC 1535 for "ndots", there's nothing that tells an endpoint how to interpret unqualified or partially qualified names -- or how to display them. IDN made this lack of specification even more obvious by not outlawing the other glyphs that look like . or /. BIND was certainly wrong to use RFC 952 to determine what a "hostname" was and to apply that restriction to A/AAAA owners and MX/SRV/NS targets, but there was no better specification available.

However, I wonder if it is really IETF business? It is a local
decision, after all.

RFC's 1535 and 2292 show that endpoint behaviour, not just signaling, are in-scope. the IETF needs more work of this kind, since the norms everybody is violating (mostly without realizing it) turn out to be important to interoperability. that is, partially qualified names and unqualified names are a layering violation, not unlike putting an RFC 1918 address into the FTP "PORT" verb.

paul mockapetris sometimes tells the story of how auto-completion was the motive for writing names with most-local on the left and most-distant on the right. my counter-observation is that when the DNS consisted of a dozen large sites each full of similarly named "hosts" that must have made more sense. now that most of the names most of us look up are not local and not of "hosts", the situation has reversed: auto-completion of .org.redbarn.www would be far easier to implement than of

ted's arguments about the insecurity of "localhost" lookups are one tiny corner of this land-mass sized lack of presentation-layer specification. it turns out you should never put an unqualified name on the wire since the days when your RDNS did search list processing for you are long gone, and it turns out that "localhost" should never have search-list processing applied to it. those two "turns out that"'s add up to a hard requirement to implement localhost-to-address and address-to-localhost lookups in the presentation-layer side of the stub resolver, except, we don't define a presentation layer, so we can't.

P Vixie

DNSOP mailing list

Reply via email to