Bind 9 and IBM AIX 4.3.3 IP V6 reverse loopback resolution

[Mark_Andrews at isc.org]

> 
> in comp.protocols.dns.bind i read:
> >> in comp.protocols.dns.bind i read:
> 
> >> so, `localhost.' [...] shouldn't actually be used -- have i that right?
> >
> >	Yes.  It shouldn't be used for a nameserver name.  It's
> >	ambigious.  It shouldn't be used for the same reason that
> >	you shouldn't publish RFC 1918 addresses in the public
> >	internet.
> 
> in that case it shouldn't be the ptr response either.  (not that i see why
> it shouldn't be present as an ns response, since both provide names for
> which an a request is typically made next, i.e., it's no worse in this
> case.)

	What you are not seeing is that the NS record causes the nameserver
	perform the lookup without the search algorithm being applied to
	"localhost".  The PTR record returns "localhost" to the application
	layer which results in the seach algorithm being applied.

	NS records *always* results in "localhost." being looked up.
	PTR records result in the search list being applied then if there
	is *not* a match on the search list "localhost." is looked up.
 
> >	This following is enough to satisfy every 'paranoid' peer
> >	address checking implementation I've seen.
> >
> >	resolv.conf:
> >	nameserver a.b.c.d
> >	search dv.isc.org
> 
> very few people put a proper search in their resolv.conf.  and it does not
> satisfy the paranoid check on all systems.  in fact nothing in that sample
> has any effect at all; you would have to have an ndots:2 option for it to
> matter.

	One of domainname or seach will do it and most resolvers are
	configured with one or other of these directives.

	ndots has *nothing* to do with this.  A single label is will
	always invoke the search algorithm unless it has been explicitly
	disabled.  Ndots can be used to prevent multilabel hostnames
	being tried as is before the search list is tried.

> >	                                 I'm more worried about people
> >	not doing everything right which results in the root servers
> >	being pumbled with bogus queries.  Using nameservers other than
> >	"localhost." reduces the impact of these mis-configurations.
> 
> i understand your desire, but you are more than a decade too late.
> 
> the ubiquitous zone master file for 0.0.127.in-addr.arpa is:
> 
>   @ in soa ...
>     in ns  ...
>   1 in ptr localhost.   ; notice the period

	You keep assuming that "1 in ptr localhost." will actually
	cause a lookup for "localhost. A".  It usually doesn't.

	Most forward zones have "localhost A 127.0.0.1" in them.  This
	entry matches the gethostbyname("localhost") query.
 
> some systems can be instructed to use dns before files, and on those
> systems the response will be `localhost.'.  in fact on lots of systems even
> gethostbyaddr will respond with `localhost.'

	No.  Gethostbyaddr() will responed with "localhost".  There
	is no period in the name returned.  "localhost." is NOT a
	syntactically valid hostname (see RFC 952).  It is what is
	entered into the DNS but it is returned as "localhost" to
	the application.

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <stdlib.h>

main() {
        struct hostent *he;
        struct in_addr addr;

        addr.s_addr = inet_addr("127.0.0.1");
        he = gethostbyaddr((char *)&addr, sizeof(addr), AF_INET);
        if (he != NULL)
                printf("%s\n", he->h_name);
}

>  so that's what will be used
> in the gethostbyname and since it contains a period it will be done via dns
> unless an ndots option of 2 or higher is present in resolv.conf or the
> system's hosts file contains a localhost. entry (i've never seen one, have
> you?) or the stub resolver contains special case code (some do).  on many
> systems this means a root query.

	This is all based on a false assumption.

> >	If you use "localhost." the you MUST has a "localhost." zone.
> >	You may get this right but a very large percentage of people
> >	won't get this right.
> 
> they would if the isc distributed a zone master file for it, because people,
> whether casual users, distribution maintainers, or systems programmers are
> mostly robots and will just use whatever you provide.  or perhaps not, you
> no longer distribute a master file for 0.0.127.in-addr.arpa, so perhaps it
> would be better if bind contained an internal locahost. zone to be used if
> nothing is locally configured.
> 
> and before anyone mentions rfc 1537, yes i've read it and no i don't agree
> with the section on this because it makes the same mistake, dropping the
> trailing period when considering the effects.
> 
> -- 
> bringing you boring signatures for 17 years
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org