[SOLVED] Weird DNS Problem
-
That resolves just fine on my win 10 box.. My guess is their nonsense with no glue for their IPv6 and your trying to access via IPv6? Their DNS is freaking HORRIBLE!!! That anyone can get there is just freaking amazing ;)
even going through pihole
$ nslookup download-c.huawei.com Server: pi-hole.local.lan Address: 192.168.3.10 Non-authoritative answer: Name: dp6opavwln80.cloudfront.net Addresses: 99.84.240.136 99.84.240.45 99.84.240.175 99.84.240.78 Aliases: download-c.huawei.com download-c.huawei.com.c.cdnhwc1.com download-c.huawei.com.wscdns.com -
@johnpoz i have IPv6 disabled on everything inc my clients
-
so do either a debug on nslookp or grab dig and do a trace and see what is failing or just getting there?
If I click what you posted I get
Welcome to nginx! If you see this page, the nginx web server is successfully installed and working. Further configuration is required. For online documentation and support please refer to nginx.org. Commercial support is available at nginx.com. Thank you for using nginx.So have no idea what you think is suppose to be there or what is suppose to get there?
edit:
Not sure what his issue was.. He rule to any to wan wouldn't of even allowed internet at all, etc. His domain resolved just fine as well - but again a nightmare of errors... cname mess as wellMaybe he had qminimization on? Have no idea with the lack of info given.
If pfsense resolves it fine, and client asks pfsense then pfsense will hand to client what it got... If you want help in finding your issue going to have to give a bit more than client can not resolve.. For all we know your clients using some proxy, etc. Do you get a time out from pfsense? Do you get a NX, etc. etc..
-
Ha, seems legit!
-
Yeah that any legit company would have such a NIGHTMARE MESS for their dns is just SAD!!!
But it does resolve - so without some more info.. there is nothing can tell you. On what your actual issue might or might not be?
You sure your pointing pfsense to itself.. See it all the time where clients point pfsense to some external when they are running resolver.. When you resolve you might have issue resolving if you can not actually talk to the NS for the domain, and with so many cnames your going to have to talk to many NS ;) failure or time out to any one of them in that chain could cause you grief in resolving.
Do a simple +trace to see where you might be having issue.
Here is trace - but its only 1st leg, since there are 2 more cnames!! Arrrggh
$ dig download-c.huawei.com +trace ; <<>> DiG 9.12.3-P1 <<>> download-c.huawei.com +trace ;; global options: +cmd . 450361 IN NS d.root-servers.net. . 450361 IN NS k.root-servers.net. . 450361 IN NS j.root-servers.net. . 450361 IN NS l.root-servers.net. . 450361 IN NS c.root-servers.net. . 450361 IN NS f.root-servers.net. . 450361 IN NS a.root-servers.net. . 450361 IN NS i.root-servers.net. . 450361 IN NS e.root-servers.net. . 450361 IN NS m.root-servers.net. . 450361 IN NS h.root-servers.net. . 450361 IN NS g.root-servers.net. . 450361 IN NS b.root-servers.net. . 450361 IN RRSIG NS 8 0 518400 20190315140000 20190302130000 16749 . ShqK2j6F+OJAQI+ sTMG6oms moskB4VtcKYv+CwtAxmuWDnVAVJz35hcj4rkdXBv6Wz423JmuesZsl4j SUMl4xFUT42faNiHG/OZybi+uxwXSggIrQHhM9kg9WlamZ+Y+ 5/i+ifoWJGMUZOXp0SIkJJGXHeFI2P2 vfReHTB6/QUQNMFPHGjMhvM37AFruXs0vktZWZ9aAjj+uXvA0kvgZYIO SKcRsbULeCQNlnvSncTZFCM+YE phwQ== ;; Received 525 bytes from 192.168.3.10#53(192.168.3.10) in 3 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF com. 86400 IN RRSIG DS 8 1 86400 20190316050000 20190303040000 16749 . FqDz8iA8R/26+mJO 5vVsdnr XEiNTUA+aO8xsAEzNfctse3SY7XLmTnMI4o/YgL4cfwLnQeUR+7fF1qj +pUvL5H+qXk3NRRWFkDhtYoaBEo4Vgg9yjZN2bSWThBelY/QD5 yWzrR5yLJfknD9OhewaHp120kCWxkn m0YnRtiZ0xUjlNm1IcmAv9CuliXTyMCTU41VqCFXfjFIoKRyVnEIMUos Q+wJ9gk1XRM4LUI3T+1+Jcobftk 3pA== ;; Received 1181 bytes from 198.97.190.53#53(h.root-servers.net) in 35 ms huawei.com. 172800 IN NS nsallsec.huawei.com. huawei.com. 172800 IN NS nsall.huawei.com. huawei.com. 172800 IN NS nsall3rd.huawei.com. huawei.com. 172800 IN NS nsall4th.huawei.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY N CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20190308054542 20190301043542 16883 com. FgR1J rnGB/qZQvAwOFwglFi sfO86z794cvm/6B4zzRDMFDLJKvhPyvYblmRCUCj2iMgZVksTqxDYbGR 2/2MFK9HwQpGr79itYpKMexrS1duvbogm/xNgiL 96PTCKH6PDT3DG589UG3MN0NA6LG5MTJ.com. 86400 IN NSEC3 1 1 0 - 96PU6P2QEB574VGKGIUQGM47GT2D04SQ NS DS RRSIG 96PTCKH6PDT3DG589UG3MN0NA6LG5MTJ.com. 86400 IN RRSIG NSEC3 8 2 86400 20190309063008 20190302052008 16883 com. g36Vi BL3b29EVq9rNyutbGT qdpfOBgD5JHsZHDf76qb0cKd7p+nzjee2UAFhd0Z5EgvRUv+3s0PM6qq evdbQx4tQA56b6NwLqipwe7SUduKpIhqAF7P0CY ;; Received 720 bytes from 192.35.51.30#53(f.gtld-servers.net) in 30 ms download-c.huawei.com. 600 IN CNAME download-c.huawei.com.c.cdnhwc1.com. ;; Received 96 bytes from 122.96.104.66#53(nsall4th.huawei.com) in 255 ms -
the huawei site is the download site for their windows application that HiSuite that connects their phones.
this is what i get on my linux client, with DNS forwarding enabled.
nslookup download-c.huawei.com Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: download-c.huawei.com canonical name = download-c.huawei.com.c.cdnhwc1.com. download-c.huawei.com.c.cdnhwc1.com canonical name = download-c.huawei.com.wscdns.com. download-c.huawei.com.wscdns.com canonical name = dp6opavwln80.cloudfront.net. Name: dp6opavwln80.cloudfront.net Address: 143.204.208.172 Name: dp6opavwln80.cloudfront.net Address: 143.204.208.221 Name: dp6opavwln80.cloudfront.net Address: 143.204.208.117 Name: dp6opavwln80.cloudfront.net Address: 143.204.208.36this is what i get, if i uncheck DNS forwarding and no other changes.
nslookup download-c.huawei.com ;; connection timed out; no servers could be reachedto be clear, with forwarding unchecked, straight after the previous nslookup, i do a google and is ok.
nslookup google.com Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: google.com Address: 172.217.17.110 Name: google.com Address: 2a00:1450:400e:806::200e -
@johnpoz said in [SOLVED] Weird DNS Problem:
dig download-c.huawei.com +trace
using your command, this is what i get with forwarding unchecked
dig download-c.huawei.com +trace ; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> download-c.huawei.com +trace ;; global options: +cmd ;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0 mthis is the result with forwarding checked, and i note the result is the same.
dig download-c.huawei.com +trace ; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> download-c.huawei.com +trace ;; global options: +cmd ;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0probably need some help from you with the commands, to do any deeper analysis. but seems very odd to me, that the nslookup fails simply by changing the forwarding mode
-
You seem to be testing against localhost. What do you have running on the client? How is that configured?
What do you see if you test against the pfSense interface IP?
Steve
-
that is what it returns. both the windows and linux clients are DHCP with the gateway pointing to the LAN interface address. for the DNS, the linux points to the LAN interface address and for windows, it has static comodo firewall servers defined.
on the pfsense box
NAT is
LAN UDP * * !LOCAL DNS 127.0.0.1 DNS
** it didn't work at all when i used the LAN interface for the NAT IP. It only works if i use 127Rules are
IPv4 TCP/UDP LAN * This Firewall DNS, VPN Gateway
** if i change the gateway to default, the results are the samethe only thing strange i notice on the windows client, (forwarding enabled)
nslookup download-c.huawei.com Server: UnKnown Address: 156.154.70.22 Non-authoritative answer: Name: dp6opavwln80.cloudfront.net Addresses: 143.204.98.14 143.204.98.132 143.204.98.156 143.204.98.173 Aliases: download-c.huawei.com download-c.huawei.com.c.cdnhwc1.com download-c.huawei.com.wscdns.comforwarding disabled
nslookup download-c.huawei.com DNS request timed out. timeout was 2 seconds. Server: UnKnown Address: 156.154.70.22 DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. *** Request to UnKnown timed-outin both cases, windows says server unknown...not sure if that is normal
-
@johnpoz said in [SOLVED] Weird DNS Problem:
Server: pi-hole.local.lan
I see in John's windows lookup above, he gets Server: pi-hole.local.lan returned, where as mine is unknown.could it be something wrong, with my NAT or Rules above?
-
Well try dig @pfSense_interface and see how that changes between modes.
Steve
-
this is from forwarding enabled
dig @192.168.20.5 ; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @192.168.20.5 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20423 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 463269 IN NS a.root-servers.net. . 463269 IN NS e.root-servers.net. . 463269 IN NS l.root-servers.net. . 463269 IN NS i.root-servers.net. . 463269 IN NS j.root-servers.net. . 463269 IN NS c.root-servers.net. . 463269 IN NS k.root-servers.net. . 463269 IN NS b.root-servers.net. . 463269 IN NS m.root-servers.net. . 463269 IN NS d.root-servers.net. . 463269 IN NS h.root-servers.net. . 463269 IN NS g.root-servers.net. . 463269 IN NS f.root-servers.net. ;; Query time: 169 msec ;; SERVER: 192.168.20.5#53(192.168.20.5) ;; WHEN: Sun Mar 03 19:15:54 CET 2019 ;; MSG SIZE rcvd: 239this is forwarding disabled.
$ nslookup download-c.huawei.com ;; connection timed out; no servers could be reached $ dig @192.168.20.5 ; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @192.168.20.5 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12658 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518383 IN NS a.root-servers.net. . 518383 IN NS b.root-servers.net. . 518383 IN NS c.root-servers.net. . 518383 IN NS d.root-servers.net. . 518383 IN NS e.root-servers.net. . 518383 IN NS f.root-servers.net. . 518383 IN NS g.root-servers.net. . 518383 IN NS h.root-servers.net. . 518383 IN NS i.root-servers.net. . 518383 IN NS j.root-servers.net. . 518383 IN NS k.root-servers.net. . 518383 IN NS l.root-servers.net. . 518383 IN NS m.root-servers.net. ;; Query time: 3 msec ;; SERVER: 192.168.20.5#53(192.168.20.5) ;; WHEN: Sun Mar 03 19:18:05 CET 2019 ;; MSG SIZE rcvd: 239 -
Sorry I meant to imply:
dig @192.168.20.5 download-c.huawei.com -
@stephenw10 said in [SOLVED] Weird DNS Problem:
dig @192.168.20.5 download-c.huawei.com
of course, sorry...brain-dead
forwarding enabled
dig @192.168.20.5 download-c.huawei.com ; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @192.168.20.5 download-c.huawei.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36586 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;download-c.huawei.com. IN A ;; ANSWER SECTION: download-c.huawei.com. 586 IN CNAME download-c.huawei.com.c.cdnhwc1.com. download-c.huawei.com.c.cdnhwc1.com. 50 IN CNAME download-c.huawei.com.wscdns.com. download-c.huawei.com.wscdns.com. 590 IN CNAME dp6opavwln80.cloudfront.net. dp6opavwln80.cloudfront.net. 50 IN A 143.204.98.173 dp6opavwln80.cloudfront.net. 50 IN A 143.204.98.14 dp6opavwln80.cloudfront.net. 50 IN A 143.204.98.132 dp6opavwln80.cloudfront.net. 50 IN A 143.204.98.156 ;; Query time: 2 msec ;; SERVER: 192.168.20.5#53(192.168.20.5) ;; WHEN: Sun Mar 03 19:28:10 CET 2019 ;; MSG SIZE rcvd: 244forwarding disabled
dig @192.168.20.5 download-c.huawei.com ; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @192.168.20.5 download-c.huawei.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached -
Mmm, well that's fun!
Check the Unbound logs when that fails. Might need to turn up the logging.
Do you see any DNS traffic blocked anywhere?Steve
-
Lot of stuff means nothing to me.... port 53 shows pass for both source and destination ports
Mar 3 19:38:32 unbound 47057:3 debug: close fd 46 Mar 3 19:38:32 unbound 47057:3 debug: close of port 27742 Mar 3 19:38:32 unbound 47057:3 debug: comm point start listening 47 Mar 3 19:38:32 unbound 47057:3 debug: opened UDP if=0 port=57612 Mar 3 19:38:32 unbound 47057:3 debug: inserted new pending reply id=f6d7 Mar 3 19:38:32 unbound 47057:3 debug: serviced query UDP timeout=752 msec Mar 3 19:38:32 unbound 47057:3 debug: EDNS lookup known=0 vs=0 Mar 3 19:38:32 unbound 47057:3 debug: try edns1xx0 <ns1.hwclouds-dns.net.> 139.159.208.43#53 Mar 3 19:38:32 unbound 47057:3 debug: timeout udp Mar 3 19:38:32 unbound 47057:3 debug: close fd 47 Mar 3 19:38:32 unbound 47057:3 debug: close of port 58861 Mar 3 19:38:32 unbound 47057:3 debug: comm point start listening 45 Mar 3 19:38:32 unbound 47057:3 debug: opened UDP if=0 port=29679 Mar 3 19:38:32 unbound 47057:3 debug: inserted new pending reply id=ef89 Mar 3 19:38:32 unbound 47057:3 debug: serviced query UDP timeout=752 msec Mar 3 19:38:32 unbound 47057:3 debug: EDNS lookup known=0 vs=0 Mar 3 19:38:32 unbound 47057:3 debug: try edns1xx0 <download-c.huawei.com.c.cdnhwc1.com.> 122.112.208.53#53 Mar 3 19:38:32 unbound 47057:3 debug: timeout udp Mar 3 19:38:31 unbound 47057:3 debug: close fd 45 Mar 3 19:38:31 unbound 47057:3 debug: close of port 45220 Mar 3 19:38:31 unbound 47057:3 debug: svcd callbacks end Mar 3 19:38:31 unbound 47057:3 debug: cache memory msg=78665 rrset=134977 infra=24276 val=74535 Mar 3 19:38:31 unbound 47057:3 info: 1RDdc mod1 rep download-c.huawei.com. A IN -
@stephenw10 i have a further update.
In the DNS Resolver, i had only the VPN enable for outgoing requests.
If i include the WAN for outgoing requests, it works.
But this defeats the purpose. I want to be sure the traffic can only go via the VPN.FFS...this 2.4.4 update has cost me so much time, when everything was working prior to it and no change of a rollback - which i would have already done days ago.
- If i add the WAN to the outgoing interface, DNSLeakTest pulls my ISP IP address, but all lookups work
- If i remove the WAN from the outgoing interface, DNSLeakTest only finds my VPN provider (but not my VPN address) but then i don't have all the routing e.g. the huawei address in this discussion.
- if i remove the WAN from the outgoing interface and use forwarding, DNSLeakTest only find my VPN provider (but not my VPN address) and all lookups work.
for me, this has simply cost too much time.
It is clear, the only option to go with is forwarding to Quad9/Cloudflare in the absence of a working DNS Resolver. -
@johnpoz said in [SOLVED] Weird DNS Problem:
What a cluster of cnames
;; QUESTION SECTION: ;download-c.huawei.com. IN A ;; ANSWER SECTION: download-c.huawei.com. 3598 IN CNAME download-c.huawei.com.c.cdnhwc1.com. download-c.huawei.com.c.cdnhwc1.com. 3600 IN CNAME download-c.huawei.com.wscdns.com. download-c.huawei.com.wscdns.com. 3600 IN CNAME dp6opavwln80.cloudfront.net.But not having any problems resolving that with unbound
They have a HUGE mess!!
http://dnsviz.net/d/download-c.huawei.com/dnssec/
Thanks !
I hope this "huawei" company doesn't include a lot of Internet usage in their business model. Because if they do, they have a problem.
-
@gertjan is the problem here, solving Huawei software update portal, or solving the problem with pfsense and unbound not being able to resolve all sites in resolver mode. I currently have to use forwarding mode as the only way to ensure all traffic goes over the VPN and all sites can work.
-
Do you actually see port 53 traffic leaving over the VPN when it's seemingly getting no response there? In a packet capture?
Are there actually any responses?
Steve
