trying to send a query to powerdns and expected result not being returned

Question

Trying to use powerdns for enum(voip) dns queries.

I believe I have it all setup correctly.

it appears to be correct in the mysql tables

select * from records\G
     id: 3
     domain_id: 3
     name: 0.1.9.2.8.4.3.3.0.7.1.e164.arpa
     type: NAPTR
     content: 100 10 "u" "E2U+sip" "!^.*$!sip:17033482910@10.0.0.12!" .
     ttl: 120
     prio: NULL
    change_date: NULL

 select * from domains\G
         id: 3
         name: e164.arpa
         master: 127.0.0.1
         last_check: NULL
         type: MASTER
         notified_serial: NULL
         account: NULL

and i can see the query based on pdns logs:

Jun  8 16:10:47 localhost pdns[12575]: Remote 127.0.0.1 wants '0.1.9.2.8.4.3.3.0.7.1.e164.arpa|NAPTR', do = 0, bufsize = 512: packetcache MISS
Jun  8 16:10:47 localhost pdns[12575]: Query: select content,ttl,prio,type,domain_id,name from records where type='SOA' and name='0.1.9.2.8.4.3.3.0.7.1.e164.arpa'
Jun  8 16:10:47 localhost pdns[12575]: Query: select content,ttl,prio,type,domain_id,name from records where type='SOA' and name='1.9.2.8.4.3.3.0.7.1.e164.arpa'
Jun  8 16:10:47 localhost pdns[12575]: Query: select content,ttl,prio,type,domain_id,name from records where type='SOA' and name='9.2.8.4.3.3.0.7.1.e164.arpa'

however my digs fail:

dig NAPTR @127.0.0.1  0.1.9.2.8.4.3.3.0.7.1.e164.arpa

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> NAPTR @127.0.0.1 0.1.9.2.8.4.3.3.0.7.1.e164.arpa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 8911
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;0.1.9.2.8.4.3.3.0.7.1.e164.arpa. IN    NAPTR

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jun  8 16:04:28 2015
;; MSG SIZE  rcvd: 49

I see why there are no results "type=SOA" in the mysql query, but why is trying type='SOA' and not 'NAPTR'?

The answer is based on Håkan Lindqvist's suggestions:

make records table look like this:

     id: 6
     domain_id: 3
     name: someServer.com
     type: SOA
     content: ns1.someDNSServer.com
     ttl: 120
     prio: NULL
     change_date: NULL
      *************************** 2. row ***************************
     id: 7
     domain_id: 3
     name: someServer.com
     type: NS
     content: ns1.someDNSServer.com
     ttl: 120
     prio: NULL
     change_date: NULL

Yes, with what you showed in the question it's made clear that there is no `NAPTR` record to be found; there is no chance of success. (Instead you see the supposed `NAPTR`-data mis-parsed into a `SOA` record in the negative response.) — Håkan Lindqvist, Jun 08 '15 at 20:06
Regarding the edited-in solution, the `SOA` RData looks malformatted and the owner names don't appear to match the zone name. If it helps, I can format the records differently in my answer, I just think that the standardized format is best recognized and more readable. — Håkan Lindqvist, Jun 08 '15 at 21:00

Håkan Lindqvist · Accepted Answer · 2015-06-08T22:19:16.900

I believe the issue is not with your NAPTR record in itself but that PowerDNS does not consider your zone valid until it has a SOA record.

Disregarding the specific behavior of PowerDNS, the requirements in DNS in general is that any zone should have at least SOA and NS records at its apex.
(PowerDNS does not appear to validate the NS aspect of this, but failing to add these records will cause problems.)

I'm not sure it actually makes sense that you are setting up a zone for the entirety of e164.arpa but in more general terms, if the name of your zone is foo.example you'd want something like this:

foo.example.     7200    IN      SOA     ns1.example.com. hostmaster.example.com. 1 3600 1800 2419200 7200
foo.example.     7200    IN      NS      ns1.example.com.
foo.example.     7200    IN      NS      ns2.example.com.
...

You'll want to add these mandatory records to your zones in addition to the specific data you want.

As was noted by Michael, 2.8.4.3.3.0.7.1.e164.arpais a more likely zone name (that would be +1 703 348 2).

In PowerDNS specific terms, if you are working directly in SQL (which is not necessarily ideal) adding this zone would be something like:

INSERT INTO domains (name, type) VALUES('2.8.4.3.3.0.7.1.e164.arpa', 'MASTER');
INSERT INTO records (domain_id, name, ttl, type, content) VALUES(7, '2.8.4.3.3.0.7.1.e164.arpa', 7200, 'SOA', 'ns1.example.com hostmaster.example.com 1 3600 1800 2419200 7200');
INSERT INTO records (domain_id, name, ttl, type, content) VALUES(7, '2.8.4.3.3.0.7.1.e164.arpa', 7200, 'NS', 'ns1.example.com');
INSERT INTO records (domain_id, name, ttl, type, content) VALUES(7, '2.8.4.3.3.0.7.1.e164.arpa', 7200, 'NS', 'ns2.example.com');

After which you would add your NAPTR record(s):

INSERT INTO records (domain_id, name, ttl, type, content) VALUES(7, '0.1.9.2.8.4.3.3.0.7.1.e164.arpa', 7200, 'NAPTR', '...');
...

More likely `2.8.4.3.3.0.7.1.e164.arpa` if +1 703 348 2 is delegated to them. — Michael Hampton, Jun 08 '15 at 20:50
I am quite a noob when it comes to DNS, so I will take an advice.. — bart2puck, Jun 08 '15 at 21:29
Well, the bad news is that [country code 1 hasn't even been delegated](http://enumdata.org/#1) yet, so the world will never see these records until that (eventually) happens. — Michael Hampton, Jun 08 '15 at 22:20
Thank you for the continued comments. You are very helpful. Why did you say "if you are working directly in SQL (which is not necessarily ideal)"? What problems could arise? — bart2puck, Jun 09 '15 at 11:27

trying to send a query to powerdns and expected result not being returned

1 Answers1