Hey, we're investigating an issue where some domains permanently run into "DNS Ran off end of data", resulting in a Temperror. Example is: > /usr/lib/python3/dist-packages/spf.py web.de Temporary DNS error: DNS Ran off end of data All affected domains have in common, that they're falling back to TCP (which then is successful when trying with dig +tcp): > dig web.de IN TXT ;; Warning: Message parser reports malformed message packet. ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> web.de IN TXT ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6712 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;web.de. IN TXT ;; ANSWER SECTION: web.de. 34 IN TXT "g6ftbncmryg0y6h956jfd242s1z9tndk" web.de. 34 IN TXT "facebook-domain-verification=ksd7xc6g15rm7xkdga4qcm9hasgkny" web.de. 34 IN TXT "Trustpilot-Verification-kqvVskCm6JQ9Vg1qAmahpBSJ5tvZORbriFyVIk4E" web.de. 34 IN TXT "google-site-verification=No4jlUg2OIV7IsI2UF0v792Q8HgI9Brnp7qary1nMAQ" web.de. 34 IN TXT "_telesec-domain-validation=D9B9D9DCF94742C07349C556E427C5A2EFFD85A67E1AC64190C473088D583370" web.de. 34 IN TXT "_telesec-domain-validation=283146_2021-04-13_3lZFRx1xmMIgOTBxEGpHAM3qQ9wdpEVvDMuSs7NxCYi5xzD2jh" web.de. 34 IN TXT "v=spf1 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.248/29 ip4:82.165.159.0/26 ip4:217.72.207.0/27 ip4:217.72.192.64/26 ip4:82.165.229.130 ip4:82.165.230.22 -all" ;; Query time: 1 msec ;; SERVER: xxx ;; WHEN: Mon Jun 07 13:31:41 CEST 2021 ;; MSG SIZE rcvd: 718 When directly trying via TCP with, it is also successful: > dig web.de IN TXT +tcp ; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> web.de IN TXT +tcp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43151 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;web.de. IN TXT ;; ANSWER SECTION: web.de. 297 IN TXT "g6ftbncmryg0y6h956jfd242s1z9tndk" web.de. 297 IN TXT "facebook-domain-verification=ksd7xc6g15rm7xkdga4qcm9hasgkny" web.de. 297 IN TXT "Trustpilot-Verification-kqvVskCm6JQ9Vg1qAmahpBSJ5tvZORbriFyVIk4E" web.de. 297 IN TXT "google-site-verification=No4jlUg2OIV7IsI2UF0v792Q8HgI9Brnp7qary1nMAQ" web.de. 297 IN TXT "_telesec-domain-validation=D9B9D9DCF94742C07349C556E427C5A2EFFD85A67E1AC64190C473088D583370" web.de. 297 IN TXT "_telesec-domain-validation=283146_2021-04-13_3lZFRx1xmMIgOTBxEGpHAM3qQ9wdpEVvDMuSs7NxCYi5xzD2jh" web.de. 297 IN TXT "v=spf1 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.248/29 ip4:82.165.159.0/26 ip4:217.72.207.0/27 ip4:217.72.192.64/26 ip4:82.165.229.130 ip4:82.165.230.22 -all" ;; Query time: 1 msec ;; SERVER: xxx ;; WHEN: Mon Jun 07 13:32:29 CEST 2021 ;; MSG SIZE rcvd: 718 This also affects other commonly used domains in our mail environment (such as gmx.net). But shouldn't pyspf be capable of handling the TCP-fallback - or is there a chance to tell pyspf to directly use TCP instead of trying UDP first? We're running python 3.6.9 with pyspf 2.0.12 on Ubuntu 18.04.1 LTS.

When	Who	Action	New State
2021-06-07	actionparsnip	Comment	Open
2021-06-07	actionparsnip	Answer	Answered
2021-06-07	Kevin Kelker	Reopen	Open
2021-06-07	actionparsnip	Comment	Open
2021-06-08	Kevin Kelker	Comment	Open
2021-06-12	Scott Kitterman	Answer	Answered
2021-06-14	Kevin Kelker	Confirm	Solved

Ubuntupyspf package

History of question #697438

Ubuntu
pyspf package