recursor 3.6: bad record content can cause timeout/DNS parser error "All data was not consumed" #1663

Closed
gryphius opened this Issue Aug 12, 2014 · 5 comments

Projects

None yet

5 participants

@gryphius
Contributor

this is the output of a dig lookup on pdns recursor 3.5.2 from a domain with a bad mx record (notice the \032 after aspmx5.googlemail.com ). the domain name has been replaced with 'example.com' here, the real domain fixed the bad record and is no longer useful to reproduce the problem.

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> mx example.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23203
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;example.com.                    IN      MX
;; ANSWER SECTION:
example.com.             300     IN      MX      10 aspmx.l.google.com.
example.com.             300     IN      MX      30 aspmx2.googlemail.com.
example.com.             300     IN      MX      30 aspmx5.googlemail.com.\032.
example.com.             300     IN      MX      30 aspmx4.googlemail.com.
example.com.             300     IN      MX      30 aspmx3.googlemail.com.
example.com.             300     IN      MX      20 alt1.aspmx.l.google.com.
example.com.             300     IN      MX      20 alt2.aspmx.l.google.com.

after upgrading to recursor 3.6, the same lookup does not work anymore:

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> mx example.com @127.0.0.1
;; global options: +cmd
;; connection timed out; no servers could be reached

server log:

Aug 12 09:14:36 DNS parser error (example.com./15 from 127.0.0.1): example.com., All data was not consumed
Aug 12 09:14:41 DNS parser error (example.com./15 from 127.0.0.1): example.com., All data was not consumed
Aug 12 09:14:46 DNS parser error (example.com./15 from 127.0.0.1): example.com., All data was not consumed
@Habbie Habbie added rec defect labels Aug 12, 2014
@Habbie
Member
Habbie commented Sep 2, 2014

(we should at least SERVFAIL instead of timeout, but answering would be even better)

@jpecar
jpecar commented Mar 31, 2015

Similar happens with authoritative server if the database 'content' entry contains trailing whitespace, like 'domain.tld '. AXFR on slave fails with "Remote nameserver closed TCP connection", master logs "TCP Connection Thread died because of STL error: All data was not consumed", which isn't really helpful.
Powerdns 3.4.3.

@FedericoOlivieri

Hi,
I can see the same problem on PDSN Rec 3.7.3.
In my case it happens with a PTR record

Nov 5 20:09:05 banana pdns_recursor[14333]: DNS parser error (51.135.241.203.in-addr.arpa./PTR from 127.0.0.1): 51.135.241.203.in-addr.arpa., All data was not consumed

Federico

@Habbie
Member
Habbie commented Dec 15, 2015

Needs to be rechecked for git master (as we are post-DNSName now).

@Habbie Habbie added this to the rec-4.0.0 milestone Dec 15, 2015
@pieterlexis
Member

This is indeed no longer an issue in master:

Mar 23 19:11:22 [1] 51.135.241.203.in-addr.arpa.: Resolved '135.241.203.in-addr.arpa.' NS dnsst2.samsung.com. to: 112.106.53.58
Mar 23 19:11:22 [1] 51.135.241.203.in-addr.arpa.: Trying IP 112.106.53.58:53, asking '51.135.241.203.in-addr.arpa.|PTR'
Mar 23 19:11:22 [1] 51.135.241.203.in-addr.arpa.: Got 3 answers from dnsst2.samsung.com. (112.106.53.58), rcode=0 (No Error), aa=1, in 305ms
Mar 23 19:11:22 [1] 51.135.241.203.in-addr.arpa.: accept answer '51.135.241.203.in-addr.arpa.|PTR|dnsst.samsung.com.' from '135.241.203.in-addr.arpa.' nameservers? 1 YES!
Mar 23 19:11:22 [1] 51.135.241.203.in-addr.arpa.: accept answer '51.135.241.203.in-addr.arpa.|PTR|dnsst.samsung.com\032.' from '135.241.203.in-addr.arpa.' nameservers? 1 YES!
Mar 23 19:11:22 [1] 51.135.241.203.in-addr.arpa.: OPT answer '.' from '135.241.203.in-addr.arpa.' nameservers
Mar 23 19:11:22 [1] 51.135.241.203.in-addr.arpa.: determining status after receiving this packet
Mar 23 19:11:22 [1] 51.135.241.203.in-addr.arpa.: answer is in: resolved to 'dnsst.samsung.com.|PTR'
Mar 23 19:11:22 [1] 51.135.241.203.in-addr.arpa.: answer is in: resolved to 'dnsst.samsung.com\032.|PTR'
Mar 23 19:11:22 [1] 51.135.241.203.in-addr.arpa.: status=got results, this level of recursion done
Mar 23 19:11:22 1 [1/1] answer to question '51.135.241.203.in-addr.arpa.|PTR': 2 answers, 1 additional, took 13 packets, 2028.35 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment