Re: ISC Bind in Active Directory
On 10/24/2012 9:50 AM, Nicholas F Miller wrote: 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 '' records is to compare the records in your DDNS zone to all of the existing computer objects in your AD. If an 'A' or '' 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). - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND does not answer
On Oct 23, 2012, at 5:17 PM, Christian Tardif wrote: Hi, I have a strange BIND behaviour I don't know how to handle. As I don't exactly know how to describe it, I'll rather explain what I did and what happens. But not quite easy to follow. In my tests, I have two servers with BIND installed on them: SiteA (BIND 9.8.2rc1 on CentOS 6.3), and SiteB (BIND 9.5.0-P2, on Mandriva 2008.1). A third environment helps me for diagnostics. SiteA is a recursive name server. I've been able to prove that it does not behave correctly under certain circumstances by hitting it with a simple request: asking it to give me NS records for a certain subdomain for which it's primary for the base domain (dig @SiteA NS sub.domain.tld, SiteA being authoritative for domain.tld). It just times out. There are glue records on SiteA for the sub.domain.tld master BIND). In order to try to figure out what was going on, I try, directly from SiterA, to send a request, as a client, directly to the master of sub.domain.tld. Times out again. At this moment, I can't tell which server is faulty. But I ge the same behaviour trying to get an answer from a completely different server (SiteB). In that case as well, no answer. But still starting from SiteA. I then tried to get a response for the request I made from SiteA to SiteB (as I control both), but this time, starting for my third environment. Then, SiteB answers to my request. So SiteB looks like it's working. But how come it does not answer my request from SiteA? From BIND logs on siteB, there's no trace of SiteA-to-SiteB' request. In order to prove that my UDP packets actually reaches their destination, and are not modified during transit, I opened a tcpdump session on SiteA and on SiteB. Packets come through in good shape, but didn't find their way to BIND application, as it seems. In my opinion, SiteB is not part of the problem, as it answers normally to every other it receives from anywhere else than SiteA. If I try again SiteA-to-SiteB request, I can see with TCPDUMP that packets gets out of SiteA, and enters SiteB. But BIND doesn't react. Even if I try to enable debugging on SiteB, I don't see anything. What could be wrong, and how do I solve it? What tools are available to help out? If I try to ask for recursive request (let's say www.google.com) from anywhere, pointing at SiteA, I get a proper answer. What happens if you use 'dig +norec' in your tests? That is, use iterative queries. Does that change the behavior you see? Chris Buxton BlueCat Networks ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC Bind in Active Directory
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. Chris Buxton BlueCat Networks ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable log message
Alan Clegg a...@clegg.com wrote: This message was added by general recognition that being able to rebuild a drop-in binary for BIND when you didn't have access to the build directory (where the config.log contains the information) was a good thing. I, for one, see no reason to suppress this message (but I do have blind spots at times). I have a tangentially related patch. I wanted to direct BIND's startup logging to the same file that it is configured to use after initialization - rather than always sending startup messages to syslog. The patch adds a -L command-line option for this purpose. You could use it to suppress the startup logging with -L/dev/null I suppose... http://dotat.at/cgi/git/bind-9.git?a=commitdiff;h=logging-startup Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC Bind in Active Directory
On 24/10/12 16:54, Kevin Darcy wrote: 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! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC Bind in Active Directory
Hello Aaron, 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. -- Carsten ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC Bind in Active Directory
Hello Phil, 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/ records) from client information. These DNS zones can have a different dynamic update policy/ACL, can even be delegated to different DNS servers. Example: DNS-Domain: example.com Ad-Domain: ad.example.com Client-DNS Zone: client.ad.example.com all with proper delegations. 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. -- Carsten Strotmann ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC Bind in Active Directory
On 10/24/2012 10:17 PM, Carsten Strotmann wrote: 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. Cheers, Phil ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: transparent DNS load-balancing with a Cisco ACE
On 10/19/2012 07:25 PM, John Miller wrote: Here's a question, however: how does one get probes working for a transparent LB setup? If an rserver listens for connections on all interfaces, then probes work fine, but return traffic from the uses the machine's default IP (not the VIP that was originally queried) for the source address of the return traffic. I'm not sure I understand this. If a DNS request comes in on a particular IP, bind should reply from that IP, always. If it doesn't, something is going seriously wrong. What have people done to get probes working with transparent LB? Are any of you using NAT to handle your dns traffic? Not tying up NAT tables seems like the way to go, but lack of probes is a deal-breaker on this end. We didn't have to do anything special, and I'm not sure why you have either. Our probes are just: probe tcp TCP_53_RECDNS ip address public ip port 53 interval 10 serverfarm host INTERNAL-DNS transparent predictor leastconns probe TCP_53_RECDNS rserver private IP 53 inservice The ACE uses ARP to discover the destination MAC of the private IP, but sends an IP packet to that MAC with a destination of the public IP. The DNS reply comes back from that, and all is well. I get the feeling I'm not understanding what isn't working for you; can you describe the failure in more detail? What server OS are you running, and can you describe the network config? Cheers, Phil ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
