Bug #13686
closed
Unbound breaks SPF
0%
Description
It seems the unbound module is not compliant with the SPF standard.
When I do the lookup on the pfsense unbound server, I will get this answer:
dig @192.168.99.254 85.222.158.221._spf.mta.salesforce.com
; <<>> DiG 9.16.33-RH <<>> @192.168.99.254 85.222.158.221._spf.mta.salesforce.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 63551
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;85.222.158.221._spf.mta.salesforce.com. IN A
;; AUTHORITY SECTION:
mta.salesforce.com. 86400 IN NS dns05.salesforce.com.
mta.salesforce.com. 86400 IN NS dns03.salesforce.com.
mta.salesforce.com. 86400 IN NS dns04.salesforce.com.
mta.salesforce.com. 86400 IN NS dns02.salesforce.com.
mta.salesforce.com. 86400 IN NS dns01.salesforce.com.
mta.salesforce.com. 86400 IN NS ns4.salesforce.com.
mta.salesforce.com. 86400 IN NS ns3.salesforce.com.
mta.salesforce.com. 86400 IN NS ns2.salesforce.com.
mta.salesforce.com. 86400 IN NS ns1.salesforce.com.
mta.salesforce.com. 86400 IN NS dns06.salesforce.com.
;; Query time: 135 msec
;; SERVER: 192.168.99.254#53(192.168.99.254)
;; WHEN: Tue Nov 22 23:53:52 CET 2022
;; MSG SIZE rcvd: 259
When I ask another public DNS, I will get this answer:
dig @213.144.129.20 85.222.158.221._spf.mta.salesforce.com
; <<>> DiG 9.16.33-RH <<>> @213.144.129.20 85.222.158.221._spf.mta.salesforce.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 26816
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;85.222.158.221._spf.mta.salesforce.com. IN A
;; ANSWER SECTION:
85.222.158.221._spf.mta.salesforce.com. 80170 IN A 127.0.0.9
;; Query time: 3 msec
;; SERVER: 213.144.129.20#53(213.144.129.20)
;; WHEN: Tue Nov 22 23:59:23 CET 2022
;; MSG SIZE rcvd: 83
So for some reason, the result 127.0.0.9 is missing in the result from unbound!
I was checking the resolver.log file and I found this:
Nov 22 23:53:52 gw unbound87835: [87835:8] debug: sanitize: removing public name with private address <85.222.158.221._spf.mta.salesforce.com.> 127.0.0.9#53
However, this website https://dmarcian.com/spf-syntax-table/ says that the response 127.0.0.x is perfectly valid.
As good the idea is to do the sanitation, in this respect it breaks SPF and the sanitation should not happen, at least not by default.
Updated by Jim Pingle about 2 years ago
- Status changed from New to Not a Bug
This is not a bug, it's a security feature. Unbound disallows private addresses in replies by default. You can disable this on a per-domain basis or entirely.
https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html
Updated by Frederic Steinfels about 2 years ago
I see, thanks. I will reformulate my request. Instead of stripping the answer, wouldn't it make more sense to replace the ip with an invalid ip address that is blocked in pfsense? The ip address returned for SPF does not matter. What matters is that there is an answer.
Updated by Jim Pingle about 2 years ago
That is not anything we can control, it's the behavior of Unbound itself. You can raise a request with them directly if you wish.
Updated by Frederic Steinfels about 2 years ago
Jim Pingle wrote in #note-3:
That is not anything we can control, it's the behavior of Unbound itself. You can raise a request with them directly if you wish.
I understand. If you have a line of contact, i'd appreciate that. Otherwise I will try to ask them. Fun fact: If you google "unbound sanitize" there are a lot of people scratching their heads how to disable this sanitation feature. Even opnsense customers dont know and most of the posts there are have no answer at all. It took me almost a day figuring out that I lost emails and that it was a /etc/postfix/policyd-spf-perl problem. I reverse engineered the source code until I figured out the exact DNS request that was different (mxtoolbox said spf was ok so the error had to be on my side). Then I had to trace the DNS stuff until I tracked it to unbound and then I checked the log where I found this by accident. So I'd appreciate it if we can save other peoples time by fixing this.
From your side, you will have to add a checkmark in unbound to make it report the "blocked" ip instead of the stripping. And there should be an instruction to create a fw rule with this destination ip and drop action.
For the moment I have disabled the rebind stuff.