"Empty zones" and BIND 9.4
Mark Andrews
Mark_Andrews at isc.org
Wed Jun 20 20:47:42 UTC 2007
> 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
More information about the bind-users
mailing list