"Empty zones" and BIND 9.4

[Mark Andrews]

> 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.
 
> -- 
> CL
> 
> > 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
> >>>
> >>>
> >>
> >>
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org