I recently had to migrate a large DNS environment from about 23 Microsoft Domain Controllers to Infoblox DNS. I could have just deleted all the zones and set the forwarding on the Microsoft DNS servers but I wanted to leave the Microsoft DNS configuration and data in place to provide a quick backout option in the unlikely event that it was need (it was needed but the second time around using the named.conf file below was the charm).
I ended up deploying ISC BIND 9.10.2-P3 across a mix of Windows 2003 and Windows 2008 domain controller servers, some 32-bit and some 64-bit.
As I alluded to above I originally had issues running BIND getting error messages such as the following after only a few hours running the service and clients failing to get name resolution.
27-Jul-2015 19:15:04.575 general: error: ..\client.c:2108: unexpected error: 27-Jul-2015 19:15:04.575 general: error: failed to get request's destination: failure 27-Jul-2015 19:15:04.981 general: error: ..\client.c:2108: unexpected error: 27-Jul-2015 19:15:04.981 general: error: failed to get request's destination: failure 27-Jul-2015 19:15:20.971 general: error: ..\client.c:2108: unexpected error: 27-Jul-2015 19:15:20.971 general: error: failed to get request's destination: failure
There were also a few other errors that apeared to be releated to the anti-DDoS mechanisms built into BIND;
27-Jul-2015 19:50:02.369 resolver: notice: clients-per-query increased to 15
So I went back and recrafted the named.conf file and came up with the following which seems to be working well for me now almost 5 days after the Infoblox DNS migration.
You’ll noticed that I commented out the localhost zone and the 127.0.0.1 reverse zone as well. I didn’t think that BIND would run without them but sure enough it does. I also enabled query logging so I could see what type of abuse the DNS servers were getting. I found a couple of servers that were querying more than 40,000 times a minute for a management platform that had been retired almost 5+ years ago.
options {
directory "c:\program files\isc bind 9\bin";
// here are the servers we'll send all our queries to
forwarders {10.1.1.1; 10.2.2.2;};
forward only;
auth-nxdomain no;
// need to include allow-query at a minimum
allow-recursion { "any"; };
allow-query { "any"; };
allow-transfer { "none"; };
// lets leave IPv6 off for now less to worry about
listen-on-v6 { "none"; };
// standard stuff
version none;
minimal-responses yes;
// cache positive and negative results for only 5 minutes
max-cache-ttl 300;
max-ncache-ttl 300;
// disable DDoS mechanisms in BIND
clients-per-query 0;
max-clients-per-query 0;
};
logging{
channel example_log{
file "C:\program files\isc bind 9\log\named.log" versions 3 size 250k;
severity info;
print-severity yes;
print-time yes;
print-category yes;
};
channel queries_file {
file "c:\program files\isc bind 9\log\queries.log" versions 10 size 10m;
severity dynamic;
print-time yes;
};
category default{ example_log; };
category queries { queries_file; };
};
//zone "localhost" in{
// type master;
// file "pri.localhost";
// allow-update{none;};
//};
//zone "0.0.127.in-addr.arpa" in{
// type master;
// file "localhost.rev";
// allow-update{none;};
//};
I setup my first nameserver running BIND 4.x back in 1995, more than 20 years ago while working at Manhattan College. While I'm pretty familiar with BIND a lot has changed since then and so I had to-do a fair bit of research to arrive at the configuration above.
Hopefully someone else will find it helpful.
Cheers!
We recently started deploying the Nortel IP 2050 Softphone v3.x for our work-from-home Contact Center agent pilot. With software release v3.x or higher you need a licensing server somewhere in your network. That means that yes you need to purchase licenses for all your concurrent 2050 users. It’s my understanding that Nortel has licensed various technologies in the 2050 that required it to deploy a licensing server as set forth in the licensing agreements with the various third parties.