I'm hopping to get some feedback from people who use ISC Bind and DHCPD in Active Directory environments.
Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a pretty stable service, redundant and we are polling statistics with Cacti. There is concern by Management of using a somewhat non standard approach for Active Directory SRV records being handled by ISC services and not AD.
The options we are looking at is migrating to AD for DNS and DHCP services or to have Bind/DHCPD handle SRV records for AD.
Some technical info on our our BIND environment.
Some Client Identifiers
300 DHCP Pools
Dynamic DNS
Cacti Graphs - Reporting
Syslog via Splunk
Overall it's been a very stable design for the last 5+ years.
If you have any relevant feed back I would appreciate it. I'm looking for information on experience with Active Directory integration with ISC or if anyone has had problems/stability issues with AD doing DNS/DHCP or AD working with ISC.
Thanks in advance.
Here's a brief survey for Schools that have ISC running in an AD environment.
You should think of DNS hosting, DNS resolution and DHCP, as separate services that can either be put together on a single platform, or run on separate platforms in various combinations, interoperating with each other. Another important factor is whether your AD domain is colocated with a bunch of other non-AD stuff, or whether it's a separate namespace (either a descendant of your main domain, or some namespace entirely).
In our case, our AD folks insist on AD-integrated zones, but on the other hand, they're in completely different namespaces. So it's a fairly simple matter of delegating from and (for reasons of performance and resiliency) replicating that data into our BIND-based infrastructure. We handle the DNS resolution and DHCP, and all of the clients can resolve the AD names from us, even though we're not the primary master for any of the zones. YMMV. One of the drawbacks of this approach is that Domain Controllers and certain other types of AD-related servers need to be added twice -- once into the AD-integrated zone for AD infrastructure purposes, and then again into a more generic zone, so that the proper forward/reverse mappings are created and kept in sync. Ideally, AD would generate outbound Dynamic Updates for the maintenance of reverse records for their resources, if they don't happen to control the relevant reverse zone(s), but good luck with that -- it's not in Microsoft's own best economic interests to foster interoperability with non-Microsoft DNS server implementations...
> I'm hopping to get some feedback from people who use ISC Bind and > DHCPD in Active Directory environments.
> Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a > pretty stable service, redundant and we are polling statistics with > Cacti. There is concern by Management of using a somewhat non > standard approach for Active Directory SRV records being handled by > ISC services and not AD.
> The options we are looking at is migrating to AD for DNS and DHCP > services or to have Bind/DHCPD handle SRV records for AD.
> Some technical info on our our BIND environment.
> Some Client Identifiers
> 300 DHCP Pools
> Dynamic DNS
> Cacti Graphs - Reporting
> Syslog via Splunk
> Overall it's been a very stable design for the last 5+ years.
> If you have any relevant feed back I would appreciate it. I'm looking > for information on experience with Active Directory integration with > ISC or if anyone has had problems/stability issues with AD doing > DNS/DHCP or AD working with ISC.
> I'm hopping to get some feedback from people who use ISC Bind and DHCPD
> in Active Directory environments.
> Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a
> pretty stable service, redundant and we are polling statistics with
> Cacti. There is concern by Management of using a somewhat non standard
> approach for Active Directory SRV records being handled by ISC services
> and not AD.
Microsoft may tell management that it's non-standard, but it's not.
What you're describing is very common, especially among EDUs.
Management's attitude appears to be based on two myths:
1. You must use AD integrated DNS for your AD installation.
2. You must use DDNS for your AD installation (at least for the relevant
SRV records).
Neither of these are true, and plenty of places have gotten by for at
least a decade with *static* SRV records in a BIND server.
A few years ago, Gartner did a paper where they discussed "new features"
that Microsoft claims "require" AD-integrated DNS. Gartner's conclusion
was that this is basically not true and that if the current BIND-AD
integration is working for you, then you should stick with it.
[snip]
> Overall it's been a very stable design for the last 5+ years.
It sounds like something that's not broken and shouldn't be fixed.
Again, this is the experience at other EDUs.
> If you have any relevant feed back I would appreciate it. I'm looking
> for information on experience with Active Directory integration with ISC
> or if anyone has had problems/stability issues with AD doing DNS/DHCP or
> AD working with ISC.
On Thu, 18 Oct 2012, bind-users-requ...@lists.isc.org wrote:
ISC Bind in Active Directory (Aaron Thompson)
> I'm hopping
Sometimes AD has that effect. :)
> to get some feedback from people who use ISC Bind and DHCPD in
> Active Directory environments.
I've been working on a client's (small) system using Bind in an AD
environment for almost ten years.
When I first met the system it was Windows only. It had been sending
the same two megabyte mail message to quite a long list of recipients
every two hours for just over two years. In unrelated incidents it had
been riddled with viruses which for example were logging keystrokes in
the accounts department. Oh, and the PDC's disc was full, but 80% of
the contents was garbage generated by a wayward third-party backup
Windows package which wasn't doing anything useful at all. The firm's
directors didn't appreciate that there might be a problem until I told
them that their passwords were being sent to China as they were typed.
I cleaned out the viruses and binned the Microsoft mail, name and DHCP
services and the backup package. I installed open source replacements.
Peace at last. Unfortunately I'm unable (yet:) to bin the Windows DCs
or I'd do that tomorrow. One of them crashes within seconds if I log
on using remote desktop and I still don't know why. I can't take it
to bits to find out so I simply don't do it any more. To manage the
dodgy DC I added another one, a virtual machine on a Linux box which
by now hosts half a dozen other Windows VMs. Eventually I hope that
all the Windows machines will be VMs so I can fix them when they go
wrong without leaving my office...
> Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a
> pretty stable service, redundant and we are polling statistics with
> Cacti. There is concern by Management ...
Where have I heard all that before? :)
> ...of using a somewhat non standard approach for Active Directory
> SRV records being handled by ISC services and not AD.
At the moment I'm chasing down a particular AD problem which _might_
have been caused by the promotion of a server to a DC. The symptoms
are (1) a bunch of clients being unable to find resources that they
could find last week and (2) all the SRV records disappearing from the
DCs. I've spent most of the past week hitting the search engines but
I don't think I'm nearer now to knowing if these things are related
(and how I'm going to fix them) than I was a week ago although tonight
I did stumble upon this little gem:
If your Management is concerned about their software, ask them how
they audit the source. :)
> Overall it's been a very stable design for the last 5+ years.
> If you have any relevant feed back I would appreciate it.
If it ain't broke, don't fix it.
> I'm looking for information on experience with Active Directory
> integration with ISC or if anyone has had problems/stability issues
> with AD doing DNS/DHCP or AD working with ISC.
To be fair I don't think there are any big interoperability problems
with the services you're asking about, and if they aren't accessible
to the Big Nasty World out there they shouldn't present too much of a
security risk. Nevertheless the main things which prevent me from
throwing out the rest of my client's Windows boxes are a niche market
accounting package that you've never heard of, a few printer drivers,
Microsoft Office and AutoCAD.
> I'm hopping to get some feedback from people who use ISC Bind and DHCPD in Active Directory environments.
> Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a pretty stable service, redundant and we are polling statistics with Cacti. There is concern by Management of using a somewhat non standard approach for Active Directory SRV records being handled by ISC services and not AD.
> The options we are looking at is migrating to AD for DNS and DHCP services or to have Bind/DHCPD handle SRV records for AD.
> Some technical info on our our BIND environment.
> Some Client Identifiers
> 300 DHCP Pools
> Dynamic DNS
> Cacti Graphs - Reporting
> Syslog via Splunk
> Overall it's been a very stable design for the last 5+ years.
> If you have any relevant feed back I would appreciate it. I'm looking for information on experience with Active Directory integration with ISC or if anyone has had problems/stability issues with AD doing DNS/DHCP or AD working with ISC.
> Thanks in advance.
> Here's a brief survey for Schools that have ISC running in an AD environment.
> -
> Aaron Thompson
> Network Architect for IT Operations
What I did was to have the AD zones mastered on Windows Domain Controllers.
I chose ONE of the DCs to be the "master" for slaving all of these AD zones
on my BIND servers. There were NO CLIENT MACHINES (to my knowledge) tha
were configured to use the Windows DNS Servers as their resolvers. All
machines pointed to the BIND slaves.
This let Windows AD register any SRV records it wanted; the updated zones
were then transferred (via DNS protocols) to my BIND slaves. The
only problem was this - when AD first appeared, the Microsoft DNS code
would update the zone serial number, even if the DNS update made no change
to the zone (except to update an internal timestamp in the AD-integrated
zone). After I opened a support call (in the Windows Server 2000 timeframe),
the MS code was changed to not increase the zone serial number if the zone
contents were not really changing. As of a year
ago, the code had been modified so zone serial numbers were increasing.
Even with MS DHCP - if a lease was renewed, the DNS update was refused, and
the DHCP server had to re-send the update with TKEY/TSIG authentication
before the update was accepted. But the zone serial number was incremented,
causing unnecessary zone transfers from the DC to the BIND servers.
I was not allowed to open a support call with MS to see why the code was
changed and to get the code changed.
--Barry Finkel
DDNS record scavenging is the only feature I'm aware of that MS DNS has that Bind doesn't . On the flip side, ISC Bind can ACL who can add certain record types to a dynamic zone using GSS-TSIG as well as supports views and ACLs for recursion. Everything else should be standard DNS.
_________________________________________________________
Nicholas Miller, OIT, University of Colorado at Boulder
On Oct 18, 2012, at 12:03 PM, Aaron Thompson wrote:
> I'm hopping to get some feedback from people who use ISC Bind and DHCPD in Active Directory environments.
> Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a pretty stable service, redundant and we are polling statistics with Cacti. There is concern by Management of using a somewhat non standard approach for Active Directory SRV records being handled by ISC services and not AD.
> The options we are looking at is migrating to AD for DNS and DHCP services or to have Bind/DHCPD handle SRV records for AD.
> Some technical info on our our BIND environment.
> Some Client Identifiers
> 300 DHCP Pools
> Dynamic DNS
> Cacti Graphs - Reporting
> Syslog via Splunk
> Overall it's been a very stable design for the last 5+ years.
> If you have any relevant feed back I would appreciate it. I'm looking for information on experience with Active Directory integration with ISC or if anyone has had problems/stability issues with AD doing DNS/DHCP or AD working with ISC.
> Thanks in advance.
> Here's a brief survey for Schools that have ISC running in an AD environment.
Nicholas F Miller <nicholas.mil...@Colorado.EDU> wrote:
>DDNS record scavenging is the only feature I'm aware of that MS DNS has
>that Bind doesn't . On the flip side, ISC Bind can ACL who can add
>certain record types to a dynamic zone using GSS-TSIG as well as
>supports views and ACLs for recursion. Everything else should be
>standard DNS.
Yeah, that would be nice to have actually. More generally, metadata on ddns records would be useful.
-- Sent from my phone. Please excuse brevity and typos.
> Nicholas F Miller <nicholas.mil...@Colorado.EDU> wrote:
>> DDNS record scavenging is the only feature I'm aware of that MS DNS has
>> that Bind doesn't . On the flip side, ISC Bind can ACL who can add
>> certain record types to a dynamic zone using GSS-TSIG as well as
>> supports views and ACLs for recursion. Everything else should be
>> standard DNS.
> Yeah, that would be nice to have actually. More generally, metadata on ddns records would be useful.
to be honest, this doesn't seem to me to be something that would fall within bind's purview. comparing bind to "microsoft dns" isn't really apples to apples. microsoft dns is more than just a dns server. it's also a dns management system [whereas bind is not], which is where things like scavenging dns data or publishing metadata would belong. one partial example of this would be dhcpd's use of ddns, which uses txt records to include some metadata in dns. as it is, bind can fully support probably any such mechanism, with the benefit of being agnostic. i like that modularity, and would be disappointed if it changed.
Aaron Thompson <athomp...@berklee.edu> writes:
> I'm hopping to get some feedback from people who use ISC Bind and
> DHCPD in Active Directory environments.
[...]
> If you have any relevant feed back I would appreciate it. I'm looking
> for information on experience with Active Directory integration with
> ISC or if anyone has had problems/stability issues with AD doing
> DNS/DHCP or AD working with ISC.
I've seen and worked in a number of Active Directory installations
during the last 12 years that were using non Microsoft DNS and DHCP
components.
My experience is that if implemented correctly, it is possible to run
Microsoft Active Directory with DNS and DHCP provided by BIND and ISC
DHCP. However, doing that successfully requires that the administrator
has a good understanding of:
* the way how DNS dynamic updates work. I found that many Administrators
do not understand the inner workings of DNS dynamic update. It is
important to understand how a machine sending dynamic updates (in AD
case an AD client or a domain controller) finds the DNS zone to be
updated. Proper DNS delegation and a clean DNS design is
key. Seperating caching/resolving DNS and authoritative DNS helps much.
* the mechanics how the Windows operating system updates the SRV a A
records in an DNS domain that is the foundation of an Active Directory
domain. Also important is the knowledge which records are expected in DNS
for successfull AD operations. The knowldegde is available on the
Internet, but the pages are often outdated (Windows 2000 is different
to Windows 2008 is different to 2012 is details) and the information
is scattered across many places. Finding it all can be difficult and
can take time. The new AD best practice analyzer that come with
Windows 2008R8 and Windows 2012 can help here.
Microsoft extenstions like "Aging and Scavenging" support the
Administrator to operate Active directory, but are not essential.
Getting communication between MS DNS <-> ISC DHCP or MS DHCP <-> BIND
DNS secured (TSIG vs. GSS-TSIG) can be challenging. But it is possible.
My general experience is: working in a "all Windows OS environment" where
all components of AD is supplied by Microsoft products require less
detail knowledge and less arguing (with Management and Microsoft
oriented consultans). But running BIND and ISC DHCP gives more
flexibility and control.
Pick you choice -- easy live vs. understanding
and fun :)
>to be honest, this doesn't seem to me to be something that would fall
>within bind's purview. comparing bind to "microsoft dns" isn't really
>apples to apples. microsoft dns is more than just a dns server. it's
>also a dns management system [whereas bind is not], which is where
>things like scavenging dns data or publishing metadata would belong. >one partial example of this would be dhcpd's use of ddns, which uses
>txt records to include some metadata in dns. as it is, bind can
>fully support probably any such mechanism, with the benefit of being
>agnostic. i like that modularity, and would be disappointed if it
>changed.
>-b
Perhaps I have not made myself clear.
In the case where ddns updates are made directly to bind, it would be handy if bind were to gather metadata about the source and time of the update, so that it is *possible* for external systems to scavenge or whatever.
I don't believe the current update logging is up to it.
Fairly obviously, external systems can't publish metadata they don't know.
-- Sent from my phone. Please excuse brevity and typos.
So I think you separated services and updated Bind statically, sorry If my brevity description of your design is incorrect. Did you try or have any success or difficulties of having Bind as master and AD resolve directly to it as well as everyone else?
Thanks for the feed back and the input on the survey!
> You should think of DNS hosting, DNS resolution and DHCP, as separate services that can either be put together on a single platform, or run on separate platforms in various combinations, interoperating with each other. Another important factor is whether your AD domain is colocated with a bunch of other non-AD stuff, or whether it's a separate namespace (either a descendant of your main domain, or some namespace entirely).
> In our case, our AD folks insist on AD-integrated zones, but on the other hand, they're in completely different namespaces. So it's a fairly simple matter of delegating from and (for reasons of performance and resiliency) replicating that data into our BIND-based infrastructure. We handle the DNS resolution and DHCP, and all of the clients can resolve the AD names from us, even though we're not the primary master for any of the zones. YMMV. One of the drawbacks of this approach is that Domain Controllers and certain other types of AD-related servers need to be added twice -- once into the AD-integrated zone for AD infrastructure purposes, and then again into a more generic zone, so that the proper forward/reverse mappings are created and kept in sync. Ideally, AD would generate outbound Dynamic Updates for the maintenance of reverse records for their resources, if they don't happen to control the relevant reverse zone(s), but good luck with that -- it's not in Microsoft's own best economic interests to foster interoperability with non-Microsoft DNS server implementations...
> - Kevin
> On 10/18/2012 2:03 PM, Aaron Thompson wrote:
>> Hi All,
>> I'm hopping to get some feedback from people who use ISC Bind and DHCPD in Active Directory environments.
>> Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a pretty stable service, redundant and we are polling statistics with Cacti. There is concern by Management of using a somewhat non standard approach for Active Directory SRV records being handled by ISC services and not AD.
>> The options we are looking at is migrating to AD for DNS and DHCP services or to have Bind/DHCPD handle SRV records for AD.
>> Some technical info on our our BIND environment.
>> Some Client Identifiers
>> 300 DHCP Pools
>> Dynamic DNS
>> Cacti Graphs - Reporting
>> Syslog via Splunk
>> Overall it's been a very stable design for the last 5+ years.
>> If you have any relevant feed back I would appreciate it. I'm looking for information on experience with Active Directory integration with ISC or if anyone has had problems/stability issues with AD doing DNS/DHCP or AD working with ISC.
>> Thanks in advance.
>> Here's a brief survey for Schools that have ISC running in an AD environment.
> On 10/18/12 11:03 AM, Aaron Thompson wrote:
>> Hi All,
>> I'm hopping to get some feedback from people who use ISC Bind and DHCPD
>> in Active Directory environments.
>> Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a
>> pretty stable service, redundant and we are polling statistics with
>> Cacti. There is concern by Management of using a somewhat non standard
>> approach for Active Directory SRV records being handled by ISC services
>> and not AD.
> Microsoft may tell management that it's non-standard, but it's not.
> What you're describing is very common, especially among EDUs.
> Management's attitude appears to be based on two myths:
> 1. You must use AD integrated DNS for your AD installation.
> 2. You must use DDNS for your AD installation (at least for the relevant
> SRV records).
> Neither of these are true, and plenty of places have gotten by for at
> least a decade with *static* SRV records in a BIND server.
> A few years ago, Gartner did a paper where they discussed "new features"
> that Microsoft claims "require" AD-integrated DNS. Gartner's conclusion
> was that this is basically not true and that if the current BIND-AD
> integration is working for you, then you should stick with it.
> [snip]
>> Overall it's been a very stable design for the last 5+ years.
> It sounds like something that's not broken and shouldn't be fixed.
> Again, this is the experience at other EDUs.
>> If you have any relevant feed back I would appreciate it. I'm looking
>> for information on experience with Active Directory integration with ISC
>> or if anyone has had problems/stability issues with AD doing DNS/DHCP or
>> AD working with ISC.
> DDNS record scavenging is the only feature I'm aware of that MS DNS has that Bind doesn't . On the flip side, ISC Bind can ACL who can add certain record types to a dynamic zone using GSS-TSIG as well as supports views and ACLs for recursion. Everything else should be standard DNS.
> _________________________________________________________
> Nicholas Miller, OIT, University of Colorado at Boulder
> On Oct 18, 2012, at 12:03 PM, Aaron Thompson wrote:
>> Hi All,
>> I'm hopping to get some feedback from people who use ISC Bind and DHCPD in Active Directory environments.
>> Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a pretty stable service, redundant and we are polling statistics with Cacti. There is concern by Management of using a somewhat non standard approach for Active Directory SRV records being handled by ISC services and not AD.
>> The options we are looking at is migrating to AD for DNS and DHCP services or to have Bind/DHCPD handle SRV records for AD.
>> Some technical info on our our BIND environment.
>> Some Client Identifiers
>> 300 DHCP Pools
>> Dynamic DNS
>> Cacti Graphs - Reporting
>> Syslog via Splunk
>> Overall it's been a very stable design for the last 5+ years.
>> If you have any relevant feed back I would appreciate it. I'm looking for information on experience with Active Directory integration with ISC or if anyone has had problems/stability issues with AD doing DNS/DHCP or AD working with ISC.
>> Thanks in advance.
>> Here's a brief survey for Schools that have ISC running in an AD environment.
I have little experience in the AD arena for DNS/DHCP. Without being a too loaded question, with your experience is it possible or common to have a very knowledgeable understanding of the performance and health of an AD system similar to a BIND system? (redundant, process, snmp, logging, trouble shooting, cacti integration, ect..)
Aaron
-
Aaron Thompson
Network Architect for IT Operations
Berklee College of Music 1140 Boylston Street, MS-186-NETT
Boston, MA 02215-3693
>> I'm hopping to get some feedback from people who use ISC Bind and
>> DHCPD in Active Directory environments.
> [...]
>> If you have any relevant feed back I would appreciate it. I'm looking
>> for information on experience with Active Directory integration with
>> ISC or if anyone has had problems/stability issues with AD doing
>> DNS/DHCP or AD working with ISC.
> I've seen and worked in a number of Active Directory installations
> during the last 12 years that were using non Microsoft DNS and DHCP
> components.
> My experience is that if implemented correctly, it is possible to run
> Microsoft Active Directory with DNS and DHCP provided by BIND and ISC
> DHCP. However, doing that successfully requires that the administrator
> has a good understanding of:
> * the way how DNS dynamic updates work. I found that many Administrators
> do not understand the inner workings of DNS dynamic update. It is
> important to understand how a machine sending dynamic updates (in AD
> case an AD client or a domain controller) finds the DNS zone to be
> updated. Proper DNS delegation and a clean DNS design is
> key. Seperating caching/resolving DNS and authoritative DNS helps much.
> * the mechanics how the Windows operating system updates the SRV a A
> records in an DNS domain that is the foundation of an Active Directory
> domain. Also important is the knowledge which records are expected in DNS
> for successfull AD operations. The knowldegde is available on the
> Internet, but the pages are often outdated (Windows 2000 is different
> to Windows 2008 is different to 2012 is details) and the information
> is scattered across many places. Finding it all can be difficult and
> can take time. The new AD best practice analyzer that come with
> Windows 2008R8 and Windows 2012 can help here.
> Microsoft extenstions like "Aging and Scavenging" support the
> Administrator to operate Active directory, but are not essential.
> Getting communication between MS DNS <-> ISC DHCP or MS DHCP <-> BIND
> DNS secured (TSIG vs. GSS-TSIG) can be challenging. But it is possible.
> My general experience is: working in a "all Windows OS environment" where
> all components of AD is supplied by Microsoft products require less
> detail knowledge and less arguing (with Management and Microsoft
> oriented consultans). But running BIND and ISC DHCP gives more
> flexibility and control.
> Pick you choice -- easy live vs. understanding
> and fun :)
We use Bind for all DNS including DDNS for our AD. We use GSS-TSIG to control what record types and machines can make dynamic updates to our AD zone. We use ISC's DHCP but don't allow it to do DNS updates since we use GSS-TSIG at the client level instead.
_________________________________________________________
Nicholas Miller, OIT, University of Colorado at Boulder
On Oct 22, 2012, at 11:36 AM, Aaron Thompson wrote:
> On Oct 19, 2012, at 10:46 AM, Nicholas F Miller <nicholas.mil...@Colorado.EDU> wrote:
>> DDNS record scavenging is the only feature I'm aware of that MS DNS has that Bind doesn't . On the flip side, ISC Bind can ACL who can add certain record types to a dynamic zone using GSS-TSIG as well as supports views and ACLs for recursion. Everything else should be standard DNS.
>> _________________________________________________________
>> Nicholas Miller, OIT, University of Colorado at Boulder
>> On Oct 18, 2012, at 12:03 PM, Aaron Thompson wrote:
>>> Hi All,
>>> I'm hopping to get some feedback from people who use ISC Bind and DHCPD in Active Directory environments.
>>> Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a pretty stable service, redundant and we are polling statistics with Cacti. There is concern by Management of using a somewhat non standard approach for Active Directory SRV records being handled by ISC services and not AD.
>>> The options we are looking at is migrating to AD for DNS and DHCP services or to have Bind/DHCPD handle SRV records for AD.
>>> Some technical info on our our BIND environment.
>>> Some Client Identifiers
>>> 300 DHCP Pools
>>> Dynamic DNS
>>> Cacti Graphs - Reporting
>>> Syslog via Splunk
>>> Overall it's been a very stable design for the last 5+ years.
>>> If you have any relevant feed back I would appreciate it. I'm looking for information on experience with Active Directory integration with ISC or if anyone has had problems/stability issues with AD doing DNS/DHCP or AD working with ISC.
>>> Thanks in advance.
>>> Here's a brief survey for Schools that have ISC running in an AD environment.
>We use Bind for all DNS including DDNS for our AD. We use GSS-TSIG to
>control what record types and machines can make dynamic updates to our AD
>zone. We use ISC's DHCP but don't allow it to do DNS updates since we use
>GSS-TSIG at the client level instead.
For me to understand: do your clients use GSS-TSIG to update temselves
instead of DHCP server doing the same?
>On Oct 22, 2012, at 11:36 AM, Aaron Thompson wrote:
>> Are you using AD or Bind for DNS/DHCP? I'm assuming your using AD for
>> authentication.
>> On Oct 19, 2012, at 10:46 AM, Nicholas F Miller <nicholas.mil...@Colorado.EDU> wrote:
>>> DDNS record scavenging is the only feature I'm aware of that MS DNS has
>>> that Bind doesn't . On the flip side, ISC Bind can ACL who can add
>>> certain record types to a dynamic zone using GSS-TSIG as well as
>>> supports views and ACLs for recursion. Everything else should be
>>> standard DNS.
isn't the client self-registration the reason why scavenging is needed?
-- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"The box said 'Requires Windows 95 or better', so I bought a Macintosh".
On Oct 24, 2012, at 7:12 AM, Matus UHLAR - fantomas wrote:
>> We use Bind for all DNS including DDNS for our AD. We use GSS-TSIG to
>> control what record types and machines can make dynamic updates to our AD
>> zone. We use ISC's DHCP but don't allow it to do DNS updates since we use
>> GSS-TSIG at the client level instead.
> For me to understand: do your clients use GSS-TSIG to update temselves
> instead of DHCP server doing the same?
That is correct.
>> On Oct 22, 2012, at 11:36 AM, Aaron Thompson wrote:
>>> Are you using AD or Bind for DNS/DHCP? I'm assuming your using AD for
>>> authentication.
>>> On Oct 19, 2012, at 10:46 AM, Nicholas F Miller <nicholas.mil...@Colorado.EDU> wrote:
>>>> DDNS record scavenging is the only feature I'm aware of that MS DNS has
>>>> that Bind doesn't . On the flip side, ISC Bind can ACL who can add
>>>> certain record types to a dynamic zone using GSS-TSIG as well as
>>>> supports views and ACLs for recursion. Everything else should be
>>>> standard DNS.
> isn't the client self-registration the reason why scavenging is needed?
Scavenging is a concern but we didn't have much choice. Our AD is only one of many subdomains and our DHCP spans all of them. If we used DHCP for DDNS records we wouldn't be guaranteed unique names. By limiting DDNS to just the AD we are guaranteed unique names. We only needed DDNS in our AD so it made the most sense to use GSS-TSIG.
A dirty way to scavenge 'A' or 'AAAA' records is to compare the records in your DDNS zone to all of the existing computer objects in your AD. If an 'A' or 'AAAA' record is in your zone but no computer object matches it in the AD it can be assumed to be orphaned. Ldapsearch is a good tool to query the AD for computer objects.
_________________________________________________________
Nicholas Miller, OIT, University of Colorado at Boulder
> On Oct 24, 2012, at 7:12 AM, Matus UHLAR - fantomas wrote:
>>> We use Bind for all DNS including DDNS for our AD. We use GSS-TSIG to
>>> control what record types and machines can make dynamic updates to our AD
>>> zone. We use ISC's DHCP but don't allow it to do DNS updates since we use
>>> GSS-TSIG at the client level instead.
>> For me to understand: do your clients use GSS-TSIG to update temselves
>> instead of DHCP server doing the same?
> That is correct.
>>> On Oct 22, 2012, at 11:36 AM, Aaron Thompson wrote:
>>>> Are you using AD or Bind for DNS/DHCP? I'm assuming your using AD for
>>>> authentication.
>>>> On Oct 19, 2012, at 10:46 AM, Nicholas F Miller <nicholas.mil...@Colorado.EDU> wrote:
>>>>> DDNS record scavenging is the only feature I'm aware of that MS DNS has
>>>>> that Bind doesn't . On the flip side, ISC Bind can ACL who can add
>>>>> certain record types to a dynamic zone using GSS-TSIG as well as
>>>>> supports views and ACLs for recursion. Everything else should be
>>>>> standard DNS.
>> isn't the client self-registration the reason why scavenging is needed?
> Scavenging is a concern but we didn't have much choice. Our AD is only one of many subdomains and our DHCP spans all of them. If we used DHCP for DDNS records we wouldn't be guaranteed unique names. By limiting DDNS to just the AD we are guaranteed unique names. We only needed DDNS in our AD so it made the most sense to use GSS-TSIG.
> A dirty way to scavenge 'A' or 'AAAA' records is to compare the records in your DDNS zone to all of the existing computer objects in your AD. If an 'A' or 'AAAA' record is in your zone but no computer object matches it in the AD it can be assumed to be orphaned. Ldapsearch is a good tool to query the AD for computer objects.
Why do you feel the need to register clients in your AD domain at all? We register our clients outside of the AD domain via the DHCP server; our AD domain only contains resource records that are actually relevant to AD (i.e. over 92% of the records in the zone are SRV records).
On Oct 24, 2012, at 6:50 AM, Nicholas F Miller wrote:
> Scavenging is a concern but we didn't have much choice. Our AD is only one of many subdomains and our DHCP spans all of them. If we used DHCP for DDNS records we wouldn't be guaranteed unique names. By limiting DDNS to just the AD we are guaranteed unique names. We only needed DDNS in our AD so it made the most sense to use GSS-TSIG.
So let the client specify the DDNS domain name, in the DHCP transaction. Or just hard-code a DDNS domain name into each subnet, possibly varying by subnet. Or do both -- use the client-supplied value if one is supplied, or else use the default.
Bear in mind, I'm not saying client updates are necessarily bad, only that you could have done it the other way.
> Why do you feel the need to register clients in your AD domain at all?
> We register our clients outside of the AD domain via the DHCP server;
Our experience is that this can cause (minor) problems.
The basic issue is that, if you have an AD realm:
EXAMPLE.COM
...and a machine:
foo
...then windows tries very hard to stick its fingers in its ears, shout "la la I am not listening" and assume its hostname is:
foo.example.com
You have to fiddle around extensively to make the client *think* it's name is what it really is, and it has never been clear to me what the implications of doing so are.
This can matter if you have systems that trust the clients own idea of the hostname (e.g. vPro/AMT enterprise provisioning) or if you have support staff who want to be able to right-click on a machine from the "AD users & computers" snap-in and click "manage".
If people have any insight into an easy way of updating clients with the correct idea of their own DNS hostnames, and can explain how this interacts with the per-connection DNS suffix stuff in the IP stack, I would be very grateful!
Aaron Thompson <athomp...@berklee.edu> writes:
> I have little experience in the AD arena for DNS/DHCP. Without being
> a too loaded question, with your experience is it possible or common
> to have a very knowledgeable understanding of the performance and
> health of an AD system similar to a BIND system? (redundant, process,
> snmp, logging, trouble shooting, cacti integration, ect..)
possible: yes
common: less so.
I found some very very knowledgeable people in larger
Microsoft dominated networks (AD networks), that know a lot about DNS and AD, at the same level as some people do in the BIND community.
However there are a couple of system administrators in Microsoft
networks that think that having a GUI does not require them to learn
what is going on "under the hood". Not good.
The challenge is that sometimes the Microsoft community (and Microsoft
themselves) are using the same words as people in the Unix community,
but they describe different things, or the other way around (using
different terms for the same stuff). Keeping a sane mind is not always
easy in that respect.
Phil Mayers <p.may...@imperial.ac.uk> writes:
> Our experience is that this can cause (minor) problems.
> The basic issue is that, if you have an AD realm:
> EXAMPLE.COM
> ...and a machine:
> foo
> ...then windows tries very hard to stick its fingers in its ears,
> shout "la la I am not listening" and assume its hostname is:
> foo.example.com
> You have to fiddle around extensively to make the client *think* it's
> name is what it really is, and it has never been clear to me what the
> implications of doing so are.
> This can matter if you have systems that trust the clients own idea of
> the hostname (e.g. vPro/AMT enterprise provisioning) or if you have
> support staff who want to be able to right-click on a machine from the
> "AD users & computers" snap-in and click "manage".
> If people have any insight into an easy way of updating clients with
> the correct idea of their own DNS hostnames, and can explain how this
> interacts with the per-connection DNS suffix stuff in the IP stack, I
> would be very grateful!
my experience is that it is safe to place clients in either a DNS domain
with the same name as the AD domain, or in a subdomain of the AD
domain.
Using a subdomain has the benefit of seperating infrastructure
information (SRV records, server A/AAAA records) from client
information. These DNS zones can have a different dynamic update
policy/ACL, can even be delegated to different DNS servers.
Clients will follow the DNS hierarchy to find the SRV records in the
AD-Domain DNS-Zone. Putting AD-Clients into a DNS-Suffix (aka "local
domain") that is a different branch of the DNS namespace than the
AD-Domain DNS name creates problems and is not
recommended. (e.g. AD-Domain "example.com", clients in "ad.example.")
Using connection-specific DNS-Suffixes to my knowledge are used in the
case that one machine has network connections into mutliple AD-networks
(a gateway machine, or a common server that servers multiple, disjoint
AD domains).
As always, DNS (also Microsoft based DNS for AD) works best if there is
a un-interrupted delegation chain from the root (can be an internal root
or the Internet DNS root) to the authoritative DNS servers, and if
resolving DNS servers are separated from the authoritative DNS
servers. Important is a unified DNS namespace from every machine in the
AD network. There should be only one DNS namespace.
A general observation:
If find a high number of DNS admins in AD networks that have the
preception that the earth, pardon DNS, is flat. It is not, it is a
hierarchy :). And every attempt too make it appear flat creates problems.
> my experience is that it is safe to place clients in either a DNS domain
> with the same name as the AD domain, or in a subdomain of the AD
> domain.
What does "place" mean, exactly?
Bear in mind that, unfortunately, Microsoft chose to embed DNS names in a lot of places when they retrofitted Kerberos, DNS and LDAP to the NT domain protocols.
You've got:
1. The clients own idea of its "main" hostname
2. Global DNS search suffixes
3. Connection-specific DNS suffixes
4. The value of the "dNSHostName" AD attribute
5. The suffixes to qualified servicePrincipalNAme AD attribute(s)
6. The value of msDS-AllowedDNSSuffixes on the domain OU
7. Finally, DNS names which point to the clients addresses
...and that's just off the top of my head. Telling me it's "safe to put the client in another DNS zone" doesn't really tell me anything about the interaction of those things, I'm afraid ;o)
> Using a subdomain has the benefit of seperating infrastructure
Yes, obviously it's desirable. The question is, how do you appropriately configure all of the above (and anything else besides) in a safe, scalable and supported way, that won't cause odd things to break, in such a way as to achieve that?
This is largely a dead issue to me - we just live with the massive inconsistency of clients believing they're one thing, and DNS saying another - so my knowledge is a bit rusty, but from what I recall, it's a huge pain configuring clients into sub-domains of the AD domain, because there are so many places you have to get it right. And *renaming* is even harder.
So we just stopped trying. All clients think they live in "example.com", and we use DNS names as we like e.g. "dept.example.com", "building.example.com". The problems it causes are less hassle than a mass reconfiguration of 20k machines...
> AD-Domain DNS-Zone. Putting AD-Clients into a DNS-Suffix (aka "local
> domain") that is a different branch of the DNS namespace than the
> AD-Domain DNS name creates problems and is not
> recommended.
Why? And again, "putting" means what here?
> Using connection-specific DNS-Suffixes to my knowledge are used in the
> case that one machine has network connections into mutliple AD-networks
> (a gateway machine, or a common server that servers multiple, disjoint
> AD domains).
I don't think this is everything. IIRC, connection-specfic DNS suffixes are candidates for the client to perform DDNS updates, depending on your configuration. And this, of course, is where the thread has spent much of it's time.
> AD network. There should be only one DNS namespace.
Yes. We have independent research groups who run their own private AD who painted themselves into this corner. It's extremely difficult to get out of.
> A general observation:
> If find a high number of DNS admins in AD networks that have the
> preception that the earth, pardon DNS, is flat. It is not, it is a
> hierarchy :). And every attempt too make it appear flat creates problems.
I don't think this accurately describes the issue, though I think I know what you mean.
I think the issue is that AD servers and clients make it EXTREMELY DIFFICULT to run what you and I would describe as a best-practice DNS, due to the above mentioned plethora of things you have to get "just right", and the extremely awkward ways of doing so.
In addition, having adopted Kerberos and DNS in Windows 2000, Microsoft then went and ignored it in lots of places, so having broken DNS isn't the showstopper it would be. Example: Windows does *not* use the DNS name of a CIFS server to obtain a kerberos ticket. It uses the name the CIFS server claims in the SMB connection setup. Which is horribly insecure.
Hell, if you've got WINS running and broadcast netbios, I think it's still possible to log in with *no* working DNS at all.
So the pressure on AD admins to "get it right" just isn't there, and thus the knowledge base isn't either :o(
If someone can give pointers to comprehensible docs about how to make all this work in *all* the places it needs to, I'd be really interested. Because it'd be great to have a subdomain at our site that clients just register themselves into, and it all just work.
> Hell, if you've got WINS running and broadcast netbios, I think it's > still possible to log in with *no* working DNS at all.
At the risk of getting *totally* off-topic, no-one who cares about security or about broadcast traffic on their LANs would even consider allowing WINS to function in their enterprise. It can (and should) be disabled via registry key and/or DHCP options, and left in the dustbin of ancient IT history.
>> Hell, if you've got WINS running and broadcast netbios, I think it's
>> still possible to log in with *no* working DNS at all.
> At the risk of getting *totally* off-topic, no-one who cares about
> security or about broadcast traffic on their LANs would even consider
> allowing WINS to function in their enterprise. It can (and should) be
> disabled via registry key and/or DHCP options, and left in the dustbin
> of ancient IT history.
Do you mean WINS, or broadcast netbios? Because the two are different.
I don't disagree that broadcast netbios probably should be disabled (though it's not at our site, for historical reasons, and I'm not sure I'm willing to take on the monumental task of disabling it).
WINS is slightly different, and the main reason to disable it is that it hides misconfigurations by allowing non-DNS hostname lookups on windows machines.
