Bypassing DNSBL for specific IPs



  • Not sure if this has been posted before but just figured out views are possible in Unbound 1.6 and can be used for bypassing DNSBL zones for specific IPs/ranges.

    To do this you need to add some stuff to the custom unbound options:

    
    server:
        access-control-view: 192.168.0.2/32 bypass
        access-control-view: 192.168.0.0/24 dnsbl
    view:
        name: "bypass"
        view-first: yes
    view:
        name: "dnsbl"
        view-first: yes
        include: /var/unbound/pfb_dnsbl.*conf
    
    

    Host 192.168.0.2 is able to bypass all pfBlockerNG inserted DNSBL zones but is able to resolve other local zones e.g. DHCP added zones. Everything else on the 192.168.0.0/24 subnet gets blocked as normal through DNSBL.

    Would be neat for pfBlockerNG to be able to create multiple conf files so that different views could utilize different sets of block lists.

    P.s. not sure if the multiple Zones are actually necessary - Unbound experts let me know if this can be improved ;) Also, documentation for "view-first" seems quite confusing. How I understand it is that if left in the default state "no" none of the "global" local zones are respected and only zones configured in the view are used.



  • Thanks. If this works, I can turn DNSBL back on and exclude the one host. Kudos to you.

    Update:
    I seem to can't get it to work.  When I added the custom commands to DNS Resolver (modified for my networks) DNSBL does not block ads.

    I will have to read up on the unbound custom views.



  • The OP's suggested config works for me. I melded it with Cloudflare's recent DNS-over-TLS commands as well to have a more robust configuration.

    In case anyone's interested, here are my commands:

    
    server:
        access-control-view: <excluded dnsbl="" subnet="">bypass
        access-control-view: <included dnsbl="" subnet="">dnsbl
        ssl-upstream: yes
        do-tcp: yes
        minimal-responses: yes
        prefetch: yes
        qname-minimisation: yes 
        rrset-roundrobin: yes
    forward-zone:
        name: "."
        # Below 4 addresses are Cloudflare DNS
        forward-addr: 1.1.1.1@853
        forward-addr: 1.0.0.1@853
    view:
        name: "bypass"
        view-first: yes
    view:
        name: "dnsbl"
        view-first: yes
        include: /var/unbound/pfb_dnsbl.*conf</included></excluded> 
    


  • This method is just not working for me  :(  I am trying to block all except host 10.168.2.157, but as soon as I add the configuration to the DNS Resolver custom options, DNSBL stops working although it is still running without errors.  I get no more DNSBL alerts and ads shows up on all my hosts.

    Here is my DNS Resolver (unbound) custom options:

    
    server:
        access-control-view: 10.168.2.157/32 bypass
        access-control-view: 10.168.0.0/16 dnsbl
        do-tcp: yes
        minimal-responses: yes
        prefetch: yes
        qname-minimisation: yes 
        rrset-roundrobin: yes
    view:
        name: "bypass"
        view-first: yes
    view:
        name: "dnsbl"
        view-first: yes
        include: /var/unbound/pfb_dnsbl.*conf
    
    


  • Revisiting this thread as I needed to exclude my Roku devices on my network as they need to reach ad sites for the news feeds to work. (sucks) Getting it to work has raised some questions that maybe others can chime in on and maybe my configuration / findings may help others.

    I am using Cloudflares DNS over TLS hence the forward-zone configuration. In addition I run a Plex server at home and need to define the private-domain to allow internal resolution to a private IP address.

    I have three Roku devices that use the "bypass" view
    Everything else on my three network segments uses DNSBL to block ads.
    I have native IPv6 and hence need to add access control as some hosts use IPv6 for DNS transport.
    There are a number of host overrides configured to resolve private IP addresses and hidden hosts from the internal Intranet and not use the public IP addresses resolved by my external NS.
    Example of my custom options: -

    server:
    private-domain: "plex.direct"
    access-control-view: 192.168.1.51/32 bypass
    access-control-view: 192.168.1.61/32 bypass
    access-control-view: 192.168.1.83/32 bypass
    access-control-view: 2601:abcd:abcd:abc0::/64 dnsbl
    access-control-view: 2601:abcd:abcd:abc1::/64 dnsbl
    access-control-view: 2601:abcd:abcd:abc2::/64 dnsbl
    access-control-view: 192.168.1.0/24 dnsbl
    access-control-view: 192.168.2.0/24 dnsbl
    access-control-view: 192.168.3.0/24 dnsbl
    rrset-roundrobin: yes
    forward-zone:
    name: "."
    forward-ssl-upstream: yes
    # Cloudflare DNS
    forward-addr: 1.1.1.1@853
    forward-addr: 1.0.0.1@853
    forward-addr: 2606:4700:4700::1111@853
    forward-addr: 2606:4700:4700::1001@853
    view:
    name: "bypass"
    view-first: yes
    #include: /var/unbound/host_entries.conf
    view:
    name: "dnsbl"
    view-first: yes
    include: /var/unbound/host_entries.conf
    include: /var/unbound/pfb_dnsbl.*conf
    

    What I have found is if I use a 192.168.0.0/22 mask (CIDR) for the IPv4 subnets it does not work, I instead had to define each subnet with /24. Maybe a /16 would have worked?

    Same problem with IPv6. (note, the examples mask my real IPv6 prefix), I had to define multiple /64's as a single /62 did not work.

    The dnsbl view needed to have include: /var/unbound/host_entries.conf otherwise the host overrides did not resolve. For some reason however that was not required for the bypass view, which seems to operate quite happily without the include: hence it is commented out. Not what I expected.

    I also, had a number of issues, that I did not continue confirming exactly the behavior, when trying to format for readability the custom options by indenting some lines using spaces. This caused it to fail. so no leading spaces on any line. :-)

    unbound "view" is not very well documented, but does provide some potential for client specific workarounds that I've needed every now and then. Debug seems limited in the log files regarding matching of access-control-view and which view is being used. Maybe I had too much verbosity enabled and message were deep and I missed them?

    With multiple hosts for testing and having dig/nslookup forced to use IPv4 or IPv6 I was able to finally reproduce what I believe is a working config. Albeit with some configuration options that I don't fully understand why they work how they do. Will see how it goes . . . .

    If anyone can comment on the subnet masks and the include:



  • One topic I keep not seeing is what if you want to block X for all. But by pass Y for a few and still block X.



  • Hi.

    Following this topic, we need to first create the ACL or u put the settings directly on the custom field?

    Regards.



  • @periko Put the settings directly into a custom field, this is the only place the ACLs are defined.

    Reference: https://jpmens.net/2016/12/20/unbound-supports-views-for-local-data/

    My implementation using the information in this post: https://mitky.com/pfblockerng-pfsense-filter-specific-clients-computers-network/



  • I had tested and works, in my layout, I got 2 networks:

    -LAN
    -VLAN

    I setup my vlan not to use the dnsbl and works.

    Thanks guys!!!



  • Hi,

    I too have managed to get this working thanks to the above.

    One question though, if I use DNSBL Category (shallalist) instead of DNSBL Feeds I've noticed that the bypass no longer works.

    I'm guessing this is because the name 'dnsbl' isn't correct when using a category. Any ideas please on the correct syntax? or other cause?

    server:
        access-control-view: 192.168.2.3/32 bypass
        access-control-view: 192.168.2.0/24 dnsbl
        access-control-view: 192.168.1.0/24 dnsbl
    view:
        name: "bypass"
        view-first: yes
    view:
        name: "dnsbl"
        view-first: yes
    server:include: /var/unbound/pfb_dnsbl.*conf
    

    Thanks



  • @yeleek Try removing the second 'server' from your options here. Your custom options should look like:

    server:
        access-control-view: 192.168.2.3/32 bypass
        access-control-view: 192.168.2.0/24 dnsbl
        access-control-view: 192.168.1.0/24 dnsbl
    view:
        name: "bypass"
        view-first: yes
    view:
        name: "dnsbl"
        view-first: yes
        include: /var/unbound/pfb_dnsbl.*conf
    

    I've also noticed more problems with this when trying to set view 'bypass' for specific addresses inside of a subnet that is also a member of your 'dnsbl' view. I can't confirm whether this is actually an issue or just misconfiguration on my part, but I'd try the above and see if it works for you, even temporarily.



  • @kevinmitky That appears to be working for now. Thank you :)



  • @yeleek Please note, if you do an update, disable and re-enable DNSBL that line will be modified again back to the standard entry. You will need to check each time and remove any leading "server:" to ensure your expected behavior works as expected.

    Just an FYI as it caught me out and is now part of my standard checks following any modifications to the configuration of my pfSense

    @ kevinmitky I am doing exactly what you described. I have my dnsbl view as the subnets and am specifying specific hosts on those subnets to bypass. These are Roku's devices that had news feeds that used block sites and I made a choice to allow it access for the convenience. Ensuring the host specific acl was before the subnet based ones was something I just do based on my background, but if you don't have it in that order, maybe that's an area to check. That and having to clear any host DNS caches made this a little more time consuming to test if I screwed up the config on pfSense :-)


Log in to reply