Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    [SOLVED] Weird DNS Problem

    Scheduled Pinned Locked Moved General pfSense Questions
    34 Posts 6 Posters 11.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • 4
      4o4rh
      last edited by

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

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Well try dig @pfSense_interface and see how that changes between modes.

        Steve

        1 Reply Last reply Reply Quote 0
        • 4
          4o4rh
          last edited by

          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
          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Sorry I meant to imply: dig @192.168.20.5 download-c.huawei.com

            4 1 Reply Last reply Reply Quote 0
            • 4
              4o4rh @stephenw10
              last edited by

              @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
              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                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

                4 2 Replies Last reply Reply Quote 0
                • 4
                  4o4rh @stephenw10
                  last edited by

                  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
                  1 Reply Last reply Reply Quote 0
                  • 4
                    4o4rh @stephenw10
                    last edited by 4o4rh

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

                    1 Reply Last reply Reply Quote 0
                    • GertjanG
                      Gertjan @johnpoz
                      last edited by

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

                      No "help me" PM's please. Use the forum, the community will thank you.
                      Edit : and where are the logs ??

                      4 1 Reply Last reply Reply Quote 1
                      • 4
                        4o4rh @Gertjan
                        last edited by 4o4rh

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

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          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

                          4 1 Reply Last reply Reply Quote 0
                          • 4
                            4o4rh @stephenw10
                            last edited by 4o4rh

                            @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
                            1 Reply Last reply Reply Quote 0
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

                              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

                              4 1 Reply Last reply Reply Quote 0
                              • 4
                                4o4rh @stephenw10
                                last edited by

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

                                1 Reply Last reply Reply Quote 0
                                • 4
                                  4o4rh
                                  last edited by 4o4rh

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

                                  1 Reply Last reply Reply Quote 0
                                  • stephenw10S
                                    stephenw10 Netgate Administrator
                                    last edited by

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

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

                                    Steve

                                    1 Reply Last reply Reply Quote 0
                                    • V
                                      vjizzle
                                      last edited by

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

                                      1 Reply Last reply Reply Quote 0
                                      • First post
                                        Last post
                                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.