PTR zone /28 not working

Kevin Darcy kcd at
Thu Nov 5 18:32:45 UTC 2009

joans4nz wrote:
> Hi,
> Thank you Mr Mark Andrews for your answer, and yes, I want help. I am 
> sorry about my first message, I repeat bellow, so I change all 
>'s to my real numbers. Thank you one more 
> time, but i don't understand very well your answers.
> You said: Well you don't serve and you don't 
> allow recursion. You should make yourself a stealth slave for 
> That way reverse lookups will continue to work 
> when your external link goes down. It will also allow remote tools to 
> not require recursion to be enabled to find the CNAME records when 
> they query your server.

> So do I must configure the zone as slave in my 
> named.conf, and in the zone file do I must write the same SOA 
> configuration of my ISP for this zone with the same serial, mail 
> address, ..... and in NS records write this?
>      IN   NS <>   ;My ISP name 
> server
>      IN   NS <>   ;My ISP name 
> server
>      IN   NS <>   ;My ISP name 
> server
>      IN   NS <>   ;My ISP name 
> server
>      IN   NS <>   ;My name server # 1
>      IN   NS <>   ;My name server # 2
You don't write records manually into a slave zone. You replicate the 
entire contents of the zone from the master server(s).
> Is that correct? Because I don't know if my ISP allow transfer a copy 
> of this zone to my DNS servers, I think is not allowed.
Mark was making a suggestion, it's not strictly necessary to get your 
reverse lookups working. But it is highly recommended, for redundancy 
and performance. Your ISP should open up zone transfers. You have, after 
all, been assigned part of that address range for your use. You are a 
legitimate "stakeholder", and should already have a business and trust 
relationship with your ISP. Get them to do it.

Unless you slave or otherwise make a specific 
exception for it in your config, then queries for those names will fall 
into your default "deny" rule and you'll continue to get REFUSED responses.
> You said: The zone's name is 224/, 
> in not part of the zone.
> Why not? If my new ip range address are from to 
>, I think 224/ include 
> address. Please explain me more about it?
Here's the key insight: BIND and DNS aren't treating those 
label-concatenations as addresses, only as names.

As a *name*, is *not* contained within the 
224/ subdomain any more than is contained in 
heed/ They share a common point in the 
hierarchy, but neither one contains the other.

Understand? They're *names*. There is no "address intelligence" or "CIDR 
intelligence" by DNS with respect to the tree. It's treated 
just a sequence of labels that happens to follow a particular naming 

You don't even need to use CIDR ("slash") notation as the convention, by 
the way. Read RFC 2317.  Some folks even opt -- in co-operation with 
their ISP -- to point those CNAMEs to PTRs residing in their "forward" zone:

In; cname

In ptr

which is perfectly legal.

They're just names. You can put them anywhere, the CNAMEs just need to 
point to the right place. Since your ISP maintains the CNAMEs they get 
the final say on where they point, but you can make suggestions.

         - Kevin

> -------------------------
> Hi,
> I use Bind-9.4.2 running on FreeBSD-7.2.
> Last week my DNS was reconfigured to a new IP address pool by my ISP 
> and by me from a /29 to /28 address range.
> Using "How is my DNS" I check my domain and all is good except reverse 
> lookup. My ISP also reconfigured the PTR zone and delegate the reverse 
> zone like RFC-2317 and this is the change executed by my ISP.
> 224/28   IN   NS <>
> 224/28   IN   NS <>
> 225        IN   CNAME   225.224/
> 226        IN   CNAME   226.224/
> 227        IN   CNAME   227.224/
> 228        IN   CNAME   228.224/
> 229        IN   CNAME   229.224/
> 230        IN   CNAME   230.224/
> 231        IN   CNAME   231.224/
> 232        IN   CNAME   232.224/
> 233        IN   CNAME   233.224/
> 234        IN   CNAME   234.224/
> 235        IN   CNAME   235.224/
> 236        IN   CNAME   236.224/
> 237        IN   CNAME   237.224/
> 238        IN   CNAME   238.224/
> I have configured my PTR zone 224/ but, when 
> I test my PTR zone using " 
> <>" or 
> " 
> <>" using default name 
> server I receive "Queried domain does not exist".
> If I test my zone using my name server in this web sites mentioned I 
> receive:
> server can't find REFUSED
> If I use the syntax:
> IN PTR <>.
> /var/log/messages show
> named[38267]: master/db. ignoring out-of-zone data 
> (
> 226 IN PTR <>.
> /var/log/messages does not show any messages but when I test my DNS 
> server from the web sites before mentioned I still receive
> server can't find REFUSED
> If I modify the PTR zone in named.conf and db file to 
> /var/log/messages does not show any messages 
> and when I test my DNS server from the web sites before mentioned I 
> receive a good answer from my DNS server.
> $ORIGIN 224/ does not work
> $ORIGIN 6.66.190.IN-ADDR.ARPA. it work
> What is wrong?
> Why does not work using 224/ zone configuration?
> Thanks for your time.
> joans4nz
> ------------------------------------------------------------------------
> _______________________________________________
> bind-users mailing list
> bind-users at

More information about the bind-users mailing list