1

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:[email protected]!" .
     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
3
  • 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.) Jun 8, 2015 at 20:06
  • ok thats a bit cleaner, and hope it makes sense.
    – bart2puck
    Jun 8, 2015 at 20:13
  • 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. Jun 8, 2015 at 21:00

1 Answer 1

1

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', '...');
...
4
  • 1
    More likely 2.8.4.3.3.0.7.1.e164.arpa if +1 703 348 2 is delegated to them. Jun 8, 2015 at 20:50
  • I am quite a noob when it comes to DNS, so I will take an advice..
    – bart2puck
    Jun 8, 2015 at 21:29
  • Well, the bad news is that country code 1 hasn't even been delegated yet, so the world will never see these records until that (eventually) happens. Jun 8, 2015 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 9, 2015 at 11:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .