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-...@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
