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

    DNS Resolver + DNSSEC + sharepoint.com = SERVFAIL?

    2.2 Snapshot Feedback and Problems - RETIRED
    3
    6
    4.0k
    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.
    • A
      asayler
      last edited by

      I'm running pfSense 2.2-RC Thu Dec 18 22:42:40 build. I'm using the new DNS resolver, and I have DNSSEC enabled on the resolver config page.

      This all seems to be working fine with some domains (e.g. test.dnssec-or-not.net):

      $ dig +noall +comments test.dnssec-or-not.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46060
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

      When I try to resolve sharepoint.com, however, I get a 'SERVFAIL' error on the client:

      $ dig +noall +comments sharepoint.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63579
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

      With the resolver log level set to 2, I get the following resolver logs:

      
Dec 19 17:51:11	unbound: [78646:1] info: Could not establish a chain of trust to keys for sharepoint.com. DNSKEY IN
Dec 19 17:51:11	unbound: [78646:1] info: response for sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: response for sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: response for sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: response for sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: response for sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: response for sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: response for sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: response for sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: response for sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: response for sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. DS IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. A IN
Dec 19 17:51:11	unbound: [78646:1] info: resolving sharepoint.com. A IN
Dec 19 17:43:19	unbound: [78646:0] info: resolving sharepoint.com. A IN
Dec 19 17:43:19	unbound: [78646:0] info: resolving sharepoint.com. A IN

      Turning off DNSSEC support in the resolver options allows me to lookup sharepoint.com without issue (but also without dnssec).

      I'm not sure if this issue effects other domains as well, but sharepoint.com is the first I've stumbled across.

      I'm using Google (8.8.8.8 and 8.8.4.4) as my upstream DNS providers on the pfSense box.

      Any thoughts on what might be going on here? Is this an issue with my setup? Or an issue with sharepoint? Or a bug in pfSense?

      1 Reply Last reply Reply Quote 0
      • J
        jcyr
        last edited by

        Not sure this is relevant, but why would you use upstream DNS with the unbound resolver?

        IPV6 Test: http://ipv6-test.com

        1 Reply Last reply Reply Quote 0
        • A
          asayler
          last edited by

          I have the "Enable Forwarding Mode" box set in the Resolver configuration., I believe this causes the server to forward requests for which it is not the authoritative server to the upstream DNS servers specified in General Setup > DNS Servers.

          That said, I updated to today's snapshot and now it seems to be working. So maybe it was just a temporary glitch.

          1 Reply Last reply Reply Quote 0
          • MikeV7896M
            MikeV7896
            last edited by

            @jcyr:

            Not sure this is relevant, but why would you use upstream DNS with the unbound resolver?

            @asayler:

            I have the "Enable Forwarding Mode" box set in the Resolver configuration., I believe this causes the server to forward requests for which it is not the authoritative server to the upstream DNS servers specified in General Setup > DNS Servers.

            I think what jcyr is saying is… don't forward the requests to another provider. The whole point of having a recursive DNS server like Unbound is that you don't need to use an upstream DNS Server. Unbound is capable of resolving everything itself, talking directly to the DNS Servers for the domain you're looking up, rather than simply forwarding the request to another server (which could result in unintended redirection or incorrect resolution, if the provider wanted to affect a domain's resolution). Keep the Google servers in for the firewall to use in case something happens to Unbound, but there's no reason to have Unbound forward requests to Google's servers.

            The S in IOT stands for Security

            1 Reply Last reply Reply Quote 0
            • A
              asayler
              last edited by

              Yea, I turned off the forwarding option. I originally had it on because I figured the Google servers and their vast caches likely provide faster response then doing full lookups nativly to each root/authoritative name server, at least without any local cache to help you out on a first-time lookup. I'll try without forwarding enabled for a bit and see how it goes. Maybe I'll benchmark the difference at soem point.

              That said, I don't know that forwarding/native was relevant to the original, now disappeared, issue.

              1 Reply Last reply Reply Quote 0
              • MikeV7896M
                MikeV7896
                last edited by

                Not to go too far off-topic, but since you mentioned it…

                GRC actually has a free DNS benchmark utility. It'll pit your server against up to 72 DNS servers operated by major ISPs around the US (some will likely be unreachable as they're for customers of that ISP, but you can remove the unreachable ones by right-clicking in the list).

                You'll likely find that cached resolution time is unbeatable by having your own local recursive DNS server, but other lookups may be just a little slower than a few of the servers. However, keep in mind we're talking milliseconds here. Also, if you commonly visit the same sites over and over, cached lookup might be what you're really interested in anyway. As an example, my system…

                • topped the list in cached performance (0 ms)

                • came out 28th out of 44 in uncached performance (85 ms avg across 50 lookups)

                • placed 17th out of 44 in resolution of uncached .com domains only (72 ms avg across 50 lookups)

                After testing, the right-click menu allows exporting results to a CSV file, which provides a bit more data (min/avg/max) and you can obviously then sort and filter it as you see fit.

                Obviously performance will depend on your ISP's performance and the internet as a whole, since Unbound will be talking to DNS servers all over the world instead of just your ISP or a reliable third-party. I'm plenty happy having Unbound do all the work though.

                The S in IOT stands for Security

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post