[SOLVED] Weird DNS Problem



  • This is a test environment with a fresh installation of pfsense 2.4.4, minimal configuration changes from the defaults, DNS Resolver works. The only firewall rules other than the defaults allow all traffic from LAN to WAN and DNS from LAN to pfsense and from pfsense to its forwarders 1.1.1.1/1.0.0.1 only. Clients on the test.local LAN run Windows 7, Windows 10, Linux Mint 19, and iOS12.1, including an iPad and an iPhone. Some of the clients are configured with static IPs and gateways, some use DHCP, but all use only the pfsense machine for DNS resolution.

    All of the clients can access most domains. However, DNS for some domains resolves when using Diagnostics/DNS Lookup on pfsense, but the resolution doesn't pass through to any of the clients. For instance, robgillen.com resolves to an IP address using DNS lookup in pfsense, but none of the clients receive that address. For example, on Windows 10, I run this from the command line:

    nslookup robgillen.com
    Server:  pfSense.test.local
    Address:  192.168.254.1
    
    DNS request timed out.
        timeout was 2 seconds.
    *** Request to pfSense.test.local timed-out
    

    But if I specify the same external DNS server that pfsense uses, it resolves on that same client:

    nslookup robgillen.com 1.1.1.1
    Server:  one.one.one.one
    Address:  1.1.1.1
    
    Non-authoritative answer:
    Name:    argodev.github.io
    Addresses:  185.199.111.153
              185.199.108.153
              185.199.109.153
              185.199.110.153
    Aliases:  robgillen.com
    

    On the other hand, this works just fine when using pfsense's DNS Resolover:

    nslookup www.google.com
    Server:  pfSense.eis.local
    Address:  192.168.254.1
    
    Non-authoritative answer:
    Name:    www.google.com
    Addresses:  2607:f8b0:400f:805::2004
              172.217.1.196
    

    If I change the clients' configurations to use external DNS servers, there are no problems, but if they use pfsense for DNS, that domain does not resolve.

    This happens on all of the clients, regardless of operating system or configuration. As I said, most domains resolve without problems, but a few don't, even though pfsense can resolve the IP addresses for those domains in DNS lookup. Disabling the firewall doesn't fix the problem.

    I'm baffled. This is the simplest and cleanest configuration I can imagine for pfsense and the test network. I'll appreciate any suggestions that anyone can offer.

    UPDATE and Solution: I think that I misunderstandd how DNS forwarding works on pfsense. It appears to work differently than it does on Windows servers. Our lab has a direct connection to the internet, and I'd configured pfsense to forward DNS resolution requests for external domains to Cloudflare's DNS servers by checking "Enable Forwarding Mode" under Services/DNS Resolver/General Settings. Removing that check mark does not stop requests from being forwarded to the DNS servers configured under Settings/General Setup, and the few sites that I was having problems with now resolve. Nevertheless, even though the problem is solved, I'd like to know what is different about those domains that was causing the problem. Maybe one day I'll have the time to research it.


  • Netgate Administrator

    Did you have DNSSec enabled?

    In resolving mode Unbound talks directly to the DNS root servers which reliably support DNSSec. If you put it into forwarding mode it's usually better to disable DNSSec as it's likely something in the chain of forwarded servers will not support DNSSec and will be ignored. Since that can be different for different sites that could explain what you were seeing.

    Steve


  • LAYER 8 Global Moderator

    @eveningstarnm said in [SOLVED] Weird DNS Problem:

    from LAN to WAN

    That his not default the default is lan to ANY... There is a HUGE difference... Wan is not the internet - its just the wan network.. Users that set such a rule will break any sort of internet access...


  • Netgate Administrator

    A "DNS from LAN to pfsense" rule should allow that though.

    Steve



  • @stephenw10 Yes, I thought that, too, and I tried it, but it didn't work. In fact, I tried opening up everything between pfsense and LAN, yet still no joy. But thanks for that observation about how Unbound works in supporting DNSSec. I think you're right: That's probably what caused the problem.



  • @eveningstarnm did you ever get the solution to this? I have in production at home, and on the whole the dns works but i have just discovered this same problem with the download-c.huawei.com in debug logging, i can see the request from the client and the requests resolves on the server correctly. also from the pfsense diag screen. however, on a win10 machine, i receive DNS Request timeout, timeout was 2sec.

    the machine originally had comodo dns servers set, but they are trapped and redirected on pfsense.
    nevertheless, i change the dns to on the client to pfsense and it makes no difference.

    p.s. i might add, if i switch DNS Query Forwarding on. it works.


  • LAYER 8 Global Moderator

    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/

    0_1551617424186_mess.png



  • like i said, if i use dns lookup on the pfsense fiag box, it resolve per yours. (both with/without forwarding)
    Only the client side, it resolves with forwarding and does not without forwarding..i am using unbound

    very strange indeed..... hence the original poster's Weird DNS Problem - but he didn't write how he solved it


  • LAYER 8 Global Moderator

    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


  • LAYER 8 Global Moderator

    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 well

    Maybe 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..


  • Netgate Administrator

    Ha, seems legit! ๐Ÿ™„


  • LAYER 8 Global Moderator

    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.36
    

    this 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 reached
    

    to 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 m
    

    this 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 0
    

    probably 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


  • Netgate Administrator

    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 127

    Rules are
    IPv4 TCP/UDP LAN * This Firewall DNS, VPN Gateway
    ** if i change the gateway to default, the results are the same

    the 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.com
    

    forwarding 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-out
    

    in 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?


  • Netgate Administrator

    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: 239
    

    this 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
    

  • Netgate Administrator

    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: 244
    

    forwarding 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
    

  • Netgate Administrator

    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.

    1. If i add the WAN to the outgoing interface, DNSLeakTest pulls my ISP IP address, but all lookups work
    2. 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.
    3. 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/

    0_1551617424186_mess.png

    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.


  • Netgate Administrator

    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



  • @stephenw10 when the WAN is enabled as an outgoing interface (it works - and clearly goes out the wan)

    192.168.0.234.52023 > 139.159.208.46.53: [udp sum ok] 31124% [1au] A? download-c.huawei.com.c.cdnhwc1.com. ar: . OPT UDPsize=1472 DO (64)
    13:51:33.971911 34:2c:c4:11:12:b4 > 00:ab:ba:22:15:4c, ethertype IPv4 (0x0800), length 149: (tos 0x0, ttl 236, id 24993, offset 0, flags [none], proto UDP (17), length 135)
        139.159.208.46.53 > 192.168.0.234.52023: [udp sum ok] 31124*- q: A? download-c.huawei.com.c.cdnhwc1.com. 1/0/1 download-c.huawei.com.c.cdnhwc1.com. CNAME download-c.huawei.com.wscdns.com. ar: . OPT UDPsize=1472 DO (107)
    13:51:33.972152 00:ab:ba:22:15:4c > 34:2c:c4:11:12:b4, ethertype IPv4 (0x0800), length 81: (tos 0x0, ttl 64, id 52665, offset 0, flags [none], proto UDP (17), length 67)
    

    When the wan is disabled as an outgoing interface, i get the below on the VPN interface

    (64)
    13:57:06.359345 AF IPv4 (2), length 139: (tos 0x0, ttl 241, id 59054, offset 0, flags [none], proto UDP (17), length 135)
        159.138.17.59.53 > 10.64.0.122.22038: [udp sum ok] 11628*- q: A? download-c.huawei.com.c.cdnhwc1.com. 1/0/1 download-c.huawei.com.c.cdnhwc1.com. CNAME download-c.huawei.com.wscdns.com. ar: . OPT UDPsize=4096 DO (107)
    13:57:06.359770 AF IPv4 (2), length 71: (tos 0x0, ttl 64, id 29014, offset 0, flags [none], proto UDP (17), length 67)
        10.64.0.122.55777 > 192.5.6.30.53: [udp sum ok] 52730% [1au] A? wscdns.com. ar: . OPT UDPsize=4096 DO (39)
    13:57:06.382731 AF IPv4 (2), length 672: (tos 0x0, ttl 53, id 58872, offset 0, flags [none], proto UDP (17), length 668)
        192.5.6.30.53 > 10.64.0.122.55777: [udp sum ok] 52730- q: A? wscdns.com. 0/9/1 ns: wscdns.com. NS dns2.wscdns.info., wscdns.com. NS dns4.wscdns.info., wscdns.com. NS dns1.wscdns.org., wscdns.com. NS dns3.wscdns.org., wscdns.com. NS dns5.wscdns.org., CK0POJMG874LJREF7EFN8430QVIT8BSM.com. Type50, CK0POJMG874LJREF7EFN8430QVIT8BSM.com. RRSIG, RCDUE08JKJECE4UVVUUU7AUF8IBGKA4U.com. Type50, RCDUE08JKJECE4UVVUUU7AUF8IBGKA4U.com. RRSIG ar: . OPT UDPsize=4096 DO (640)
    

    One thing i notice on the firewall logs, the request goes to both LAN addresses and the localhost.
    Is that correct?

    Mar 4 14:19:03 	GREEN 	Pass GREEN DNS to Firewall (1551369636) 	192.168.20.49:42006		192.168.21.5:53		UDP
    	Mar 4 14:18:55 	GREEN 	Pass GREEN DNS to Firewall (1551369636) 	192.168.20.49:52424		192.168.20.5:53		UDP
    	Mar 4 14:18:36 	GREEN 	Pass GREEN DNS to Firewall (1551369636) 	192.168.20.49:60957		127.0.0.1:53		UDP
    

  • Netgate Administrator

    Those are firewall logs on the client? I imagine that's checking local host data in addition to resolving against Unbound.

    Hmm, certainly seems to be getting a response in that pcap. Nothing shown blocked in the firewall logs I assume?

    Steve



  • @stephenw10 nope. nothing blocked in relation to 53 or 853



  • fixed almost all of the problems i have been having with the following expressvpn config
    https://forum.netgate.com/topic/140931/expressvpn-down-on-pfsense-2-4-4

    Now have DNS Resolver working as it should
    i.e. without forwarding, without going over WAN and resolving download-c.huawei.com
    packet trace on WAN shows only 1195 traffic.

    Both Expressvpn interfaces are up in fail-over, everything is working except one thing.......

    Linux Mint clients.
    Most of the mirrors are unavailable or have super slow speeds.
    This does not appear to be a problem if only one ExpressVPN interface is used.

    from main tessa mirrors, there are less than 10 and none connectable.
    from the base bionic mirrors, there are also much less and most have unreachable.

    so still something not quite right.....


  • Netgate Administrator

    This seems unrelated, it should be in a new thread.

    Please start a new topic and I'll moved these posts across.

    Steve



  • Thanks Steve. I have opened a new topic here: link text


Log in to reply