Happy holidays...
On Sun, 24 Dec 2023, Jon Murphy via Unbound-users wrote:
[...]
With a simple network (well defined, eh?) I am guessing it does not matter.
It doesn't matter has long as you have one address per name. X-D
I can have one A and one PTR record per network interface.
You forget about the name in that algebra.
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.
The name in that construction doesn't distinguish between interfaces.
Are both interfaces accessible, everywhere? If not, then half of the
attempts to reach deb12dell (using the A records) will initially fail.
What happens after that depends on the software. There is no way to query
for just one of the A records (unless you set up views or split horizon
DNS), the software attempting to connect will have to decide which address
to try, and whether or not to try them both.
You've confounded the PTR record case (by using an intentionally
unresolvable-on-the-internet name) making it more difficult to discuss,
although I'm less concerned about it. Going back to the case of a mail
server (a reminder, this isn't in the mail protocol, it's something people
do as a practical test for legitimacy), as long as there's only one A
record for a name it doesn't matter how many PTR records resolve to it
because they'll never be enumerated by any normal DNS query:
example.com. MX 10 server.example.com.
server.example.com. A 10.0.1.111
111.1.0.10.in-addr.arpa. PTR server.example.com.
112.1.0.10.in-addr.arpa. PTR server.example.com.
In case you wanted to encode some reliable identity information in the
name (there be dragons! a file share would be a bad application of this,
at least without some other authentication / access controls) let's say a
file share that is only accessible to the "downtown" office you could have
a whole bunch of PTR records resolving to downtown.office.localdomain, the
A records don't have to agree with the PTR records for that purpose:
joe.downtown.example.com. A 10.0.0.22
jean.downtown.example.com. A 10.0.0.28
22.0.0.10.in-addr.arpa. PTR downtown.example.com.
28.0.0.10.in-addr.arpa. PTR downtown.example.com.
There are two different ways some sort of access control can work in the
above scenario, and it's up to the server architect how it works:
1) You list joe.downtown.example.com and jean.downtown.example.com as
permitted. When the service starts it performs A record lookups and
stores the addresses 10.0.0.22 and 10.0.0.28 internally. When a
connection attempt is made, it compares the client's address with
10.0.0.22 amd 10.0.0.28 to see if it's one of those.
2) You list downtown.example.com as permitted. This FQDN is read, but no
lookups are performed at service startup. When a connection attempt is
made, a PTR lookup is performed for the address and it compares the
FQDN with what it stored at startup.
(I see you picked up on the need for the trailing dot, good for you!)
Kind of depends on your use case, or application; it's usually not
configurable. There are three questions to ask:
1) Is the A record compared to the PTR record for identity?
2) Is the A record query made at startup, and the address recorded and
used going forward?
3) Is the PTR record query made at access time?
--
Fred Morris
