[ snipping ]
On 3/2/21 1:56 PM, Andrew Sullivan wrote:
On Tue, Mar 02, 2021 at 12:10:44PM -0800, Doug Barton wrote:
I think you missed my followup where I indicated that from what I can
see, Verisign is creating host objects for every host mentioned in a
delegation regardless of bailiwick, but not putting glue records into
the zone where they are not needed.
Verisign definitely uses host objects, and _has to_ have a host object
for any name that is referred to as a name server. That's just how EPP
operates.
Yes, I understand that now, thank you for confirming.
I think I didn't actually understand your followup. Is the problem that
there is an out-of-bailiwick host object that has an IP address?
No. The issue I'm concerned about is that there are host records with IP
addresses where the IP addresses used to be relevant because they were
needed for glue, but are not any longer. (I think part of the confusion
here is that some people are conflating host records and glue records.
I'm using "glue" in the strictly DNS sense, as in published in the zone
because the host names the domain is delegated to are in-bailiwick.)
Here is an example similar to one I posted up-thread:
zone example.com
Yesterday, delegated to:
ns1.example.com
ns2.example.com
so glue was needed for these two hosts.
Today, delegated to:
ns1.example.info
ns2.example.info
so no glue is needed.
What I'm concerned about it is that because the host objects for
ns1.example.com and ns2.example.com must (in my situation) remain in the
db because other, legitimate zones are delegated to them; that the
now-stale IP addresses that are associated with those objects are going
to end up in the COM zone, or some other place where they shouldn't be.
For peace of mind I would much rather see the IP addresses in those
host objects removed when they are not needed as glue, rather than
being ignored, since that reduces the chance of a spurious glue record
being published accidentally.
… _how_ would they get "published accidentally"?
If I could tell you that, then we'd just fix that problem and move on,
right? LOL
In what zone?
COM, hopefully that's obvious now from what I mentioned here.
I understand that it's not likely to happen, probably isn't happening
now, etc. But from a data cleanliness standpoint, if you delete the
obsolete IP addresses then there is nothing that COULD leak down the road.
Doug
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
