Pihole not resolving a domain MX record

The issue I am facing is that I have one domain that I am using that is not resolving the MX records. The strange thing is that other domains with similar MX records are resolving. I have been through the normal faulting process and confirmed the issue has something to do with the pihole-FTL. When I bypass the pi, the MX record resolves correctly. When I query the bind9 server, it resolves correctly. The issue seems to be when I use the pihole-FTL this domain is not returning a result.

What I am after is some tips about where to look next.

I am using pihole on a raspberry Pi 4 8Gb and bind9 as a recursive server. pihole-FTL is on port 53 and bind is running on local host port 5353.

The pihole is working on a number of domains however there is one domain that is not resolving for some reason. A debug shows no obvious faults with the only error being an IPv6 gateway issue.

Here are the lookups I am using to test:

 $ dig alflawyers.com.au MX

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> alflawyers.com.au MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56004
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;alflawyers.com.au.             IN      MX

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jul 03 10:50:54 AEST 2022
;; MSG SIZE  rcvd: 46

$ dig alflawyers.com.au MX -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> alflawyers.com.au MX -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43180
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 77e5a516504a052018be20b262c0e7f8ae751c63b904e04a (good)
;; QUESTION SECTION:
;alflawyers.com.au.             IN      MX

;; ANSWER SECTION:
alflawyers.com.au.      2321    IN      MX      0 alflawyers-com-au.mail.protection.outlook.com.

;; AUTHORITY SECTION:
au.                     171473  IN      NS      r.au.
au.                     171473  IN      NS      t.au.
au.                     171473  IN      NS      s.au.
au.                     171473  IN      NS      q.au.

;; ADDITIONAL SECTION:
q.au.                   171473  IN      A       65.22.196.1
r.au.                   171473  IN      A       65.22.197.1
s.au.                   171473  IN      A       65.22.198.1
t.au.                   171473  IN      A       65.22.199.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Sun Jul 03 10:51:04 AEST 2022
;; MSG SIZE  rcvd: 263

 $ dig microsoft.com MX

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> microsoft.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1813
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;microsoft.com.                 IN      MX

;; ANSWER SECTION:
microsoft.com.          2195    IN      MX      10 microsoft-com.mail.protection.outlook.com.

;; Query time: 46 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jul 03 10:54:18 AEST 2022
;; MSG SIZE  rcvd: 96

$ dig microsoft.com MX -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> microsoft.com MX -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48698
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b04f27957acb94321fe7066962c0e8c9c2f20d90ca447dca (good)
;; QUESTION SECTION:
;microsoft.com.                 IN      MX

;; ANSWER SECTION:
microsoft.com.          3600    IN      MX      10 microsoft-com.mail.protection.outlook.com.

;; AUTHORITY SECTION:
microsoft.com.          172799  IN      NS      ns4-39.azure-dns.info.
microsoft.com.          172799  IN      NS      ns1-39.azure-dns.com.
microsoft.com.          172799  IN      NS      ns3-39.azure-dns.org.
microsoft.com.          172799  IN      NS      ns2-39.azure-dns.net.

;; ADDITIONAL SECTION:
ns1-39.azure-dns.com.   172799  IN      A       150.171.10.39

;; Query time: 770 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Sun Jul 03 10:54:33 AEST 2022
;; MSG SIZE  rcvd: 274

From another server using the pihole as it's DNS I get:

$ dig alflawyers.com.au MX

; <<>> DiG 9.16.30-RH <<>> alflawyers.com.au MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1392
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;alflawyers.com.au.             IN      MX

;; Query time: 2 msec
;; SERVER: 192.168.10.2#53(192.168.10.2)
;; WHEN: Sun Jul 03 10:49:44 AEST 2022
;; MSG SIZE  rcvd: 46

]$ dig microsoft.com MX

; <<>> DiG 9.16.30-RH <<>> microsoft.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32109
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;microsoft.com.                 IN      MX

;; ANSWER SECTION:
microsoft.com.          3600    IN      MX      10 microsoft-com.mail.protection.outlook.com.

;; Query time: 46 msec
;; SERVER: 192.168.10.2#53(192.168.10.2)
;; WHEN: Sun Jul 03 11:15:56 AEST 2022
;; MSG SIZE  rcvd: 96

No other changes have been made.

Thanks in advance

Do you have DNSSEC enabled?

I get the following result for the offending MX record:

$  dig alflawyers.com.au MX
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> alflawyers.com.au MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47165
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 09 ("..")
;; QUESTION SECTION:
;alflawyers.com.au.             IN      MX

;; Query time: 324 msec
;; SERVER: 192.168.1.28#53(192.168.1.28)
;; WHEN: Sun Jul 03 09:46:53 CEST 2022
;; MSG SIZE  rcvd: 52

OPT=15 indicates to an RFC8914 EDE error code; its value 00 09 translates to DNSKEY Missing. A missing DNSKEY for a DNSSEC enabled domain would make it impossible to verify authenticity and integrity of DNS records, thus invalidating the reply as BOGUS, so Pi-hole would ultimatetly discard the MX record even if it has received it.
This is also available from Pi-hole's logs:

$ grep alflawyers.com.au /var/log/pihole.log
Jul  3 09:46:51 dnsmasq[1363]: 1120 192.168.1.28/47282 query[MX] alflawyers.com.au from 192.168.1.28
Jul  3 09:46:51 dnsmasq[1363]: 1120 192.168.1.28/47282 forwarded alflawyers.com.au to 127.0.1.1#5335
Jul  3 09:46:52 dnsmasq[1363]: 1120 192.168.1.28/47282 reply alflawyers.com.au is <MX>
Jul  3 09:46:52 dnsmasq[9159]: 1124 192.168.1.28/53149 query[MX] alflawyers.com.au from 192.168.1.28
Jul  3 09:46:52 dnsmasq[9159]: 1124 192.168.1.28/53149 forwarded alflawyers.com.au to 127.0.1.1#5335
Jul  3 09:46:53 dnsmasq[9159]: 1127 dnssec-query[DS] alflawyers.com.au to 127.0.1.1#5335
Jul  3 09:46:53 dnsmasq[9159]: 1124 192.168.1.28/53149 validation alflawyers.com.au is BOGUS (EDE: DNSKEY missing)

If DNSSEC valiadtion is intended to work for that domain, the missing DNSKEY has to be provided by the maintainers of the authoritative DNS server.

Side note:

You should avoid using port 5353, as that port is reserved for use by the mDNS protocol as implemented e.g. by Avahi (for Linux/BSD), Bonjour (for Apple devices), Windows etc.

Depending on your adlists, that domain might simply be blocked

https://blocklist-tools.developerdan.com/entries/search?q=alflawyers.com.au

Thank you Bucking_Horn and yubiuser for your replies.

I did not have dnssec set on the pihole.

There is definitely something blocking the resolution. gravity is blocking the returned value of 0.0.0.0 and that is being blocked as NODATA. Unfortunately I haven't been able to replicate the OPT=15 error you have seen Bucking_Horn

I was able to run dig +dnssec +multi +trace alflawyers.com.au MX from an internal server and get a result after bypassing the pihole caching dns server.
I will keep digging tomorrow night.

Thanks your your help guys.

Run

pihole -q alflawyers.com.au

pihole -q alflawyers.com.au
 Match found in "https://dbl.oisd.nl/:"
   alflawyers.com.au

As I said: the domain is blocked by one of your adlist. If you want to keep that list, you can add alflawyers.com.au to your whitelist to unblock that domain.

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.