PTR zone /28 not working
kcd at chrysler.com
Thu Nov 5 18:32:45 UTC 2009
> 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
> CCC.BBB.AAA.in-addr.arpa'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 66.6.190.in-addr.arpa and you don't
> allow recursion. You should make yourself a stealth slave for
> 66.6.190.in-addr.arpa. 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 66.6.190.in-addr.arpa. 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 ns1.etecsa.net <http://ns1.etecsa.net> ;My ISP name
> IN NS ns2.etecsa.net <http://ns2.etecsa.net> ;My ISP name
> IN NS ns3.etecsa.net <http://ns3.etecsa.net> ;My ISP name
> IN NS ns4.etecsa.net <http://ns4.etecsa.net> ;My ISP name
> IN NS ns1.mincex.cu <http://ns1.mincex.cu> ;My name server # 1
> IN NS ns2.mincex.cu <http://ns2.mincex.cu> ;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 66.6.190.in-addr.arpa 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/220.127.116.11.in-addr.arpa,
> 18.104.22.168.in-addr.arpa in not part of the zone.
> Why not? If my new ip range address are from 22.214.171.124 to
> 126.96.36.199, I think 224/188.8.131.52.in-addr.arpa include
> 184.108.40.206.in-addr.arpa 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*, 220.127.116.11.in-addr.arpa is *not* contained within the
224/18.104.22.168.in-addr.arpa subdomain any more than
now.is.the.time.for.all.good.men is contained in
heed/well.the.time.for.all.good.men. 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 in-addr.arpa 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:
22.214.171.124.in-addr.arpa. cname 126.96.36.199.rev.example.com.
188.8.131.52.rev.example.com. ptr foo.example.com.
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.
> 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 ns1.mincex.cu <http://ns1.mincex.cu>
> 224/28 IN NS ns2.mincex.cu <http://ns2.mincex.cu>
> 225 IN CNAME 225.224/184.108.40.206.in-addr.arpa.
> 226 IN CNAME 226.224/220.127.116.11.in-addr.arpa.
> 227 IN CNAME 227.224/18.104.22.168.in-addr.arpa.
> 228 IN CNAME 228.224/22.214.171.124.in-addr.arpa.
> 229 IN CNAME 229.224/126.96.36.199.in-addr.arpa.
> 230 IN CNAME 230.224/188.8.131.52.in-addr.arpa.
> 231 IN CNAME 231.224/184.108.40.206.in-addr.arpa.
> 232 IN CNAME 232.224/220.127.116.11.in-addr.arpa.
> 233 IN CNAME 233.224/18.104.22.168.in-addr.arpa.
> 234 IN CNAME 234.224/22.214.171.124.in-addr.arpa.
> 235 IN CNAME 235.224/126.96.36.199.in-addr.arpa.
> 236 IN CNAME 236.224/188.8.131.52.in-addr.arpa.
> 237 IN CNAME 237.224/184.108.40.206.in-addr.arpa.
> 238 IN CNAME 238.224/220.127.116.11.in-addr.arpa.
> I have configured my PTR zone 224/18.104.22.168.in-addr.arpa. but, when
> I test my PTR zone using "www.kloth.net/services/nslookup.php
> <http://www.kloth.net/services/nslookup.php>" or
> <http://network-tools.com/nslook/Default.asp>" 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
> server can't find 22.214.171.124.in-addr.arpa: REFUSED
> If I use the syntax:
> 126.96.36.199.in-addr.arpa. IN PTR ns1.mincex.cu <http://ns1.mincex.cu>.
> /var/log/messages show
> named: master/db.188.8.131.52:21: ignoring out-of-zone data
> 226 IN PTR ns1.mincex.cu <http://ns1.mincex.cu>.
> /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 184.108.40.206.in-addr.arpa: REFUSED
> If I modify the PTR zone in named.conf and db file to
> 66.6.190.in-addr.arpa. /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/220.127.116.11.IN-ADDR.ARPA. does not work
> $ORIGIN 6.66.190.IN-ADDR.ARPA. it work
> What is wrong?
> Why does not work using 224/18.104.22.168.IN-ADDR.ARPA. zone configuration?
> Thanks for your time.
> bind-users mailing list
> bind-users at lists.isc.org
More information about the bind-users