RE: RHEL5 BIND in PROD
For new deployments, I would likely choose RHEL6 over RHEL5; unless you have a compelling reason to run RHEL5. RHEL6 includes BIND 9.7.0. You mention that you would like to keep your DNS boxes appliance like. If this is the case, rolling out source code and compiling on each box may not be the best solution for you. If you decide to compile your own BIND, I would look at rolling RPM's for them to make deployment and upgrades easier. Also, keep in mind that while RHEL BIND versions will never be cutting-edge/brand-new, security patches are backported into them. Hope this helps. Josh -Original Message- From: bind-users-bounces+jbaird=follett@lists.isc.org [mailto:bind-users-bounces+jbaird=follett@lists.isc.org] On Behalf Of Mike Diggins Sent: Tuesday, March 15, 2011 9:45 AM To: bind-us...@isc.org Subject: RHEL5 BIND in PROD I'm about to transition my name servers from Solaris 10 to RedHat Linux 5.6. I'm debating whether to compile BIND directly from source as I usually do or use one of the RHEL packages, likely the newly released 9.7.0-6.P2. I would like to make our DNS a little more appliance based to ease some of the support burden. I'm also concerned with stability over new features. I'm interested to know what others are doing. -Mike ___ 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: RHEL5 BIND in PROD
If these are new servers that are only for BIND I'd suggest going with RHEL6 rather than 5.6 - RHEL releases have very long life cycle. When I get a spare moment I intend to update our servers to RHEL6. We use the RHEL5 BIND package for the reasons you give. However, the way RedHat does things is they go with a base release from upstream (e.g. 9.3 is default for RHEL5.x) then backport security and bug fixes from later base releases into that. This causes confusion because people will post here that they're using 9.3 which makes it look like they aren't paying attention to later updates and all. If you like the latest greatest you could build your own but as I once said to the folks at RedHat: If I have a dedicated server that only runs BIND and I have to build my own why should I pay for a subscription based Linux?. As you note they now have (as a bug request) a later version of the base release available in RHEL 5.x but that isn't the one you'll get updates for with yum. I've suggested to RedHat that they do as they did with Java where they made different base releases (e.g. Java 1.4.2, Java 1.6.0) and provide updates for whichever (or both) you choose to use. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Mike Diggins Sent: Tuesday, March 15, 2011 9:45 AM To: bind-us...@isc.org Subject: RHEL5 BIND in PROD I'm about to transition my name servers from Solaris 10 to RedHat Linux 5.6. I'm debating whether to compile BIND directly from source as I usually do or use one of the RHEL packages, likely the newly released 9.7.0-6.P2. I would like to make our DNS a little more appliance based to ease some of the support burden. I'm also concerned with stability over new features. I'm interested to know what others are doing. -Mike ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Advice wanted on Nameserver switchover
Have two questions about the switchover of our external nameservers: I'll call the old nameservers oldns1, oldns2, offsitens and the new nameservers newns1 and newns2 Q1: I had thought to add newns12 to the whois record, whether or not they are online. Just as my offsitens gets all the traffic if we have a power/connectivity failure and go off the air, it would seem to me that if the newns12 aren't there, oldns12 plus offsitens will carry it as they always have. Is there any problem with this? So after the new WHOIS record comes into play, I can bring newns12 online and they'll take 2/5ths of the traffic, more or less. If they seem to be running fine, I can disconnect oldns12 to see how the new stuff takes prime responsibility, but bring the old stuff right back if there's a problem, The two other switchover alternatives are 1) updating WHOIS to be either the new or old nameservers...which involves godawful latency OR 2) playing games with the new nameservers so that they answer to the addresses of the old nameserver in addition to their native addresses...which could be messy and introduce weirdness. Just adding the newns12 to the WHOIS seems to be a lot simpler and allow for a quick phasein and, if necessary, fall back. Am I missing something? Seems too easy to be true Finally, when the new stuff proved out, I'd just remove the oldstuff in WHOIS... Q2; The only messiness I can see about what I want to do is that SOA nameservers list in oldns12 and offsitens would be just them and in the newns12, just those and offsitensthough I could include all in both. I guess my questions is: If nameserver sourcing for the Internet is determined by the WHOIS record info being reflected in the root-servers, where does the SOA nameserver list get used? Forgive me if I reveal collossal ignorance and misunderstanding -- Grant us, in our direst need, the smallest gifts: the nail of the horseshoe, the pin of the axle, the feather at the pivot point, the pebble at the mountain's peak, the kiss in despair, the one right word. In darkness, understanding. Paladin of Souls by Lois McMaster Bujold -- Stewart Dean, Unix System Admin, Henderson Computer Center, Bard College, Annandale, New York 12504 sd...@bard.edu voice: 845-758-7475, fax: 845-758-7035 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Advice wanted on Nameserver switchover
On Tue, 15 Mar 2011, Stewart Dean wrote: Have two questions about the switchover of our external nameservers: I'll call the old nameservers oldns1, oldns2, offsitens and the new nameservers newns1 and newns2 So, you're replacing oldns1 oldns2 with newns1 newns2, while keeping offsitens. The master is currently oldns1 will be newns1. The others are slaves. Yes? I suggest: 1. replace oldns2 with newns2 a. configure newns2 how you want it, pretty much identical to oldns2 but with different interface addresses; verify things work b. disconnect newns2 from the net c. change interface addresses of newns2 to those of oldns2 d. disconnect oldns2 from the net e. connect newns2 to the net f. verify newns2 working: zone transfers, query resolution... 2. replace oldns1 with newns1 a. configure newns1 how you want it, pretty much identical to oldns1 but with different interface addresses; verify things work b. disconnect newns1 from the net c. change interface addresses of newns1 to those of oldns1 d. disconnect oldns1 from the net e. connect newns1 to the net f. verify newns1 working: zone transfers, query resolution... 3. verify offsitens still works No SOA changes, no whois fiddling, back-out 1 box at a time if necessary. Regarding your idea of pointing whois information at name servers which aren't live: don't do that. DNS will probably handle it, but only after dealing with the fact that 2 of the 5 servers don't work. You'll see delays possibly failures. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Advice wanted on Nameserver switchover
See below On 3/15/2011 10:59 AM, Jay Ford wrote: On Tue, 15 Mar 2011, Stewart Dean wrote: Have two questions about the switchover of our external nameservers: I'll call the old nameservers oldns1, oldns2, offsitens and the new nameservers newns1 and newns2 So, you're replacing oldns1 oldns2 with newns1 newns2, while keeping offsitens. The master is currently oldns1 will be newns1. The others are slaves. Yes? Right I suggest: 1. replace oldns2 with newns2 a. configure newns2 how you want it, pretty much identical to oldns2 but with different interface addresses; verify things work b. disconnect newns2 from the net c. change interface addresses of newns2 to those of oldns2 d. disconnect oldns2 from the net e. connect newns2 to the net f. verify newns2 working: zone transfers, query resolution... but while oldns1 will be sending xfers to the new slave at the old address, the xfers will be refused there because they will be coming from the wrong addressthe new slave will be expecting updates from the new master, not the old one. Big deal, I'd have to change the new slaves' named.conf in addition to its interface address. AND I would have to change the serial numbers in all the old master's zone files to get the xfers to work and then again in the new master for the xfer to work for #2 2. replace oldns1 with newns1 a. configure newns1 how you want it, pretty much identical to oldns1 but with different interface addresses; verify things work b. disconnect newns1 from the net c. change interface addresses of newns1 to those of oldns1 d. disconnect oldns1 from the net e. connect newns1 to the net f. verify newns1 working: zone transfers, query resolution... 3. verify offsitens still works No SOA changes, no whois fiddling, back-out 1 box at a time if necessary. Regarding your idea of pointing whois information at name servers which aren't live: don't do that. DNS will probably handle it, but only after dealing with the fact that 2 of the 5 servers don't work. You'll see delays possibly failures. OTOH, maybe the thing to do is to change the WHOIS to include both the oldns12, newns12 and offsitens. If there's any problem with newns12, simply disconnect them and make oldns12 answer to the newns address while straightening things out. Still want to know: what uses the SOA NS info? Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 -- pre One must think like a hero to behave like a merely decent human being. - May Sarton Having overcome your worst fear, the thing you are most vulnerable to, that is the definition of heroic. Also, it's such a worthwhile human activity. The most. -Fran Liebowitz Funny how it's women who see the real heroism (that of going on, of being true) so clearly. Stewart Dean, Unix System Admin, Bard College, New York 12504 sd...@bard.edu voice: 845-758-7475, fax: 845-758-7035 /pre ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RHEL5 BIND in PROD
So, how many servers are you talking about? After having tried to use the distribution supplied packages (for multiple distributions) my opinion is that building from source is the right answer for BIND. The distributions lag more than I'm comfortable with, and BIND builds cleanly from source with mo muss, no fuss For a small number of devices (4 or 5ish) building from source on each box is not *too* hard. For anything more than that, you should be using some sort of system management / configuration thing -- personally I'm partial to Puppet. Trust me, the 2 or 3 days that you will burn getting it all setup and recipes written will more than pay for itself... Being able to bump the version number on a single node, confirm it works, then change the version on the default node and have all your boxes scurry off any upgrade themselves is wickedly fun Installing a new box used to be a multi day event, with much scampering around, package installing, kvetching abut the fact that emacs, bc, tcpdump, traceroute, etc are not installed by default, backup system configuration, kerberos key-diddling, ssh key poking, etc. Now it is: PXE boot / kickstart a base image. Enroll box in puppet: apt-get install puppet; puppet agent --waitforcert 60 --test; on serversudo puppet cert --sign newbox.example.com have coffee, read XKCD for 20 minutes (I read slow!) Profit! W On Mar 15, 2011, at 6:45 AM, Mike Diggins wrote: I'm about to transition my name servers from Solaris 10 to RedHat Linux 5.6. I'm debating whether to compile BIND directly from source as I usually do or use one of the RHEL packages, likely the newly released 9.7.0-6.P2. I would like to make our DNS a little more appliance based to ease some of the support burden. I'm also concerned with stability over new features. I'm interested to know what others are doing. -Mike ___ 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
Zones not getting transferred after a restart
Hi, we have an internal distribution point running BIND 9.5.0-P2 (SLES 11.1 distribution package). It slaves about 1800 zones from a commercial DNS management software running on 127.0.0.1:8054 and distributes them towards our servers. Whenever we restart BIND on that system, the 1800 zones are loaded within two seconds (1800 loaded serial x entries, running), but it takes up to 30 minutes (26 minutes the last time) where it does not do any AXFR upstream and logs 15-Mar-2011 09:36:47.334 zone kongress.xxx.de/IN: notify from 127.0.0.1#8054: refresh in progress, refresh check queued on every notify it receives. I cannot really see SOA queries upstream either. When that time has passed by it catches up with the zone transfers. Other than having edns no and request-ixfr no set for the upstream server (due to bugs in this field) the configuration is pretty standard. I'm not really opposed to updating the BIND to a newer version, but given I'd have to go away from the distribution package where I feel fine using it (firewalled system, only reachable by our other servers) I'd rather know for sure that this problem is solved. I see similar issues on our frontend servers running 9.7.3. Can anyone explain how I can speedup this progress? Also I'd like to disable/tune down the 15-Mar-2011 08:25:36.828 zone xxx.in-addr.arpa/IN: refresh: skipping zone transfer as master 127.0.0.1#8054 (source 0.0.0 .0#0) is unreachable (cached) thing. Good idea, but stopping all zone transfers for 10 minutes from the only master just because it was unreachable for a few seconds is a bad idea. I have searched for a named.conf knob and have failed to find any. Closest I have found is serial-query-rate, which is not set in our environment and should default to 20. Bernhard ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RHEL5 BIND in PROD
I recompile the source rpm fedora core 14 bind 9.7.3 to EL4 and EL5 with koji see my blog for explanations http://fakessh.eu/2011/03/10/bind-9-7-3-sur-centos-5-5-depuis-rpm-source-fecora-14/ Le mardi 15 mars 2011 à 09:45 -0400, Mike Diggins a écrit : I'm about to transition my name servers from Solaris 10 to RedHat Linux 5.6. I'm debating whether to compile BIND directly from source as I usually do or use one of the RHEL packages, likely the newly released 9.7.0-6.P2. I would like to make our DNS a little more appliance based to ease some of the support burden. I'm also concerned with stability over new features. I'm interested to know what others are doing. -Mike ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 signature.asc Description: Ceci est une partie de message numériquement signée ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RHEL5 BIND in PROD
fakessh @ writes: I recompile the source rpm fedora core 14 bind 9.7.3 to EL4 and EL5 with koji see my blog for explanations http://fakessh.eu/2011/03/10/bind-9-7-3-sur-centos-5-5-depuis-rpm-source-fecora-14/ Yep, that works fine, and even on RHEL3. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Best ipfw Rules for DNS-SEC
Is there a recommended set of firewall rules that insure that all necessary DNS traffic can enter and leave, even the larger packets that result from dns-sec? We want port 53 traffic from anywhere, in this case and can send it anywhere, and want to be sure that no port 53 traffic is being lost. Thank you ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best ipfw Rules for DNS-SEC
On Mar 15, 2011, at 11:08 AM, Martin McCormick wrote: Is there a recommended set of firewall rules that insure that all necessary DNS traffic can enter and leave, even the larger packets that result from dns-sec? # allow UDP DNS queries out to the world, and in to your nameservers ## It's faster to do this stateless, and reduces DoS risk against the firewall, ## but you are exposing your network to UDP port scans from source port 53 ## (if you have other open UDP ports). If you want to be stateful, switch to: ## add pass udp from any to $NAMESERVER_IP 53 keep-state ## add pass udp from $YOURNET to any 53 keep-state add pass udp from any to $NAMESERVER_IP 53 add pass udp from $NAMESERVER_IP 53 to any add pass udp from $YOURNET 53,1024-65535 to any 53 add pass udp from any 53 to $YOURNET 53,1024-65535 # allow TCP DNS outbound and inbound only to nameserver boxes ## Likewise, you can add keep-state if you want to be stateful; ## in which case the established line can be removed. add pass tcp from any to any established add pass tcp from $YOURNET to any 53 setup add pass tcp from any to $NAMESERVER_IP 53 setup -- For something like a Cisco PIX/ASA, you probably want no fixup protocol dns to avoid breaking EDNS, but fixup protocol dns maximum-length 4096 might be a workable alternative. Regards, -- -Chuck ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Zones not getting transferred after a restart
In message ilo4hp$s5g$1...@dough.gmane.org, Bernhard Schmidt writes: Hi, we have an internal distribution point running BIND 9.5.0-P2 (SLES 11.1 distribution package). It slaves about 1800 zones from a commercial DNS management software running on 127.0.0.1:8054 and distributes them towards our servers. Whenever we restart BIND on that system, the 1800 zones are loaded within two seconds (1800 loaded serial x entries, running), but it takes up to 30 minutes (26 minutes the last time) where it does not do any AXFR upstream and logs 15-Mar-2011 09:36:47.334 zone kongress.xxx.de/IN: notify from 127.0.0.1#8054: refresh in progress, refresh check queued on every notify it receives. I cannot really see SOA queries upstream either. When that time has passed by it catches up with the zone transfers. Other than having edns no and request-ixfr no set for the upstream server (due to bugs in this field) the configuration is pretty standard. I'm not really opposed to updating the BIND to a newer version, but given I'd have to go away from the distribution package where I feel fine using it (firewalled system, only reachable by our other servers) I'd rather know for sure that this problem is solved. I see similar issues on our frontend servers running 9.7.3. Can anyone explain how I can speedup this progress? Disable notify for the zones. Increase soa-query-rate. It also applies to notifies. Also I'd like to disable/tune down the 15-Mar-2011 08:25:36.828 zone xxx.in-addr.arpa/IN: refresh: skipping zone transfer as master 127.0.0.1#8054 (source 0.0.0 .0#0) is unreachable (cached) thing. Good idea, but stopping all zone transfers for 10 minutes from the only master just because it was unreachable for a few seconds is a bad idea. Adjust lame-ttl. I have searched for a named.conf knob and have failed to find any. Closest I have found is serial-query-rate, which is not set in our environment and should default to 20. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best ipfw Rules for DNS-SEC
In message 1200b563-8a00-4c0a-822d-85733143f...@mac.com, Chuck Swiger writes : On Mar 15, 2011, at 11:08 AM, Martin McCormick wrote: Is there a recommended set of firewall rules that insure that all necessary DNS traffic can enter and leave, even the larger packets that result from dns-sec? # allow UDP DNS queries out to the world, and in to your nameservers ## It's faster to do this stateless, and reduces DoS risk against the firewa ll, ## but you are exposing your network to UDP port scans from source port 53 ## (if you have other open UDP ports). If you want to be stateful, switch t o: ## add pass udp from any to $NAMESERVER_IP 53 keep-state ## add pass udp from $YOURNET to any 53 keep-state add pass udp from any to $NAMESERVER_IP 53 add pass udp from $NAMESERVER_IP 53 to any add pass udp from $YOURNET 53,1024-65535 to any 53 add pass udp from any 53 to $YOURNET 53,1024-65535 # allow TCP DNS outbound and inbound only to nameserver boxes ## Likewise, you can add keep-state if you want to be stateful; ## in which case the established line can be removed. add pass tcp from any to any established add pass tcp from $YOURNET to any 53 setup add pass tcp from any to $NAMESERVER_IP 53 setup -- For something like a Cisco PIX/ASA, you probably want no fixup protocol dns to avoid breaking EDNS, but fixup protocol dns maximum-length 4096 might be a workable alternative. You also want to pass UDP fragments. e.g. ipfw: add pass udp from any to any frag ipf: pass in quick proto udp from any to any with frag keep frag -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RHEL5 BIND in PROD
On Tue, 15 Mar 2011, Warren Kumari wrote: After having tried to use the distribution supplied packages (for multiple distributions) my opinion is that building from source is the right answer for BIND. The distributions lag more than I'm comfortable with, and BIND builds cleanly from source with mo muss, no fuss disclaimer: I'm a passive co-maintainer of bind in rhel/fedora (with Adam doing all the work) If you just want a newer version of bind on RHEL, then I strongly recommend grabbing the existing source rpm, downloading the new bind source, and recompiling using the spec file as much as possible, eg: yumdownloader --source bind yum install rpm-build rpm -hiv bind*src.rpm cd ~/rpmbuild/SOURCES wget ftp://ftp.isc.org/../bind-9.8.x.tar.gz [edit ~/rpmbuild/SPECS/bind.spec and update the version to the latest bind source) rpmbuild -ba ~/rpmbuild/SPECS/bind.spec rpm -Uhv ~/rpmbuild/RPMS/x86_64/bind-9.8.x-1*rpm You might need to disable a patch that got merged upstream, or a patch that has not been converted yet to the new upstream source if your build fails to compile. This will ensure compatibility with RHEL, for instance with initscripts, SElinux, etc. Alternatively, you can look into the development tree for RHEL, called Fedora. Fedora is on a 6 month release cycle and releases updates more often. But take note that you're exchanging stability and testing for a more rapid new version deployment. Paul ps. You can catch me tomorrow at the ICANN DNSSEC panel where I will talk about DNSSEC and Fedora/RHEL. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best ipfw Rules for DNS-SEC
ISC has deployed two test zones with specially configured servers to support the testing of firewalls and EDNS. You can test the firewall rules using: dig edns-v4-ok.isc.org txt (IPv4) dig edns-v6-ok.isc.org txt (IPv6) These queries will only be successfully answered if there is a clean EDNS UDP path that supports a 4096 byte EDNS packet. The servers for these zones are setup to cause the query to fail if there is not a clean EDNS UDP path that supports a 4096 byte EDNS packet. Fall back to TCP is NOT supported on the servers for these zones. EDNS queries using UDP buffer sizes less than 4096 for these queries will NOT work. You can check that the caching server can reach the servers for the zones with: dig edns-v4-ok.isc.org soa (IPv4) dig edns-v6-ok.isc.org soa (IPv6) To query the servers directly you will need to specify +edns=0 or +dnssec with dig to get the TXT record. dig +dnssec edns-v4-ok.isc.org txt @edns-v4-ok.isc.org (IPv4) dig +dnssec edns-v6-ok.isc.org txt @edns-v6-ok.isc.org (IPv6) Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Operating system recommendation
Most of the time it's own preference, we use FreeBSD, because of the light and clean packages. -- Paul Ooi On 10-Mar-2011, at 3:52 AM, pollex wrote: Hi, I want to know in your experience what is the best operating system to run bind for an ISP. We currently have Debian for the 5 Cache servers and for the 2 Authoritative servers. We have around 111851 success querys in the cache servers and around 7267 zones created in the authoritative servers. We are doing a major re analysis for all the arquitecture and Debian is changing to soon their versions and only have support for 1 version before so I dont know if this is best option Best regards and thanks ___ 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
