Of course you realize that there's a fairly obvious implication to what you
just said: "we need to write another document!!11!"


On Mon, Feb 12, 2018 at 12:51 PM, Paul Vixie <p...@redbarn.org> wrote:

> 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
DNSOP mailing list

Reply via email to