"Empty zones" and BIND 9.4

Mark Andrews Mark_Andrews at isc.org
Wed Jun 20 22:43:14 UTC 2007


> Mark Andrews wrote:
> >> Mark Andrews wrote:
> >>>> For the loopback subnet reverse zone, if you want to create a PTR
> >>>> record for each possible IP, use a wildcard. So instead of this
> >>>> from Mark's example:
> >>>>
> >>>> 1.0.0 PTR localhost.
> >>>>
> >>>> use this:
> >>>>
> >>>> *     PTR localhost.
> >>>>
> >>>> Chris Buxton
> >>>> Men & Mice
> >>>
> >>> Normally you only need "1.0.0 PTR localhost." as that
> >>> is usually the only address in use.
> >>>
> >>> If you don't use it then you don't need a PTR.  If you do
> >>> use it but forget the PTR then you want to stop the query
> >>> leaking so that why the zone is 127.IN-ADDR.ARPA and not
> >>> 1.0.0.127.IN-ADDR.ARPA, 0.0.127.IN-ADDR.ARPA or 0.127.IN-ADDR.ARPA.
> >>> NXDOMAIN will be returned if there is no PTR record.
> >>
> >> Maye I'm confused, but why is it 0.0.127.IN-ADDR.ARPA cannot be used?
> >> Why/how would that cause "query leaking" (and what is that exactly?)
> >
> > If you use address 127.1.1.1 and do a reverse lookup on it
> > then it is will not be answered from 0.0.127.IN-ADDR.ARPA.
> > The query instead will go to the IN-ADDR.ARPA servers and
> > a NXDOMAIN will be returned.  The query is supposed to be
> > answered locally and 127/8 is a purely local resource.
> >
> >> I guess I jsut want to understand the logic & reasoning behind all
> >> this.
> >>
> >>> Additionally the PTR from the wildcard will be rejected by
> >>> may applications / libraries as there is not a corresponding
> >>> A record.
> >>
> >> Wouldn't it just map ever IP that starts with 127. to localhost? How
> >> would that break anything? Looking up, say, 127.0.0.21 would yield
> >> localhost, would it not? Sorry, I just don't see how this could be a
> >> problem.
> >
> > localhost has a well known values (127.0.0.1 and ::1).
> > To make "21.0.0.127.IN-ADDR.ARPA PTR localhost." effective
> > you need to have a "localhost A 127.0.0.21" record on the
> > search path.  Lookups for localhost would then return
> > 127.0.0.1, 127.0.0.21 and ::1.  Not all applictions will
> > cope well with this especially as 127.0.0.21 may not exist
> > on all the machines that get this answer.
> 
> Well, wouldn't be better to have the '* IN PTR localhost' and just have 
> 'localhost IN A 127.0.0.1', that way localhost resolves to 127.0.0.1 
> like expected and 127.0.0.1 (any anything else 127.*) comes back as 
> localhost, as all 127/8 addresses are technically "localhost" addresses?
> 
> -- 
> CL

	Many getnamebyaddr() implementations do forward checks on
	reverse answers and if getnamebyaddr() doesn't parinoid
	applications do.  It is a waste of effort adding PTR records
	without corresponding address records.

	Also all you need is NXDOMAIN to force getnamebyaddr() to
	fallback to /etc/hosts for the non standard addresses in
	127/8.  You however want that to be locally generated rather
	than requiring off local net traffic which is why you use
	127.IN-ADDR.ARPA not 0.0.127.IN-ADDR.ARPA.

	Mark

> >>> I DO NOT recommend adding all the possible A records in this
> >>> space.  It will only cause applications to break.
> >>>
> >>> Mark
> >>>
> >>>> On Jun 18, 2007, at 7:33 AM, Mark Andrews wrote:
> >>>>
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> There was big discussion about empty-zones feature in BIND >= 9.4
> >>>>>> on Red
> >>>>>> Hat's bugzilla. We have found two problems around this.
> >>>>>>
> >>>>>> - RFC 3330 says that loopback could be 127/8. Does anybody here
> >>>>>> know how
> >>>>>> configure 127.in-addr.arpa. zone as described in RFC? $GENERATE
> >>>>>> directive isn't sufficient for solve this problem.
> >>>>>
> >>>>> Why would one want to use $GENERATE.
> >>>>>
> >>>>> zone "127.IN-ADDR.ARPA" {
> >>>>> };
> >>>>>
> >>>>> @ SOA ..
> >>>>> @ NS ..
> >>>>> 1.0.0 PTR localhost.
> >>>>>
> >>>>>> - RFC 2181, section 7.3 tells about MNAME record in SOA. It's
> >>>>>> name of primary server. All empty zones returns name of zone
> >>>>>> instead primary nameserver (could be "localhost.")
> >>>>>
> >>>>> No.  It's the name of the primary (only) nameserver.  It just
> >>>>> happens to be the name of the zone as well.  The zone names
> >>>>> are all legal hostnames.
> >>>>>
> >>>>> draft-ietf-dnsop-default-local-zones-02.txt
> >>>>>
> >>>>> There are also named.conf options to change what is returned.
> >>>>>
> >>>>>> Thanks for any hints,
> >>>>>> Adam
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list