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
them
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 www.redbarn.org.
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
