Quick reverse dns zone question

Mark Andrews marka at isc.org
Fri Jan 25 23:38:28 UTC 2013


In message <CAHEKYV55Q7oddjc8OVFSd1eURTrYJUXoZksLyrR0X9bixjF6MQ at mail.gmail.com>, Mauricio Tavares writes:
> so I want to define a reverse dns zone to handle 172.16.101.64/27. In
> the named.conf file I set:
> 
> acl bogusnets {
>         0.0.0.0/8;
>         1.0.0.0/8;
>         2.0.0.0/8;
>         192.0.2.0/24;
>         224.0.0.0/3;
>         10.0.0.0/8;
>         !172.16.101.64/27;
>         172.16.0.0/12;
>         192.168.0.0/16;
> };
> 
> [...]
> // 172.16.101.64/27
> // zone "101.16.172.in-addr.arpa" IN {
> // zone "64/27.101.16.172.in-addr.arpa" IN {
> zone "64-27.101.16.172.in-addr.arpa" IN {
>         type master;
>         file "/etc/bind/64-27.101.155.216.in-addr.arpa.zone";
> };
> 
> but when I try to get, say, the fqdn for 172.16.191.84 (using dig or
> nslookup pointed at the above dns), I get
> 
> Jan 17 15:52:05 mirror named[4078]: client 172.16.101.84#59786: RFC 1918
> response from Internet for 66.101.16.172.in-addr.arpa
> 
> Since I know that if I use zone "101.16.172.in-addr.arpa" IN { it
> works as it should, I must believe it is ignoring my reverse zone and
> asking the big wide world to resolve my request. I thought that
> starting the zone with either 64-27 or 64/27 would define my
> less-than-class-C network (172.16.101.64/27).

Since you are using 172.16.191.64/27 rather than 172.16.191.0/24
presumably this private space has been delegated too you rather
than you having choosen to use it.

You need to talk to whomever did this delegation to arrange for a
RFC 2317 style delegation to be made if you wish to consolidate all
the PTR records in a single zone.  You also need to slave the
"parent" zone so that you have the mapping from the well known
reverse names to the names you are actually using.

zone "101.16.172.in-addr.arpa" {
	type slave;
	file "/etc/bind/101.16.172.in-addr.arpa.zone";
	masters { .... };
};
zone "64-27.101.16.172.in-addr.arpa" IN {
        type master;
        file "/etc/bind/64-27.101.155.216.in-addr.arpa.zone";
};

If you don't wish to do this you can create a reverse zone for every
address in this range and put the PTR record at the zone apex.  These
zones should still be delegated to you by whomever delegated the space.

zone "64.101.16.172.in-addr.arpa" {
	type master;
	file "64.101.16.172.in-addr.arpa";
	....
};
zone "65.101.16.172.in-addr.arpa" {
	type master;
	file "65.101.16.172.in-addr.arpa";
	....
};
...
zone "95.64.101.16.172.in-addr.arpa" {
	type master;
	file "95.101.16.172.in-addr.arpa";
	....
};

64.101.16.172.in-addr.arpa:
@	3600	SOA	ns.example.net.	hostmaster.example.net. .....
@	3600	NS	ns.example.net.

65.101.16.172.in-addr.arpa:
@	3600	SOA	ns.example.net.	hostmaster.example.net. .....
@	3600	NS	ns.example.net.
@	3600	PTR	router.example.net.

95.101.16.172.in-addr.arpa:
@	3600	SOA	ns.example.net.	hostmaster.example.net. .....
@	3600	NS	ns.example.net.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the bind-users mailing list