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

    About blocking DNS 53 on WAN interface

    DHCP and DNS
    4
    6
    484
    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 Former User
      last edited by

      I use and force my DNS request to quad9 using DoT.
      To make sure of that, I followed the NAT recipe and added a block rule on port 53 of the wan interface. Only 853 is allowed.

      When I reboot my pfSense, I can see that it attempted to contact every DNS root servers on UDP 53, which was blocked.

      Can this cause a problem? I don't see any but...

      S 1 Reply Last reply Reply Quote 0
      • ?
        A Former User
        last edited by

        Well!
        This is unexpected: no answer to this?!?
        I'm starting to be concerned...

        keyserK 1 Reply Last reply Reply Quote 0
        • keyserK
          keyser Rebel Alliance @A Former User
          last edited by

          @marchand-guy said in About blocking DNS 53 on WAN interface:

          Well!
          This is unexpected: no answer to this?!?
          I'm starting to be concerned...

          Don’t be. It’s quite normal behaviour. UNBOUND resolver will still attempt to populate it’s root server hints via normal DNS queries (it’s what it is designed for) even though it is in forwarding mode to Quad9 via DoT.

          Love the no fuss of using the official appliances :-)

          1 Reply Last reply Reply Quote 0
          • S
            SteveITS Galactic Empire @A Former User
            last edited by

            @marchand-guy This recipe?
            https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

            A rule on WAN would block incoming connections from the Internet. Which are blocked by default because WAN has no allow rules out of the box.

            Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
            When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
            Upvote 👍 helpful posts!

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

              @steveits said in About blocking DNS 53 on WAN interface:

              A rule on WAN would block incoming connections from the Internet.

              True - unless he was doing a floating rule on wan interface in the outbound direction, which is what I think he was doing.

              A redirection of 53 traffic coming in on your lan side interface might be better. This should prevent any client from using anything other than your dns. And would still allow pfsense to go out on normal 53 for what it might need, for example if your unbound is down, pfsense could still resolve using what you setup is forwarders in just normal dns 53 mode. Clients would be down - but pfsense would still have dns, so your webgui shouldn't stall on you, and you could check for updates and packages, 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.7.2, 24.11

              ? 1 Reply Last reply Reply Quote 0
              • ?
                A Former User @johnpoz
                last edited by

                @johnpoz said in About blocking DNS 53 on WAN interface:

                unless he was doing a floating rule on wan interface in the outbound direction, which is what I think he was doing.

                Exactly what I am doing.
                Everything out on WAN using dest port udp 53 is blocked.

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