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

    Unbound, DNSSEC, and co.uk domains

    Scheduled Pinned Locked Moved DHCP and DNS
    13 Posts 3 Posters 1.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.
    • R
      rjorgenson
      last edited by

      I noticed lately that I am unable to resolve any co.uk domain names against unbound in pfSense with DNSSEC enabled. Here is query level log output of trying to lookup google.co.uk - https://pastebin.com/y4CCBws8

      The domain lookup is successful in Diagnostics -> DNS Lookup wether DNSSEC is enabled or not, but lookups against 192.168.1.1 return nothing when it is enabled.

      #: dig @192.168.1.1 google.co.uk
      
      ; <<>> DiG 9.10.6 <<>> @192.168.1.1 google.co.uk
      ; (1 server found)
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11563
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
      
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 4096
      ;; QUESTION SECTION:
      ;google.co.uk.			IN	A
      
      ;; Query time: 547 msec
      ;; SERVER: 192.168.1.1#53(192.168.1.1)
      ;; WHEN: Sun Aug 19 06:43:38 MST 2018
      ;; MSG SIZE  rcvd: 41
      

      This does not happen with other double TLD's as far as I can tell, for example google.co.nz lookup works with DNSSEC enabled. I did confirm the same behavior with other .co.uk domains as well, so it's not specific to google.co.uk - they all exhibit the same behavior. I've tried both with "Harden DNSSEC Data" and without and get the same result with both settings. Anyone have any idea what I might be doing wrong here?

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

        @rjorgenson said in Unbound, DNSSEC, and co.uk domains:

        google.co.uk

        resolves here
        <<>> DiG 9.12.2 <<>> google.co.uk
        ;; global options: +cmd
        ;; Got answer:
        ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11508
        ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

        ;; OPT PSEUDOSECTION:
        ; EDNS: version: 0, flags:; udp: 4096
        ;; QUESTION SECTION:
        ;google.co.uk. IN A

        ;; ANSWER SECTION:
        google.co.uk. 300 IN A 172.217.1.35

        ;; Query time: 203 msec
        ;; SERVER: 192.168.3.10#53(192.168.3.10)
        ;; WHEN: Sun Aug 19 10:12:54 Central Daylight Time 2018
        ;; MSG SIZE rcvd: 57

        But I do show them with formerror problems - so they prob have an issue with edns/dnscookies

        http://dnsviz.net/d/google.co.uk/dnssec/

        Your version of of dig is a dated and I don't think it supports dnscookies.. which I believe were enabled in 9.11

        Yeah they clearly have some issues
        https://ednscomp.isc.org/ednscomp/044369457e

        Are you actually resolving - or do you have unbound forwarding?

        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
        • R
          rjorgenson
          last edited by

          Unbound is set to forward and I have 1.1.1.1 configured as the upstream. I tested the lookup using the same tools against 1.1.1.1 and the domains resolved as expected. I tried turning off forwarding and the domains I tested previously all resolve now. So I can either turn off DNSSEC or disable forwarding and the lookups will work but if either are on it fails.

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

            forwarding dnssec is pointless if you ask me.. Either just forward and live with what you get or resolve and use dnssec..

            The whole point of dnssec is to validate the records are correct from authoritative ns.. if your just going to forward and ask 1.2.3.4 you have thrown out the whole point of dnssec validation anyway.. The forwarder your asking could hand you anything it wants..

            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
            • R
              rjorgenson
              last edited by

              I'm not entirely sure if the merits/consequences of doing either, I believe this was the default setting. It has been forever since I originally configured my pfSense though so I can't say for sure. Is there any reason why I would want to forward over resolving myself?

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

                Resolving is always better! ;) You are not handing all your dns queries to someone else and trusting they give you the correct and current IP.

                With resolving you walk down the tree from roots and actually talk to the authoritative ns for what your looking for.. With dnssec you actually validate is in fact the case all the way down from root.

                With forwarding your doing nothing but playing a game of telephone and hoping what you get is correct.. Do what you want, but if your going to forward there is really little reason to ask for dnssec,

                The only reason you would want to forward over resolve is if our on some really bad latency connection, or the connection your on prevents it.. Satellite connection for example is not conducive to resolving.

                Pfsense out of the box resolves with dnssec enabled.. They didn't pick this mode of operation for no reason.

                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
                • R
                  rjorgenson
                  last edited by

                  @johnpoz said in Unbound, DNSSEC, and co.uk domains:

                  With forwarding your doing nothing but playing a game of telephone and hoping what you get is correct.. Do what you want, but if your going to forward there is really little reason to ask for dnssec,

                  Good to know, thanks =]

                  For what it's worth to anyone else who stumbles upon this I tried 9.9.9.9 instead and the domains resolve fine with forwarding and DNSSEC. Seems to be something with the way 1.1.1.1 handles the query.

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

                    You do understand that quad 9 has stated they resolve via dnssec.. So you forwarding dnssec to them is pointless and your just adding to your overall dns traffic for no reason.

                    https://www.quad9.net/faq/#Does_Quad9_implement_DNSSEC

                    If your going to forward there is little reason to ask for dnssec, either the end of the tunnel resolver is going to be using it and not returning an answer per what dnssec is suppose to do.. Or they are not going to do anything with it and just forward it upstream to either another forwarder or a resolver - does this resolver support dnssec? Again you do not know because your at the mercy of who you forwarded your traffic too.. Be it they do what they say they do or not, etc.

                    When you resolve you KNOW exactly what is going on and where your getting the data from - if it fails you can look to why.. When you forward your asking a black box for an answer.. How it got the answer do not actually know, nor do you actually know what they might be doing with said data, etc. etc.

                    Seems to be something with the way 1.1.1.1 handles the query.

                    Welcome to the black box you are forwarding your all your queries too ;)

                    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
                    • R
                      rjorgenson
                      last edited by

                      Yes I understand that, you explained it pretty well. I was just adding more info in case anyone stumbles upon the the issue created by this particular configuration(which as you stated is pointless) with 1.1.1.1 - Just because it's pointless doesn't mean someone else won't run into the issue with that configuration and want to know why. I was unable to find anything using various searches and just trying to leave something someone else might be able to find in the future. I have turned forwarding off personally.

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

                        Then why are did you state you have dnssec enabled when forwarding to quad 9? Doesn't seem like you understand from you doing that.

                        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
                        • R
                          rjorgenson
                          last edited by rjorgenson

                          Because I didn't understand =] I tried the forwarding with quad9 to see if it was an issue specific to 1.1.1.1 or if it was an overall issue with having those two boxes checked in the Resolver configuration. I just felt it was worth writing down for anyone who makes the same poor decisions I did in the future and doesn't understand them. They can find the answer without having to ask someone. I'm no DNS expert. Beyond "this setting makes it use the DNS servers I configured for lookups" I didn't really know what forwarding meant or why I might want it on or off. It's not a decisions I consciously made to use DNSSEC and forward because I think it's the right thing to do. It's just the state my Resolver configuration ended up in, which didn't work which is how I ended up here. Now I have a better idea and hopefully so will the next person.

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

                            Agreed, the more discussion of how dns works the better for the end user.. It seems to be a black box for many of them.

                            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
                            • GertjanG
                              Gertjan
                              last edited by Gertjan

                              Strange indeed :

                              [2.4.3-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: dig @192.168.1.1 google.co.uk
                              
                              ; <<>> DiG 9.11.2-P1 <<>> @192.168.1.1 google.co.uk
                              ; (1 server found)
                              ;; global options: +cmd
                              ;; Got answer:
                              ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60086
                              ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
                              
                              ;; OPT PSEUDOSECTION:
                              ; EDNS: version: 0, flags:; udp: 4096
                              ;; QUESTION SECTION:
                              ;google.co.uk.                  IN      A
                              
                              ;; ANSWER SECTION:
                              google.co.uk.           300     IN      A       216.58.212.131
                              
                              ;; Query time: 167 msec
                              ;; SERVER: 192.168.1.1#53(192.168.1.1)
                              ;; WHEN: Mon Aug 20 07:32:50 CEST 2018
                              ;; MSG SIZE  rcvd: 57
                              

                              Btw : I have "Harden DNSSEC Data" checked

                              The Resolver is working in resolver mode, right (no forwarding) ?

                              edit : stupid me, answered to your initial post - didn't saw the follow up, that completely solved the "issue" already.

                              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
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.