[Pdns-users] authoritative answers for TXT records on subdomains - unexpected results.

[Aj Mirani]

Hello,

I've done some digging through the docs/wiki/mailinglist archives and
I can't come up with a definitive answer to if the following is
expected/normal behavior or not.

A few details:
PDNS Version: 2.9.19
Linux Kernel: 2.6.15.4
Debian 3.1

If I have a domain 'example.com' and I set a subdomain 'sub.example.com'
with NS records pointing to some other servers.  Which server is
responsible for the TXT record for that domain?

Here is my output from dig with domains obscured:




So we confirm that myserver.com has different NS records for the
subdomain:

$ dig -t ns sub.example.com @ns1.myserver.com

; <<>> DiG 9.3.1 <<>> -t ns sub.example.com @ns1.myserver.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59216
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.example.com.         IN      NS

;; ANSWER SECTION:
sub.example.com.  300     IN      NS      ns1.other-domain.com.
sub.example.com.  300     IN      NS      ns2.other-domain.com.




If I ask myserver for the TXT record, it doesn't know obviously and
since it doesn't recurse, its not going to find out:

$ dig -t txt sub.example.com @ns1.myserver.com

; <<>> DiG 9.3.1 <<>> -t txt sub.example.com @ns1.myserver.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7826
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.example.com.         IN      TXT

;; AUTHORITY SECTION:
example.com.        300     IN      SOA     ns1.myserver.com.
hostmaster.myserver.com. 721632004 10001 7200 2419200 86400




When I ask the NS setup for sub.example.com for the TXT record, it has
the answer as I would expect:

$ dig -t txt sub.example.com @ns2.other-domain.com

; <<>> DiG 9.3.1 <<>> -t txt sub.example.com @ns2.other-domain.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62268
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;sub.example.com.         IN      TXT

;; ANSWER SECTION:
sub.example.com.  3600    IN      TXT     "v=spf1 include:cust-spf.other-domain.com ~all"
sub.example.com.  3600    IN      TXT     "spf2.0/pra include:cust-spf.other-domain.com ~all"

;; AUTHORITY SECTION:
sub.example.com.  3600    IN      NS      ns2.other-domain.com.
sub.example.com.  3600    IN      NS      ns1.other-domain.com.



But... If I ask some other random DNS server about the TXT record its
looking at my server for the answer and can't get the record:


$ dig -t txt sub.example.com @ns.random-dns-server.com

; <<>> DiG 9.3.1 <<>> -t txt sub.example.com @ns.random-dns-server.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38805
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;sub.example.com.         IN      TXT

;; AUTHORITY SECTION:
example.com.        300     IN      SOA     ns1.myserver.com.
hostmaster.myserver.com. 721632004 10001 7200 2419200 86400




The strange part is, if I look for a TXT record for a subdomain of
sub.example.com... I get the proper result:

$ dig -t txt bounce.sub.example.com @66.96.30.99

; <<>> DiG 9.3.1 <<>> -t txt bounce.sub.example.com @66.96.30.99
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30641
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;bounce.sub.example.com.  IN      TXT

;; ANSWER SECTION:
bounce.sub.example.com. 3600 IN   TXT     "spf2.0/pra include:cust-senderid.other-domain.com ~all"
bounce.sub.example.com. 3600 IN   TXT     "v=spf1 include:cust-spf.other-domain.com ~all"

;; AUTHORITY SECTION:
sub.example.com.  3600    IN      NS      ns2.other-domain.com.
sub.example.com.  3600    IN      NS      ns1.other-domain.com.


Is there some issue with how PowerDNS handles subdomain delegations? Or
is this expected behavior?

Thanks for looking at this problem.


-- 
Aj Mirani