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 > On Jan 10, 2024, at 11:18 AM, Jon Murphy <jcmurph...@gmail.com> wrote: > > 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 > > >> On Jan 10, 2024, at 7:37 AM, RayG <rgs...@btinternet.com> wrote: >> >> 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. >> >> >> From: Jon Murphy <jcmurph...@gmail.com> >> Sent: Wednesday, January 10, 2024 4:07 AM >> To: Fred Morris <m3047-unbound-...@m3047.net> >> Cc: unbound-users@lists.nlnetlabs.nl >> Subject: Re: A records, PTR records, and TTL setting >> >> 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 >> >> >> >>> On Dec 25, 2023, at 2:45 PM, Fred Morris via Unbound-users >>> <unbound-users@lists.nlnetlabs.nl> wrote: >>> >>> 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. >> >> 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. >> >> >>> 2) 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. >> >> >>> 3) Is the PTR record query made at access time? >> >> I am not understanding the question. I now there are reverse lookups. >> >> >> Thank you! >> Jon >> >> >> >>> >>> -- >>> >>> Fred Morris >>> >
