consolidating in-addr.arpa data

[Greg Choules]

>From the correct mail alias!

On Sat, 16 Sept 2023 at 21:50, Greg Choules <gregchoules at googlemail.com>
wrote:

> Hi Ged.
> 172.16/12 is not a special case. The whole problem (IMHO) stems from how
> humans have chosen to represent both IP addresses (v4; v6 are different and
> actually a little easier) AND DNS domain names; both using the dot
> character (or full stop or period or whatever it's called in your
> geography) as a separator.
>
> Say a user is assigned the address 172.16.1.2 and you want to create a PTR
> record for that. According to
> https://datatracker.ietf.org/doc/html/rfc1034#section-5.2.1 point 2:
> >The octets of the IP address are reversed, used as name components, and
> suffixed with "IN-ADDR.ARPA".
>
> This designates ARPA as a top level domain and IN-ADDR as a second level
> domain
> What this means in practice is that the first octet of an IPv4 address
> (172 in this example) is a third level domain then there is a dot, which
> not only indicates the transition from octet 1 to octet 2 but also the
> transition from a third level domain to a fourth level domain.
> Thus it is that octets and domains are inextricably linked.
>
> There are a couple of ways you could handle reverses for 172,16/12
> addresses, depending on your addressing scheme, desired flexibility in DNS
> and business policy.
>
> I would like to offer an opinion at this point: only create zones if you
> need them!
> For instance, if one group of people run a single DNS technology, go for
> the most general domains you can get away with.
>
> Using 172.16/12 address space as an example you could create up to sixteen
> zones as follows:
> 16.172.in-addr.arpa
> 17.172.in-addr.arpa
> ...
> 31.172.in-addr.arpa
>
> You may not need all of them.
> PTR records in these zones would look like:
> 2.1   PTR   the-first-client.example.com.
> etc.
>
> You might be tempted to create zones like the following:
> 1.16.172.in-addr.arpa
> 2.16.172.in-addr.arpa
> ...
>
> The PTR record in the first zone for 172.16.1.2 would look like:
> 2   PTR   the-first-client.example.com.
>
> It's a personal choice. But I would keep the zones to a minimum.
>
> For 10.whatever addresses you have even more choices:
> 1) 10.in-addr.arpa
> 2) 1.10.in-addr.arpa (and possibly 2.10.. 3.10.. etc.)
> 3) 1.1.10.in-addr.arpa (and 2.1.10.. 3.1.10.. etc. etc.)
>
> With 1) you need one zone.
> With 2) you need up to 256 zones.
> With 3) you need up to 64k zones.
>
>
> John's issue (I think) is that two sets of people using different
> technologies both want a piece of the 10 pie. So it doesn't make sense that
> both of them have the whole /8. He needs to make a decision about which DNS
> is higher in the pecking order. Personally I would make it BIND.
> For instance, if you use 10.1 in MS land but 10.2, 10.3 and others for
> non-MS purposes:
>
> In MS DNS, configure 1.10.in-addr.arpa as a zone, making sure that the
> automatically created 10.in-addr.arpa gets deleted. All MS clients that
> want to register their 10.1.x.y addresses will submit a dynamic update to a
> DC, which will add it to this 1.10... zone.
>
> In BIND, configure 10.in-addr.arpa as a zone. In that zone add the
> following:
> 1  NS  ms-dns1.active-directory-domain.
> 1  NS  ms-dns2.active-directory-domain.
> ...
> Thus, 10.1 has been delegated to the MS boxes and 10.everything else stays
> with BIND.
>
>
> As a parting shot, IPv6 is a bit more granular; see
> https://datatracker.ietf.org/doc/html/rfc8501
> Since IPv6 addresses are written as hextets separated by colons there is
> no implicit connection with DNS domains. 8501 says that each hex character
> (4 bits) is to be treated as a separate DNS label. This has the potential
> to make the number of zones incredibly huge. The upside is that each level
> in the domain hierarchy now only represents 4 bits rather than 8, so it is
> more granular.
>
> That's me done for the night. I hope some of that makes sense.
> Cheers, Greg
>
> On Sat, 16 Sept 2023 at 10:23, G.W. Haywood via bind-users <
> bind-users at lists.isc.org> wrote:
>
>> Hi there,
>>
>> On Sat, 16 Sep 2023, Greg Choules wrote:
>> > On Sat, 16 Sep 2023,  G.W. Haywood wrote:
>> > ...
>> > > Is there a reason not to split the /8 into two /9s or something like
>> that?
>> > ...
>> > Although it is technically possible to do reverses on non-octet
>> boundaries
>> > (for example, see https://www.ietf.org/rfc/rfc2317.txt) it is a
>> > complete pita, in my experience. Personally I would not head down that
>> > path. Stick to /8, /16 or /24.
>>
>> Please could you elaborate a bit?
>>
>> Does RFC1918's 172.16/12 mark a special case, or is that a PITA too?
>> I've used such addresses, but never at anything like their full scale.
>>
>> My "something like" might have included 10.16.0/12 and 10.24.0.0/12,
>> is your PITA comment equally applicable?  I'd be surprised if the OP
>> couldn't manage with 2^20 IPs in a segment - but then I guess he does
>> work in the .gov domain.
>>
>> I'm not trying to be awkward, I'd really like to know in case I ever
>> come up against this myself.
>>
>> (And it's the thirtieth anniversary of RFC1517.  What did we miss? :)
>>
>> --
>>
>> 73,
>> Ged.
>> --
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>> from this list
>>
>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>> information.
>>
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230916/bff9a197/attachment.htm>