Project

General

Profile

Actions

Bug #9586

closed

Unbound Access List /31 UI Issue

Added by matt s almost 5 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
DNS Resolver
Target version:
Start date:
06/15/2019
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

Description

Forum Topic: https://forum.netgate.com/topic/144193/bug-dns-resolver-access-list-31-ui-issue\

Consider the below list of /32s whose queries are to be denied by the DNS Resolver as per the rule policy.

Once attempting to add an additional host to this list, like the below, all the /32s convert to /31s, and you will see the UI does not allow you to revert this back to /32s (happening on multiple browsers). As a result the rules are saved as /31 and 2 hosts are affected by this rule, not one (due to /31). This can be corrected if you re-edit the rule after saving, however to the untrained eye this will cause DNS issues to hosts.


I've noticed this recently as my vCenter Appliance (10.1.1.15) stopped resolving hostnames and lost connection to ESX hosts (via FQDN) once I added my 10.1.1.14 client to the deny ruleset. At some point once I made an edit on this page, the /32s converted to /31s, and the 10.1.1.14 rule also affected 10.1.1.15, my vCenter App.

Is this a known bug? It appears to be very consistent and have noticed it for some time.

Please could some others assist with checking this out on their setups to confirm?

As a feature request, I'd like to see aliases as usable in this menu, is that possible at all?
This will allow us to have more granularity around DNS access lists.

Actions #2

Updated by Jim Pingle almost 5 years ago

  • Status changed from New to Confirmed
  • Assignee set to Anonymous
  • Priority changed from High to Normal
  • Target version set to 2.5.0

I can confirm this, but it doesn't have an obvious cause. If I change line 241 to have a minimum of 1, then /32 stays OK, but an IPv6 /128 address is still cut down to /127

It doesn't seem to happen to NTP restrict lists which use the same mechanism, though.

Actions #3

Updated by Anonymous almost 5 years ago

  • Status changed from Confirmed to Feedback

Fixed by detecting if option list includes /0 or not

Actions #4

Updated by Anonymous almost 5 years ago

  • % Done changed from 0 to 100
Actions #5

Updated by Viktor Gurov over 4 years ago

Steve Beaver wrote:

Applied in changeset 7ec80e763f7e8357a4e5b0d2d57546cfd5d0f0f0.

Tested on 2.5.0.a.20191011.1853

correct now:

# cat /var/unbound/access_lists.conf | grep 3[1-2]
access-control: 127.0.0.1/32 allow_snoop
access-control: 10.10.10.1/32 allow
access-control: 10.1.1.1/32 allow
access-control: 10.1.2.1/31 allow
access-control: 192.168.5.5/32 allow

Resolved

Actions #6

Updated by Jim Pingle over 4 years ago

  • Status changed from Feedback to Resolved
Actions #7

Updated by Jim Pingle over 4 years ago

  • Target version changed from 2.5.0 to 2.4.5
Actions #8

Updated by Jim Pingle over 4 years ago

  • Status changed from Resolved to Feedback

Needs checked and/or tested again on 2.4.5 snapshots

Actions #9

Updated by Viktor Gurov over 4 years ago

Jim Pingle wrote:

Needs checked and/or tested again on 2.4.5 snapshots

tested on 2.4.5.a.20191205.1442_3

Resolved

Actions #10

Updated by Jim Pingle over 4 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF