DNS issues with certain sites like netflix, spotify, usps and even opnsense.org

[rgonzales98]

This initially started with netflix and spotify not working on my TV and stating no internet connection even though everything else was working. I have tried to find a solution to this but nothing is working :/ . Netflix has started working after i have disabled ipv6 but whenever i ping netflix.com it still gives me a timeout response as if the dns is not responding with a valid IP!!!  I have read that maybe some websites with load balancers are not responding with the correct IP address or just overall not responding at all to query requests. I am a beginner so ive just been following basic tutorials on how to set this up. Currently allowing all traffic on my firewall LAN for ipv4 so its not an issue with my firewall rules.

I'm either getting a ERR_CONNECTION_TIMED_OUT (opnsense.org) or DNS_PROBE_FINISHED_NXDOMAIN(usps.com).

I was wanting to stick with my ISP DNS and keep my DNS config simple using unbound but maybe thats the issue? Any recommendations on what i should do to fix this? I dont have an special DNS settings setup. I have included screenshots of my DNS settings and general settings. I have been dealing with this for hours.

[OPNenthu]

I'm not having issues on the other sites you mentioned, but since yesterday many Netflix domains are not resolving in Unbound (recursive mode) and it's not due to block lists.  See screenshots.

Local resolver returning NXDOMAIN:

Code: [Select]

$ dig help.netflix.com

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> help.netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37074
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;help.netflix.com.              IN      A

;; ANSWER SECTION:
help.netflix.com.       300     IN      CNAME   help.dradis.netflix.com.
help.dradis.netflix.com. 60     IN      CNAME   help.us-east-2.internal.dradis.netflix.com.

;; AUTHORITY SECTION:
dradis.netflix.com.     60      IN      SOA     e.ns.nflxso.net. nicadmin.netflix.com. 1732744401 16384 2048 1048576 60

;; Query time: 43 msec
;; SERVER: 192.168.40.1#53(192.168.40.1) (UDP)
;; WHEN: Wed Nov 27 17:02:57 EST 2024
;; MSG SIZE  rcvd: 169


Same query working with public DNS (DoH):

Code: [Select]

$ dig @1.1.1.1 help.netflix.com +https

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @1.1.1.1 help.netflix.com +https
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29796
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;help.netflix.com.              IN      A

;; ANSWER SECTION:
help.netflix.com.       32      IN      CNAME   help.dradis.netflix.com.
help.dradis.netflix.com. 60     IN      CNAME   help.us-east-2.internal.dradis.netflix.com.
help.us-east-2.internal.dradis.netflix.com. 60 IN CNAME apiproxy-helpcenter-nlb-6cc037a5a8a90429.elb.us-east-2.amazonaws .com.
apiproxy-helpcenter-nlb-6cc037a5a8a90429.elb.us-east-2.amazonaws.com. 60 IN A 3.136.253.118
apiproxy-helpcenter-nlb-6cc037a5a8a90429.elb.us-east-2.amazonaws.com. 60 IN A 52.14.201.162
apiproxy-helpcenter-nlb-6cc037a5a8a90429.elb.us-east-2.amazonaws.com. 60 IN A 3.133.57.11

;; Query time: 35 msec
;; SERVER: 1.1.1.1#443(1.1.1.1) (HTTPS)
;; WHEN: Wed Nov 27 17:05:21 EST 2024
;; MSG SIZE  rcvd: 236

When I temporarily switch my browser to use DoH, Netflix sites start working again.

Incidentally the Netflix app on my phone is not able to connect to the Chromecast for streaming as of yesterday.  Not sure if related.  I'm seeing a persistent error message when trying to cast that I'm unable to find information about online.  This was working the day before.

[OPNenthu]

Ok, I solved it.

Services->Unbound DNS->Advanced->Strict QNAME Minimisation (uncheck)

Disabling that makes everything with Netflix work again, including the Chromecast.

Code: [Select]

$ dig help.netflix.com

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> help.netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64904
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;help.netflix.com.              IN      A

;; ANSWER SECTION:
help.netflix.com.       300     IN      CNAME   help.dradis.netflix.com.
help.dradis.netflix.com. 60     IN      CNAME   help.us-east-1.internal.dradis.netflix.com.
help.us-east-1.internal.dradis.netflix.com. 60 IN CNAME apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com.
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 3.231.234.168
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 52.71.159.247
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 3.222.220.127

;; Query time: 79 msec
;; SERVER: 192.168.40.1#53(192.168.40.1) (UDP)
;; WHEN: Wed Nov 27 18:12:00 EST 2024
;; MSG SIZE  rcvd: 236

Always a sad day having to disable a global pro-privacy option that had been working previously.

[rgonzales98]

Doesnt seem to be my issue unfortunately. I'm getting back a reply for some of the domains but websites like opnsense.org dont even load lmao. It requires me to use a vpn for me to load this site.

Code: [Select]

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> opnsense.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52253
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;opnsense.org.                  IN      A

;; ANSWER SECTION:
opnsense.org.           826     IN      A       178.162.131.118

;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Nov 28 00:51:10 UTC 2024
;; MSG SIZE  rcvd: 57

Code: [Select]

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48874
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;netflix.com.                   IN      A

;; ANSWER SECTION:
netflix.com.            60      IN      A       3.211.157.115
netflix.com.            60      IN      A       3.225.92.8
netflix.com.            60      IN      A       54.160.93.182

;; Query time: 38 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Nov 28 00:53:00 UTC 2024
;; MSG SIZE  rcvd: 88


Code: [Select]

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> usps.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25141
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;usps.com.                      IN      A

;; Query time: 2 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Nov 28 00:53:30 UTC 2024
;; MSG SIZE  rcvd: 37


[rgonzales98]

Maybe it's not an issue with DNS issue since im getting a reply back?

Ok, I solved it.

Services->Unbound DNS->Advanced->Strict QNAME Minimisation (uncheck)

Disabling that makes everything with Netflix work again, including the Chromecast.

Code: [Select]

$ dig help.netflix.com

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> help.netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64904
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;help.netflix.com.              IN      A

;; ANSWER SECTION:
help.netflix.com.       300     IN      CNAME   help.dradis.netflix.com.
help.dradis.netflix.com. 60     IN      CNAME   help.us-east-1.internal.dradis.netflix.com.
help.us-east-1.internal.dradis.netflix.com. 60 IN CNAME apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com.
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 3.231.234.168
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 52.71.159.247
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 3.222.220.127

;; Query time: 79 msec
;; SERVER: 192.168.40.1#53(192.168.40.1) (UDP)
;; WHEN: Wed Nov 27 18:12:00 EST 2024
;; MSG SIZE  rcvd: 236

Always a sad day having to disable a global pro-privacy option that had been working previously.

[meyergru]

You should try to look at what exactly is not working. Other than the thread title suggests, the DNS resolution seems to work just fine...

Are you using jumbo frames or does your ISP connection use VLANs or PPPoE? There are websites that do not use PMTU discovery, so they may fail when your MTU settings are wrong.

[rgonzales98]

Thank you for your response! I've left any MTU setting as default so it should be 1500. From my understanding my ISP uses PPPoE. If my ISP did use VLANs i would have to set the vlan ID for the internet to work at all correct? Just did some ping test to see if i can figure it the MTU. Seems to be 1500. Ill use wireshark to try and find the failing point for this since im at a loss

Code: [Select]

ping yahoo.com -f -l 1472

Pinging yahoo.com [74.6.231.20] with 1472 bytes of data:
Reply from 74.6.231.20: bytes=1472 time=44ms TTL=49
Reply from 74.6.231.20: bytes=1472 time=47ms TTL=49
Reply from 74.6.231.20: bytes=1472 time=46ms TTL=49
Reply from 74.6.231.20: bytes=1472 time=46ms TTL=49

Ping statistics for 74.6.231.20:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 44ms, Maximum = 47ms, Average = 45ms

Code: [Select]

ping netflix.com -f -l 1472

Pinging netflix.com [54.160.93.182] with 1472 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 54.160.93.182:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

Code: [Select]

ping opnsense.org -f -l 1472

Pinging opnsense.org [178.162.131.118] with 1472 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 178.162.131.118:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

You should try to look at what exactly is not working. Other than the thread title suggests, the DNS resolution seems to work just fine...

Are you using jumbo frames or does your ISP connection use VLANs or PPPoE? There are websites that do not use PMTU discovery, so they may fail when your MTU settings are wrong.

[meyergru]

And there you have it!

As you can see, the problematic sites cannot be accessed by a payload of 1472 bytes corresponding to a MTU of 1500. That is your problem,

The maximum physical MTU of the ethernet adapter has to be reduced by 4 bytes for VLANs, plus 8 bytes for PPPoE encapsulation, thus you will either have to reduce your WAN (net) MTU by these amounts. That is, you should reduce your MTU to 1492 or 1488 bytes.

Or you can hope that your ethernet driver (and your ISP) supports even more than 1500 bytes and set larger sizes for the lower layers beneath the logical WAN adapter in order to keep 1500 bytes.

But beware:

1. The OpnSense settings here are somewhat "wrong". If you have a WAN over PPPoE over VLAN, you "should" have to set WAN = 1500, pppoe0 = 1508, ONT = 1512, but in reality it works for me with these MTUs:

WAN: 1508 (this also sets pppoe0, which you cannot set directly, but really results in 1500 on WAN)
ONT (this means the physical ethernet port): 1512 if you have a VLAN for PPPoE, 1508 if not.

2. Set the above values in the web UI and then reboot - they cannot be changed via UI manipulations, because the order of application seems to be wrong that way.

Retry your tests afterwards.

And please change your thread title as it is obviously not DNS that is your problem. If your problem is fixes, add [SOLVED] to the thread title.

[MagikMark]

meyergru

Is there a way to know if your ISP is doing what you just described?  Or this is just trial and error? My ISP uses IPoE over vlan and multicast vlan.  Following your instruction, this would be 1500 + 4 + 4 MTU is now 1508?