A records, PTR records, and TTL setting

[Fred Morris]

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

On Fri, 22 Dec 2023, Jon Murphy via Unbound-users wrote:
> 
> 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

--

Fred Morris, internet plumber

--

[0] https://github.com/m3047/rkvdns
[1] https://github.com/m3047/rear_view_rpz
[2] https://github.com/m3047/rkvdns_examples/tree/main/fanout