SPF lookup timeout met PowerDNS recursor

[Borromini]

Ik heb de PowerDNS recursor op mijn VPS geïnstalleerd naar aanleiding van wat eigenaardigheden met de DNS van mijn leverancier (zie Spamhaus weigert RBL lookup). Als ik hun eigen DNS gebruik dan gaat het opzoeken van de SPF records goed:

code:

Feb  8 22:07:00 atalanta policyd-spf[22226]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=185.70.40.22; helo=mail2.protonmail.ch; envelope-from=[e-mail]; receiver=<UNKNOWN>

Met PowerDNS in gebruik krijg ik echter een 'temperror' bij elke SPF record lookup:

code:

Feb  8 22:43:48 atalanta policyd-spf[22971]: prepend Received-SPF: Temperror (mailfrom) identity=mailfrom; client-ip=185.70.40.22; helo=mail2.protonmail.ch; envelope-from=[e-mail]; receiver=<UNKNOWN>

Als ik dit google lijkt het dat het om UDP truncation zou kunnen gaan, maar als ik de 'udp truncation treshold' in PowerDNS verhoog van de standaardwaarde (1680 bytes) naar de aanbevolen maximumwaarde (4096) dan verdwijnen de foutmeldingen niet. Bovendien geeft een TXT record nslookup voor bv. Protonmail.com niet aan dat de reply truncated is (met PowerDNS op 1680 bytes, op 4096 bytes, of met de 'native' OVH DNS). Dit lijkt dus niet het probleem te zijn.

M'n firewall logt in- en uitgaande verbindingen maar er staat geen DNS-verkeer tussen dat geblokkeerd zou worden (zowel TCP als UDP DNS requests (poort 53) zijn uitgaand toegelaten in de firewall, en gerelateerd inkomend verkeer ook).

Als ik query logging inschakel bij PowerDNS krijg ik het volgende, maar ik zie daar niet direct een foutmelding instaan?

code:

feb 08 22:43:20 atalanta pdns_recursor[22918]: Feb 08 22:43:20 1 [37/1] question for 'tantalos.no-ip.net|A' from 127.0.0.1
feb 08 22:43:20 atalanta pdns_recursor[22918]: Feb 08 22:43:20 1 [38/2] question for 'tantalos.no-ip.net|AAAA' from 127.0.0.1
feb 08 22:43:20 atalanta pdns_recursor[22918]: Feb 08 22:43:20 1 [37/2] answer to question 'tantalos.no-ip.net|A': 1 answers, 0 additional, took 2 packets, 19.849 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=0
feb 08 22:43:20 atalanta pdns_recursor[22918]: Feb 08 22:43:20 1 [38/2] answer to question 'tantalos.no-ip.net|AAAA': 0 answers, 0 additional, took 2 packets, 19.863 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=0
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 1 question answered from packet cache tag=0 from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [46/1] question for '22.40.70.185.iadb.isipp.com|A' from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [47/2] question for '22.40.70.185.wl.mailspike.net|A' from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 1 [39/1] question for '22.40.70.185.dnsbl.sorbs.net|A' from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 1 [40/2] question for '22.40.70.185.bl.spamcop.net|TXT' from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [48/3] question for '22.40.70.185.zen.spamhaus.org|A' from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [49/4] question for '22.40.70.185.sa-trusted.bondedsender.org|TXT' from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 1 [41/3] question for '22.40.70.185.sa-accredit.habeas.com|TXT' from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [50/5] question for '22.40.70.185.bl.score.senderscore.com|A' from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 1 [42/4] question for '22.40.70.185.psbl.surriel.com|A' from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [51/6] question for '22.40.70.185.bl.mailspike.net|A' from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [52/7] question for '22.40.70.185.list.dnswl.org|A' from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [51/7] answer to question '22.40.70.185.bl.mailspike.net|A': 0 answers, 1 additional, took 1 packets, 13.863 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 1 [42/4] answer to question '22.40.70.185.psbl.surriel.com|A': 0 answers, 1 additional, took 3 packets, 21.034 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 question answered from packet cache tag=0 from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 question answered from packet cache tag=0 from 127.0.0.1
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 1 [40/3] answer to question '22.40.70.185.bl.spamcop.net|TXT': 0 answers, 1 additional, took 4 packets, 40.364 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [47/6] answer to question '22.40.70.185.wl.mailspike.net|A': 1 answers, 1 additional, took 2 packets, 100.013 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=0
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [49/5] answer to question '22.40.70.185.sa-trusted.bondedsender.org|TXT': 0 answers, 1 additional, took 4 packets, 114.724 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [48/4] answer to question '22.40.70.185.zen.spamhaus.org|A': 0 answers, 1 additional, took 2 packets, 120.102 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [46/3] answer to question '22.40.70.185.iadb.isipp.com|A': 0 answers, 1 additional, took 1 packets, 149.202 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [52/2] answer to question '22.40.70.185.list.dnswl.org|A': 1 answers, 1 additional, took 3 packets, 164.336 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=0
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 2 [50/1] answer to question '22.40.70.185.bl.score.senderscore.com|A': 0 answers, 1 additional, took 6 packets, 241.467 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3
feb 08 22:43:48 atalanta pdns_recursor[22918]: Feb 08 22:43:48 1 [41/2] answer to question '22.40.70.185.sa-accredit.habeas.com|TXT': 0 answers, 1 additional, took 4 packets, 287.022 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3
feb 08 22:43:49 atalanta pdns_recursor[22918]: Feb 08 22:43:49 1 [39/1] answer to question '22.40.70.185.dnsbl.sorbs.net|A': 0 answers, 1 additional, took 7 packets, 355.983 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3

[Vorkie]

Uiteindelijk gaat het er volgens mij om dat je VPS in een IP segment zit wat (soms) wordt geblokkeerd door de RBL lists. Daar gaat een lokale DNS recurser of DNS van je provider niet bij helpen.

Heb je al eens gewoon met Google / Quad9 / OpenDNS / ..... geprobeerd te werken?

Verder blijft bovenstaande van toepassing ; als jouw VPS subnet aan het maximale aantal queries zit, kan je dus geblokkeerd worden. (Vindt ikzelf veelal een nadeel van VPS, je weet niet wat voor rotzooi er allemaal wordt gedaan op andere hosts in dat subnet)

Om nou voor deze functie powerDNS te installeren lijkt mij niet efficient (In ieder geval op dezelfde server) DNS recursers plaats je meestal op een aparte server als je niet wilt dat servers / clients direct zelf DNS zaken mogen opvragen, vanwege Active Directory of gewoon qua veiligheid.

[ Voor 18% gewijzigd door Vorkie op 09-02-2018 13:13 ]

[Borromini]

Het gaat om de SPF lookups, de RBL lookups staan daar los van .

[lordgandalf]

begrijp ik het nu goed dat blocklist a en txt records bij jouw doen ?
Als ik de log zie is dat het geval. Ik zie dat er maar 3 records worden beantwoord.
Hoe heb je pdns ingericht ? bind of mysql of iets anders.
Heb dnssec aanstaan ?

[Kees]

Zit je spf record toevallig over de 10 lookups?

[Borromini]

lordgandalf schreef op vrijdag 9 februari 2018 @ 16:33:
begrijp ik het nu goed dat blocklist a en txt records bij jouw doen ?
Als ik de log zie is dat het geval. Ik zie dat er maar 3 records worden beantwoord.

Dat draait allemaal goed. Tenzij ik me vergis staat dat ook los van de SPF records. Zodra ik terugschakel naar de DNS van OVH krijg ik 'name service errors' voor de blocklist lookups. Vandaar PowerDNS.

Hoe heb je pdns ingericht ? bind of mysql of iets anders.

De recursor heeft nauwelijks configuratie nodig. Meer dan /etc/resolv.conf aanpassen, zodat alle queries naar localhost gaan, is normaal gezien niet nodig. Ik heb de volledige configuratie hier online gezet.

Heb dnssec aanstaan ?

Dat staat standaard op 'process-no-validate' en daarover zegt de handleiding:

Respond with DNSSEC records to clients that ask for it, set the DO bit on all outgoing queries. Don’t do any validation.

Kees schreef op vrijdag 9 februari 2018 @ 19:14:
Zit je spf record toevallig over de 10 lookups?

Hoe bedoel je? De SPF lookups die Postfix doet zijn allemaal voor de remote domains. Het lijkt me ook dat herhaalde SPF record lookups door de cache van PowerDNS worden opgevangen. Ik heb de cache-instellingen daarvoor nog even nagekeken en die staan op de standaardinstellingen (dus aan).

[ Voor 15% gewijzigd door Borromini op 09-02-2018 19:46 ]

[Kees]

Borromini schreef op vrijdag 9 februari 2018 @ 19:42:
[...]


Hoe bedoel je? De SPF lookups die Postfix doet zijn allemaal voor de remote domains. Het lijkt me ook dat herhaalde SPF record lookups door de cache van PowerDNS worden opgevangen. Ik heb de cache-instellingen daarvoor nog even nagekeken en die staan op de standaardinstellingen (dus aan).

Volgens de specificatie mag een SPF record maximaal 10 lookups doen (dus iedere include of a-record is een lookup). Daarna zou hij er in theorie mee moeten stoppen.

[Borromini]

Edit: ik heb mijn antwoord hierboven aangepast.

De lookups in de log lijken mij allemaal van de blacklists te komen? Hieronder de smtpd_client_restrictions in /etc/postfix/main.cf. Postfix haalt eerst alles door de blacklists, en voert het daarna aan de SPF policy daemon.

smtpd_client_restrictions = 
	permit_mynetworks,
	reject_unlisted_recipient,
	reject_invalid_hostname,
	reject_non_fqdn_sender,
	reject_non_fqdn_recipient,
	reject_unknown_sender_domain,
	reject_unauth_destination,
	reject_unauth_pipelining,
# Let Postgrey have a look first.
	check_policy_service unix:var/run/postgrey/postgrey.sock,
# DNS blacklists.
	reject_rbl_client b.barracudacentral.org,
	reject_rbl_client zen.spamhaus.org,
#	reject_rbl_client bl.spamcop.net,
	reject_rbl_client cbl.abuseat.org,
# Check SPF policy
	check_policy_service unix:private/policyd-spf,
	permit

Ik heb - om de ruis van de blacklists eruit te halen - nu de blacklists even uitgeschakeld en alleen de SPF policy check behouden. Dan word ik echt niks wijzer van wat PowerDNS opvraagt -hij lijkt alleen maar voor DMARC te checken

code:

Feb  9 20:03:55 atalanta pdns_recursor[367]: Feb 09 20:03:55 1 [1/1] question for '_dmarc.protonmail.com|TXT' from 127.0.0.1
Feb  9 20:03:55 atalanta pdns_recursor[367]: Feb 09 20:03:55 1 [1/1] answer to question '_dmarc.protonmail.com|TXT': 2 answers, 1 additional, took 6 packets, 117.75 ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=0

Edit: ondertussen heb ik de 'spfquery' tool gevonden en die schept al meer duidelijkheid.

Met OVH DNS:

code:

# spfquery --sender=[e-mail] --ip=185.70.40.18
pass

spfquery: domain of protonmail.com designates 185.70.40.18 as permitted sender
Received-SPF: Pass (spfquery: domain of protonmail.com designates 185.70.40.18 as permitted sender) client-ip=185.70.40.18; envelope-from="[e-mail]"; receiver=spfquery; mechanism="include:_spf.protonmail.ch"; identity=mailfrom

Met de recursor actief:

code:

# spfquery --sender=[e-mail] --ip=185.70.40.18
temperror
SPF Temporary Error: DNS No working name servers discovered
spfquery: temporary error in processing during lookup of protonmail.com
Received-SPF: TempError (spfquery: temporary error in processing during lookup of protonmail.com) client-ip=185.70.40.18; envelope-from="[e-mail]"; receiver=spfquery; identity=mailfrom

Nochtans luistert PowerDNS gewoon op 53:

code:

# netstat -puntal|grep pdns
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1327/pdns_recursor
tcp6       0      0 ::1:53                  :::*                    LISTEN      1327/pdns_recursor
udp        0      0 127.0.0.1:53            0.0.0.0:*                           1327/pdns_recursor
udp6       0      0 ::1:53                  :::*                                1327/pdns_recursor

En ook een DNS lookup lijkt mij goed te gaan:

code:

# dig @::1 tweakers.net AAAA

; <<>> DiG 9.10.3-P4-Debian <<>> @::1 tweakers.net AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49957
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tweakers.net.                  IN      AAAA

;; ANSWER SECTION:
tweakers.net.           60      IN      AAAA    2001:9a8:0:e:1337:0:80:1

;; Query time: 1590 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Feb 09 21:24:33 CET 2018
;; MSG SIZE  rcvd: 69

Zie ik nu zo iets voor de hand liggends over het hoofd?

[ Voor 43% gewijzigd door Borromini op 09-02-2018 22:32 ]

[Borromini]

OK... Complete PEBKAC. Had de lokale nameservers opgegeven in /etc/resolv.conf zonder er 'nameserver' voor te zetten

@Vorkie Ik zal Quad9 even proberen. Heb ook suggesties gelezen dat je voor je eigen mailserver best ook een eigen DNS-server kan draaien, maar ik vermoed dat iedereen daar wel een eigen mening over heeft? Als ik toch m'n eigen DNS zou willen voorzien, wat raad je dan wel aan ipv een recursor?

[d1ng]

Is je /usr/share/dns/root.hints file van een beetje recente versie?

[_JGC_]

pdns-recursor zou gewoon moeten werken. Als ik je dig output zie duurt het 1590ms om tweakers.net te resolven. Wat gaat daar mis? Zo'n lookup hoort binnen een paar ms te gaan.

[Borromini]

Als ik Quad9 gebruik doet ie er 9 ms over. De eerste keer via PowerDNS idd 1600 ms. Als ik andere sites test komt dat vaak wel op een 30 ms uit voor een 'koude' query. Ik heb PowerDNS als lokale fallback ingesteld nu (OK, misschien een beetje overkill).

@d1ng die dateert van augustus 2017 (meest recente Debian-pakket...). Ik zal dat van testing even binnentrekken. Heeft dat veel invloed op opzoektijden?

[d1ng]

Er is ondertussen wel een nieuwere van beschikbaar http://www.internic.net/domain/named.root

Of dat echt verschil gaat maken, denk het niet hoor aangezien je al een redelijk nieuwe versie hebt. Wijzigingen eraan gaan volgens mij vrij conservatief. Maar het kan in ieder geval geen kwaad om eens in de zoveel tijd bij te houden.

[Borromini]

OK bedankt. Heb nu die van Testing geïnstalleerd in ieder geval. Is van begin 2018.