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

    DNS not resolving some sites

    Scheduled Pinned Locked Moved DHCP and DNS
    13 Posts 4 Posters 2.5k 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.
    • H
      HankB
      last edited by

      Problem:

      Hosts on my LAN cannot resolve "coder.show" Most other sites seem to be OK.

      If I type "coder.show" (w/out the quotes of course) into https://192.168.1.1/diag_dns.php it resolves to the correct  address.

      My configuration is fairly vanilla except that I've configured to use Cloudflare DNS by using the following Custom options

      server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853

      in https://192.168.1.1/services_unbound.php

      Other settings are:
      Network Interfaces: ALL
      Outgoing Network Interfaces: WAN
      System Domain Local Zone Type: Transparent
      DNSSEC: Enabled
      DNS Query Forwarding: disabled
      DHCP Registration (Register DHCP leases in the DNS Resolver): Enabled
      Static DHCP: enabled
      OpenVPN Clients: disabled

      I'm pretty sure that Advanced Settings and Access Lists are unchanged from default.

      I updated earlier today from 2.4.3 to 2.4.3_1 (which now identifies itself as 2.4.3-RELEASE-p1) and results are unchanged.

      From the command line (on other PCs on my LAN) this host cannot be resolved.

      hbarta@olive:~/Documents/purchase$ nslookup coder.show
;; Got SERVFAIL reply from 192.168.1.1, trying next server
Server:		2601:249:e00:3813:201:2eff:fe6f:f9f9
Address:	2601:249:e00:3813:201:2eff:fe6f:f9f9#53

** server can't find coder.show: SERVFAIL

hbarta@olive:~/Documents/purchase$ nslookup coder.show 1.1.1.1
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
coder.show	canonical name = hosted.fireside.fm.
Name:	hosted.fireside.fm
Address: 96.126.99.139

hbarta@olive:~/Documents/purchase$ nslookup coder.show 192.168.1.1
Server:		192.168.1.1
Address:	192.168.1.1#53

** server can't find coder.show: SERVFAIL

hbarta@olive:~/Documents/purchase$ nslookup google.com
Server:		192.168.1.1
Address:	192.168.1.1#53

Non-authoritative answer:
Name:	google.com
Address: 108.177.112.100
Name:	google.com
Address: 108.177.112.101
Name:	google.com
Address: 108.177.112.102
Name:	google.com
Address: 108.177.112.113
Name:	google.com
Address: 108.177.112.138
Name:	google.com
Address: 108.177.112.139

      I'm baffled by what could cause this and how to proceed with debugging. I looked in the general and DNS logs and don't see anything that gives me a clue about what is going on.

      Thanks for any suggestions.

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

        Hi,

        C:\Users\Réception-Gauche>nslookup coder.show
Serveur :   pfsense.brit-hotel-fumel.net
Address:  2001:470:1f13:5c0:2::1

Réponse ne faisant pas autorité :
Nom :    hosted.fireside.fm
Address:  96.126.99.139
Aliases:  coder.show

        Who is "192.168.1.1" ? make your DNS work on that device, because the PC where you are running nslookup was told to use it.

        Note : it's ok to move from the default Resolver, and set up something different - using "8..8.8.8" or Cloudfare or whatever. But : finish the setup  ;)

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

        1 Reply Last reply Reply Quote 0
        • H
          HankB
          last edited by

          @Gertjan:

          Hi,

          Who is "192.168.1.1" ? make your DNS work on that device, because the PC where you are running nslookup was told to use it.

          Note : it's ok to move from the default Resolver, and set up something different - using "8..8.8.8" or Cloudfare or whatever. But : finish the setup  ;)

          Sorry, I should have mentioned that the pfsense host is at 192.168.1.1 and it does resolve coder.show using the management web page https://192.168.1.1/diag_dns.php.

          thanks,
          hank

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

            Hi,

            I have set up DNS resolver on pfsense and can see the same behavior. When I point my client to pfsense for DNS resolving, sometimes certain websites will not resolve. When I try the diagnostic option in pfsense the domain resolve just fine. I am not running anything particular like pfblocker or squid. Just basic pfsense with DNS resolver enabled. Logs don't show anything special. When I restart DNS resolver on pfsense everything is fine.

            1 Reply Last reply Reply Quote 0
            • johnpozJ
              johnpoz LAYER 8 Global Moderator
              last edited by

              I would suggest you troubleshoot the specific fqdn your having issues with by looking at unbound has cached for this record and NS for that domain, etc.

              Look to the unbound documentation on how to troubleshoot resolving issues.

              If your just forwarding - then lack of resolution is out of your hands and you are at the mercy of who your forwarding to to correctly resolve something.  And have no way to troubleshoot what their problem might be.

              An intelligent man is sometimes forced to be drunk to spend time with his fools
              If you get confused: Listen to the Music Play
              Please don't Chat/PM me for help, unless mod related
              SG-4860 24.11 | Lab VMs 2.8, 24.11

              1 Reply Last reply Reply Quote 0
              • H
                HankB
                last edited by

                @johnpoz:

                I would suggest you troubleshoot the specific fqdn your having issues with by looking at unbound has cached for this record and NS for that domain, etc.

                Look to the unbound documentation on how to troubleshoot resolving issues.

                Hi johnpoz,
                Thank you for the suggestion. I bumped the log level by 1 for the resolver and found the following in the log when I tried the troublesome name.

                May 20 10:34:52 	unbound 	6706:3 	info: Could not establish a chain of trust to keys for coder.show. DNSKEY IN
May 20 10:34:52 	unbound 	6706:3 	info: query response was nodata ANSWER
May 20 10:34:52 	unbound 	6706:3 	info: reply from <.> 1.1.1.1#853
May 20 10:34:52 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: Could not establish a chain of trust to keys for coder.show. DNSKEY IN
May 20 10:34:52 	unbound 	6706:2 	info: query response was nodata ANSWER
May 20 10:34:52 	unbound 	6706:2 	info: reply from <.> 1.1.1.1#853
May 20 10:34:52 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: query response was CNAME
May 20 10:34:52 	unbound 	6706:3 	info: reply from <.> 1.1.1.1#853
May 20 10:34:52 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: query response was CNAME
May 20 10:34:52 	unbound 	6706:2 	info: reply from <.> 1.1.1.1#853
May 20 10:34:52 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: query response was nodata ANSWER
May 20 10:34:52 	unbound 	6706:3 	info: reply from <.> 1.0.0.1#853
May 20 10:34:52 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: query response was nodata ANSWER
May 20 10:34:52 	unbound 	6706:2 	info: reply from <.> 1.0.0.1#853
May 20 10:34:52 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: query response was CNAME
May 20 10:34:52 	unbound 	6706:3 	info: reply from <.> 1.0.0.1#853
May 20 10:34:52 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: query response was CNAME
May 20 10:34:52 	unbound 	6706:2 	info: reply from <.> 1.1.1.1#853
May 20 10:34:52 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: query response was nodata ANSWER
May 20 10:34:52 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: reply from <.> 1.0.0.1#853
May 20 10:34:52 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: query response was nodata ANSWER
May 20 10:34:52 	unbound 	6706:2 	info: reply from <.> 1.0.0.1#853
May 20 10:34:52 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: query response was CNAME
May 20 10:34:52 	unbound 	6706:2 	info: reply from <.> 1.1.1.1#853
May 20 10:34:52 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: query response was CNAME
May 20 10:34:52 	unbound 	6706:3 	info: reply from <.> 1.0.0.1#853
May 20 10:34:52 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:2 	info: query response was nodata ANSWER
May 20 10:34:52 	unbound 	6706:2 	info: reply from <.> 1.0.0.1#853
May 20 10:34:52 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:52 	unbound 	6706:3 	info: query response was nodata ANSWER
May 20 10:34:52 	unbound 	6706:3 	info: reply from <.> 1.1.1.1#853
May 20 10:34:52 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: query response was CNAME
May 20 10:34:51 	unbound 	6706:2 	info: reply from <.> 1.0.0.1#853
May 20 10:34:51 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: query response was CNAME
May 20 10:34:51 	unbound 	6706:3 	info: reply from <.> 1.1.1.1#853
May 20 10:34:51 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: query response was nodata ANSWER
May 20 10:34:51 	unbound 	6706:2 	info: reply from <.> 1.0.0.1#853
May 20 10:34:51 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: query response was nodata ANSWER
May 20 10:34:51 	unbound 	6706:3 	info: reply from <.> 1.0.0.1#853
May 20 10:34:51 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: query response was CNAME
May 20 10:34:51 	unbound 	6706:3 	info: reply from <.> 1.1.1.1#853
May 20 10:34:51 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: query response was CNAME
May 20 10:34:51 	unbound 	6706:2 	info: reply from <.> 1.0.0.1#853
May 20 10:34:51 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: query response was nodata ANSWER
May 20 10:34:51 	unbound 	6706:3 	info: reply from <.> 1.1.1.1#853
May 20 10:34:51 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: query response was nodata ANSWER
May 20 10:34:51 	unbound 	6706:2 	info: reply from <.> 1.0.0.1#853
May 20 10:34:51 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: query response was CNAME
May 20 10:34:51 	unbound 	6706:2 	info: reply from <.> 1.1.1.1#853
May 20 10:34:51 	unbound 	6706:2 	info: response for coder.show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: query response was CNAME
May 20 10:34:51 	unbound 	6706:3 	info: reply from <.> 1.0.0.1#853
May 20 10:34:51 	unbound 	6706:3 	info: response for coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: validated DNSKEY show. DNSKEY IN
May 20 10:34:51 	unbound 	6706:2 	info: query response was ANSWER
May 20 10:34:51 	unbound 	6706:2 	info: reply from <.> 1.1.1.1#853
May 20 10:34:51 	unbound 	6706:2 	info: response for show. DNSKEY IN
May 20 10:34:51 	unbound 	6706:3 	info: resolving coder.show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: validated DNSKEY show. DNSKEY IN
May 20 10:34:51 	unbound 	6706:3 	info: query response was ANSWER
May 20 10:34:51 	unbound 	6706:3 	info: reply from <.> 1.1.1.1#853
May 20 10:34:51 	unbound 	6706:3 	info: response for show. DNSKEY IN
May 20 10:34:51 	unbound 	6706:2 	info: resolving show. DNSKEY IN
May 20 10:34:51 	unbound 	6706:2 	info: validated DS show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: query response was ANSWER
May 20 10:34:51 	unbound 	6706:2 	info: reply from <.> 1.0.0.1#853
May 20 10:34:51 	unbound 	6706:2 	info: response for show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: resolving show. DNSKEY IN
May 20 10:34:51 	unbound 	6706:3 	info: validated DS show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: query response was ANSWER
May 20 10:34:51 	unbound 	6706:3 	info: reply from <.> 1.0.0.1#853
May 20 10:34:51 	unbound 	6706:3 	info: response for show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: resolving show. DS IN
May 20 10:34:51 	unbound 	6706:2 	info: query response was ANSWER
May 20 10:34:51 	unbound 	6706:2 	info: reply from <.> 1.1.1.1#853
May 20 10:34:51 	unbound 	6706:2 	info: response for coder.show. A IN
May 20 10:34:51 	unbound 	6706:3 	info: resolving show. DS IN
May 20 10:34:51 	unbound 	6706:3 	info: query response was ANSWER
May 20 10:34:51 	unbound 	6706:3 	info: reply from <.> 1.0.0.1#853
May 20 10:34:51 	unbound 	6706:3 	info: response for coder.show. A IN
May 20 10:34:51 	unbound 	6706:2 	info: resolving coder.show. A IN
May 20 10:34:51 	unbound 	6706:2 	info: query response was CNAME
May 20 10:34:51 	unbound 	6706:2 	info: reply from <.> 1.0.0.1#853
May 20 10:34:51 	unbound 	6706:2 	info: response for coder.show. A IN
May 20 10:34:51 	unbound 	6706:3 	info: resolving coder.show. A IN
May 20 10:34:51 	unbound 	6706:3 	info: query response was CNAME
May 20 10:34:51 	unbound 	6706:3 	info: reply from <.> 1.1.1.1#853
May 20 10:34:51 	unbound 	6706:3 	info: response for coder.show. A IN
May 20 10:34:50 	unbound 	6706:2 	info: resolving coder.show. A IN
May 20 10:34:50 	unbound 	6706:3 	info: resolving coder.show. A IN

                Can I presume that this is a DNSSEC misconfiguration somewhere along the line?

                Can I also presume that the Diagnostics -> DNS Lookup page ignores the "Enable DNSSEC Support" setting on the Services -> DNS Resolver page? That would seem to explain why I can resolve from the diagnostics page but not from other hosts on my LAN?

                One more bit of the puzzle… The problem may be intermittent. This is a podcast host. The podcast client on my phone did manage to update podcasts from this host some time overnight. It is configured to only update podcasts over WiFi and I don't think it associated with an outside AP during this time, though I cannot rule this out.

                I've looked at https://dnslookup.org/coder.show/A/#dnssec and don't really understand the output. At the bottom left of the screen I see "Result is Insecure", but I see the same if I lookup google.com.

                What should be my next step?

                johnpozJ 1 Reply Last reply Reply Quote 0
                • johnpozJ
                  johnpoz LAYER 8 Global Moderator @HankB
                  last edited by johnpoz

                  To be honest forwarding and dnssec is kind of pointless.. Your at the mercy of who you forward too do valid dnssec, etc.

                  There is more going on with coder.show than just an dnssec issue.. I show lots of warnings on that

                  coder.show/CNAME (NXDOMAIN): The server responded with no OPT record, rather than with RCODE FORMERR. (64.98.148.13, 216.40.47.26, UDP_0_EDNS0_32768_4096, UDP_0_EDNS0_32768_512)
coder.show/CNAME (NXDOMAIN): The server returned CNAME for coder.show, but records of other types exist at that name.
coder.show/CNAME: The server responded with no OPT record, rather than with RCODE FORMERR. (64.98.148.13, 216.40.47.26, UDP_0_EDNS0_32768_4096)
coder.show/CNAME: The server returned CNAME for coder.show, but records of other types exist at that name.
coder.show/NS: The server responded with no OPT record, rather than with RCODE FORMERR. (64.98.148.13, 216.40.47.26, UDP_0_EDNS0_32768_4096)

                  http://dnsviz.net/d/coder.show/dnssec/

                  I would suggest you try and contact them to FIX their mess..

                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                  If you get confused: Listen to the Music Play
                  Please don't Chat/PM me for help, unless mod related
                  SG-4860 24.11 | Lab VMs 2.8, 24.11

                  H 1 Reply Last reply Reply Quote 0
                  • H
                    HankB @johnpoz
                    last edited by

                    @johnpoz Thanks for the further information. I have asked this question on the unbound mailing list and got the same answer. (I would have posted that here sooner but the site was offline before I left for the weekend and I was not able to log in until this morning.) The discussion on the mailing list can be seen at https://unbound.nlnetlabs.nl/pipermail/unbound-users/2018-May/005237.html

                    One of the responders on the mailing lists filed a bug report against unbound. (https://gitlab.labs.nic.cz/knot/knot-resolver/issues/359) I believe the "bug" is that unbound does not work well with misconfigured sites.

                    I have added exceptions in my configuration for the offending sites. I have also contacted the owner of the sites to notify them of the misconfiguration.

                    To be honest forwarding and dnssec is kind of pointless… Your at the mercy of who you forward too do valid dnssec, etc.

                    I would like to know more about your comment as I don't fully understand it. I'm expecting two benefits from DNSSEC. First the chain of trust will insure that my border device (running pfsense) will not somehow be spoofed into connecting to the wrong DNS server. (*) Second, my DNS queries cannot be snooped by a nosy ISP.

                    Incidentally I've blocked DNS (port 53) for hosts on my LAN to enforce the usage of the pfsense device for DNS service.

                    (*) I see an article about a possible BGP hijack on Hacker News this morning. https://news.ycombinator.com/item?id=17178905#17179014 Wouldn't DNSSEC prevent my device from connecting to a rogue DNS server?

                    GertjanG 1 Reply Last reply Reply Quote 0
                    • johnpozJ
                      johnpoz LAYER 8 Global Moderator
                      last edited by johnpoz

                      dnssec has zero to do with your isp snooping..

                      dnssec just provides validation that your talking to the correct dns, and the records have been signed by them. When you forward you have your just asking who you forward to to provide you with what they have or what they will "resolve" or "forward" to get said answer.

                      You never actually talk to any authoritative ns for anything, be them signed or not - you never talk to roots to have the dnssec chain validated, etc. So in "theory" who you forward to could hand you anything and even show it validated with dnssec, etc.

                      If you want to validate the records you get then resolve, don't forward.

                      As to a bug with unbound not working with broken dns - how and the F is that a bug?? ;) I will have to read this bug report you linked too.

                      edit: How is that a bug against unbound?? Looks to be a bug with knot.. I didn't see any mention of unbound at all.. unless you mean where it says "breaks validating forwarders which point to kresd."

                      An intelligent man is sometimes forced to be drunk to spend time with his fools
                      If you get confused: Listen to the Music Play
                      Please don't Chat/PM me for help, unless mod related
                      SG-4860 24.11 | Lab VMs 2.8, 24.11

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

                        @hankb said in DNS not resolving some sites:

                        I would like to know more about your comment as I don’t fully understand it. I’m expecting two benefits from DNSSEC. First the chain of trust will insure that my border device (running pfsense) will not somehow be spoofed into connecting to the wrong DNS server. (*) Second, my DNS queries cannot be snooped by a nosy ISP.

                        This is what the resolver does. It uses the fastest root level (" . ") DNS servers, to drill down to the top TLD (like ".com") that send you over results, the name servers (at least 2 - or more) and these will finally handle your initial DNS request, like what is the A record of example.com.

                        If available, DNSSEC will be used.

                        If root level DNS servers and/or TLD level DNS servers are "hacked", then Internet as a businesses closes down right away.
                        If the name servers of example.com are hacked, well, contact the site admin, because he is running his own DNS, or using the ones offered by his host company. Stay away from example.com a while and you'll be fine.

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

                        1 Reply Last reply Reply Quote 0
                        • H
                          HankB @johnpoz
                          last edited by

                          @johnpoz said in DNS not resolving some sites:

                          As to a bug with unbound not working with broken dns - how and the F is that a bug?? ;) I will have to read this bug report you linked too.

                          edit: How is that a bug against unbound?? Looks to be a bug with knot.. I didn't see any mention of unbound at all.. unless you mean where it says "breaks validating forwarders which point to kresd."

                          FWIW I did not (and would not have) filed the bug. And yes, I think you are correct. It is not against unbound but knot. I had not realized that.

                          thanks,
                          hank

                          1 Reply Last reply Reply Quote 0
                          • johnpozJ
                            johnpoz LAYER 8 Global Moderator
                            last edited by johnpoz

                            Here is the thing - their dns records are not correct... If they expect users to get to them then they need to fix their stuff.

                            Contact them and tell them to FIX it... Clearly its borked... I gave you as site that will validate all kinds of dns, etc. Just look yourself on any other dns checker - they all show that domain being borked!! With multiple problems... I show more problems now with bad glue, etc.

                            An intelligent man is sometimes forced to be drunk to spend time with his fools
                            If you get confused: Listen to the Music Play
                            Please don't Chat/PM me for help, unless mod related
                            SG-4860 24.11 | Lab VMs 2.8, 24.11

                            H 1 Reply Last reply Reply Quote 0
                            • H
                              HankB @johnpoz
                              last edited by

                              @johnpoz said in DNS not resolving some sites:

                              Here is the thing - their dns records are not correct... If they expect users to get to them then they need to fix their stuff.

                              Contact them and tell them to FIX it... Clearly its borked... I gave you as site that will validate all kinds of dns, etc. Just look yourself on any other dns checker - they all show that domain being borked!! With multiple problems... I show more problems now with bad glue, etc.

                              Yes, I have contacted them and I included the link to dnsvis which you kindly provided. I suggested that he forward that to his network engineer. Thing is, I may be the only one complaining. The network owner can resolve all of the hosts so it looks to him like nothing is wrong. Hopefully he will hand this off to someone who understands and can fix it.

                              thanks,
                              hank

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