A records, PTR records, and TTL setting

[Jon Murphy]

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


> On Jan 10, 2024, at 12:11 PM, Fred Morris <m3047-unbound-b3u at m3047.net> wrote:
> 
> 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.
> 
> DNS is a database which happens to be utilized in multiple, quirky, incompatible ways by various software, even with as simple of a story as "name and address association". You have to know about the story and the software to make a determination, in pretty much every circumstance. (MySQL as a backing store for the BIND nameserver is different than MySQL as a virtual table lookup for Postfix the mailserver, which is different than an ERP solution relying on MySQL.)
> 
> Took these two quotes out of context to make a point:
> 
>> For me, there is only a LAN or local network.  And only A records and PTR records.
> 
>> Right now there are two interfaces. One ethernet and one wireless.  In the future there could be more.
> 
> 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? Are your feet identical? In spite of your best efforts, does one of the shoes fit one of your feet better? Will you still steadfastly insist on referring to either shoe interchangeably as "a shoe" or "the shoe"? Aren't you shortchanging your decriptive ability to refer to the phenomenon of each shoe being associated with a particular foot? Can you wear both shoes on one foot at the same time? What exactly does "interchangeable" mean in this context? Are the two shoes interchangeable in all senses?
> 
> Suppose you buy a second pair of shoes: is it because you grew more feet? Is it because other people wanted your shoes so much you bought a second pair to loan out? Are you ever going to be using both pairs of shoes at the same time? Will you still steadfastly insist on referring to any of the shoes interchangeably as "a shoe" or "the shoe"? Is the second pair of shoes associated with a particular foot? Are all four shoes interchangeable in all senses?
> 
> Can you imagine any reason at all for referring to "new left shoe" or "old right shoe"? How about for referring to an arbitrary shoe as "the shoe currently known as 'The Shoe'?" due to some additional context? That context could be time, it could be because you're standing on one foot, anything at all; it might not be possible to determine what that is by static analysis of the shoe.
> 
> Naming is a tough problem. ;-)
> 
> On Tue, 9 Jan 2024, Jon Murphy wrote:
>> 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.
> 
> 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. The IP address is utilized for delivery between LANs. Something functionally the same (from the standpoint of IP) happens for Wifi. It is common to have MAC addresses which deliver for unique IP addresses on that LAN, and one MAC address which delivers for pretty much the entire rest of the internet. (Look into ARP and Proxy ARP; know that Proxy ARP is a point solution to a general problem which is usually solved in more general ways, called "routing".)
> 
> I know what ISC and DHCP are; there are several potential pieces of software which fit the intersection of ISC and DHCP. At least one of these pieces of software has the ability to look up a MAC address in a predefined table and always hand out a particular IP address for that MAC; this software also has the capability to hand out an IP address from a pool when the MAC is not found in that lookup table.
> 
> From simplest to understand to more complex and breaking some things to make other things work:
> 
> * Unique A record, unique PTR record.
> 
> * Unique (multiple) A records, all PTR records have the same generic name. (You'd want to make the PTR pretty generic in this case. Yes yes, I know, only one of the A + PTR pairings is idempotent in this scenario... at a given moment in time.)
> 
> * Multiple A records for the same name, all PTR records have the same name. Serious network architecture questions about the purpose and the scope. Multiple LANs. Routing advertisements. F5 and Cisco appliances.
> 
> * Unique A record, unique PTR record. The anycast version. Different machines have the same A record on different LANs, but they all have the same PTR record! F5 and Cisco appliances.
> 
> * Avoid multiple PTR records for the same IP address in the in-addr namespace. (But they're ok for off-label purposes.)
> 
> * Use CNAMEs. Realize that if you have CNAMEs your single PTR record can't do it justice. Resist the impulse to add more PTR records. Move on with your life. PTR records were never intended to solve identity in all cases to begin with.
> 
> --
> 
> Fred Morris, internet plumber