Re: Moving DNS out of non-cooperative provider
Eventually, if you have done the parent delegations (through where you register your zone) and have updated the new NS records to point only to the new spot, the old zone will only be used by that provider, and nowhere else. So, if com points to the new set of name servers, and example.com has the new set, 99.% of the world will be good. The case exists where oldprovider.net's users (say, mail servers, etc) may continue using their copy of the zone. However, I doubt you care overly much about that unless oldprovider.net is huge. --Michael On Jun 18, 2012, at 8:49 AM, Alexander Gurvitz wrote: Can someone enlighten me on the following scenario (I guess it's explained somewhere, but can't find the info.): example.com was served by ns.OLDprovider.net example.com owner wants to move his domain to ns.NEWprovider.net oldprovider.net is not cooperating, and continues to serve example.com 172800 NS ns.OLDprovider.net (*.gtld-servers.net and ns.newprovider.com now serve example.com 172800 NS ns.NEWprovider.net) Recursive resolver ns.isp.com queried for www.example.com every few minutes, and currently have example.com 45892 NS ns.OLDprovider.net in it's cache. www.example.com have TTL of 3600. Thus each hour ns.isp.com queries ns.OLDprovider.net, with each query gets new NS record, and... refreshes the NS TTL ? Will ns.isp.com EVER query ns.NEWprovider.net ? I'd be happy to know how BIND behaves, but also how other servers may behave in this case. Regards, Alexander Gurvitz, net-me.net ___ 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 ___ 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: OT: cached memory
On Jun 13, 2012, at 5:02 PM, Dan Letkeman wrote: I understand the concept, as I have read many documents like that. I am more interested in a real world example of how much free memory for caching is recommended for an average server. Dan. It depends on many things, but what I'd do to find the optimum cache size is: (1) Start with some limit, say 128 MB. (2) Observe the server's performance over time, and memory usage. (3) Pick some reasonable time, like I want it to hit the max memory size in 3 days or one week (4) If it reaches the maximum too quickly, add more cache size. I suspect this is one metric that would help greatly to add to the XML stats... Cache hit rate is sort of a standard metric. --Michael ___ 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: Recommended value for max-cache-size for cache-only shared hosts..
It's really something you'll have to set, and monitor. I'd start with 1 GB, and see how close it gets to that in (say) a week. If it takes a few hours, you might need to go up to 2 or 4, and see how that works. It may never hit the memory limit. Also note that there is 10% to 20% overhead, so if you set a 1 GB limit, it's really more like a 1.1GB to 1.2GB limit. This is because the cache is not the only thing that uses memory, of course, and the limit is only for the cache. Remember that the cache is only used as a cache, and is not required for operation. Technically, BIND 9 could run with a very, very small cache. The default of 32 MB is actually a fairly new thing. It used to be unlimited, but that means BIND will hit some operating system imposed limit, and that is more painful than self-management. --Michael On Jun 1, 2012, at 12:26 AM, blr maani wrote: Doug, hmmm.. 75%-85% seems too large because the host runs email application in addition to cache-and-forward-only BIND (for better local caching). So, I was wondering if there are any best/proven practice/recommendations for such shared application hosts ? The default value is 32MB. We have 8GB RAM. I don't know if its better to start with 1GB (1/8th of RAM)? thanks blr On Thu, May 31, 2012 at 8:17 PM, Michael Graff mgr...@isc.org wrote: Hmm, I don't quite think this is a good idea. BIND 9 (since 9.5) manages memory quite well, but it will happily consume all you have and go into swap. I'd set it high enough (on a dedicated machine) to use plenty of RAM, but low enough to not cause other OS components to swap out or BIND itself to swap. 75% or 85% range seems like a good starting point. --Michael On May 31, 2012, at 8:18 PM, Doug Barton wrote: On 5/31/2012 1:51 PM, blrmaani wrote: Question: what is the recommended configuration for 'max-cache-size' for optimum usage ? You should not restrict the size of the cache at all if you want the best performance. BIND will use as much memory as it needs in order to satisfy the requests of your users. -- If you're never wrong, you're not trying hard enough ___ 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 ___ 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: Recommended value for max-cache-size for cache-only shared hosts..
Hmm, I don't quite think this is a good idea. BIND 9 (since 9.5) manages memory quite well, but it will happily consume all you have and go into swap. I'd set it high enough (on a dedicated machine) to use plenty of RAM, but low enough to not cause other OS components to swap out or BIND itself to swap. 75% or 85% range seems like a good starting point. --Michael On May 31, 2012, at 8:18 PM, Doug Barton wrote: On 5/31/2012 1:51 PM, blrmaani wrote: Question: what is the recommended configuration for 'max-cache-size' for optimum usage ? You should not restrict the size of the cache at all if you want the best performance. BIND will use as much memory as it needs in order to satisfy the requests of your users. -- If you're never wrong, you're not trying hard enough ___ 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 ___ 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: random-device purpose in DNSSEC
Some signature methods require this, some do not. RSA should not (in general) but RSA encryption in practice may. Signing is different, in that you know both halves (encrypted and cleartext) so it should not require padding. I think DSA does require randomness in signing. --Michael On May 10, 2012, at 2:41 PM, Alexander Gurvitz wrote: Hello all. What random device used for ? ARM says Entropy is primarily needed for DNSSEC operations, such as ... dynamic update of signed zones. I don't get why signing a zone requires any randomness. This bothers me as I'm implementing DNSSEC now, and I know that my systems are low at entropy, and BIND default random-device is /dev/random, and it (the device) blocks when there's no entropy available. Does BIND really needs that entropy, and how much ? Regards, Alexander Gurvitz, net-me.net ___ 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 ___ 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: More than 4k TXT entries
more than 4k will exceed the default settings for EDNS0 UDP responses. If you dig @ your server, with +tcp, do you get a reply? If not, perhaps you are not allowing TCP connections to port 53? What error you are getting may be of help. --Michael On Feb 29, 2012, at 1:20 PM, Darvin Denmian wrote: Hi I would like to know if there is some limitation in Bind regard: - Max number of TXT entries for a specific domain or - Max size of a zone file I'm asking this because one of the domains configured in my Bind server have more than 4k TXT entries and its zone file have more than 400KB. So my problem is When I perform a DNS query , requesting the last TXT entries that I've added, I receive no answer from my Bind server. Do you have some ideia of what is happening? I hope you can help me and .understand my Brazilian English :p . ___ 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 ___ 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: More than 4k TXT entries
Actually, no, there isn't enough information in your reply to help you debug. Please issue, from a machine not your DNS server: $ dig @your-server-address +tcp domain.name TXT A TXT record has a maximum length of around 64k per TXT record, and each part of the text record can be 255 bytes, if memory serves. However, this is well beyond practical limits. The size of the zone is not really important compared to the size of the individual TXT record at a specific name. There is no maximum that spreads across names, but there are practical limits. If you just have a long string of TXT records, each at its own name like in your example, you should not be running into problems. --Michael On Feb 29, 2012, at 1:48 PM, Darvin Denmian wrote: Hi, Graff, thanks for you reply... As you can see below my server is accepting DNS connections: ACCEPT udp -- anywhere anywhereudp dpt:domain ACCEPT tcp -- anywhere anywheretcp dpt:domain and the service is up and running: # netstat -ntplu | grep -i named tcp0 0 XXX.XXX.XX.XXX:53 0.0.0.0:* LISTEN 7547/named tcp0 0 XXX.XXX.XX.XXX:53 0.0.0.0:* LISTEN 7547/named tcp0 0 127.0.0.1:9530.0.0.0:* LISTEN 7547/named udp0 0 XXX.XXX.XX.XXX:53 0.0.0.0:* 7547/named udp0 0 XXX.XXX.XX.XXX:53 0.0.0.0:* 7547/named The zone file is composed of a lot of TXT records...below a small piece of the file: spf_1 900 IN TXT v=spf1 ip4:XX.XX.XXX.XX/28 ip4:XX.XX.XXX.XX ?all spf_10001 900 IN TXT v=spf1 ip4:XX.XX.XXX.XX/28 ip4:XX.XX.XXX.XX ?all spf_10003 900 IN TXT v=spf1 ip4:XX.XX.XXX.XX/28 ip4:XX.XX.XXX.XX ?all spf_10004 900 IN TXT v=spf1 ip4:XX.XX.XXX.XX/28 ip4:XX.XX.XXX.XX ?all spf_10008 900 IN TXT v=spf1 ip4:XX.XX.XXX.XX/28 ip4:XX.XX.XXX.XX ?all ... spf_16416 900 IN TXT v=spf1 ip4:XX.XX.XXX.XX/28 ip4:XX.XX.XXX.XX ?all spf_16417 900 IN TXT v=spf1 ip4:XX.XX.XXX.XX/28 ip4:XX.XX.XXX.XX ?all spf_16418 900 IN TXT v=spf1 ip4:XX.XX.XXX.XX/28 ip4:XX.XX.XXX.XX ?all spf_16419 900 IN TXT v=spf1 ip4:XX.XX.XXX.XX/28 ip4:XX.XX.XXX.XX ?all spf_16420 900 IN TXT v=spf1 ip4:XX.XX.XXX.XX/28 ip4:XX.XX.XXX.XX ?all I hope those informations can help you to help me :) Regards! On Wed, Feb 29, 2012 at 4:25 PM, Michael Graff mgr...@isc.org wrote: more than 4k will exceed the default settings for EDNS0 UDP responses. If you dig @ your server, with +tcp, do you get a reply? If not, perhaps you are not allowing TCP connections to port 53? What error you are getting may be of help. --Michael On Feb 29, 2012, at 1:20 PM, Darvin Denmian wrote: Hi I would like to know if there is some limitation in Bind regard: - Max number of TXT entries for a specific domain or - Max size of a zone file I'm asking this because one of the domains configured in my Bind server have more than 4k TXT entries and its zone file have more than 400KB. So my problem is When I perform a DNS query , requesting the last TXT entries that I've added, I receive no answer from my Bind server. Do you have some ideia of what is happening? I hope you can help me and .understand my Brazilian English :p . ___ 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 ___ 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 dies with assertion failure
It is a known issue, and is indeed a bug. We're working on it already, so stay tuned. --Michael On Feb 14, 2012, at 12:44 PM, Alex wrote: Hi, I have a fedora16 x86_64 box and named keeps dying with an assertion failure: 14-Feb-2012 13:24:41.137 general: critical: rbtdb.c:1619: INSIST(!((void *)((node)-deadlink.prev) != (void *)(-1))) failed 14-Feb-2012 13:24:41.137 general: critical: exiting (due to assertion failure) This is bind-9.8.2-0.2.rc1.fc16.x86_64. Is this a known issue? Is this indeed a bug or perhaps something otherwise wrong with the server? How can I troubleshoot this further? Thanks, Alex ___ 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 ___ 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 9.9rc2 notification gone wild
Key management (and how BIND 9 in the form of named handles issues like this) is likely too large a topic to address before 9.9.0 is out. I don't think the management has gotten worse from 9.8 to 9.9 though. We're hoping to make key management the next major focus area in bind 9, now that we have inline signing. That would help round-out the dnssec offering. --Michael On Feb 1, 2012, at 11:23 AM, Spain, Dr. Jeffry A. wrote: I can install bind 9.9.0rc2 tomorrow and test with both nsupdate and rndc reload. I would also like to test DNSSEC automatic key rollover with inline signing again. I imagine this will be fixed in rc2, given the success of the patch you provided earlier. My next ZSK activation date is 3/10/2012 with inactivation of the previous key on 3/11 and deletion on 4/15. I will move those dates up 5 weeks on one of the zones in the hope of getting test results sooner, although ultimately the timing depends on individual signature expiration dates. Thank you. 9.9.0rc2 is now available to BIND Forum members for initial testing before we roll it out to the public tomorrow. I created a comedy of errors modifying the key metadata for the test described above. Bind's behavior in the face of this may or may not be something you want to address in the run-up to the bind 9.9.0 release, but I think it does also demonstrate that the problem with expired signatures in inline-signed zones in 9.9.0rc1 has been fixed. Here's what happened. I made metadata changes to two keys using dnssec-settime yesterday morning. Yesterday evening, as previously posted, I discovered that bind couldn't read the private key files due to the mode change to 0600 made by dnssec-settime. The syslog contained a series of helpful messages in this regard: Jan 31 11:52:52 nstest named[845]: dns_dnssec_keylistfromrdataset: error reading private key file jaspain.us/RSASHA1/55158: permission denied Jan 31 11:52:52 nstest named[845]: dns_dnssec_keylistfromrdataset: error reading private key file jaspain.us/RSASHA1/30795: permission denied Jan 31 11:52:52 nstest named[845]: dns_dnssec_findmatchingkeys: error reading key file Kjaspain.us.+005+55158.private: permission denied Jan 31 11:52:52 nstest named[845]: dns_dnssec_findmatchingkeys: error reading key file Kjaspain.us.+005+30795.private: permission denied These were repeated hourly with each next key event. Yesterday evening I fixed the permissions on the private keys and a new series of errors began to appear. It turns out that by mistake I had set the currently active key (55158) to become inactive 24 hours before its published successor (30795) was due to be made active. This resulted in the following series of log messages, also very helpful and informative: Feb 1 06:19:17 nstest named[845]: zone jaspain.us/IN (signed): Key jaspain.us/RSASHA1/55158 missing or inactive and has no replacement: retaining signatures. Feb 1 06:19:17 nstest named[845]: zone jaspain.us/IN (signed): sending notifies (serial 201512) Feb 1 06:19:52 named[845]: last message repeated 7 times Feb 1 06:20:53 named[845]: last message repeated 12 times Feb 1 06:21:53 named[845]: last message repeated 12 times Feb 1 06:22:53 named[845]: last message repeated 12 times ... and many more such. Apparently bind found the need to update some signatures on the signed zone jaspain.us but could not do so without an active ZSK. Despite its inability to update the signed zone and despite no increment in the serial number, it started sending notifies to its slave server every five seconds. Looking at the slave server logs confirms this, with entries like the following being present every five seconds: Feb 1 06:19:52 nstest2 named[735]: client 2001:4870:20ca:158:4423:f19d:4ead:5c20#29061/key nstest-nstest2.countryday.net: received notify for zone 'jaspain.us': TSIG 'nstest-nstest2.countryday.net' Feb 1 06:19:52 nstest2 named[735]: zone jaspain.us/IN: notify from 2001:4870:20ca:158:4423:f19d:4ead:5c20#29061: zone is up to date When I observed this behavior this morning, I corrected the key metadata making ZSK 30795 active at 8:30 a.m. Almost immediately afterwards the master server made some modifications to the signed zone, incremented its serial number, sent another notify, and transferred the zone: Feb 1 08:30:03 nstest named[845]: zone jaspain.us/IN (signed): sending notifies (serial 201513) Feb 1 08:30:03 nstest named[845]: client 2001:4870:20ca:9:1890:f431:72c9:caaf#37863/key nstest-nstest2.countryday.net (jaspain.us): transfer of 'jaspain.us/IN': IXFR started: TSIG nstest-nstest2.countryday.net Feb 1 08:30:03 nstest named[845]: client 2001:4870:20ca:9:1890:f431:72c9:caaf#37863/key nstest-nstest2.countryday.net (jaspain.us): transfer of 'jaspain.us/IN': IXFR ended The slave's log also shows that this transfer was successful: Feb 1 08:30:03 nstest2
BIND 9.9.0 RC2 -- call for testing
As Evan mentioned earlier, we are coming close to releasing a final BIND 9.9.0. It's scheduled to go to our Forum members on the 7th of February and as a public release about a week later. Some inline signing defects were resolved earlier this week, and we've released 9.9.0RC2. This release candidate includes fixes for all major defects reported in inline signing and other features. We prefer to give at least two weeks between the final RC and the release. However, due to our use of improved code testing in our development process, and that most of the inline signing bugs were found earlier in the release cycle than is typical, we feel confident that this shortened RC-to-release time is a fairly safe choice to make. The 9.9.0 pre-releases have been the most user-tested of any of our releases to date, and we appreciate each and every tester's valuable time. But, we are asking for more. More testers, more reports of success, and of course of failures. The more people who test 9.9.0 RC2 before February the 7th, the better the release will be. While we hope for no major defects, we'd rather know of them than not. Please head on over to http://www.isc.org/software/bind/990rc2 and give it a try. If you don't want to send mail to this list for success or failure stories, sending them to me personally will get them to the right place. Thank you everyone for helping us make great software even better. --Michael ___ 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: Bind9 Design Document
This is one of the reasons we are doing things differently in BIND 10. BIND 9 had some early stuff (under doc directory) but it was never fully fleshed out. --Michael On Jan 26, 2012, at 10:58 AM, Cong Guo wrote: Hello, How can I get the design documents of Bind9, like the ones for Bind10? I can find only the ARM and man pages at the isc ftp. My research is on name service and hope to study Bind. Your help will be appreciated. Thanks, Cong -- Cong Guo PhD Candidate David R. Cheriton School of Computer Science, University of Waterloo, Waterloo, ON N2L 3G1 ___ 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 ___ 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: DNSSEC made simple, is this possible?
You want BIND 9.9 (currently 9.9.0rc1) with inline signing. This will do exactly what you want, I think. --Michael On Jan 11, 2012, at 9:31 AM, Howard Leadmon wrote: OK, in an attempt to start using DNSSEC over here, I suppose I bit myself in the backside, and even spending some time using googlefu I still haven't quite figured this all out. I am currently running the current BIND 9.8.1, and setup to support DNSSEC. After reading around a bit, I saw that setting auto-dnssec in the config would read in the keys and sign the zones automatically, this seemed in theory to be perfect, so I configured it this way. After that the domains were signed, and going to places like the verisign debugger showed my domain was happily secured with DNSSEC. Then I go to make a change to my DNS file, whoa was I in for a shock, as apparently BIND took my nice text file for DNS I have edited for ages, and converted it into a full signed zone. Try and edit that file, and if course it bitches about it no longer matching the .jnl file and drops the zone.This sure makes it hard to update things, well the way I am used to doing it. So I guess my million dollar question is, I want to use DNSSEC (it's actually working now), but I want to be able to edit my zone files the way I always have for many years, and just have BIND sign the zones with the keys and update as needed to keep DNS running smoothly. Is there some easy way to do this, some scripts someone has made, or some documentation to walk me through accomplishing this? I can't believe there aren't a lot of others that have run DNS just as I have for years and years, and just want a nice simple way to keep using BIND and implementing the new security for the domains I manage. I have googled till I have about turned blue, and maybe I am missing it, but I have seen some very complex keymanagement systems and so forth, I have no need for anything that complex, so figure I am missing the solution that is hiding someplace. Any pointers?? --- Howard Leadmon ___ 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 ___ 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: DNSSEC made simple, is this possible?
ISC is also, by pure luck, offering a web seminar on inline signing in BIND 9.9 today. While the first one starts in 15 minutes as I write this message, there are a total of three sessions today. Head on over to http://www.isc.org/webinar to find out the times and information on how to join. Sorry for my rather short answer before, but I wanted to check that this was indeed a public presentation before I sent people to a customer-only one. --Michael On Jan 11, 2012, at 9:31 AM, Howard Leadmon wrote: OK, in an attempt to start using DNSSEC over here, I suppose I bit myself in the backside, and even spending some time using googlefu I still haven't quite figured this all out. I am currently running the current BIND 9.8.1, and setup to support DNSSEC. After reading around a bit, I saw that setting auto-dnssec in the config would read in the keys and sign the zones automatically, this seemed in theory to be perfect, so I configured it this way. After that the domains were signed, and going to places like the verisign debugger showed my domain was happily secured with DNSSEC. Then I go to make a change to my DNS file, whoa was I in for a shock, as apparently BIND took my nice text file for DNS I have edited for ages, and converted it into a full signed zone. Try and edit that file, and if course it bitches about it no longer matching the .jnl file and drops the zone.This sure makes it hard to update things, well the way I am used to doing it. So I guess my million dollar question is, I want to use DNSSEC (it's actually working now), but I want to be able to edit my zone files the way I always have for many years, and just have BIND sign the zones with the keys and update as needed to keep DNS running smoothly. Is there some easy way to do this, some scripts someone has made, or some documentation to walk me through accomplishing this? I can't believe there aren't a lot of others that have run DNS just as I have for years and years, and just want a nice simple way to keep using BIND and implementing the new security for the domains I manage. I have googled till I have about turned blue, and maybe I am missing it, but I have seen some very complex keymanagement systems and so forth, I have no need for anything that complex, so figure I am missing the solution that is hiding someplace. Any pointers?? --- Howard Leadmon ___ 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 ___ 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: Botnet Malware issue on bind BIND 9.7.1-P2
I see many valid IP addresses in your list. But that said, are the responses going back large individually, or is it the number of them that is large? If you think this is attempting to crash the server with a single large answer, that's different than if your server is getting a lot of queries from others, where the number of them is large. Is your server crashing due to these queries? Are these clients ones you intend to provide service to? If not, can you limit access to your server to only those clients you intend to provide service for? --Michael On Dec 5, 2011, at 10:42 AM, jagan padhi wrote: Hi, There are huge request are coming frm the valid ip with .ws domain which are not exist and causes degrade the server performance. Thanks, Jagan www3.cbox.ws.barnasinternational.com. (65) 14:24:41.223958 IP 211.164.230.208.17125 103.145.184.40.domain: 64+ A? mlvabdz.ws. (28) 14:24:41.300652 IP 61.246.253.55.44111 208.73.210.76.domain: 47143 [1au] A? xoguzsdl.ws. (40) 14:24:41.338215 IP 211.178.172.128.fpitp 103.145.184.32.domain: 20686+ A? ppckbydtbr.ws. (31) 14:24:41.342505 IP 61.246.253.53.7628 208.73.210.76.domain: 28787 [1au] A? lodqbvd.ws. (39) 14:24:41.346545 IP 211.178.164.175.23186 103.145.184.32.domain: 2298+ A? jdzojm.ws. (27) 14:24:41.350427 IP 211.164.232.28.1028 103.145.184.32.domain: 52540+ A? ujtkmid.ws. (28) 14:24:41.518083 IP 211.174.99.37.10290 103.145.184.40.domain: 17039+ A? phkaxt.ws. (27) 14:24:41.597469 IP 61.246.253.53.53556 208.73.210.76.domain: 5848 [1au] A? jdzojm.ws. (38) 14:24:41.608805 IP 61.246.253.55.gbs-stp 208.73.210.76.domain: 60602 [1au] A? rvoykpdvuw.ws. (42) 14:24:41.613744 IP 211.174.93.126.10443 103.145.184.32.domain: 57+ A? yphpeqeq.ws. (29) 14:24:41.647610 IP 211.174.158.140.20813 103.145.184.32.domain: 119+ A? qhfibjvct.ws. (30) 14:24:41.648165 IP 211.174.158.140.20814 103.145.184.40.domain: 119+ A? qhfibjvct.ws. (30) 14:24:41.649318 IP 211.174.158.140.20813 103.145.184.32.domain: 120+ A? aplsmxcne.ws. (30) 14:24:41.650589 IP 211.174.158.140.20814 103.145.184.40.domain: 120+ A? aplsmxcne.ws. (30) 14:24:41.651435 IP 211.174.69.219.fpitp 103.145.184.32.domain: 18969+ A? xoguzsdl.ws. (29) 14:24:41.802136 IP 211.174.110.194.mcp-port 103.145.184.32.domain: 63099+ A? ujtkmid.ws. (28) 14:24:41.828624 IP 211.174.77.240.12803 103.145.184.32.domain: 42241+ A? ujtkmid.ws. (28) 14:24:41.896891 IP 211.174.96.42.10349 103.145.184.32.domain: 10320+ A? rvoykpdvuw.ws.HUL-RS.COM. (42) 14:24:41.951168 IP 211.174.76.161.directv-tick 103.145.184.32.domain: 51760+ A? jdzojm.ws. (27) 14:24:41.978719 IP 61.246.253.51.60690 208.73.210.76.domain: 22757 A? ppckbydtbr.ws. (31) 14:24:41.992364 IP 211.178.145.35.18834 103.145.184.40.domain: 102+ A? bfrdqsraipi.ws. (32) 14:24:41.995598 IP 211.164.42.255.iad1 103.145.184.32.domain: 62681+ A? mdbyqndydim.ws. (32) 14:24:41.998899 IP 211.164.42.255.1028 103.145.184.32.domain: 49093+ A? xopcz.ws. (26) 14:24:41.999731 IP 211.174.98.2.unet 103.145.184.32.domain: 8066+ A? plzpbuzykzi.ws. (32) 14:24:42.063680 IP 211.164.24.202.traversal 103.145.184.32.domain: 29788+ A? mlvabdz.ws. (28) 14:24:42.080591 IP 211.178.149.74.26153 103.145.184.40.domain: 94+ A? plzpbuzykzi.ws. (32) 14:24:42.081309 IP 211.178.149.74.26152 103.145.184.32.domain: 94+ A? plzpbuzykzi.ws. (32) 14:24:42.083018 IP 211.178.149.74.26153 103.145.184.40.domain: 95+ A? ofqliyah.ws. (29) 14:24:42.084333 IP 211.178.149.74.26152 103.145.184.32.domain: 95+ A? ofqliyah.ws. (29) 14:24:42.212815 IP 211.164.230.208.17132 103.145.184.40.domain: 73+ A? mlvabdz.ws. (28) 14:24:42.213857 IP 211.164.230.208.17133 103.145.184.32.domain: 73+ A? mlvabdz.ws. (28) 14:24:42.254075 IP 211.178.182.51.17331 103.145.184.32.domain: 31124+ A? xopcz.ws. (26) 14:24:42.257642 IP 211.174.43.2.21902 103.145.184.32.domain: 22199+ A? vqdqp.ws. (26) 14:24:42.257967 IP 61.246.253.53.62271 208.73.210.76.domain: 10273 A? xoguzsdl.ws. (29) 14:24:42.259110 IP 211.174.43.2.21919 103.145.184.32.domain: 22704+ A? kuatmftlz.ws. (30) 14:24:42.360653 IP 211.165.222.201.av-emb-config 103.145.184.32.domain: 16608+ A? phkaxt.ws. (27) 14:24:42.376847 IP 211.174.36.28.danf-ak2 103.145.184.32.domain: 18594+ A? xopcz.ws. (26) 14:24:42.389801 IP 211.164.230.208.17132 103.145.184.40.domain: 75+ A? mlvabdz.ws.DOMAIN. (35) 14:24:42.390902 IP 211.164.230.208.17133 103.145.184.32.domain: 75+ A? mlvabdz.ws.DOMAIN. (35) 14:24:42.392527 IP 61.246.253.51.36056 192.36.148.17.domain: 18602 [1au] A? mlvabdz.ws.DOMAIN. (46) 14:24:42.393726 IP 61.246.253.55.43598 192.33.4.12.domain: 42970 [1au] A? mlvabdz.ws.DOMAIN. (46) 14:24:42.398797 IP 61.246.253.51.30802 208.73.210.76.domain: 1409 A? kuatmftlz.ws. (30) 14:24:42.424327 IP 211.165.57.59.10944 103.145.184.32.domain: 4917+ A? ymkvpdpwls.ws. (31) 14:24:42.432527
Re: nanny (was Re: bind-9.8.1: INSIST(! dns_rdataset_isassociated(sigrdataset)) failed)
On Nov 18, 2011, at 4:44 AM, G.W. Haywood wrote: Never in several machine decades have I had to do anything like that for BIND. The fact that people are even talking about it is of some concern to me. Twice in approximately the last month I have had one particular server go down for no apparent reason. This machine runs BIND. I keep its copy of BIND fairly well up to date. It has been running 24/7 for well over a decade with typically a couple of years between reboots. I have no evidence that BIND was the culprit, but in view of recent events elsewhere it seems just a little suspicious. Speaking as one of the original BIND 9 authors, I am happy to hear you have never needed a nanny script. I don't think the need has significantly increased on average, but BIND is complex software, and there are bugs. I am using monit for my servers -- all of the things my servers do -- because it will restart and notify me in the case of a crash. I've triggered the BIND restart many times, usually when I kill it or tell it to stop, or I am running pre-release code on one of the two name servers I run. BIND rarely crashes, but can crash. The same is said for Apache, sshd, the 10's of helper scripts I run for various web sites, database engines (although on my system those just report failure and stay down) -- even the mail server itself can crash. That said, while it is not necessary to use a nanny script, I do find your statement sort of backwards from what I think of as best practice. If an attacker can remotely crash a daemon while attacking it, that seems scary to me; I'd ensure it was started on some alternate port if I could at least, so I always had a back door and if it runs as root, get that crash fixed. A crash is only one step away from a code execution exploit often enough. BIND 9 has taken extra steps to convert this type of flaw into an intentional crash rather than a random, unexpected, and undiagnosed cause. No software is perfect. I'd run all services I consider critical with monit or some other advanced keep the daemon running and report when it fails system. God, Monit, and there are probably others I've not tried, all keep things going so I don't have to. BTW, I also run sshd on a second port, with a second instance of the daemon, just in case the primary fails. Or I have to firewall it off quickly. :) --Michael ___ 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: dnssec-keygen not responding
I'm using an Araneus Alea I, from http://www.araneus.fi/products-alea-eng.html. I'm sure others would work as well. I know the creator of this device personally though, so it's the one sticking out of the back of the box I own. :) As for the daemon, well, I may have to find the time to clean it up. :) Basically, I map the USB dongle into one VM I use for control stuff that doesn't run anything else, and is running a scaled down NetBSD install under VMWare. The daemon accepts connections over TCP, and sends chunks of randomness to whoever asks, as much as they request, when it is available. The receiver then encrypts the data with a 128-bit key to scramble it further, and feeds it into the system's random pool. From there on, /dev/random just works. It basically attempts to keep the random pool full, so while /dev/random may block, it won't do so for very long. I believe the daemon checks once every 100ms or so. --Michael On Dec 1, 2011, at 5:17 AM, Jan-Piet Mens wrote: On Wed Nov 30 2011 at 20:45:30 CET, Michael Graff wrote: For my VM environment, I bought a USB random source, and share it across the VMs with a little daemon I wrote. Would you be willing to give us a few more details, such as the name of the USB random source generator (is it an Entropy Key) ? Of course, if you do tell us what hardware you're using, the next thing will be we'll want a copy of your unofficial little daemon ... ;-) Regards, -JP ___ 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: Choosing max-journal-size
On Nov 30, 2011, at 4:09 AM, Matus UHLAR - fantomas wrote: On 11/29/2011 11:33 PM, Chris Thompson wrote: I wonder if an external tool to trim the journal would be an option? You'd need a timestamp on records (relying on the RRSIGs mean it only works for signed). Not sure about the locking implications. In general, BIND should handle trimming. I think this is something BIND should take care about. Does BIND veridy the journal not to exceed usefull size? There are three issues that I see in our journal files: (1) The default size is unlimited. (2) To shrink the journal, we copy the more recent half (or some part anyway) to a new file. For large journals, this is significant time and I/O. (3) Because of (2) and other reasons, even if you set a max journal size, we don't always respect it. (1) is fixable easily. We could even estimate based on sizes internally to BIND. We may get the guess wrong for some, but I would submit that unlimited is ALWAYS wrong. (2) is harder to fix. I once proposed we used SQLite for storage, so we could expire records very quickly without re-writing the journal files. I also once proposed that we used two files, each of which was 50% of the max size, and would just delete the older half when needed. Either fix is reasonable. (3) is an admin expectations problem. If you run 9.4 or earlier still, you are aware that our cache size also did not respect the administrator set maximum. 9.5 and later fixed that, and this is one more case where complete correctness of operation interferes with expectations. We have had journal file issues like this on our road map for some time now. However, there always seems to be a more pressing issue. Perhaps it would be possible for some contributed solutions? If so, contact me directly. I'm sure someone has an intern or programmer to spare for a bit :) --Michael ___ 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: dnssec-keygen not responding
On Nov 30, 2011, at 3:01 AM, Torsten Segner wrote: In RHEL there is a RPM package called unuran. It's a random number generator daemon using either a piece of hardware or /dev/urandom as source. Running this will provide enough entropy to create lots of keys. I'd be rather wary of keys made from /dev/urandom but I am often times a paranoid security freak. For my VM environment, I bought a USB random source, and share it across the VMs with a little daemon I wrote. Of course, you could just map the RNG into the VM you need too, and even move it around. --Michael ___ 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: found a bug in bind9.7.3
Hello 张海阔, I've opened a bug ticket for this one. I don't know that bind-users is a good place to continue discussions, but consider perhaps bind-workers (which is more for coders). I'll send you a link to the bug in separate message. --Michael On Nov 30, 2011, at 6:09 AM, 张海阔 wrote: hello, bind-users, I found a bug at openssl patch in bind 9.7.3. pk11_active_add function should be called with the active list lock protection in pk11_get_private_rsa_key function at hw_pk11so_pub.c file, but it is not locked. the other question is that why pFuncList-C_Finalize is commented in pk11_finish funciton at hw_pk11so.c? you said calling this function may have side-effects. I don't know what is the side-effects, can you tall me something detail about the side-effects? Regards ___ 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 ___ 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: OT: Bind 9.9.0B1 Inline-Signing Question
Do you see that each time named starts or just on the first load of the zone? What happens if you send a query to the server with dig +dnssec? On Nov 10, 2011, at 14:23, McConville, Kevin kmcconvi...@albany.edu wrote: I know that this isn’t the forum for betas, which is why I put off-topic on the subject line. We are trying to implement DNSSEC for our static zones. While the dynamic signing has been automated, static inline-signing isn’t available until Bind 9.9 We have been testing with the alphas and now with the beta. What we are seeing is that whenever named starts, it initially creates the signed static zone file, but never really finishes. The logging shows: 10-Nov-2011 14:38:14.766 general: error: zone xx.org/IN (signed): not loaded due to errors. 10-Nov-2011 14:38:14.766 general: info: zone localhost/IN: loaded serial 42 10-Nov-2011 14:38:14.767 general: notice: all zones loaded 10-Nov-2011 14:38:14.768 general: notice: running 10-Nov-2011 14:38:14.768 general: info: zone xx.org/IN (signed): loaded serial 200905 10-Nov-2011 14:38:14.768 notify: info: zone xx.org/IN /IN (signed): sending notifies (serial 200905) So, it doesn’t load the zone due to errors, but then later claims to load the same zone file. Has anyone been able to get the inline-signing function to work? I’ve triple-checked my named.conf, ran named-checkzone, went to a vanilla zone file, and even tested the zone file as dynamic (which worked). Any ideas or suggestions of where to check next are greatly appreciated. Thanks, -Kevin Kevin McConville University at Albany ___ 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 ___ 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: Securing zone transfer and DDNS
Are you saying you cannot compile from source, or that you must use the vendor supplied version of bind? On Nov 7, 2011, at 10:04, Aleksander Kurczyk aleksanderkurc...@o2.pl wrote: I'm using Mac OS X 10.4.11 Tiger on G4 400 MHz PPC Mac and BIND 9.7.4 is the last version that I'm able to use. ___ 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: inline-signing
I opened a ticket on Tony's behalf so we can track the crash problem and the other defects he mentioned. As I told him there, the master functionality is still a work in progress, and the code's not there yet. Soon. Thank you Tony for giving this a try as an alpha! Your time is appreciated. --Michael ___ 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: NXDOMAIN redirection in BIND 9.9
On Sep 29, 2011, at 4:06 PM, Bill Owens wrote: I've obviously been asleep and not following along with the announcements of new features in BIND 9.9 until today I'm happy you read it, and hope to see you at the forum/customer webinar next week! I'll be speaking, and will bring my fireproof undies. . . . both Evan's blog post http://www.isc.org/community/blog/201109/isc-bind-990a1-feature-preview and the announcement of next week's webinar include NXDOMAIN redirection as the first new feature. I'm really surprised by that - is this something that BIND users were clamoring for? Yes. Or is it a situation where other servers were providing this feature, and BIND needed it to maintain parity? Yes. Obviously those of us who find this idea disturbing don't need to enable it, and DNSSEC provides an effective defense against those who would enable it* but it still leaves me curious. We came to the conclusion that no matter how much we wanted it to not be true, people find a way to do NXDOMAIN if they want to. The issue is not ours to push, it's between the ISP and the customer ultimately, and people will do it -- and more intrusively -- than BIND 9.9 will. *except that perhaps those who enable this feature will use it as an excuse to avoid enabling validation, which would be a very bad result, IMO. . . That's perhaps the case, but once again, it's up to the ISP ultimately. Don't think that just because BIND 9 didn't do this before, that people didn't. They instead use a proxy which filters answers, for instance, and returns whatever they want to the customer. --Michael ___ 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: CNAME or A record?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-09-28 9:36 AM, feralert wrote: Thanks Jeff, But I really only wrote that as an example :) . The real question is what is best or what is recommended, two A RR (one for domain, one for www) or a single A RR for domain and a CNAME RR for www, is one way better than the other or can I choose either way? Choose either way. If they are in the same domain, in general it won't matter all that much. I personally prefer the address method so each DNS request is smaller and absolute, but others prefer the CNAME method. If you cross a zone, however, remember that the address method does not require additional DNS queries to be sent, while the CNAME method would. That said, I believe most CDN type networks require a CNAME as the addresses a specific user would get varies greatly, so that lookup is not much of an impact it seems. - -- - --Michael ISC offers support on many of its products, including BIND 9. If you depend on it, depend on us! See http://www.isc.org/support/ for all the details. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6DNCQACgkQLdqv0r6eD6a83gCdEFlS+pvqQPo8UKJfJPGD+d4T xsMAnjusN2fMbBwfvXqhSD24peDH1r5D =8rLm -END PGP SIGNATURE- attachment: mgraff.vcf___ 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: faster fail-over between multiple masters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-08-30 12:06 PM, Klaus Darilion wrote: Unfortunately I fail to find the options where I can configure the number of retransmissions, timeouts and number of transactions - please give me some hints. I don't believe there are external knobs for this behavior. I can think of several possible fixes here: (1) if we get a notify during a SOA check, proceed as usual but flag this so we will just start another SOA check. We may transfer the zone between these checks (and probably should.) (2) send all SOA requests in parallel, and use an overall max time to wait (perhaps 20 seconds) and re-send the SOA to servers which have not responded every 4 seconds. This limits the total time an SOA check will take. (3) If any of the servers respond with better SOA serial numbers than we have, transfer from the masters as listed in the config file or whichever is better, depending on current behavior. I do not know when we would be able to get to this change, but I'll put them on the back-log for future releases. If you want to go code diving, you can likely find the timeouts and change the behavior for your servers. However, you'll have to track this each time we do a release for the foreseeable future. - -- - --Michael ISC offers support on many of its products, including BIND 9. If you depend on it, depend on us! See http://www.isc.org/support/ for all the details. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5dLQYACgkQLdqv0r6eD6aGmACdGXG8oXQyB2XeZD0x4n8L5K7L JooAn3qhx18/S2fCiJdsYP1zfLf0rz69 =vGoU -END PGP SIGNATURE- attachment: mgraff.vcf___ 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: DNSSEC : once correct, always correct ?
Yes. It is correct behavior. There is no revoke method for a publisher. I don't think adding one would be wise. --Michael (from an iPhone) On Aug 17, 2011, at 7:18, Marc Lampo marc.la...@eurid.eu wrote: Hello, Experimenting with key roll-over timing conditions, with a Bind 9.7.3 setup, I noticed, today, that this version does not re-validate DNSSEC data, once something makes it into its cache. I wonder though, if that is correct ? What I noticed : - some data (with long TTL) is queried for a first time -- answer is with AD bit set (I know : for info only) and with corresponding RRSIG (generated with old ZSK) - then I replaced the ZSK : old ZSK -- new ZSK (a quick ZSK roll-over) and resigned the zone -- new RRSIG (generated with new ZSK) - when the DNSKEY RRset timed-out from the caching name server, I queried for the same data again (to my surprise) -- the answer is again with AD bit set, and again with the (old) RRSIG (querylog from the auth NS does not show any query for DNSKEY information) - indeed, when queried for DNSKEY RRset, with +norecurse, -- no DNSKEY's in the cache, 0 returned - when queried for DNSKEY RRset, *without* +norecurse, -- *new* DNSKEY RRset is in the cache (in the cache are now both the *old* RRSIG and the *new* ZSK) - again : querying for the initial data (with long TTL) still yields the old RRSIG (that cannot be decrypted with the new DNSKEY) It looks like once DNSSEC'd data validates correctly, that version of Bind will keep reusing that data (until TTL expires). While it may make sense, to save on CPU cycles, I am unsure if that behaviour is correct : suppose a validating *forwarding* name server (or validating resolvers in clients, once we they become available) addresses this caching name server in that condition. It would : 1) receive, from the cache, the data + (old) RRSIG 2) when queried for it, because the forwarding name server wants to validate, it will deliver the (new) DNSKEY's -- validation should now fail !!! Very confusing for debugging : One validating name server yields AD-'d data; the other, using the first one, yields SERVFAIL ... If I overlooked something obvious, sorry for the interrupt (but thanks for sending clarifying references). Thanks and kind regards, Marc Lampo Security Officer EURid Woluwelaan 150 1831 Diegem - Belgium marc.la...@eurid.eu http://www.eurid.eu Want a .eu web address in your own language? Find out how so you don’t miss out! ___ 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 ___ 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: Patching bind for additional stats - any tips?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am very interested in hearing what you are looking for. I have some thoughts about performance measurements, mostly to answer the age-old question, Are my servers working well? Would you release the patches, and if so, would you be willing to work with the ISC BIND 9 team to see if we can find common ground and perhaps get your patches into BIND 9 releases quickly? - --Michael On 7/18/11 8:13 PM, Alex Kolchinski wrote: Hi everyone - I'm at Google and currently starting on a mini-project to get some more insight into how our BIND servers are performing. Our first thoughts on how to add logging on metrics we're interested in are currently to patch BIND to spit out the wanted stats directly from BIND (data on each query, perhaps aggregated). An alternative to this would be to try to match the incoming and outgoing request and response packets and amass the data from that, but our attempts at data gathering through sniffing have given unreliable results. (One alternative I've stumbled upon is DSC - http://dns.measurement-factory.com/tools/dsc/ - but I'm not sure yet how appropriate or effective it would be for our needs, so if anyone has any thoughts, that would be much appreciated.) I've never worked with BIND before, so I'm looking over the code right now figuring out which approach is going to be the most effective and straightforward. Does anyone have any experience with something similar and/or suggestions on approaches or considerations to think about? It's looking like if the patch is going to be the way to go, simply modifying BIND's stats-outputting functionality should be a good way to extend what statistics we're getting, although I'm not sure on that count either. Any thoughts? Thanks, everyone -Alex ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOJTzQAAoJEDRzoY2A7tzbJqYH/1wfTSTp9VBz+VTurD4pJDpi Zsr2JY+jo/G6VPluAN5G1ZnjqvtVlmqoagSBy5nRtA0qkp9kGiWWboDA5b3uEnEK sqeAy7ns0j8Mp8Lp8i5WyxMSm1QiPQUO93sLoQqMcWwWVcVsw/oWM0OZnucvR/a2 puLR865BmFTtgp0gg/nzaCrls2J+8kY8nxmo2iSAEfn17v0H3T9DqHNwhFR3D4f6 /7V8nP8Ts0F0RRMPLLkx7K4qGNjTy7ha24P+2gzK/w/TkTbVLCXv8UJHK08f3TEM uW5LQJnsrOFxLDWHsXUrzS323sLQtQo616Rbw2PZwBM7Cx4x0UNgLFgAjlSzUU8= =D35/ -END PGP SIGNATURE- ___ 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: bind9.xsl vs. /bind9.xsl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-14 2:28 PM, Chris Thompson wrote: So is there anything that could go wrong if the style sheet reference *was* relative rather than absolute? Not that I can see. It's probably that we never considered that use case. Send in a bug report, it seems like a quick fix and one that should help your use case and not affect others. - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4fU3sACgkQLdqv0r6eD6aSDgCffbs0xEm1bcez/+Qx0TJfybsW wFkAmQFOgvpFJtPn0rYC3A+Z0XED4HCa =VB7Q -END PGP SIGNATURE- ___ 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: better performance with 32 bit ! why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/29/11 8:19 AM, Eivind Olsen wrote: Really? I thought you said the 64 bit server had a CPU with 1.6GHz cores, and the 32 bit server had 2.33GHz cores? Benchmarking on different machine types, even if they are identical speed, can be affected by any number of issues: ethernet card type, motherboard chipset, etc. Even features chosen on an identical chipset. For true comparison, one must run the 32-bit OS on the same hardware (not just similar hardware) to do a direct comparison. That said, more is not always better. 64-bit means it can move more memory around faster in certain circumstances, and it can address more than 4 GB without pulling special hardware tricks. That said, it MUST move around double the memory in certain operations, like pointers. BIND 9 uses a fair number of pointers, so often times the overhead increases faster than the benefit of a larger accessible memory area. - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC0ErAAoJEDRzoY2A7tzb+sgH/2svm6VPTa8OTm6L3H+Rq0QY 5pHQsT55GoclIZ+ttTQBouz8bla4QIJ53Cwjpw1bnBFrH6LEIR0vWDalBA5RUmX/ 7ZVqShxhvI2MfpYaramFJEjocDMcDxxt4mmFk+StvqATaENJSaqfXxpXHpqViDoK Et5a+npBaHfqPCyVWKO3VUlgSMhqFo6xIUSGhuXl7spe65zPEBfat5/Kea8S+puS wynsW+M7/Steqh5yLOdN9oD/wWQNSqOXSRZFpGliZNuFyrk90dWB0T+cyXMki7Jd Ls+fAyE7Z0jKPJIE0ttgJ0ditSXOFzW4oQmMfxd4eN+WzTDRXAF/zJUcsvGCMos= =IwZR -END PGP SIGNATURE- ___ 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
Large number of small zones in BIND? We have something for you to try.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We've been working on the start-up time of BIND 9, when many many zones are configured. By many, I mean in the 10k to 1m range. If you are someone who has a large number of zones loaded into BIND 9, and would like to try out some test code to see if our work improves your load time, please contact me. This is another CPU time / memory trade-off, but we don't think the overhead will be significant. If you choose to test, we will want you to report your original and hopefully-improved start-up time, original and new memory usage, and of course any problems you encounter. I have set the reply-to address for this mail to myself; if you want to discuss this on the list, please do so but set it back to the list address. Thanks! Please include the following: Number of zones loaded: BIND 9 version in use: Can you test with a different, developmental version? Would you test in your lab or production? If we got code to you this or next week, when could you complete your measurements? - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC1J4AAoJEDRzoY2A7tzb9qkH/j6ruhDfJjvZrwOlK67y6Txs R/jcQuMcJxLOwxFDl2+Rl6SGEBAc7AuK7sZRZxlAlxd6UFyLP3t9NHqkHHizdXKX 0/k85mbAS+BKaJ7s9kc4nr/54bYSqx/seaTPBE5Jz8z+0PqBzsRxveDLWDvcETyp DM/ck5Zs8CoyL5w4pv3kKM7u3v3XMXb2G3egvM3VS38n7qyd86+Czq0W0hCHnhaB 6yZh5Ms9oYzkzINYRQAr5Hhk09Kvw++wVfEQ2dFdxYYWs5eHQDq8MWC4CbWs4fqZ 9p1hc61uycCpglUaP9FcLiapzsVWlIvsYPY4uoh1DZYmwpoahuW7ZIQylOx9dI0= =M6cr -END PGP SIGNATURE- ___ 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: better performance with 32 bit ! why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/29/11 9:08 AM, Sven Eschenberg wrote: Maybe some bind developer can shed a light on this: Does bind use epoll()? AIO (as in Posix RT extensions) BIND 9 uses epoll() I believe, but AFAIK does not touch AIO. I've not touched that code recently though, so this is possibly out of date information. Also, which version of BIND 9.x introduced the epoll() I am not certain of. That said, the single biggest problem in BIND 9 currently in terms of using all CPUs on a high-core machine is that all initial I/O is processed on a single core per UDP socket. Thus, you had 32 real cores in a server today and would use this beast for DNS, you'd not be happy unless you somehow spread this across multiple UDP listening sockets. We're working on this though. As with all things, we work on the things that are most important to our customers and users, so making your voice heard that this is important is helpful to us. Running code is always good too, as is a monetary donation for a development effort you want to see moving forward faster. - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC1eJAAoJEDRzoY2A7tzbOTYH+wZUawX9R+dH6weqxXlyTLL+ 48OtpAh/DHDyPGFCa7O3IDuYdvNr455oAoSzN4qSLV/gEAKsRCLC3mxa90Fit367 r4goLR4uC96DYMKWdUJzsruxqeyUcET1xbNRWiz+g5M40ZJf0YYpW4mIlGls+9UP lXyFiCAxESTmklYNrwTy++m4Hz8JjuV9FsbXzvlu0IyQR+qdbsZ3xYleHblawb1b Q57hpXvcmpxI4e7hRrj0Q2QdfZKk87+LXiErWbhaqui/hOw89PAlF7HR1J8vwLtj maBil2+UV3kSUtF3EVoFasuQKUTYWM14uqYA4Eu3RbHWVf4VJuZ1+gB3dhtbBh0= =7Qi6 -END PGP SIGNATURE- ___ 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: better performance with 32 bit ! why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/29/11 9:16 AM, iharrathi@orange-ftgroup.com wrote: Do i have to use bind compiled and running on 32 bit server to have better performance rather than bind compiled and running on 64 bit server? No matter what, what gets you the best performance is what you should choose to do. BIND 9 does not currently benefit as much from more cores, but does from more powerful cores. I suspect this is what is happening in your tests. The 4 core machine is able to be fully utilized, and each core is faster. In the 8 core machine, you are not only doubling the amount of data needed to be moved around in some cases, you are lowering the core speed. If BIND uses perhaps 6 of the cores, with the typical 64-bit overhead of more data and more effort on the system, you are losing performance. Also, like mentioned by several here, you are not using identical machines. When you benchmark and compare results, you want to minimize the differences or at least account for them. Your machine is not just made of CPUs, it has memory (which may vary in speed), network cards and the drivers (which may be better or worse depending in the card and drivers), and motherboard chipsets in use. There are just too many variables to account for in your comparison that we cannot really help with. Thus, the only answer that is ultimately important to you is, on this new hardware, how can I make BIND 9 run fastest? If that turns out to be a 32-bit OS or a 32-bit named binary, that's your answer. - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC2bZAAoJEDRzoY2A7tzbkf8H/iIOCnEUfz8p6AtTBzuxcRag z5R4f4C9vVd2MtqvYbN4BxrLz8dfqlgYM4ZAtIB7HyQnFnkeNuxIiqc1PDec6866 mpk/COSF+RP+mzMqenEbWcYOPl/giVq/0qFL+oqiD9Fq4PQCltsgCwMSf65fLdgH CoutRsM8AAO3cJ6N80PIlAMe0kocP6K/MBGJyaJznKhZR/TusKCdRP9cg9xc9h51 Y6XlflaOE6EKXq9pv49JupUxSN6Fk5pVJ+jsBmr6wLroQIZpVZRK9Zm2idbvtrC5 L8EaeDgeYNJRCNglOT5kwYydAt/g3SvGkgm9Q1zNk+HqX18EeNTNqZqK31yETBo= =ZSz9 -END PGP SIGNATURE- ___ 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: better performance with 32 bit ! why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/29/11 3:00 PM, Sven Eschenberg wrote: One thing that just popped up my mind: Does it increase performance, when you, let's say, bind multiple IPs to the same NIC and make bind listen to all of those IPs, while of course taking care to fix the corresponding NS RRs to contact all of thos IPs. In general, yes. If the NIC can handle the data flow well, and the OS kernel can handle the multiple UDP sockets well. I've seen some people work around BIND 9's implementation by using 3 sockets on the same host, either on different IP addresses or on different ports, and use an external load balancer to make them appear as a singe entity to the outside world, as well as allow them to be used directly if on different addresses. ISC is addressing this limitation. It's pretty clear more cores are in our future, not more CPU per core. *hugs his 8-core 3.00 Ghz Xeon box* :) A lot of work has been done in TCP-land to enable web applications, and this means UDP has somewhat fallen to the wayside. After all, there aren't a lot of applications that use UDP and really expect high data rates, right? :) I've seen some kernels (to remain nameless) that use one giant lock for all UDP input in the kernel, and while this is a short-lived lock, it is a contention point. If listening on more than one socket still has this bottleneck there isn't much to do about it. - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC5e1AAoJEDRzoY2A7tzbQBkH/0/4PHvUKK6/fxw4/s5P+8Oy V3+RqCF3P1rSNAxnjJNv0r7Lcbflene/zCUol7/wjob20vpLdld5ummRPo76H5vZ gm5rIbYRZQ7W85dTT++f+rOawO7g6DEJNB3vJvH4WucoON4dhfSL4IMHkE0eWxEs 3nhG7bp6yExoXlO10Ug4LzDMux8saYBykWkGOBJSXCQ8eZfs5dPMU/N1DcjXgYUg h5UGgS8l4QfIycidcPen62VOdExrNEjD36E8tDBv/SA8U+D0wLfYRbptvvSsx5kT 5OYL3tkB8A0nsodHsj2cjnl3KclElN0yZTqYPf/ZOn0kfdsBkPc0lc2a0q0uGGU= =GyI9 -END PGP SIGNATURE- ___ 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: better performance with 32 bit ! why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/29/11 4:28 PM, Sven Eschenberg wrote: P.S.: If all parts of bind were optimized towards multicore processing and the pattern of queries fits, yes, then the 8 core machine could probably outrun the 4 core machine, even when having a slower clock. But this might worsen the performance on single or dual core CPUs on the other hand. We hope to improve this in 9.9 or at the latest 9.10, and have something that can saturate all CPUs. And no, we're not cracking RSA keys on the extra CPUs just to keep them busy! - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOC6rwAAoJEDRzoY2A7tzbS9YH/2t6ohywrYjmX6xvg/Dshq5F 7cjirVvoE4jCarVREPWoL3vTAEUmehMccSIq6NRw9Uqb/Mrwa/UoNe9lN0D9r5zy 47trPsORG3kQW0T+znkO4zizlC4goKS4MBjasuXMKOYMtSizdi4pRBWBI6uaVgdG fnGhPpK6s6bKFpH7labYnz32cBQW1P9FxyNV+aFgW/A8EJdhRbEMrTsbZHYFpoQO mpVuvYoQOljCfjYhqpch/hsxdGdJO2w2XIqLpbWe4Etdt7OScuCbWfhmTnVrFP2Q J6fcx2WmrHh5neOWkGe7jEanPBG6ajrMyBUZH5qClVQTYPYRu9TlRgti7RFCm3M= =ndSh -END PGP SIGNATURE- ___ 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
