Re: consolidating in-addr.arpa data
On 18. 09. 23 18:02, John Thurston wrote: Yep. I understand the IP space can be delegated, and some of it allocated for use by systems registering in MS DNS. But this isn't going to happen. There are multiple MS Active Directories, with registered machines scattered willy-nilly across the 10-dot address-space, sometimes several competing in the same subnets. The "design and delegate" ship sailed years ago. I don't have a prayer of correctly fixing the underlying problem. After thinking harder, I don't even need correct records in all of the publishers of the various 10.in-addr.arpa zones. My goal now is simpler. Get the PTR-records from the zones handled by ISC BIND into (and out of) one particular MS DNS system. I don't need to get the PTRs registered in MS DNS back into the BIND data. I think I can get where I need to be by leveraging /nsdiff/ No. We won't be correctly publishing accurate PTRs from all of the possible DNS services in the environment. But this is achievable, and will address the problem (of our own making) which is causing pain. FTR one-way synchronization could also leverage IXFR to get list of recent updates. Of course some custom code and possibly nsdiff are in order as fallback when IXFR is not available. -- Petr Špaček Internet Systems Consortium -- 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
Yep. I understand the IP space can be delegated, and some of it allocated for use by systems registering in MS DNS. But this isn't going to happen. There are multiple MS Active Directories, with registered machines scattered willy-nilly across the 10-dot address-space, sometimes several competing in the same subnets. The "design and delegate" ship sailed years ago. I don't have a prayer of correctly fixing the underlying problem. After thinking harder, I don't even need correct records in all of the publishers of the various 10.in-addr.arpa zones. My goal now is simpler. Get the PTR-records from the zones handled by ISC BIND into (and out of) one particular MS DNS system. I don't need to get the PTRs registered in MS DNS back into the BIND data. I think I can get where I need to be by leveraging /nsdiff/ No. We won't be correctly publishing accurate PTRs from all of the possible DNS services in the environment. But this is achievable, and will address the problem (of our own making) which is causing pain. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 9/15/2023 10:55 PM, Greg Choules wrote: This is because (close your ears MS) it assumes it is the only DNS in town. Why would there be another one? If there is one client with a 10.x.y.z address then there are potentially several billion more, so we'll create 10... just to be on the safe side. This makes MS DNS THE source of truth for all 10, so no-one else can have any of it unless you start creating delegations.-- 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
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
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
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, 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 John. Sorry if this sounds picky, but a dot out of place in this game is the difference between success and crash-n-burn. Please can you show me EXACTLY what ...10.in-addra.arpa zones you have in both sets of DNS? >From previous work with AD clients I think that, if it doesn't already exist, MS DNS will auto-create the reverse zone with the class (remember classes?) that matches the client's IP. e.g. if a client comes along saying "I'm 10.1.2.3" then MS DNS will create the /8 or class A reverse zone "10.in-addr.arpa". Not "3.2.1.10..." or "2.1.10..." or "1.10..." but the whole of 10! This is because (close your ears MS) it assumes it is the only DNS in town. Why would there be another one? If there is one client with a 10.x.y.z address then there are potentially several billion more, so we'll create 10... just to be on the safe side. This makes MS DNS THE source of truth for all 10, so no-one else can have any of it unless you start creating delegations. More on that in a bit. So first things first, Is this what happens in your environment? Or something else? Real examples please + screenshots from MS DNS of the list of zones. Screenshots? In a mailing list?? Try it anyway. You can redact hostnames if you like, though they won't mean anything out of context. Secondly, why do you have ...10 in BIND at all? What's its purpose? Next, I would keep it simple. Don't try and replicate data in different places if you don't need to. You COULD use zone transfer, of course, which brings me to my next point... Decide on a policy and stick to it. What data do you want MS DNS to be authoritative for, what data do you want BIND to be authoritative for and where do users send their queries? For example, if AD clients are all assigned addresses from the range 10.1 then MS DNS only needs a zone 1.10..., not 10... The automatic zone creation behaviour can be overridden if you create the zones you need at the start. In a previous life, I wanted ALL clients to query BIND and for MS to be just a database. BIND would be authoritative for 10, MS would be authoritative for (say) 1.10 and 2.10 but NOT 10. BIND would be authoritative for 10 and delegate 1.10 and 2.10 to MS. ALL clients would query BIND, including when performing their dynamic updates to MS. This works because BIND knows who is responsible for all addresses starting 10.1 or 10.2 Long-winded, I know. But I think it's important to understand your end goal before configuration. Cheers, Greg On Sat, 16 Sept 2023 at 01:16, 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. > > And since writing my earlier note, I have re-located the code I think I > stumbled across earlier > > Tony Finch's "nsdiff" > > > https://dotat.at/prog/nsdiff/ > > > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591john.thurs...@alaska.gov > Department of Administration > State of Alaska > > On 9/15/2023 2:21 PM, Greg Choules wrote: > > Hi John. > Can you tell me a bit more please? > - What zones exist in both BIND and MS DNS for something.10.in-addr.arpa? > - Where are hosts auto registering to? I'd guess MS, but it would be good > to confirm. > - What does fragmentation look like? A few real examples would be useful. > I'm trying to understand just what is the problem. > - How much of 10 do you use? > - What do you mean by "...can be published from two different DNS > services."? Could you expand on that please? > - Is there any zone transfer between BIND and MS DNS? > > Thanks, Greg > > On Fri, 15 Sept 2023 at 21:00, John Thurston > wrote: > >> This question involves making our BIND system work with Microsoft's DNS >> software. If this makes it off-topic, let me know and I'll be quiet about >> it. >> >> We use ISC BIND to hold and host most of our zone data. Internally, we >> have delegated some zones, and they are held in Microsoft DNS. These zones >> are used for MS Active Directory 'Domains', and accept auto-registration of >> DNS records from authorized hosts. Because we are using 10-dot addresses >> internally, the auto-registration by hosts causes fragmentation of the >> 10.in-addr.arpa zone data. >> >> I recall someone once offered a bit of code to mash this zone data back >> together, so the same information can be published from two different DNS >> services. I've hunted through this list's archive and have not found the >> reference.
Re: consolidating in-addr.arpa data
You can't resolve differences in both directions automatically without inevitable conflicts, similar to merging code changes. That said, RPZ for fun and profit... On Fri, 15 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. Something in an RPZ will take precedence over what's in the delegated zone. RPZs are zones like any other zone and can be AXFR / IXFRed. The choice of MS DNS taking precendence might be the obvious choice, but the namespace in the RPZ won't be the same (e.g. 1.0.0.10.in-addr.arpa.rpz.example.com): it won't be "naked". So that won't work off the shelf (I know of no option to automagically rewrite the delegating zone). However, if you made BIND a secondary for the MS DNS PTR zone then it should serve it; and you could put BIND-specific edits in an RPZ. Then the BIND-specific values would take precedence over what's in the MS DNS zone, at least as seen when BIND is queried. Rear View RPZ (https://github.com/m3047/rear_view_rpz/) watches (BIND) Dnstap telemetry for A/ queries and uses it to update PTR records in an RPZ, as an example. -- Fred Morris -- 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
Create a 10.in-addr.arpa zone with appropriate delegations and have all servers serve it. That way they can all find te sub zones. -- Mark Andrews > On 16 Sep 2023, at 10:16, 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. > > And since writing my earlier note, I have re-located the code I think I > stumbled across earlier > > Tony Finch's "nsdiff" > > > > https://dotat.at/prog/nsdiff/ > > > > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > On 9/15/2023 2:21 PM, Greg Choules wrote: >> Hi John. >> Can you tell me a bit more please? >> - What zones exist in both BIND and MS DNS for something.10.in-addr.arpa? >> - Where are hosts auto registering to? I'd guess MS, but it would be good to >> confirm. >> - What does fragmentation look like? A few real examples would be useful. >> I'm trying to understand just what is the problem. >> - How much of 10 do you use? >> - What do you mean by "...can be published from two different DNS >> services."? Could you expand on that please? >> - Is there any zone transfer between BIND and MS DNS? >> >> Thanks, Greg >> >> On Fri, 15 Sept 2023 at 21:00, John Thurston >> wrote: >>> This question involves making our BIND system work with Microsoft's DNS >>> software. If this makes it off-topic, let me know and I'll be quiet about >>> it. >>> >>> We use ISC BIND to hold and host most of our zone data. Internally, we have >>> delegated some zones, and they are held in Microsoft DNS. These zones are >>> used for MS Active Directory 'Domains', and accept auto-registration of DNS >>> records from authorized hosts. Because we are using 10-dot addresses >>> internally, the auto-registration by hosts causes fragmentation of the >>> 10.in-addr.arpa zone data. >>> >>> I recall someone once offered a bit of code to mash this zone data back >>> together, so the same information can be published from two different DNS >>> services. I've hunted through this list's archive and have not found the >>> reference. Before I go roll my own, can anyone point me at an existing >>> solution? >>> >>> -- >>> -- >>> Do things because you should, not just because you can. >>> >>> John Thurston907-465-8591 >>> john.thurs...@alaska.gov >>> Department of Administration >>> State of 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 -- 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
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. And since writing my earlier note, I have re-located the code I think I stumbled across earlier Tony Finch's "nsdiff" https://dotat.at/prog/nsdiff/ -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 9/15/2023 2:21 PM, Greg Choules wrote: Hi John. Can you tell me a bit more please? - What zones exist in both BIND and MS DNS for something.10.in-addr.arpa? - Where are hosts auto registering to? I'd guess MS, but it would be good to confirm. - What does fragmentation look like? A few real examples would be useful. I'm trying to understand just what is the problem. - How much of 10 do you use? - What do you mean by "...can be published from two different DNS services."? Could you expand on that please? - Is there any zone transfer between BIND and MS DNS? Thanks, Greg On Fri, 15 Sept 2023 at 21:00, John Thurston wrote: This question involves making our BIND system work with Microsoft's DNS software. If this makes it off-topic, let me know and I'll be quiet about it. We use ISC BIND to hold and host most of our zone data. Internally, we have delegated some zones, and they are held in Microsoft DNS. These zones are used for MS Active Directory 'Domains', and accept auto-registration of DNS records from authorized hosts. Because we are using 10-dot addresses internally, the auto-registration by hosts causes fragmentation of the 10.in-addr.arpa zone data. I recall someone once offered a bit of code to mash this zone data back together, so the same information can be published from two different DNS services. I've hunted through this list's archive and have not found the reference. Before I go roll my own, can anyone point me at an existing solution? -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of 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
Hi John. Can you tell me a bit more please? - What zones exist in both BIND and MS DNS for something.10.in-addr.arpa? - Where are hosts auto registering to? I'd guess MS, but it would be good to confirm. - What does fragmentation look like? A few real examples would be useful. I'm trying to understand just what is the problem. - How much of 10 do you use? - What do you mean by "...can be published from two different DNS services."? Could you expand on that please? - Is there any zone transfer between BIND and MS DNS? Thanks, Greg On Fri, 15 Sept 2023 at 21:00, John Thurston wrote: > This question involves making our BIND system work with Microsoft's DNS > software. If this makes it off-topic, let me know and I'll be quiet about > it. > > We use ISC BIND to hold and host most of our zone data. Internally, we > have delegated some zones, and they are held in Microsoft DNS. These zones > are used for MS Active Directory 'Domains', and accept auto-registration of > DNS records from authorized hosts. Because we are using 10-dot addresses > internally, the auto-registration by hosts causes fragmentation of the > 10.in-addr.arpa zone data. > > I recall someone once offered a bit of code to mash this zone data back > together, so the same information can be published from two different DNS > services. I've hunted through this list's archive and have not found the > reference. Before I go roll my own, can anyone point me at an existing > solution? > > -- > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591john.thurs...@alaska.gov > Department of Administration > State of 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 > -- 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
consolidating in-addr.arpa data
This question involves making our BIND system work with Microsoft's DNS software. If this makes it off-topic, let me know and I'll be quiet about it. We use ISC BIND to hold and host most of our zone data. Internally, we have delegated some zones, and they are held in Microsoft DNS. These zones are used for MS Active Directory 'Domains', and accept auto-registration of DNS records from authorized hosts. Because we are using 10-dot addresses internally, the auto-registration by hosts causes fragmentation of the 10.in-addr.arpa zone data. I recall someone once offered a bit of code to mash this zone data back together, so the same information can be published from two different DNS services. I've hunted through this list's archive and have not found the reference. Before I go roll my own, can anyone point me at an existing solution? -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of 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
