I’ve been doing some more testing, and here it gets a little weird.
If I do a query 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
C:\Users\moshe>nslookup docs.sentry.io 1.1.1.2
Server: UnKnown
Address: 1.1.1.2
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
C:\Users\moshe>nslookup cname.vercel-dns.com 1.1.1.2
Server: UnKnown
Address: 1.1.1.2
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 the router (pfSense, running 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.
So there are now two questions that remain:
- Why is the Vercel domain blocked on its own?
- Why does Unbound not use the second part of the DNS response?
I hope I’ll get an answer here on the first question, and I’m following up on the pfSense forum about the second question.