In message <[email protected]>, Matthew Pounse
tt writes:
>
> On 2011/10/22, at 15:21, Keith Moore wrote:
>
> >
> > On Oct 22, 2011, at 2:42 PM, Doug Barton wrote:
> >
> >> 1. I think we're all in agreement that dot-terminated names (e.g.,
> >> example.) should not be subject to search lists. I personally don't have
> >> any problems with any document mentioning that this is the expected
> >> behavior.
> >
> > agree. however there are standard protocols for which a trailing dot in a
> domain name is a syntax error.
>
> Any protocol that makes a standard FQDN a syntax error is itself in error. N
> ot to say that these don't exist, but if people are writing protocols that ca
> n't deal with a properly formatted FQDN they need to stop. Now.
Except it isn't a standard hostname. Periods *seperate* labels in
hostnames RFC 952. They DO NOT appear at the end of hostnames.
Appending a period to the end of a name is user interface hack to
prevent searching. If is also a way to prevent the appending of
the current origin to all names in a DNS master file as the current
origin is always appended if it isn't done.
In addition single labels are not HEIRACHICAL / DOMAIN STYLE names
as envisioned when we went from a flat namespace of simple hostnames
to a heirarchical namespace.
foo.bar is a heirachical hostname.
bar is a simple hostname.
Why are we trying to bring them back on a global context?
> > Strongly disagree. That would leave users without a protocol-independent w
> ay of unambiguously specifying "this is a fully-qualified domain name".
> >
> > The practice of applying search lists to names with "."s in them needs to d
> ie.
>
> I can't agree with this statement. As others have said, the practice of usin
> g a search list to allow 'ssh foo.bar' to reach 'foo.bar.example.com' isn't g
> oing anywhere, and there are a lot of people that make extensive use of the c
> onvenience. Ask any security professional about how easy it is to compete wi
> th convenient access.
>
> I think we need to accept that this practice is here to stay, and figure out
> how to deal with it on those terms.
People deal with all sorts of changes. Point out the obvious
security flaws, make enough fuss, vendors have to ship with this
behaviour gone/disabled. People stop worrying about it.
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
