Clarification Question re: Defining Local Zone Names

[johntdavis84]

Hello!

I'd like to give the devices on my network that use Unbound as their DNS provider names, so I don't have to remember their IPs all the time.

Instructions for this are in the README at https://github.com/MatthewVance/unbound-docker-rpi . However, having not done this before, I find myself a bit cautious about messing with these files.

A couple of questions:

1. When should I use a PTR record, instead of an A record?
2. In the provided example, am I supposed to replace "local-data" with the nickname of the device?
3. Is there any real advantage to using SRV records in this case? What if I use a reverse proxy behind unbound?

Here's the relevant portion of my unbound.conf: (I don't define any forward records, which forces unbound to recursively resolve things on its own ... right?)

Thanks!

 ###########################################################################
     # LOCAL ZONE
     ###########################################################################

     # Include file for local-data and local-data-ptr
     include: /opt/unbound/etc/unbound/a-records.conf
     include: /opt/unbound/etc/unbound/srv-records.conf

     ###########################################################################
     # FORWARD ZONE
     ###########################################################################

     # include: /opt/unbound/etc/unbound/forward-records.conf

Here are my a-records and PTRs:

❯ cat a-records.conf
# SOURCE: https://github.com/MatthewVance/unbound-docker/blob/master/README.md
# File last modified: 2021 07 28

 # A Record
   #local-data: "somecomputer.local. A 192.168.1.1"

 # PTR Record
   #local-data-ptr: "192.168.1.1 somecomputer.local."

And SRVs:

❯ cat srv-records.conf

# Source: https://github.com/MatthewVance/unbound-docker/blob/master/README.md
# Date modified: 2021 07 28

# SRV records
# _service._proto.name. | TTL | class | SRV | priority | weight | port | target.

[MatthewVance]

The DNS RFC goes into more detail and explains this better than I can. Short answer is PTR is the inverse of the a record so input both. You don't need srv.

Local-data is an identifier for the file. Don't change it. It's explained in the unbound.conf man page. Nothing is special about these files. They're simply includes to break allow these standard Unbound settings to be put in a separate file from the overall conf file.

On Wed, Jul 28, 2021, 7:40 PM johntdavis84 @.***> wrote:

Hello!

I'd like to give the devices on my network that use Unbound as their DNS provider names, so I don't have to remember their IPs all the time.

Instructions for this are in the README at https://github.com/MatthewVance/unbound-docker-rpi . However, having not done this before, I find myself a bit cautious about messing with these files.

A couple of questions:

1. When should I use a PTR record, instead of an A record?
2. In the provided example, am I supposed to replace "local-data" with the nickname of the device?
3. Is there any real advantage to using SRV records in this case? What if I use a reverse proxy behind unbound?

Here's the relevant portion of my unbound.conf: (I don't define any forward records, which forces unbound to recursively resolve things on its own ... right?)

Thanks!

###########################################################################

LOCAL ZONE

###########################################################################

Include file for local-data and local-data-ptr

include: /opt/unbound/etc/unbound/a-records.conf

include: /opt/unbound/etc/unbound/srv-records.conf

###########################################################################

FORWARD ZONE

###########################################################################

include: /opt/unbound/etc/unbound/forward-records.conf

Here are my a-records and PTRs:

❯ cat a-records.conf SOURCE: https://github.com/MatthewVance/unbound-docker/blob/master/README.md File last modified: 2021 07 28 A Record

local-data: "somecomputer.local. A 192.168.1.1"

PTR Record

local-data-ptr: "192.168.1.1 somecomputer.local."

And SRVs:

❯ cat srv-records.conf

Source: https://github.com/MatthewVance/unbound-docker/blob/master/README.md

Date modified: 2021 07 28

SRV records

_service._proto.name. | TTL | class | SRV | priority | weight | port | target.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MatthewVance/unbound-docker-rpi/issues/20, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUMHOWDMDRCP5ZILZOY7WLT2CPRNANCNFSM5BFMZ63A .

[MatthewVance]

Hello again,

Apologies for the terse answer yesterday. I'm not on mobile now so I'll attempt a longer, better formatted answer.

When should I use a PTR record, instead of an A record?

I always use them together. An a-record returns the IP address associated with a domain name. A pointer record (PTR) returns the IP address associated with a domain name.

In the provided example, am I supposed to replace "local-data" with the nickname of the device?

No. From unbound.conf documentation:

       local-data: "<resource record string>"
            Configure local data, which is served in reply to queries for  it.
            The query has to match exactly unless you configure the local-zone
            as redirect. If not matched exactly, the  local-zone  type  deter-
            mines  further processing. If local-data is configured that is not
            a subdomain of a local-zone, a transparent local-zone  is  config-
            ured.   For record types such as TXT, use single quotes, as in lo-
            cal-data: 'example. TXT "text"'.

            If you need more complicated authoritative data,  with  referrals,
            wildcards,  CNAME/DNAME  support, or DNSSEC authoritative service,
            setup a stub-zone for it as detailed in the stub zone section  be-
            low.

       local-data-ptr: "IPaddr name"
            Configure  local data shorthand for a PTR record with the reversed
            IPv4 or IPv6 address and the host name.   For  example  "192.0.2.4
            www.example.com".   TTL  can  be  inserted like this: "2001:DB8::4
            7200 www.example.com"

Thus, if you wanted a server with IP of 192.168.1.2 to be have a LAN DNS record of example.lan and another device with IP of 192.168.1.3 to be computer-two.lan, your a-records.conf file would look like:

# A Record
    #local-data: "somecomputer.local. A 192.168.1.1"
    local-data: "example.lan. A 192.168.1.2"
    local-data: "computer-two.lan. A 192.168.1.3"

# PTR Record
    #local-data-ptr: "192.168.1.1 somecomputer.local."
    local-data-ptr: "192.168.1.2 example.lan."
    local-data-ptr: "192.168.1.3 computer-two.lan."

Thus if you did something like dig example.lan, the a-record returned would give you 192.168.1.2. If you did the inverse of dig 192.168.1.2, the PTR would return example.lan.

Is there any real advantage to using SRV records in this case? What if I use a reverse proxy behind unbound?

No. A SRV record servers more of a niche use case. It is explained in details in rfc2782.

I don't really understand this part of the question: What if I use a reverse proxy behind unbound? DNS doesn't care about reverse proxies. DNS main goal is to give IP addresses friendly names. A reverse proxy acts like an intermediary server (for caching, load balancing, http performance, etc.) that front ends web applications such as a flask app behind gunicorn. It doesn't really care about DNS, beyond making use of domain names within the config file to know how to find backends.

A reverse proxy would have its own host name and IP address. Each server or service behind it would have its own domain name and IP address as well (though the IP could technically the same as the reverse proxy's host name if you run the web app as a virtual host or on a different port).

For instance, you may have local web application(s) behind an NGINX reverse proxy and the nginx configuration file would tell nginx where to find those backend server(s), either on the same host or different host(s). A client would talk to the nginx server and nginx would return the content that goes with that domain name by reaching back to those backend virtual hosts or servers (i.e., return results from the server_name in a server block or a server in an upstream block).

As long as you configure your reverse proxy correctly and your a-records/ptr file in Unbound, you should be good to go.

It's been a bit since I've configured NGINX so hopefully I didn't get the details wrong.

(I don't define any forward records, which forces unbound to recursively resolve things on its own ... right?)

That doesn't matter in this context.

The a-records.conf causes Unbound to function as an authoritative name server for the LAN (even though Unbound is never a public authoritative name server like BIND or NSD can be). In other words, if unbound knows example.lan is 192.168.1.2 because it's been configured to know that, it returns that answer immediately (there's no need to forward or recursively resolve anything); no other DNS server it would recurse or forward to would know example.lan is 192.168.1.2.

However, if you ask Unbound for nlnetlabs.nl, it would not be authoritative for that domain. As such, it would recursively look up nlnetlabs.nl by talking to other DNS servers on your behalf regardless if you do or don't have a local-data for some local-zone (a-records.conf). If you happened to be forwarding instead of recursively resolving, not much would change because Unbound will still have to go elsewhere to figure out what IP belongs to nlnetlabs.nl (the only difference is it offloads the recursive work to a public DNS server that is more likely to have the result in its cache already).

[MatthewVance]

If anything further is needed to help answer the questions, let me know. Thanks!