DNS & IP address management

Thu Sep 23 08:42:31 UTC 2021

I am a noob here and I know we have failed to implement DNS scavenging 
which removes duplicate entries, not sure if its related to your issue. 
But if its not enabled on the dns server this can be troublesome.

Sent via BT Email App
From: Owen DeLong via NANOG <nanog at nanog.org>
Sent: 23 September 2021 02:45:27 BST
To: Joel Sommers <jsommers at colgate.edu>
Cc: nanog at nanog.org
Subject: Re: DNS & IP address management
Many organizations will use their in-addr.arpa zone(s) as an alternative 
form of poor-man’s IPAM.

It looks like you’ve come across some such organizations.

Likely those are simply the free (unassigned) addresses within the 
organization. Likely there are other similar host names in other /24s in 
the same organization if they have more than a /24 of total address 
space.

OTOH, organizations which do this tend to be relatively small as it 
doesn’t scale well to multiple administrators managing the same free 
pool.

Owen

On Sep 22, 2021, at 07:12 , Joel Sommers <jsommers at colgate.edu> wrote:

Hello all -

I am a researcher at Colgate University, working with colleagues at the 
University of Wisconsin and Boston University on studying aspects of the 
DNS.

We're wondering if anyone here would be willing to share some insight 
into an apparent IP address management practice we have observed that is 
evident through the DNS.  In particular, we've seen a number of 
organizations that have a fairly large number of IPv4 addresses 
(typically all within the same /24 aggregate or similar) all associated 
with a single FQDN, where the name is typically something like 
"reserved.52net.example.tld".  Besides the common "reserved" keyword in 
the FQDN, we also see names like "not-in-use.example.tld", again with 
quite a few addresses all mapped to that one name.  The naming appears 
to suggest that this is an on-the-cheap IP address management practice, 
but we are wondering if there are other operational reasons that might 
be behind what we observe.

Thank you for any insights you have -- please feel free to respond 
off-list.

Regards,

Joel Sommers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210923/e149c4da/attachment.html>