Subject: localhost.

From: Edward Lewis <[email-masked]>
Date: Thu, 1 Apr 1999 16:20:30 -0500

(This question is pertinent to DNS security extenstions:)

     Who signs "localhost. A 127.0.0.1"?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                       Network Associates/TIS
Phone: +1 443-259-2352                             Email: [email-masked]

Think globally, scope locally.
"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

Opinions expressed are property of my evil twin, not my employer.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Fri, 02 Apr 1999 00:01:16 -0500

If someone is going to add any local data like "localhost" that they
want authenticated, then they need to sign it and staticly configure
the authenticating public key.  If they are following RFC 2535
closely, then, according to section 6.3.1 rule 3, anything that is
directly signed by a staticly configured key is accepted regardless
of the relation between their names.  If your local policy does not
accept rule 3 but is more restrictive, then the staticly configured
key would probably have to have owner name localhost. or root.

Another solution, of course, would be to add a "localhost" top level
domain name to the root zone and have the generally accepted root sign
it but there are two problems with that: (1) its not clear to me when
root will be secured and (2) the political nonsense that has swirled
around the root for the past three years makes changes to the root
very difficult.

Thanks,
Donald

From:  Edward Lewis <[email-masked]>
Message-Id:  <v0313031cb32993455305@[10.33.10.3]>
Date:  Thu, 1 Apr 1999 16:20:30 -0500
To:  [email-masked]
Cc:  [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Fri, 02 Apr 1999 21:12:58 +1000

Date:        Thu, 1 Apr 1999 16:20:30 -0500
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <v0313031cb32993455305@[10.33.10.3]>

  |      Who signs "localhost. A 127.0.0.1"?

Aside from what Donald said, who cares?   Why would anyone want that
record?

In almost all situations, a lookup of "localhost" (which is what software
actually looks up) results in a lookup of "localhost.my.dom.ain." as names
without dots are essentially always treated as being a name within the
local domain, or at least, somewhere on the domain search path.

I have never had a "localhost." fake entry in any DNS server I have ever
managed, and I have never felt any ill effects from that (I also disable all
lookups in /etc/hosts or similar after initial boot config is done, so my
lookups aren't finding a "localhost" in there either).

The better question would have been

	Who signs "1.0.0.127.IN-ADDR.ARPA. IN PTR localhost." ?

Then Donald's (first paragraph of) answer becomes more relevant.
I don't think that having this being a "well known" zone is the
appropriate response, as that would prevent me from also having
a "2.0.0.127.IN-ADDR.ARPA" for my second loopback interface, etc...

kre

---

From: Edward Lewis <[email-masked]>
Date: Fri, 2 Apr 1999 08:35:10 -0500

>lookups aren't finding a "localhost" in there either).

Originally, nslookup complained because I hadn't included a localhost in my
DNSSEC test zones.  So I added localhost entries to all the zones, and then
realized the conflict in the rev-map entry.  My rev-map has multiple PTR's
because of this.  That got me wondering if/how we'd ever manage to sign the
rev-map.

Not having a long history of running BIND (or DNS in general), I consulted
Cricket Liu's ORA book.  It mentions including the "localhost." entry.
That is what prompted me to ask the question this way.

Having the one localhost. rather than multiple localhost mappings makes it
feasible to have one signature cover the rev-map entry.

Are current software weaknesses (like looking up localhost instead of
localhost.) a reason to leave this (or any) part of the DNS dangling?  It
would seem to me that this can be corrected in a non-disruptive manner
(assuming "broken" software never asks for the rev-map of localhost to
confirm the result).

---

From: Paul A Vixie <[email-masked]>
Date: Fri, 02 Apr 1999 08:06:01 -0800

well, 127/8 is a 1918-like net so perhaps 1918bis can address this.