DNS Resolver returning incorrect result

[kohenkatz]

Today I tried to go to docs.sentry.io and I got a DNS failure message from the browser.

I have my PC set up to use my pfSense as its DNS server, and pfSense is set to use Cloudflare's 1.1.1.1 for Families as its upstream DNS with the following settings:

System -> General

DNS Servers

(with hostnames for TLS certificate validation)

• 1.1.1.3 - family.cloudflare-dns.com
• 1.0.0.3 - family.cloudflare-dns.com
• 2606:4700:4700::1113 - family.cloudflare-dns.com
• 2606:4700:4700::1003 - family.cloudflare-dns.com

Services -> DNS Resolver

• DNSSEC - Enabled

• DNS Query Forwarding - Enabled

• Use SSL/TLS for outgoing queries - Enabled

• Custom options (to disable Firefox DoH)

  server:
  local-zone: "use-application-dns.net" always_nxdomain
  

---

When I query using nslookup on my PC, I get the following weird results:

❯ nslookup docs.sentry.io
Server:  pfsense
Address:  172.16.66.1

Non-authoritative answer:
Name:    cname.vercel-dns.com
Addresses:  ::
          0.0.0.0
Aliases:  docs.sentry.io

But when I query the upstream directly, I get the correct response:

❯ nslookup docs.sentry.io 1.1.1.3
Server:  UnKnown
Address:  1.1.1.3

Non-authoritative answer:
Name:    cname.vercel-dns.com
Address:  76.76.21.21
Aliases:  docs.sentry.io

I tried clearing DNS cache by clicking the restart button for Unbound, which did not help.

I SSHed into my pfSense to try using dig and I got the same results, weird from my pfSense box and correct when querying the upstream directly:

dig docs.sentry.io @127.0.0.1 +short
cname.vercel-dns.com.
0.0.0.0

dig docs.sentry.io @1.1.1.1 +short
cname.vercel-dns.com.
76.76.21.21

---

I tried disabling DNSSEC and TLS to see if that would help, and it didn't.

I also checked the Unbound cache using unbound-control and neither the domain nor the CNAME were in the cache.

---

Why is my pfSense giving a bad answer, even though the upstream is giving the correct answer?

System Specs:

• 2.5.0-RELEASE (amd64)
• Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
• Dell Optiplex 960 (11.5 years old, and still reliable until today)
• WAN - Onboard (Intel PRO/1000)
• LAN - HP NC380T (Broadcom)
• IPv6 - Hurricane Electric TunnelBroker.net

[kohenkatz]

I did some more investigation, and I think I found the issue:

If I do a query from my computer to 1.1.1.3 (or 1.1.1.2) directly for docs.sentry.io, I get this:

C:\Users\moshe>nslookup docs.sentry.io 1.1.1.3
Server:  UnKnown
Address:  1.1.1.3

Non-authoritative answer:
Name:    cname.vercel-dns.com
Address:  76.76.21.21
Aliases:  docs.sentry.io

Compare to my results for just the CNAME:

C:\Users\moshe>nslookup cname.vercel-dns.com 1.1.1.3
Server:  UnKnown
Address:  1.1.1.3

Non-authoritative answer:
Name:    cname.vercel-dns.com
Addresses:  ::
          0.0.0.0

According to the packet capture, the DNS response from 1.1.1.3 includes two answers, one for the CNAME record for docs.cloudflare.com and one for the A record for cname.vercel-dns.com.

However, it seems that pfSense (i.e. Unbound) sees only the CNAME and ignores the second part of the answer, so it does its own query for cname.vercel-dns.com which gets blocked by 1.1.1.3.

Why does Unbound ignore the second part of the DNS answer?

[kohenkatz]

Seems like some other users of DNS-based filtering have already found this problem in Unbound.

It looks like they might do something about it for DoT queries at some point, but there hasn't been much activity on that issue.