0

Allow list does not bypass blocked TLDs

When blocking a TLD from the security tab, and adding a FQDN to the allow list, the allow list is not honored.

For example, I block '.work' as a TLD. If I add frame.work to my account's allow list, it still does not resolve it.

If I remove the .work TLD block, I can then resolve the frame.work domain again.

Troubleshooting I have done is to clear my DNS cache and restart local network DNS resolvers (Unbound). Doing this when adding to the allow list does not resolve anything. Performing these steps when removing the TLD block works.

I would expect an allow list entry to override TLD blocks because of the following statement at the top of the allow list page:
"Allowing a domain will automatically allow all its subdomains. Allowing takes precedence over everything else, including security features."

11 replies

null
    • Calvin_Hobbes
    • 2 mths ago
    • Reported - view

    "Allowing a domain will automatically allow all its subdomains. Allowing takes precedence over everything else, including security features."

    It works as described  for me.   I have blocked nearly every TLD and make exceptions as needed.

      • LRN
      • 2 mths ago
      • Reported - view

       

      Thanks for the reply.

      To clarify, these are the steps I take:

      1. Go to the Allowlist tab
      2. Add frame.work to the list
      3. Go to the security tab (to clarify, this is not the Denylist tab)
      4. Navigate to the 'Block Top-Level Domains (TLDs)' section
      5. Add the '.work' TLD to the blocked TLDs list
      6. And then be able to resolve the frame.work domain to an IP

      I perform these steps and am unable to resolve frame.work until I remove the blocked TLD from the Security tab.

      If this process works for you, and you have cleared DNS Cache locally, how are you routing DNS requests to NextDNS? I am routing them all through my router using OPNSense and Unbound DNS.

      • Calvin_Hobbes
      • 2 mths ago
      • Reported - view

       I did the steps 1 through 6  (actually skipped 3-5 because .work was already blocked), and I am able to resolve frame.work


      > frame.work
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: frame.work
Address: 104.22.15.240
Name: frame.work
Address: 172.67.27.183
Name: frame.work
Address: 104.22.14.240
Name: frame.work
Address: 2606:4700:10::6816:ff0
Name: frame.work
Address: 2606:4700:10::6816:ef0
Name: frame.work
Address: 2606:4700:10::ac43:1bb7
>

      The only difference is I am running NextDNS locally on my Mac using the configuration profile  (not the app) .    The installation is similar to a router installation but my DNS queries are sent to 127.0.0.1 which is forwarding to the NextDNS servers, like a router would.  I'm not familiar with unbound DNS, but I can't imagine why it would behave differently.   Is it possible there's some additional rules configured within unbound?

      • LRN
      • 2 mths ago
      • Reported - view

       

      Nothing particularly special configured in my Unbound DNS on my router.

      It forwards all requests (excluding my local domain) to NextDNS using DNS over TLS.

      Andy any changes that happen where the TLD is blocked or allowed all happen when I modify settings in NextDNS.

      I ran into the same thing with the steamdb[.]info domain just now. I have an allow list entry for it, but a blocked TLD of .info had to be removed in order for it to work.

      Since you are running DNS locally on your device, and it is working as expected for you, I suspect there is something about Unbound's interaction with the TLD block settings and allowlists configured in NextDNS.

    • Calvin_Hobbes
    • 2 mths ago
    • Reported - view

    That is indeed strange.  For troubleshooting can you switch unbound to use old fashioned plaintext UDP 53 to NextDNS and get a packet capture of UDP 53 of your router’s WAN traffic?

      • LRN
      • 2 mths ago
      • Reported - view

       

      Good advice, it won't be a small task for me at the moment. But I will work on collecting this.

    • beetapplepie
    • 2 mths ago
    • Reported - view

    Just to help out, I have also tested this for you.

    Like Calvin Hobbes, I already have .work blocked in the TLD section of the Security tab. I first tested that frame.work was blocked by trying to browse to it in my web browser. I also verified this against the Nextdns logs and could see that it was blocked. I then added frame.work into the allowlist and I could then browse to frame.work in my web browser, without needing to refresh any DNS cache. I also verified in my Nextdns logs that frame.work was now allowed.

    Check your Nextdns logs to see whether frame.work is being allowed or denied, this will help you determine if the problem is with Nextdns or with your equipment.

      • LRN
      • 2 mths ago
      • Reported - view

       

      Thanks for the additional help.

      I started with just .work in the blocked TLD section.
      I then resolved using a client in my network, which failed to resolve the domain.
      I checked the logs and noticed the logs showed a blocked attempt to resolve the frame.work domain.
      I then added the the the frame.work domain to the allowlist tab.
      I restarted unbound and attempted to resolve the domain.
      I was not seeing an entry show up in the log but was not returning an IP address.

      This prompted me to ensure that the cache was being cleared on restart of Unbound.
      It turns out that it was not being cleared.
      Running these commands on my unbound service cleared the cache appropriately:
       

      unbound-control -c /var/unbound/unbound.conf flush_zone frame.work

      Note: the -c parameter and path are required for my router as the default configuration path is not referenced when accessing from the console for some reason beyond me.

      I then cleared my cache on my local device and I was able to access frame.work.

      I will double check this again using steamdb[.]info. But I believe this may have resolved my issue.

      Possible root cause: A PEBKAC error in not clearing the DNS cache appropriately....

      • LRN
      • 2 mths ago
      • Reported - view

       

      Well I am glad I tried to duplicate the issue with steamdb.info.
      That one remains blocked for me.

      I started with just .info in the blocked TLD section.
      I then resolved using a client in my network, which failed to resolve the domain.
      I checked the logs and noticed the logs showed a blocked attempt to resolve the frame.work domain.
      I then added the the the steamdb.info domain to the allowlist tab.
      I restarted flushed unbound cache for the zone as mentioned in my post above, I cleared the cache in my client.
      And this time I see a log in NextDNS showing an allowed. But I do not return an IP address.
      I'm going to suspect a problem with the Unbound DNS at this point.
      I may have just gotten lucky with the frame.work domain above. Since using the same steps does not reproduce the same results.

    • beetapplepie
    • 2 mths ago
    • Reported - view

    Glad you were now able to pinpoint the issue down further and can rule out NextDns. 
    I’m afraid I don’t know anything about Unbound so I’ll leave you to troubleshoot that further. 
    But just remember that your web browser also has its own dns cache, independent of the OS. 

    • okcprime
    • 1 mth ago
    • Reported - view

    what is your Unbound configurations forward-zone? can you show that.

     

    untill You do not configure you Forward zone in Unbound . unbound will not work properly to over ride local dns 

     

    forward-addr: 45.90.28.0#xxxxxx.dns1.nextdns.io

    forward-addr: 2a07:a8c0::#xxxxxx.dns1.nextdns.io

    forward-addr: 45.90.30.0#xxxxxx.dns2.nextdns.io

    forward-addr: 2a07:a8c1::#xxxxxx.dns2.nextdns.io

     

    including you need to setup NEXTDNS.conf 

Login to reply

Content aside

  • 1 mth agoLast active
  • 11Replies
  • 90Views
  • 4 Following