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