Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Networking - DNS - Unbound - Configure Access ======

Control which clients are allowed to make (recursive) queries to the server.

This example assumes that the LAN sits at 192.168.1.0/24.

<file bash /etc/unbound/unbound.conf.d/access_options.conf>
access-control: "0.0.0.0/0" allow
access-control: "127.0.0.0/8" allow
access-control: "192.168.1.0/24" allow
</file>

or

<code>
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: ::0/0 refuse
access-control: ::1 allow
access-control: ::ffff:127.0.0.1 allow
</code>



<WRAP info>
**NOTE:** By default everything is refused, except for localhost.

Options include:

  * **deny** - Drop message.
  * **refuse** - Polite error reply.
  * **allow** - Recursive ok.
  * **allow_setrd** - Recursive ok, rd bit is forced on.
  * **allow_snoop** - Recursive and non-recursive ok.
  * **deny_non_local** - Drop queries unless can be answered from local-data.
  * **refuse_non_local** - Like **<nowiki>deny_non_local</nowiki>** but polite error reply.

</WRAP>


<WRAP info>
**NOTE:**  There are many good reasons for restricting access to your DNS server.

The first one is that a DNS server may be used as part of a denial of service attack.

  * A common technique is to send queries with spoofed IP addresses to exposed recursive DNS servers, which will send their responses to what they think is the computer that made the query in the first place.
  * In practice, it means that an attacker can ask the recursive server for a DNS record using a fake IP, and the owner of the IP address that was faked will get the response.
  * This means that an evil entity can force a recursive server to flood a victim with DNS responses and therefore use the server as a proxy for a denial of service attack.

Another reason is that a local DNS server might contain sensitive DNS entries that are not intended to be known by outsiders.

  * If you are using a local zone for naming local resources, such as printers, cameras, and NAS servers, it is better to have that information protected from outsiders.

In addition to the Unbound configuration presented here, it is a good idea to block access to your DNS server by using appropriate firewall rules.

  * DNS servers listen for queries at port 53 and may support both UDP and TCP.

The **access-control** directives are self-explanatory.

</WRAP>

----

===== Tag access-control =====

Tag **access-control** with a list of tags (in "" with spaces between).

Clients using this access control element use localzones that are tagged with one of these tags.

<code>
access-control-tag: 192.0.2.0/24 "tag2 tag3"
</code>

----

===== Set action for a particular tag =====

Set action for a particular tag for a given access control element if you have multiple tag values

The tag used to lookup the action is the first tag match between **access-control-tag** and **local-zone-tag** where "first" comes from the order of the define-tag values.

<code>
access-control-tag-action: 192.0.2.0/24 tag3 refuse
</code>

----

===== Set redirect data for particular tag for access control element =====


<code>
access-control-tag-data: 192.0.2.0/24 tag2 "A 127.0.0.1"
</code>

----

===== Set view for access control element =====


<code>
access-control-view: 192.0.2.0/24 viewname
</code>

----

===== References =====

https://blog.nlnetlabs.nl/client-based-filtering-in-unbound/