[Pdns-users] Reverse Lookup zone subnetted

bryantz-pdns at zktech.com bryantz-pdns at zktech.com
Fri Jul 19 12:55:54 UTC 2019


Brian

Thank you for your response. 

So what we have in our pdns server is this. zone

zone 160/27.176.183.65.in-addr.arpa
records 

160/27.176.183.65.in-addr.arpa
	 NS	 ns1.granddial.net

160/27.176.183.65.in-addr.arpa
	 NS	 ns2.granddial.net

179.160/27.176.183.65.in-addr.arpa
	 PTR	 mail.granddial.net

179.160/27.176.183.65.in-addr.arpa
	 PTR	 mail.granddial.com

Our provider has the following in their DNS server (Not Power DNS)

65.183.176.160/27    
160/27   IN      NS      NS1.ZKTECH.NET.
161      IN      CNAME   161.160/27
162      IN      CNAME   162.160/27
163      IN      CNAME   163.160/27
164      IN      CNAME   164.160/27
165      IN      CNAME   165.160/27
166      IN      CNAME   166.160/27
167      IN      CNAME   167.160/27
168      IN      CNAME   168.160/27
169      IN      CNAME   169.160/27
170      IN      CNAME   170.160/27
171      IN      CNAME   171.160/27
172      IN      CNAME   172.160/27
173      IN      CNAME   173.160/27
174      IN      CNAME   174.160/27
175      IN      CNAME   175.160/27
176      IN      CNAME   176.160/27
177      IN      CNAME   177.160/27
178      IN      CNAME   178.160/27
179      IN      CNAME   179.160/27
180      IN      CNAME   180.160/27
181      IN      CNAME   181.160/27
182      IN      CNAME   182.160/27
183      IN      CNAME   183.160/27
184      IN      CNAME   184.160/27
185      IN      CNAME   185.160/27
186      IN      CNAME   186.160/27
187      IN      CNAME   187.160/27
188      IN      CNAME   188.160/27
189      IN      CNAME   189.160/27
190      IN      CNAME   190.160/27

If we do the following dig against any public server we get the expected PTR records. 

 dig -x 65.183.176.179 @8.8.8.8
; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> -x 65.183.176.179 @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17920
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;179.176.183.65.in-addr.arpa.   IN      PTR
;; ANSWER SECTION:
179.176.183.65.in-addr.arpa. 21599 IN   CNAME   179.160/27.176.183.65.in-addr.arpa.
179.160/27.176.183.65.in-addr.arpa. 119 IN PTR  mail.granddial.net.
179.160/27.176.183.65.in-addr.arpa. 119 IN PTR  mail.granddial.com.
;; Query time: 175 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jul 19 08:18:08 EDT 2019
;; MSG SIZE  rcvd: 145

If we do the following dig against our dns server we get a failure... 

 dig -x 65.183.176.179 @ns1.granddial.net
; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> -x 65.183.176.179 @ns1.granddial.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 30112
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;179.176.183.65.in-addr.arpa.   IN      PTR
;; Query time: 24 msec
;; SERVER: 216.109.195.252#53(216.109.195.252)
;; WHEN: Fri Jul 19 08:49:21 EDT 2019
;; MSG SIZE  rcvd: 56

By adding to our powerdns server a zone

zone
176.183.65.in-addr.arpa

records
160/27.176.183.65.in-addr.arpa NS ns1.granddial.net
179.176.183.65.in-addr.arpa CNAME 179.160/27.176.183.65.in-addr.arpa

We now get correct dig results, but 

dig -x 65.183.176.179 @ns1.granddial.net
; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> -x 65.183.176.179 @ns1.granddial.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1334
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;179.176.183.65.in-addr.arpa.   IN      PTR
;; ANSWER SECTION:
179.176.183.65.in-addr.arpa. 120 IN     CNAME   179.160/27.176.183.65.in-addr.arpa.
179.160/27.176.183.65.in-addr.arpa. 120 IN PTR  mail.granddial.net.
179.160/27.176.183.65.in-addr.arpa. 120 IN PTR  mail.granddial.com.
;; Query time: 22 msec
;; SERVER: 216.109.195.252#53(216.109.195.252)
;; WHEN: Fri Jul 19 08:44:46 EDT 2019
;; MSG SIZE  rcvd: 145

The issue is now our powerdns server tries to resolve all 255 address in the root level domain, and we only have authority for our /27 block. 
I really need some way to allow reverse lookup to respond on only the /27 IP addresses in our block

I know I could put in a separate zone file for each IP address, but with 15 to 20 /27 blocks that is over 300 domains 

Any ideas would be appreciated

Thanks
Bryant

----------------------------------------
From: Brian Candler <b.candler at pobox.com>
Sent: 7/19/19 4:20 AM
To: bryantz-pdns at zktech.com, pdns-users at mailman.powerdns.com
Subject: Re: [Pdns-users] Reverse Lookup zone subnetted
On 19/07/2019 00:02, bryantz-pdns at zktech.com wrote:
zone file - 60/27.1.1.1.in-addr.arpa
We then added PTR records for it would looks something like

62.60/27.1.1.1.in-addr.arpa. IN PTR mail.ourserver.net
63.60/27.1.1.1.in-addr.arpa. IN PTR mail.ourotherserver.net

For some reason PowerDNS will not handle the reverse zone as 60/27.1.1.1.in-addr.arpa
It will not respond to reverse dns lookup requests. 

In what sense will it "not respond"?  What do you actually see, if you run:

dig @x.x.x.x 62.60/27.1.1.1.in-addr.arpa. ptr

where x.x.x.x is your PowerDNS auth server?

Also: if you show the real IP address as per free support policy, we can check if the delegation is correct or not.

Bryant Zimmerman 
 
Sr. Systems Architect
Grand Dial Communications, A ZK Tech Inc. Company
616-299-5607 (mobile) 
616-855-1030 Ext. 2003 (office)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20190719/9d693dd0/attachment.html>


More information about the Pdns-users mailing list