Date: Sun, 30 Mar 2003 11:36:24 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Terry Lambert <tlambert2@mindspring.com> Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@ofug.org> Subject: Re: Allow underscores in DNS names Message-ID: <200303301636.h2UGaODN042934@whizzo.transsys.com> In-Reply-To: Your message of "Sat, 29 Mar 2003 18:18:18 PST." <3E8653EA.BAF9D765@mindspring.com> References: <xzpu1dm2k2h.fsf@flood.ping.uio.no> <3E864AD1.6C1C3656@mindspring.com> <200303300205.h2U25vDN037209@whizzo.transsys.com> <3E8653EA.BAF9D765@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> "Louis A. Mamakos" wrote:
> > > There was a better patch that made it an option in resolv.conf,
> > > rather than turning it on all the time.
> >
> > This is great, except that you'd don't need to have a resolv.conf
> > on your system at all; the resolver will default to using a local
> > caching nameserver.
>
> By this argument, it should do that anyway, if the only option
> is this one.
>
> My own argument is that there should be an "allow_chars" option
> in the resolv.conf, so that the Tuesday after this is committed,
> and someone now wants "#" in domain names to support their idea
> of mapping phone numbers to domain names, we don't have to go
> through this whole dumb "let's violate RFC-952, just this once!"
> argument yet againt.
Sure, fine. Note that RFC-952 was written in a time where most
host names were looked up in a file that was periodically FTP'ed
from SRI-NIC.
>
> > > FreeBSD should be standards compliant, by default, and take work
> > > to make it possible to give bogus data to other hosts on the
> > > Internet who can not handle "_" or other characters because they
> > > *are* standars compliant.
> >
> > Since this is a resolver option, you're not handing out names to
> > other hosts using the DNS infrastructure.
>
> You are if you are a caching DNS server, which uses the resolver
> code to look up data on the global DNS, caches it, and returns
> it to local DNS querants.
No, I don't think so, otherwise you break the DNS's ability to to
have any strings of octets be DNS labels. A caching DNS server
does not do gethostbyname(), nor does it use a stub resolver to
resolve queries.
[...]
>
> > > "Be conservative in what you send."
> >
> > And liberal in what you receive, which is exactly what modifing
> > the resolver to not cause gethostbyname() and it's ilk to barf
> > on these types of names.
>
> And liberal in what you resend?
As I mentioned above, this discussion is irrelevant when it comes
to "resending" anything within the context of the DNS. It's a policy
decision on the part of the stub resolver that back-ends gethostby*().
> Reading the 1998 discussion, as was previously suggested, is a
> good idea.
>
>
> > There are lots of things in ancient RFCs which probably do not
> > make as much sense these days as they once did.
>
> There is a fix for that: join an IETF group, and create a
> "supercedes" RFC.
Having served as the first chair of the DNS working group in the
IETF more than a decade ago, I'm somewhat familiar with the
process and the DNS, thanks.
> The standards are the standards, as they are.
Let's just review the first few paragraphs of this "standard:"
STATUS OF THIS MEMO
This RFC is the official specification of the format of the Internet
Host Table. This edition of the specification includes minor
revisions to RFC-810 which brings it up to date. Distribution of this
memo is unlimited.
INTRODUCTION
The DoD Host Table is utilized by the DoD Hostname Server maintained
by the DDN Network Information Center (NIC) on behalf of the Defense
Communications Agency (DCA) [See RFC-953].
LOCATION OF THE STANDARD DOD ONLINE HOST TABLE
A machine-translatable ASCII text version of the DoD Host Table is
online in the file NETINFO:HOSTS.TXT on the SRI-NIC host. It can be
obtained via FTP from your local host by connecting to host
SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51), logging in as user =
ANONYMOUS, password = GUEST, and retrieving the file
"NETINFO:HOSTS.TXT". The same table may also be obtained via the NIC
Hostname Server, as described in RFC-953. The latter method is
faster and easier, but requires a user program to make the necessary
connection to the Name Server.
Everyone that's still usign the DOD ONLINE HOST TABLE, please raise
your hand? Thanks.
>
> > If there is a security issue in applications, they should get
> > fixed regardless.
>
> OK.
>
> So you are advocating getting rid of the stupid "This program
> uses gets(), which is unsafe" messages, right?
I dunno, do the program do DNS queries?
> Because the programs where the API that is being used lead to a
> security isseu in applications, when people do not know how to
> use the API properly.
These programs are still broken and code in the stub resolver won't
protect them from bogus names in /etc/hosts or NIS, so don't sleep
too soundly at night, thinking you're safe from the evil underscores.
>
> > All this heartburn over what the gethostbyname() library function
> > chooses to believe from the DNS still doesn't address getting
> > hostnames out of NIS or /etc/hosts.
>
> NIS and /etc/hosts should *NEVER* contain a host name with an
> "_". *NEVER*.
Really. Using the awesome power of emacs, I caused this to happen on
my system. Further, please do a 'man hosts' and see the last
sentence of the DESCRIPTION section:
Host names may contain any printable character other
than a field delimiter, newline, or comment character.
louie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200303301636.h2UGaODN042934>