<div dir="ltr">From the correct mail alias!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 16 Sept 2023 at 21:50, Greg Choules <<a href="mailto:gregchoules@googlemail.com">gregchoules@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Ged.<div>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.</div><div><br></div><div>Say a user is assigned the address 172.16.1.2 and you want to create a PTR record for that. According to <a href="https://datatracker.ietf.org/doc/html/rfc1034#section-5.2.1" target="_blank">https://datatracker.ietf.org/doc/html/rfc1034#section-5.2.1</a> point 2:<br>>The octets of the IP address are reversed, used as name components, and suffixed with "IN-ADDR.ARPA".</div><div><br></div><div>This designates ARPA as a top level domain and IN-ADDR as a second level domain</div><div>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.</div><div>Thus it is that octets and domains are inextricably linked.</div><div><br></div><div>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.</div><div><br></div><div>I would like to offer an opinion at this point: only create zones if you need them!</div><div>For instance, if one group of people run a single DNS technology, go for the most general domains you can get away with.</div><div><br></div><div>Using 172.16/12 address space as an example you could create up to sixteen zones as follows:</div><div>16.172.in-addr.arpa</div><div>17.172.in-addr.arpa</div><div>...</div><div>31.172.in-addr.arpa</div><div><br></div><div>You may not need all of them.</div><div>PTR records in these zones would look like:</div><div>2.1   PTR   <a href="http://the-first-client.example.com" target="_blank">the-first-client.example.com</a>.</div><div>etc.</div><div><br></div><div>You might be tempted to create zones like the following:</div><div>1.16.172.in-addr.arpa</div><div>2.16.172.in-addr.arpa</div><div>...</div><div><br></div><div><div>The PTR record in the first zone for 172.16.1.2 would look like:</div><div>2   PTR   <a href="http://the-first-client.example.com" target="_blank">the-first-client.example.com</a>.</div><br></div><div>It's a personal choice. But I would keep the zones to a minimum.</div><div><br></div><div>For 10.whatever addresses you have even more choices:</div><div>1) 10.in-addr.arpa</div><div>2) 1.10.in-addr.arpa (and possibly 2.10.. 3.10.. etc.)</div><div>3) 1.1.10.in-addr.arpa (and 2.1.10.. 3.1.10.. etc. etc.)</div><div><br></div><div>With 1) you need one zone.</div><div>With 2) you need up to 256 zones.</div><div>With 3) you need up to 64k zones.</div><div><br></div><div><br></div><div>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.</div><div>For instance, if you use 10.1 in MS land but 10.2, 10.3 and others for non-MS purposes:</div><div><br></div><div>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.</div><div><br></div><div>In BIND, configure 10.in-addr.arpa as a zone. In that zone add the following:</div><div>1  NS  ms-dns1.active-directory-domain.</div><div>1  NS  ms-dns2.active-directory-domain.</div><div>...</div><div>Thus, 10.1 has been delegated to the MS boxes and 10.everything else stays with BIND.</div><div><br></div><div><br></div><div>As a parting shot, IPv6 is a bit more granular; see <a href="https://datatracker.ietf.org/doc/html/rfc8501" target="_blank">https://datatracker.ietf.org/doc/html/rfc8501</a></div><div>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.</div><div><br></div><div>That's me done for the night. I hope some of that makes sense.</div><div>Cheers, Greg</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 16 Sept 2023 at 10:23, G.W. Haywood via bind-users <<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi there,<br>
<br>
On Sat, 16 Sep 2023, Greg Choules wrote:<br>
> On Sat, 16 Sep 2023,  G.W. Haywood wrote:<br>
> ...<br>
> > Is there a reason not to split the /8 into two /9s or something like that?<br>
> ...<br>
> Although it is technically possible to do reverses on non-octet boundaries<br>
> (for example, see <a href="https://www.ietf.org/rfc/rfc2317.txt" rel="noreferrer" target="_blank">https://www.ietf.org/rfc/rfc2317.txt</a>) it is a<br>
> complete pita, in my experience. Personally I would not head down that<br>
> path. Stick to /8, /16 or /24.<br>
<br>
Please could you elaborate a bit?<br>
<br>
Does RFC1918's 172.16/12 mark a special case, or is that a PITA too?<br>
I've used such addresses, but never at anything like their full scale.<br>
<br>
My "something like" might have included 10.16.0/12 and <a href="http://10.24.0.0/12" rel="noreferrer" target="_blank">10.24.0.0/12</a>,<br>
is your PITA comment equally applicable?  I'd be surprised if the OP<br>
couldn't manage with 2^20 IPs in a segment - but then I guess he does<br>
work in the .gov domain.<br>
<br>
I'm not trying to be awkward, I'd really like to know in case I ever<br>
come up against this myself.<br>
<br>
(And it's the thirtieth anniversary of RFC1517.  What did we miss? :)<br>
<br>
-- <br>
<br>
73,<br>
Ged.<br>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>
</blockquote></div>