Re: Peaceful coexistence with Windows domain
I guess you can use "views" in bind view "external" as master for outside users view "internal" as slave of your windows dns for internal users LD On Friday 13 March 2009 07:35:13 Jeff Lightner wrote: > e internal users would see. If the > internal users need to see external records then it must be added by the > Windows admins to the zone on the Windows DNS servers. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Peaceful coexistence with Windows domain
Inferior as MS-DNS may be, it is my experience that taking dns away from AD admins is like trying to take a bone away from a pit bull. And it sounds like the AD's already are forwarding requests to the BIND servers (or performing recursive lookups, one of the two). So the only change I was suggesting was to have all internal hosts use the AD's for resolution so that they could then sanitize the zone on their BIND servers. That's not the ideal solution (and perhaps not even a particularly good one), but I didn't think installing additional BIND servers (etc.) for their non-AD internal hosts would qualify as a "quick" fix (which is what he asked for). Ben > -Original Message- > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy > Sent: Thursday, March 12, 2009 10:45 PM > To: bind-us...@isc.org > Subject: Re: Peaceful coexistence with Windows domain > > You mean, other than the fact that MS-DNS is an inferior DNS > implementation and, as pointed out in the original post, > would need to forward all queries for names outside of the AD zones? > > > > - Kevin > > > Ben Bridges wrote: > > > If I dump the delegation and make an MX record in the master, mail > > will be > > > OK, but then no one can query records in that zone > because it's not > > > actually delegated unless they point at MS-DNS. > > Is there a reason why you can't point all of your internal > hosts (AD > > and non-AD) at your AD's for resolution? > > > > > > > -- > > -- > > *From:* bind-users-boun...@lists.isc.org on behalf of Peter Laws > > *Sent:* Thu 3/12/2009 4:51 PM > > *To:* bind-us...@isc.org > > *Subject:* Peaceful coexistence with Windows domain > > > > Our environment includes a couple of AD servers. They serve DNS to > > PCs using AD (but not all PCs). They allow DDNS for > clients and slave > > the rest of our environment's zones. For some reason, they > *forward* > > every other query to us, but never mind that. Look it up your own > > damn ... well, never mind. > > > > At any rate, we don't actually delegate "their" zone to them. This > > causes problems, as you can imagine. > > > > I'm told that the reason we're doing things this way is > that we don't > > want any of those "internal addresses" to be queried by the > unwashed > > masses lurking outside our perimeter. > > > > So my thought was, well, let's delegate the zone to the AD > servers. > > Since they are already ACLed (or whatever MS calls it), no > one will be > > able to see "their" records off-campus but on-campus folks will be > > able to > > (finally) resolv addresses in that zone regardless of where > they point > > (internally) for DNS. > > > > Except that they need an MX record for that zone. > > > > So adding the NS record to delegate the zone to them properly meant > > that no one could see the MX from the outside (since the MS-DNS is > > ACLed). > > > > If I dump the delegation and make an MX record in the master, mail > > will be OK, but then no one can query records in that zone because > > it's not actually delegated unless they point at MS-DNS. > > > > We thought of slaving that zone on the master, but then we run into > > security, who doesn't want any of that "internal > information" leaked out. > > No problem, since we're slaving the zone, we'll pop an ACL on it. > > Problem solved! Hurray. > > > > Except for that MX record. > > > > Once you delegate a zone, you *delegate* the zone. The MX > is invisible. > > > > > > So my requirements are to 1) allow that MX record to be seen > > "outside", 2) allow any host in our environment to be able to query > > names in any zone regardless of which system they point at for DNS, > > and 3) not have any records in that zone be visible > "outside" save for that MX. > > > > I'm assuming that switching our configuration to use views > would help, > > but we'd like to avoid that, at least for now. > > > > Any quick fixes? > >
Re: Peaceful coexistence with Windows domain
On Thu, 2009-03-12 at 16:51 -0500, Peter Laws wrote: > Our environment includes a couple of AD servers. They serve DNS to PCs > using AD (but not all PCs). They allow DDNS for clients and slave the rest > of our environment's zones. For some reason, they *forward* every other > query to us, but never mind that. Look it up your own damn ... well, never > mind. > > At any rate, we don't actually delegate "their" zone to them. This causes > problems, as you can imagine. > > I'm told that the reason we're doing things this way is that we don't want > any of those "internal addresses" to be queried by the unwashed masses > lurking outside our perimeter. > > So my thought was, well, let's delegate the zone to the AD servers. Since > they are already ACLed (or whatever MS calls it), no one will be able to > see "their" records off-campus but on-campus folks will be able to > (finally) resolv addresses in that zone regardless of where they point > (internally) for DNS. > > Except that they need an MX record for that zone. > > So adding the NS record to delegate the zone to them properly meant that no > one could see the MX from the outside (since the MS-DNS is ACLed). > > If I dump the delegation and make an MX record in the master, mail will be > OK, but then no one can query records in that zone because it's not > actually delegated unless they point at MS-DNS. > > We thought of slaving that zone on the master, but then we run into > security, who doesn't want any of that "internal information" leaked out. > No problem, since we're slaving the zone, we'll pop an ACL on it. Problem > solved! Hurray. > > Except for that MX record. > > Once you delegate a zone, you *delegate* the zone. The MX is invisible. > > > So my requirements are to 1) allow that MX record to be seen "outside", 2) > allow any host in our environment to be able to query names in any zone > regardless of which system they point at for DNS, and 3) not have any > records in that zone be visible "outside" save for that MX. > > I'm assuming that switching our configuration to use views would help, but > we'd like to avoid that, at least for now. > > Any quick fixes? > > I checked, and per the MS-People, MS-DNS cannot put ACLs on particular > records. Neither can BIND, so no surprise there. > > Which rock do I need to look under? > My suggestion would be to have your internal hosts register themselves with your internal DNS servers (Windows AD/DNS servers as in your case should be fine if that is what you use). Next, create your zones that you wish to publish to the outside world on either the same or another (prefer) internal DNS master server (BIND). The servers that you will be exposing to the Internet in a DMZ should then be configured as slaves and pull their zones from the internal master (through a firewall). Your internal systems should use the internal DNS servers (Windows AD/DNS) to resolve your internal services and if outside queries need to be performed then they should be forwarded by the internal DNS servers to the DNS slaves in the DMZ, who in tern would recursively resolve the queries on the Internet. Cheers, Frank ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Peaceful coexistence with Windows domain
Well not a perfect solution but what we have done for records that need to be seen inside and outside is simply create the zone in both Windows DNS and BIND. In BIND we only have the stuff the outside world would see. In Windows we have the stuff the internal users would see. If the internal users need to see external records then it must be added by the Windows admins to the zone on the Windows DNS servers. Here like there all lookups from internal clients go first to the Windows DNS servers. If they have the zone then they'll never send the request to us which is why it must be duplicated there. For all other lookups the Windows DNS servers queries the BIND DNS servers. On the latter we allow recursive lookups for internal clients. Also there are many zones BIND DNS for our various brands that do not exist at all on the Windows DNS server so all those request SHOULD come to us any way. Of course you could do all this with views in BIND and take the zone duplication out of Windows DNS and (Linux)/BIND. I just implemented views for those other brands because we had a need to have an internal web server tested as it will be used for staging what goes to the external web server. -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy Sent: Thursday, March 12, 2009 11:45 PM To: bind-us...@isc.org Subject: Re: Peaceful coexistence with Windows domain You mean, other than the fact that MS-DNS is an inferior DNS implementation and, as pointed out in the original post, would need to forward all queries for names outside of the AD zones? - Kevin Ben Bridges wrote: > > If I dump the delegation and make an MX record in the master, mail > will be > > OK, but then no one can query records in that zone because it's not > > actually delegated unless they point at MS-DNS. > Is there a reason why you can't point all of your internal hosts (AD > and non-AD) at your AD's for resolution? > > > > *From:* bind-users-boun...@lists.isc.org on behalf of Peter Laws > *Sent:* Thu 3/12/2009 4:51 PM > *To:* bind-us...@isc.org > *Subject:* Peaceful coexistence with Windows domain > > Our environment includes a couple of AD servers. They serve DNS to PCs > using AD (but not all PCs). They allow DDNS for clients and slave the > rest > of our environment's zones. For some reason, they *forward* every other > query to us, but never mind that. Look it up your own damn ... well, > never > mind. > > At any rate, we don't actually delegate "their" zone to them. This causes > problems, as you can imagine. > > I'm told that the reason we're doing things this way is that we don't want > any of those "internal addresses" to be queried by the unwashed masses > lurking outside our perimeter. > > So my thought was, well, let's delegate the zone to the AD servers. Since > they are already ACLed (or whatever MS calls it), no one will be able to > see "their" records off-campus but on-campus folks will be able to > (finally) resolv addresses in that zone regardless of where they point > (internally) for DNS. > > Except that they need an MX record for that zone. > > So adding the NS record to delegate the zone to them properly meant > that no > one could see the MX from the outside (since the MS-DNS is ACLed). > > If I dump the delegation and make an MX record in the master, mail will be > OK, but then no one can query records in that zone because it's not > actually delegated unless they point at MS-DNS. > > We thought of slaving that zone on the master, but then we run into > security, who doesn't want any of that "internal information" leaked out. > No problem, since we're slaving the zone, we'll pop an ACL on it. Problem > solved! Hurray. > > Except for that MX record. > > Once you delegate a zone, you *delegate* the zone. The MX is invisible. > > > So my requirements are to 1) allow that MX record to be seen "outside", 2) > allow any host in our environment to be able to query names in any zone > regardless of which system they point at for DNS, and 3) not have any > records in that zone be visible "outside" save for that MX. > > I'm assuming that switching our configuration to use views would help, but > we'd like to avoid that, at least for now. > > Any quick fixes? > > I checked, and per the MS-People, MS-DNS cannot put ACLs on particular > records. Neither can BIND, so no surprise there. > > Which rock do I need to look under? > > -- > Peter L
Re: Peaceful coexistence with Windows domain
You mean, other than the fact that MS-DNS is an inferior DNS implementation and, as pointed out in the original post, would need to forward all queries for names outside of the AD zones? - Kevin Ben Bridges wrote: > If I dump the delegation and make an MX record in the master, mail will be > OK, but then no one can query records in that zone because it's not > actually delegated unless they point at MS-DNS. Is there a reason why you can't point all of your internal hosts (AD and non-AD) at your AD's for resolution? *From:* bind-users-boun...@lists.isc.org on behalf of Peter Laws *Sent:* Thu 3/12/2009 4:51 PM *To:* bind-us...@isc.org *Subject:* Peaceful coexistence with Windows domain Our environment includes a couple of AD servers. They serve DNS to PCs using AD (but not all PCs). They allow DDNS for clients and slave the rest of our environment's zones. For some reason, they *forward* every other query to us, but never mind that. Look it up your own damn ... well, never mind. At any rate, we don't actually delegate "their" zone to them. This causes problems, as you can imagine. I'm told that the reason we're doing things this way is that we don't want any of those "internal addresses" to be queried by the unwashed masses lurking outside our perimeter. So my thought was, well, let's delegate the zone to the AD servers. Since they are already ACLed (or whatever MS calls it), no one will be able to see "their" records off-campus but on-campus folks will be able to (finally) resolv addresses in that zone regardless of where they point (internally) for DNS. Except that they need an MX record for that zone. So adding the NS record to delegate the zone to them properly meant that no one could see the MX from the outside (since the MS-DNS is ACLed). If I dump the delegation and make an MX record in the master, mail will be OK, but then no one can query records in that zone because it's not actually delegated unless they point at MS-DNS. We thought of slaving that zone on the master, but then we run into security, who doesn't want any of that "internal information" leaked out. No problem, since we're slaving the zone, we'll pop an ACL on it. Problem solved! Hurray. Except for that MX record. Once you delegate a zone, you *delegate* the zone. The MX is invisible. So my requirements are to 1) allow that MX record to be seen "outside", 2) allow any host in our environment to be able to query names in any zone regardless of which system they point at for DNS, and 3) not have any records in that zone be visible "outside" save for that MX. I'm assuming that switching our configuration to use views would help, but we'd like to avoid that, at least for now. Any quick fixes? I checked, and per the MS-People, MS-DNS cannot put ACLs on particular records. Neither can BIND, so no surprise there. Which rock do I need to look under? -- Peter Laws / N5UWY National Weather Center / Network Operations Center University of Oklahoma Information Technology pl...@ou.edu --- Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Peaceful coexistence with Windows domain
> If I dump the delegation and make an MX record in the master, mail will be > OK, but then no one can query records in that zone because it's not > actually delegated unless they point at MS-DNS. Is there a reason why you can't point all of your internal hosts (AD and non-AD) at your AD's for resolution? From: bind-users-boun...@lists.isc.org on behalf of Peter Laws Sent: Thu 3/12/2009 4:51 PM To: bind-us...@isc.org Subject: Peaceful coexistence with Windows domain Our environment includes a couple of AD servers. They serve DNS to PCs using AD (but not all PCs). They allow DDNS for clients and slave the rest of our environment's zones. For some reason, they *forward* every other query to us, but never mind that. Look it up your own damn ... well, never mind. At any rate, we don't actually delegate "their" zone to them. This causes problems, as you can imagine. I'm told that the reason we're doing things this way is that we don't want any of those "internal addresses" to be queried by the unwashed masses lurking outside our perimeter. So my thought was, well, let's delegate the zone to the AD servers. Since they are already ACLed (or whatever MS calls it), no one will be able to see "their" records off-campus but on-campus folks will be able to (finally) resolv addresses in that zone regardless of where they point (internally) for DNS. Except that they need an MX record for that zone. So adding the NS record to delegate the zone to them properly meant that no one could see the MX from the outside (since the MS-DNS is ACLed). If I dump the delegation and make an MX record in the master, mail will be OK, but then no one can query records in that zone because it's not actually delegated unless they point at MS-DNS. We thought of slaving that zone on the master, but then we run into security, who doesn't want any of that "internal information" leaked out. No problem, since we're slaving the zone, we'll pop an ACL on it. Problem solved! Hurray. Except for that MX record. Once you delegate a zone, you *delegate* the zone. The MX is invisible. So my requirements are to 1) allow that MX record to be seen "outside", 2) allow any host in our environment to be able to query names in any zone regardless of which system they point at for DNS, and 3) not have any records in that zone be visible "outside" save for that MX. I'm assuming that switching our configuration to use views would help, but we'd like to avoid that, at least for now. Any quick fixes? I checked, and per the MS-People, MS-DNS cannot put ACLs on particular records. Neither can BIND, so no surprise there. Which rock do I need to look under? -- Peter Laws / N5UWY National Weather Center / Network Operations Center University of Oklahoma Information Technology pl...@ou.edu --- Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Peaceful coexistence with Windows domain
Peter Laws wrote: Our environment includes a couple of AD servers. They serve DNS to PCs using AD (but not all PCs). They allow DDNS for clients and slave the rest of our environment's zones. For some reason, they *forward* every other query to us, but never mind that. Look it up your own damn ... well, never mind. At any rate, we don't actually delegate "their" zone to them. This causes problems, as you can imagine. I'm told that the reason we're doing things this way is that we don't want any of those "internal addresses" to be queried by the unwashed masses lurking outside our perimeter. So my thought was, well, let's delegate the zone to the AD servers. Since they are already ACLed (or whatever MS calls it), no one will be able to see "their" records off-campus but on-campus folks will be able to (finally) resolv addresses in that zone regardless of where they point (internally) for DNS. Except that they need an MX record for that zone. So adding the NS record to delegate the zone to them properly meant that no one could see the MX from the outside (since the MS-DNS is ACLed). If I dump the delegation and make an MX record in the master, mail will be OK, but then no one can query records in that zone because it's not actually delegated unless they point at MS-DNS. We thought of slaving that zone on the master, but then we run into security, who doesn't want any of that "internal information" leaked out. No problem, since we're slaving the zone, we'll pop an ACL on it. Problem solved! Hurray. Except for that MX record. Once you delegate a zone, you *delegate* the zone. The MX is invisible. So my requirements are to 1) allow that MX record to be seen "outside", 2) allow any host in our environment to be able to query names in any zone regardless of which system they point at for DNS, and 3) not have any records in that zone be visible "outside" save for that MX. I'm assuming that switching our configuration to use views would help, but we'd like to avoid that, at least for now. Any quick fixes? I checked, and per the MS-People, MS-DNS cannot put ACLs on particular records. Neither can BIND, so no surprise there. Which rock do I need to look under? You can't really have it both ways, either the zone is visible or it isn't. The MX record is at the very top of the zone -- what is often called the "apex" -- so it's not like you can delegate it and put an ACL on the delegated zone. It seems a little inconsistent to me that your Security folks don't mind the MX record being exposed but they're paranoid about the zone's other "internal" stuff leaking out. I don't see any way to to meet the requirements you've been given, as you've described them. There's nothing really unusual about having separate internal-versus-external versions of your namespace, and the delegation structure doesn't need to be the same for both. So why not just stick with an undelegated AD zone in the external version? You can still delegate it in the internal version, if it makes you feel better. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Peaceful coexistence with Windows domain
Our environment includes a couple of AD servers. They serve DNS to PCs using AD (but not all PCs). They allow DDNS for clients and slave the rest of our environment's zones. For some reason, they *forward* every other query to us, but never mind that. Look it up your own damn ... well, never mind. At any rate, we don't actually delegate "their" zone to them. This causes problems, as you can imagine. I'm told that the reason we're doing things this way is that we don't want any of those "internal addresses" to be queried by the unwashed masses lurking outside our perimeter. So my thought was, well, let's delegate the zone to the AD servers. Since they are already ACLed (or whatever MS calls it), no one will be able to see "their" records off-campus but on-campus folks will be able to (finally) resolv addresses in that zone regardless of where they point (internally) for DNS. Except that they need an MX record for that zone. So adding the NS record to delegate the zone to them properly meant that no one could see the MX from the outside (since the MS-DNS is ACLed). If I dump the delegation and make an MX record in the master, mail will be OK, but then no one can query records in that zone because it's not actually delegated unless they point at MS-DNS. We thought of slaving that zone on the master, but then we run into security, who doesn't want any of that "internal information" leaked out. No problem, since we're slaving the zone, we'll pop an ACL on it. Problem solved! Hurray. Except for that MX record. Once you delegate a zone, you *delegate* the zone. The MX is invisible. So my requirements are to 1) allow that MX record to be seen "outside", 2) allow any host in our environment to be able to query names in any zone regardless of which system they point at for DNS, and 3) not have any records in that zone be visible "outside" save for that MX. I'm assuming that switching our configuration to use views would help, but we'd like to avoid that, at least for now. Any quick fixes? I checked, and per the MS-People, MS-DNS cannot put ACLs on particular records. Neither can BIND, so no surprise there. Which rock do I need to look under? -- Peter Laws / N5UWY National Weather Center / Network Operations Center University of Oklahoma Information Technology pl...@ou.edu --- Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
