A records, PTR records, and TTL setting

Unbound
1

Hello! Newbie here and I am looking for help with A records and PTR records. I just started learning unbound and came across things that confuse me. I am experimenting with unbound Version 1.18.0. My unbound is for a local network.

I have one device that has two network interfaces (ethernet and Wi-Fi).

I added this Ethernet to unbound:
  deb12dell.localdomain. 60 IN A 192.168.60.175
  175.60.168.192.in-addr.arpa. 60 IN PTR deb12dell.localdomain.

For the 2nd network interface on "deb12dell" I added two more lines. And yes, all seems fine!
  deb12dell.localdomain. 60 IN A 192.168.65.180
  180.65.168.192.in-addr.arpa. 60 IN PTR deb12dell.localdomain.

then...

I read somewhere that I should only have one A record per device (with multiple interfaces). Like this:
  deb12dell.localdomain. 60 IN A 192.168.60.175
  175.60.168.192.in-addr.arpa. 60 IN PTR deb12dell.localdomain.
  180.65.168.192.in-addr.arpa. 60 IN PTR deb12dell.localdomain.

And I read somewhere else I should only have one PTR record per device. Like this:
  deb12dell.localdomain. 60 IN A 192.168.65.180
  180.65.168.192.in-addr.arpa. 60 IN PTR deb12dell.localdomain.
  deb12dell.localdomain. 60 IN A 192.168.65.180

And the above two examples just do not "feel" right.

So my question is:
- should there only be one A Record per device?
- or maybe only one PTR Record per device?

I’ve searched Giggle and I looked through the mailing list but did not find an answer.

2

This isn't specific to Unbound.. Can't help you with the TTL questions.

Hello! Newbie here and I am looking for help with A records and PTR records.

Any time you have multiple RRs (records) the results are "implementation dependent". The only thing you cannot have multiples of is CNAME (a number of DNS server implementations enforce this).

I have one device that has two network interfaces (ethernet and Wi-Fi).
[...]
then...
[...]

Any time you have an oname (FQDN) which resolves to multiple addresses, some application is going to choose the wrong one for reasons you do not comprehend. It is done for load balancing and sometimes failover, but it works poorly unless you wrote the client software as well. This kind of load balancing is oftentimes pushed down the stack with anycast, where server selection is done with routing (different servers all answer at the same address).

That hints at the first problem, which is that sometimes only one address is reachable from a given network / segment.

Unless you want client applications to try both the ethernet and wifi interfaces, don't list them both as the same name. flame.m3047.net has four interfaces. That one is in the public DNS, the other three are published in a private TLD (yes, I enjoy running through the forest naked covered in honey): flame.m3047, wlan0.flame.m3047, eth2.flame.m3047. None of those addresses is reachable from the other ones.

People hate search lists, but maybe it would have been smarter to name the latter two flame.wlan0.m3047 and flame.eth2.m3047 and then if DHCP handed out wlan0.m3047 and eth2.m3047 as the domain depending on which segment a device was connected to, it would be able to pick the correct interface if I simply specified flame (but not flame., an obscure search list thing).

I have another box with two addresses on a single interface because it publishes two DNS services on the same network segment (a "normal" DNS service, and RKVDNS[0] for security telemetry). Technically the box is reachable on either address, but you might not get the answer you expect if you talk to the wrong address. (If you want to SSH to the box you can use either address, but DNS queries obviously return very different results).

And I read somewhere else I should only have one PTR record per device. Like this:

When you're using PTRs for on-label purposes technically multiple PTRs are allowed, but it causes problems for how they are used. PTR records are widely used for crappy security, but sometimes that's all there is.

For instance NFS, if you have multiple PTRs and you use host based access controls you need to list them all. Email servers are vetted by peers based on the PTR and A / AAAA records validating each other, which breaks with multiple PTRs.

I mentioned elsewhere that you can only ever have one CNAME, and since PTRs are built the same way they're sometimes utilized for off-label purposes (such as fanout[2]).

Another issue with PTRs and CNAMEs is that the PTR typically points to what the CNAME points to (if there is any PTR at all), which isn't all that helpful. I use Dnstap telemetry to populate a Response Policy Zone with PTR records reflecting the name which was actually looked up[1].

As part of my RPZ implementation I (also) follow best practices and have both a white and a block list. When I whitelist stuff it's often in some cesspool like cloudfront, so I create -owner PTR records as documentation: DE6F7G5I6V6QF.CLOUDFRONT.NET-OWNER.whitelist.m3047.net. 600 IN PTR UMBRELLA.COM.

[...]
I’ve searched Giggle and I looked through the mailing list but did not find an answer.

I use Gmrgle, but you be you. :-p

3

Hello Fred - thank you for the quick response!

Being a newbie I am not sure I understand your response. This is over my head. I’ll read it again after the holidays.

It sounds like the answer to my questions is -> it matters when it matters. As you said it is "implementation
dependent".

With a simple network (well defined, eh?) I am guessing it does not matter. I can have one A and one PTR record per network interface. So for my "deb12dell.localdomain" device, it is OK to have "two" or each, like this:

deb12dell.localdomain. 60 IN A 192.168.60.175
175.60.168.192.in-addr.arpa. 60 IN PTR deb12dell.localdomain.
deb12dell.localdomain. 60 IN A 192.168.65.180
180.65.168.192.in-addr.arpa. 60 IN PTR deb12dell.localdomain.

Thank you!

Merry Christmas / Happy Holidays,

Jon

4

IMHO these are not issues concerning unbound but rather understanding of DNS in general. So maybe this is not the right forum.

To answer your question, what you are suggesting is not normally done. But it doesn’t necessarily generate errors. You need to know what you are doing / what goal you want to achieve.

If you are declaring two identical A records pointing to different IP addresses, then the resolved IP will randomly be chosen between all entries. It can be used as a load-balancer for the poor.

Usually you have one IP (and one name) per interface. It doesn’t matter what “device” that interface belongs to.

Very often people use “service names” to point to some IP and then the name of the actual host the IP is assigned to is used in the reverse lookup.

I.e.
accounting CNAME acc01prd
acc01prd IP 1.2.3.4
1.2.3.4 PTR acc01prd

So you don’t use the cryptic hostname to access the service, but if you do a reverse lookup you find out where the IP is hosted.

But it all depends on what you want to accomplish.

5

Comments below…

Jon

IMHO these are not issues concerning unbound but rather understanding of DNS in general. So maybe this is not the right forum.

This is my first time experimenting with DNS (though I have been experimenting with RPZ)..

What is the right forum?

To answer your question, what you are suggesting is not normally done.

That is the main thing I want to know! What is normally done!

But it doesn’t necessarily generate errors. You need to know what you are doing / what goal you want to achieve.

I am trying to add devices (clients) to unbound DNS. Most have one network interface and a few have two interfaces.

If you are declaring two identical A records pointing to different IP addresses, then the resolved IP will randomly be chosen between all entries. It can be used as a load-balancer for the poor.

That makes sense! I had not heard this before (and I had not considered it). This helps - Thank you!

Usually you have one IP (and one name) per interface. It doesn’t matter what “device” that interface belongs to.

Very often people use “service names” to point to some IP and then the name of the actual host the IP is assigned to is used in the reverse lookup.

I.e.
accounting CNAME acc01prd
acc01prd IP 1.2.3.4
1.2.3.4 PTR acc01prd

So when loading the up unbound-control list_local_data or even writing line(s) to “/etc/unbound/dhcp-leases.conf”, what is the proper way to add the 1st network interface and the 2nd network interface.

This is my current items:
deb12dell.localdomain. 60 IN A 192.168.60.175
175.60.168.192.in-addr.arpa. 60 IN PTR deb12dell.localdomain.

deb12dell.localdomain. 60 IN A 192.168.65.180
180.65.168.192.in-addr.arpa. 60 IN PTR deb12dell.localdomain.

What would the the proper way?

Can CNAMES be added to a “/etc/unbound/dhcp-leases.conf” file?

So you don’t use the cryptic hostname to access the service, but if you do a reverse lookup you find out where the IP is hosted.

But it all depends on what you want to accomplish.

Thank you! The above does help!

6

You don’t add devices. DNS does not know what a “device” is. It’s like a phonebook, it assigns names to numbers and doesn’t care if some live in the same house or not.

What is the proper way? I explained it. Usually, the proper way is to avoid assigning different IP addresses to the same name.

In your specific case, use names like
Deb12dell-eth0 ↔ ip1
Deb12dell-eth1 ↔ ip2
Make the names unique.

I think DNS may be treated in networking forums. Unbound is an implementation of a dns server, besides bind and many others. Once you know what you want to do with DNS, only then can you choose what server you want to use, and then find out how to configure it. You may be doing this the wrong way by trying to configure a server without understanding the protocol.

7

What they said.

8

Hi,

I think you may want to think about this from a slightly different angle. Rather than “what entries should my device have in DNS?”, you might want instead to ask:

  • “by what name(s) do I want other hosts to be able to connect to this device?” (A records)
  • “When other hosts see connections from this device, if they try to look up the name of that IP, what name should they see?” (PTR records)

should there only be one A Record per device?

An A record maps a name to one or more IPs. If/When a client looks up “deb12dell.localdomain”, they are probably connecting to it. Why would they connect to this name and what IP do you want them to connect to? If you really want them to get back two IPs and to choose one (probably somewhat randomly, but it’s they who decide), then two A records makes sense. For a single device, that’s a pretty unusual choice.

For a website name like www.foo.com with many redundant servers and IPs, it’s pretty common to put multiple IPs behind a single name and let the clients choose. It allows a form of load balancing and even allows some clever clients to retry if the first IP they try fails quickly.

In your case, I would probably only create an A record for the wired connection, on the assumption I don’t want anyone connecting via the wireless connection which is typically slower and less reliable. If I want to explicitly be able to connect via the wireless connection, I would probably make up a second name. If the answer depends on what network the client is connecting from or some other information, things get complicated.

or maybe only one PTR Record per device?

A PTR record maps an IP to a domain name. If a device or system administrator sees a connection from 192.168.60.175 (perhaps in their log files) and looks up DNS to find out the name of that device, what name do you want them to see?

In your case, I would say it’s reasonable and probably helpful to create a PTR for each IP address. The names you return could be the same for both or you could make up names that specify the interface if you like. If you do that, you probably want to make A records that correspond to each name you show in a PTR. There’s no rule that a single device only gets one domain name in DNS - even if a device typically has one canonical name.

How do I set the default TTL for A records and PTR records within unbound.conf??

I don’t see an obvious config option here at a quick scan (searching for the 3600 default).

https://nlnetlabs.nl/documentation/unbound/unbound.conf/

The settings you have tried are directives on what ttl unbound may force when caching answers it receives from other upstream nameservers.

Unbound is not traditionally an authoritative DNS server (one that stores answers). It is a resolver (one that finds answers on behalf of clients and caches them temporarily). You can use it as an authoritative server for your local network, as you are, but that’s not really the primary use case of unbound.

Gavin

9

Happy New Year to everyone. Hope you all had fun over the holidays.

Sorry for my late response - I spent most of the holidays with family and away from the computer. (I tried to stay away from devices as best I could!)

I’ve been reading and re-reading the responses and trying to understand all of the comments. And I am fairly sure I’ve caused most of the confusion with my poor questions and lack of details. I owe you all an apology for that!

10

Hello? Can someone assist?

Or did I make everyone mad? (Sorry if I did!)

Jon

11

Hi Jon,

Based on your quoted text, it looks like you may have missed the
latest emails on this thread from Fred and Gavin.

Perhaps I am mistaken? Here are the mailing list archives for your
perusal:

Do you still have any outstanding questions that have been left
unanswered?

- Otto

12

Thank you! I will look.

13

Hi Gavin,

I apologized for not responding sooner. Otto was helpful and clued me in!

I added these details I should have included in my initial post:
https://lists.nlnetlabs.nl/pipermail/unbound-users/2024-January/008207.html

I am not sure if my update might change your answers below.

My comments are below.

Jon

Hi,

I think you may want to think about this from a slightly different angle. Rather than “what entries should my device have in DNS?”, you might want instead to ask:

  • “by what name(s) do I want other hosts to be able to connect to this device?” (A records)

Since the names (hostnames) are supplied by ISC DHCP, I do not wish to change the names unless that would make things correct or better.

  • “When other hosts see connections from this device, if they try to look up the name of that IP, what name should they see?” (PTR records)

Same response as above.

should there only be one A Record per device?

An A record maps a name to one or more IPs. If/When a client looks up “deb12dell.localdomain”, they are probably connecting to it. Why would they connect to this name and what IP do you want them to connect to? If you really want them to get back two IPs and to choose one (probably somewhat randomly, but it’s they who decide), then two A records makes sense. For a single device, that’s a pretty unusual choice.

Thank you! This helps. So based on the new information I posted on January 1, I think this is OK. Is it really OK?

deb12dell.localdomain. 60 IN A 192.168.60.175 (for the Ethernet connection)

deb12dell.localdomain. 60 IN A 192.168.65.180 (for the Wi-FI connection)

For a website name like www.foo.com with many redundant servers and IPs, it’s pretty common to put multiple IPs behind a single name and let the clients choose. It allows a form of load balancing and even allows some clever clients to retry if the first IP they try fails quickly.

In your case, I would probably only create an A record for the wired connection, on the assumption I don’t want anyone connecting via the wireless connection which is typically slower and less reliable. If I want to explicitly be able to connect via the wireless connection, I would probably make up a second name. If the answer depends on what network the client is connecting from or some other information, things get complicated.

Again, Thank you! This too helps!

There are some wireless to wireless connections. There are a few interactions between wireless devices (like an iPhone to a wireless device).

And I could have a wireless-only laptop device (in the 192.168.65.0/24 subnet) connecting to a device that is on both Ethernet and Wireless (like the deb12dell device). I would connect to both devices via wireless.

So for the moment I am a little confused.

Since I receive the wireless hostname deb12dell (and IP 192.168.65.180) from DHCP, should I change this to deb12dell-1? Or just leave as-is. This is on the Wi-Fi side.

And so knowing this, I think I need to two A Records. But I am not sure (thus the confusion on my part)

I know the DCHP was not known in your response. So the confusion is my own fault.

or maybe only one PTR Record per device?

A PTR record maps an IP to a domain name. If a device or system administrator sees a connection from 192.168.60.175 (perhaps in their log files) and looks up DNS to find out the name of that device, what name do you want them to see?

I want them to see deb12dell

In your case, I would say it’s reasonable and probably helpful to create a PTR for each IP address. The names you return could be the same for both or you could make up names that specify the interface if you like. If you do that, you probably want to make A records that correspond to each name you show in a PTR. There’s no rule that a single device only gets one domain name in DNS - even if a device typically has one canonical name.

Again more confusion on my part… I need to learn about CNAME so I understand your comment.

How do I set the default TTL for A records and PTR records within unbound.conf??

I don’t see an obvious config option here at a quick scan (searching for the 3600 default).

https://nlnetlabs.nl/documentation/unbound/unbound.conf/

The settings you have tried are directives on what ttl unbound may force when caching answers it receives from other upstream nameservers.

Unbound is not traditionally an authoritative DNS server (one that stores answers). It is a resolver (one that finds answers on behalf of clients and caches them temporarily). You can use it as an authoritative server for your local network, as you are, but that’s not really the primary use case of unbound.

Thank you! I dug through the GitHub unbound code for the number 3600 and could not find the setting.

I’ll keep reading about DNS and authoritative DNS servers just so I understand.

Thanks again (and again!)
Jon