Re: consolidating in-addr.arpa data
Hi there, On Sat, 16 Sep 2023, John Thurston wrote: A host which auto-registers in MS DNS, creates an A in foo.alaska.gov and PTR in whatever.10.in-addr.arpa. MS DNS is happy to publish those. But the DNS system running on BIND also has a whatever.10.in-addr.arpa zone. So if I want to find the PTR for 13.12.11.10.in-addr.arpa, I must query both DNS systems in turn. If I get NXDOMAIN from both, then I can say the PTR doesn't exist. On each system, I'd like to be able to take the 10.in-addr.arpa data from the other, compute the differences, and incorporate them locally. Then I'll be able to query either system, and accept an NXDOMAIN with confidence. Is there a reason not to split the /8 into two /9s or something like that? Then you'd have no fragmentation (at least not for this reason) and you'd always know who to ask. And since writing my earlier note, I have re-located the code I think I stumbled across earlier Tony Finch's "nsdiff" Does that mean problem replaced, if not solved? -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: consolidating in-addr.arpa data
Hi. 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. Cheers, Greg On Sat, 16 Sept 2023 at 09:20, G.W. Haywood via bind-users < bind-users@lists.isc.org> wrote: > Hi there, > > On Sat, 16 Sep 2023, John Thurston wrote: > > > A host which auto-registers in MS DNS, creates an A in foo.alaska.gov > > and PTR in whatever.10.in-addr.arpa. MS DNS is happy to publish those. > > > > But the DNS system running on BIND also has a whatever.10.in-addr.arpa > > zone. > > > > So if I want to find the PTR for 13.12.11.10.in-addr.arpa, I must query > > both DNS systems in turn. If I get NXDOMAIN from both, then I can say > > the PTR doesn't exist. > > > > On each system, I'd like to be able to take the 10.in-addr.arpa data > > from the other, compute the differences, and incorporate them locally. > > Then I'll be able to query either system, and accept an NXDOMAIN with > > confidence. > > Is there a reason not to split the /8 into two /9s or something like that? > Then you'd have no fragmentation (at least not for this reason) and you'd > always know who to ask. > > > And since writing my earlier note, I have re-located the code I think I > > stumbled across earlier > > > > Tony Finch's "nsdiff" > > Does that mean problem replaced, if not solved? > > -- > > 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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: consolidating in-addr.arpa data
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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: consolidating in-addr.arpa data
On Sat, 16 Sep 2023 10:22:26 +0100 (BST) "G.W. Haywood via bind-users" wrote: > Hi there, > ... >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. ^^^ The OP's contact email is "@alaska.gov". Since the population of Alaska is only about 3/4 million (well below 2^20), I can't imagine that alaska.gov would possibly need more than one 10.0.0.0/8 IPv4 address per person in Alaska. :-) -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: consolidating in-addr.arpa data
>From the correct mail alias! On Sat, 16 Sept 2023 at 21:50, Greg Choules 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@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 kno
