Unbound-users Digest, Vol 48, Issue 5

Unbound
1

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

2

Happy holidays...

[...]
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?

3

Jon,

People have different learning styles. If you're just getting started it's like learning a new language. Some people read Tin Tin or Winnie il Pu; some prefer to go to the cafe or the tavern. Some people get the repair manual written in German or Italian and try to do something simple like change a headlight or the oil.

If it would help I'd be happy to get on a video call sometime in the next week and spend an hour talking about / looking at stuff. (Others are welcome!)

4

Fred,

I am sorry for the late response. Otto informed me to look for your post. Your post made it to my email but then it just sat. Ugh!

Thank you for your response!

I added details I did not include in my initial post:
https://lists.nlnetlabs.nl/pipermail/unbound-users/2024-January/008207.html

And this January 1 update may help.

My comments below,Jon

Happy holidays…

[…]
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.

The info is coming from the ISC-DHCP system I get a hostname and an IP address. I can modify the hostname and make the second item something like deb12dell-1 and then pass that change to unbound.

But this does not feel right…

Right now there are two interfaces. One ethernet and one wireless. In the future there could be more.

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.

For me, there is only a LAN or local network. And only A records and PTR records.

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.

Wow - this is over my head!

(I see you picked up on the need for the trailing dot, good for you!)

Thank you! Based on what I read it seemed like the right thing to make it an absolute path.

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?

Yes.

  1. Is the A record query made at startup, and the address recorded and
    used going forward?

It may or may not be at start-up since my info comes from ISC-DHCP. It could happen, or even change, as devices come and go.

  1. Is the PTR record query made at access time?

I am not understanding the question. I now there are reverse lookups.

Thank you!
Jon

5

I think you have the format wrong:

unbound-control.exe" local_data deb12dell.localdomain 60 A 192.168.60.175

unbound-control.exe" local_data 192.168.60.175.in-addr.arpa. 60 PTR deb12dell.localdomain

Works for me.

6

Interesting - I will give it a try. I don’t know why I included the `IN`. I think I found an example and copied it!

I found I could remove the TTL and that led to my question concerning the default TTL or 3600.

Thank you for the response!

Jon

7

Ugh! It just dawned on me where I saw it.

It was from running the `unbound-control list_local_data` command, and I got a response like this:

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

And so I copied it!

Jon

8

Fred,

Thank you for your response. You’ve given me a lot to ponder and learn!

I can't easily sort out what's quoted and what's a reply, so I'm going to go to what I think is the heart of this.

I have a terrible time reading the same. I thought replying like others did! I’ll change!

Suppose you have a shoe. You can call it "a shoe" or "the shoe".
Suppose you have two shoes, because you have two feet. Are they identical?

I’d like to change the analogy - to a person with two ears. And one head.

The head (brain?, CPU?) knows it is referred to as "deb12dell" because that is what I named her.

She is standing in the doorway to two rooms, The left ear listens to zone Living Room (ethernet). The right ear listens to zone Reading Room (wi-fi).

If someone in the Living Room (ethernet) asks where is she ("deb12dell") located, I expect the answer to be she is at "192.168.60.175".

Does this change the answer?

That is basically my story.

For what it is worth, I don’t plan to change anything related to DHCP. Right now I plan to only work with what I get from DCHP which is the IP address and the hostname. DHCP is another package built and admin'd by someone else.

You've introduced an additional layer of indirection (addressing) without realizing it. The MAC address is used for packet delivery on a LAN; it is sometimes called an "ethernet address" in this context.

I do not believe unbound does anything with MAC addresses. So I let DHCP take care of that and I ignore them from Unbound.

Am I not right?

Jon

9

Hi,

first let me slide out on a tangent, and then say a few words
about what I think this is about:

Suppose you have a shoe. You can call it "a shoe" or "the shoe".
Suppose you have two shoes, because you have two feet. Are they identical?

I'd like to change the analogy - to a person with two ears. And one head.

The head (brain?, CPU?) knows it is referred to as "deb12dell"
because that is what I named her.

Careful with the terminology here :), this reminds me of this
entry from the "fortune" program:

     "... The name of the song is called 'Haddocks' Eyes'!"
     "Oh, that's the name of the song, is it?" Alice said, trying to
   feel interested.
     "No, you don't understand," the Knight said, looking a little
   vexed. "That's what the name is called. The name really is, 'The Aged
   Aged Man.'"
     "Then I ought to have said "That's what the song is called'?"
   Alice corrected herself.
     "No, you oughtn't: that's quite another thing! The song is
   called 'Ways and Means': but that's only what it is called you know!"
     "Well, what is the song then?" said Alice, who was by this time
   completely bewildered.
     "I was coming to that," the Knight said. "The song really is
   "A-sitting on a Gate": and the tune's my own invention."
       -- Lewis Carroll, "Through the Looking Glass"

She is standing in the doorway to two rooms, The left ear
listens to zone Living Room (ethernet). The right ear listens
to zone Reading Room (wi-fi).

If someone in the Living Room (ethernet) asks where is she
("deb12dell") located, I expect the answer to be she is at
"192.168.60.175".

You can name more or less whatever you like in the DNS. You can
name hosts, be they single-homed or multi-homed, or if you have a
need to identify a particular interface on a multi-homed host,
you can name the interface on the host with a distinct name.
It's all up to you, dictated by your needs and what turns out to
be convenient or even necessary.

With that said, multi-homed hosts are IMHO somewhat of a kludge
-- you don't need to change expectations much before they end up
as routers. There's also the matter of whether a multi-homed
host implements the "strong" or "weak" host model. Ref.
https://en.wikipedia.org/wiki/Host_model -- that may influence
whether you want or need to name the individual interfaces.

Best regards,

- Håvard