Re: BIND 9.9.1-P1 reload bug
Known issue being tracked as RT #29872. In message <4ffd89c1.4080...@kit.edu>, "Harald A. Irmer" writes: > Hi all, > > This just happened on our nameserver: > > 11-Jul-2012 13:54:01.711 general: info: received control channel command > 'reload' > 11-Jul-2012 13:54:01.712 general: info: loading configuration from > '/etc/named.conf' > 11-Jul-2012 13:54:01.891 general: critical: server.c:4436: fatal error: > 11-Jul-2012 13:54:01.891 general: critical: RUNTIME_CHECK(result == 0) > failed > 11-Jul-2012 13:54:01.891 general: critical: exiting (due to fatal error > in library) > > > Best wishes, > > Harald > > -- > > Karlsruhe Institute of Technology (KIT) > ATIS - IT Infrastruture and Services, Faculty of Computer Science > > Harald A. Irmer > IT Manager / Computer Networks Group > > Am Fasanengarten 5 > Building 50.34 > 76131 Karlsruhe, Germany > > Phone: +49 721 608-46963 > Fax: +49 721 608-46699 > Email: harald.ir...@kit.edu > http://www.kit.edu/ > > KIT University of the State of Baden-Wuerttemberg and > National Laboratory of the Helmholtz Association > > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
recursive-clients recommended values
Sorry for the repeat post.. but I know that the value of 'recursive-clients' option is based on: 1. Query rate 2. RAM size and various other factors. I vaguely recollect that it is 90 x x , but I forgot why... I searched earlier posts but noticed that people are recommending it to just increase it to suppress the errors in log. Any pointers on this? thanks blr ___ 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: Operation Cancelled Error
I am doing load testing on our local caching dns.But while doing it , i added google dns and some other dns ips as forwarder to test QPS. Even if I am not using any forwarder in that case also, I am having those same error which i was getting. I am confusing that those errors are due to bind misconfiguration or something else? If someone share his experience with it, What are the maximum QPS handled by bind? that is good to understand more. Regards, Ben Hi Ben, At 05:37 11-07-2012, Ben wrote: Actually, I am doing load testing with my CACHING DNS SERVER, and for that i setup one client machine which sent queries to CACHING DNS SERVER, and while doing this , i got below given erros in log.So is point to any network problem or any fine tunning / configuration required to bind? I am using google public dns ips as forwarder in named.conf Are you doing load testing on Google's DNS server? Regards, -sm ___ 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: Survey - how many people running ISP nameservers define "minimal-responses" - was Re: What is the deal on missing "Authority Section" and "additional section" from google's DNS servers?
In message , Barry Margolin writes: > In article , > "Michael Hoskins (michoski)" wrote: > > > while it's largely personal preference -- i generally like to "be > > conservative in what i send, and liberal in what i accept": > > > > http://en.wikipedia.org/wiki/Robustness_principle > > This doesn't refer to quantity, but to how strictly you should adhere to > the specification. > > > it's not violating RFCs to send the full data so it's not technically > > "wrong". however, if sending back too much data is known to cause > > problems in some cases and can potentially be used against you...then it > > seems wise to take the minimal path. > > As long as you stay under the traditional 500 byte limit, I think you're > being conservative enough. "Liberal" would be depending on EDNS0 > extensions. EDNS is initiated by the client so there is no issue here. > However, I think it's reasonable to adhere to the following policy: > > Caching nameserver: minimal-responses yes. The clients of these are > primarily stub resolvers, which probably won't cache the additional > data, so it's a waste of bandwidth and could potentially cause problems. Except for MTA's which know to look for A/ records in the additional section. There is no cache poisioning issue with stub resolvers as they will be talking to the same recursive servers. > Authoritative nameserver: minimal-responses no. The clients are almost > all caching nameservers, and they'll cache what they can. > > -- > Barry Margolin > Arlington, MA > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Survey - how many people running ISP nameservers define "minimal-responses" - was Re: What is the deal on missing "Authority Section" and "additional section" from google's DNS servers?
In article , "Michael Hoskins (michoski)" wrote: > while it's largely personal preference -- i generally like to "be > conservative in what i send, and liberal in what i accept": > > http://en.wikipedia.org/wiki/Robustness_principle This doesn't refer to quantity, but to how strictly you should adhere to the specification. > it's not violating RFCs to send the full data so it's not technically > "wrong". however, if sending back too much data is known to cause > problems in some cases and can potentially be used against you...then it > seems wise to take the minimal path. As long as you stay under the traditional 500 byte limit, I think you're being conservative enough. "Liberal" would be depending on EDNS0 extensions. However, I think it's reasonable to adhere to the following policy: Caching nameserver: minimal-responses yes. The clients of these are primarily stub resolvers, which probably won't cache the additional data, so it's a waste of bandwidth and could potentially cause problems. Authoritative nameserver: minimal-responses no. The clients are almost all caching nameservers, and they'll cache what they can. -- Barry Margolin Arlington, MA ___ 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: Survey - how many people running ISP nameservers define "minimal-responses" - was Re: What is the deal on missing "Authority Section" and "additional section" from google's DNS servers?
-Original Message- From: Ted Mittelstaedt Date: Wednesday, July 11, 2012 11:26 AM To: "bind-users@lists.isc.org" Subject: Survey - how many people running ISP nameservers define "minimal-responses" - was Re: What is the deal on missing "Authority Section" and "additional section" from google's DNS servers? >Great answers to my question, thanks! > >So now, what do you guys all run? > >I have always followed the principle of "provide the most information >possible and let the users decide what to ignore" which is why I never >gave a second thought to providing additional data. i run minimal-responses externally, and provide full data internally where bandwidth is cheap and i'm less concerned over use cases. >But if as Warren said: > >"...Many things (correctly (IMO)) ignore the info in additional section >due to past entertainment with cache poising, etc" > >then what would be best practices for an ISP? while it's largely personal preference -- i generally like to "be conservative in what i send, and liberal in what i accept": http://en.wikipedia.org/wiki/Robustness_principle it's not violating RFCs to send the full data so it's not technically "wrong". however, if sending back too much data is known to cause problems in some cases and can potentially be used against you...then it seems wise to take the minimal path. ___ 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
Survey - how many people running ISP nameservers define "minimal-responses" - was Re: What is the deal on missing "Authority Section" and "additional section" from google's DNS servers?
Great answers to my question, thanks! So now, what do you guys all run? I have always followed the principle of "provide the most information possible and let the users decide what to ignore" which is why I never gave a second thought to providing additional data. But if as Warren said: "...Many things (correctly (IMO)) ignore the info in additional section due to past entertainment with cache poising, etc" then what would be best practices for an ISP? Ted On 7/11/2012 8:03 AM, Warren Kumari wrote: On Jul 11, 2012, at 6:30 AM, Ted Mittelstaedt wrote: On 7/10/2012 6:37 PM, Michael Hoskins (michoski) wrote: -Original Message- From: Ted Mittelstaedt Date: Tuesday, July 10, 2012 6:24 PM To: "bind-users@lists.isc.org" Subject: What is the deal on missing "Authority Section" and "additionalsection" from google's DNS servers? I can't seem to find an option to turn off additional data. How does Google and OpenDNS do it? WHY do they do it? have you tried "minimal-responses yes;"? That did it, thanks! it can increase name server performance, but can also increase client workload (e.g. lead to additional queries). some might also feel it's best to be "conservative in what you send". I would then have to assume that Google and OpenDNS are aware of bugs in specific resolver implementations - very likely in certain firmware versions of the small Dlink/Linksys/etc. routers - and have turned off the additional data in order to make their stuff as compatible as possible so that as few people as possible complain. It would be nice if anyone could confirm this. As you have just seen from one of your customers, there are a non-zero number of folk / devices that have issues with "larger" responses / responses with additional data / etc. Exactly what the devices are isn't (IMO) important, what is is getting answers to folk. By *far* the majority of folk querying these services are end users / stub resolvers. What they are looking for is simply an A / and anything extra is simply wasted bandwidth, time, opportunities to get confused, etc. Many things (correctly (IMO)) ignore the info in additional section due to past entertainment with cache poising, etc. It would be nicer if Google or OpenDNS would confirm they are doing it and why. I think that it is clear from querying (at least Google!) that this is the case: $ dig www.example.com @8.8.8.8 | grep ADDI ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 No doubt both regard it as some sort of trade secret. Hopefully not… ;-) W Ted ___ 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: Operation Cancelled Error
Hi Ben, At 05:37 11-07-2012, Ben wrote: Actually, I am doing load testing with my CACHING DNS SERVER, and for that i setup one client machine which sent queries to CACHING DNS SERVER, and while doing this , i got below given erros in log.So is point to any network problem or any fine tunning / configuration required to bind? I am using google public dns ips as forwarder in named.conf Are you doing load testing on Google's DNS server? Regards, -sm ___ 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.9.1-P1 reload bug
> This just happened on our nameserver: > > 11-Jul-2012 13:54:01.711 general: info: received control channel command > 'reload' > 11-Jul-2012 13:54:01.712 general: info: loading configuration from > '/etc/named.conf' > 11-Jul-2012 13:54:01.891 general: critical: server.c:4436: fatal error: > 11-Jul-2012 13:54:01.891 general: critical: RUNTIME_CHECK(result == 0) > failed > 11-Jul-2012 13:54:01.891 general: critical: exiting (due to fatal error > in library) I think this is a fairly-recently identified bug (#29872). It's a race condition between management of the Address Database part of cache (ADB) and the rndc reload. There isn't a patch available for it, but it will be fixed in a future release. It's also more likely to occur after a rndc reload on a server that's been fairly recently restarted and hasn't yet reached a stable-state cache population - although it still can happen some significant time later. ___ 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: What is the deal on missing "Authority Section" and "additional section" from google's DNS servers?
On Jul 11, 2012, at 6:30 AM, Ted Mittelstaedt wrote: > On 7/10/2012 6:37 PM, Michael Hoskins (michoski) wrote: >> -Original Message- >> >> From: Ted Mittelstaedt >> Date: Tuesday, July 10, 2012 6:24 PM >> To: "bind-users@lists.isc.org" >> Subject: What is the deal on missing "Authority Section" and >> "additional section" from google's DNS servers? >> >>> I can't seem to find an option to turn off additional data. How >>> does Google and OpenDNS do it? WHY do they do it? >> >> have you tried "minimal-responses yes;"? >> > > That did it, thanks! > >> it can increase name server performance, but can also increase client >> workload (e.g. lead to additional queries). some might also feel it's >> best to be "conservative in what you send". >> > > I would then have to assume that Google and OpenDNS are aware of > bugs in specific resolver implementations - very likely in certain > firmware versions of the small Dlink/Linksys/etc. routers - and > have turned off the additional data in order to make their stuff as > compatible as possible so that as few people as possible complain. > > It would be nice if anyone could confirm this. > As you have just seen from one of your customers, there are a non-zero number of folk / devices that have issues with "larger" responses / responses with additional data / etc. Exactly what the devices are isn't (IMO) important, what is is getting answers to folk. By *far* the majority of folk querying these services are end users / stub resolvers. What they are looking for is simply an A / and anything extra is simply wasted bandwidth, time, opportunities to get confused, etc. Many things (correctly (IMO)) ignore the info in additional section due to past entertainment with cache poising, etc. > It would be nicer if Google or OpenDNS would confirm they are doing > it and why. > I think that it is clear from querying (at least Google!) that this is the case: $ dig www.example.com @8.8.8.8 | grep ADDI ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > No doubt both regard it as some sort of trade secret. Hopefully not… ;-) W > > Ted > ___ > 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 > -- There are only 10 types of people in this world -- those who understand binary arithmetic and those who don't. ___ 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 CPU load problems
On 10/07/12 13:08, Phil Mayers wrote: > On 10/07/12 12:56, Shon Stephens wrote: >> Dear Mike, >> >> I am not being hit with a Denial of Service attack and the query >> logging doesn't appear to be any different from other hosts in the DNS >> complex. There are no errors in logs or messages files either. I have >> not installed a previous version from source. > > Does "strace" indicate what the bind process is doing? Various troubleshooting ideas here - though it's not a fully comprehensive list (you might look at different aspects of what's happening depending on what you find at various steps): https://kb.isc.org/article/AA-00341/0/What-to-do-with-a-misbehaving-BIND-server.html ___ 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
BIND 9.9.1-P1 reload bug
Hi all, This just happened on our nameserver: 11-Jul-2012 13:54:01.711 general: info: received control channel command 'reload' 11-Jul-2012 13:54:01.712 general: info: loading configuration from '/etc/named.conf' 11-Jul-2012 13:54:01.891 general: critical: server.c:4436: fatal error: 11-Jul-2012 13:54:01.891 general: critical: RUNTIME_CHECK(result == 0) failed 11-Jul-2012 13:54:01.891 general: critical: exiting (due to fatal error in library) Best wishes, Harald -- Karlsruhe Institute of Technology (KIT) ATIS - IT Infrastruture and Services, Faculty of Computer Science Harald A. Irmer IT Manager / Computer Networks Group Am Fasanengarten 5 Building 50.34 76131 Karlsruhe, Germany Phone: +49 721 608-46963 Fax: +49 721 608-46699 Email: harald.ir...@kit.edu http://www.kit.edu/ KIT University of the State of Baden-Wuerttemberg and National Laboratory of the Helmholtz Association ___ 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: Operation Cancelled Error
Hi, On Jul 10, 2012, at 2:25 AM, Ben wrote: Hi, We deploy BIND 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6 and trying to do load test while doing it we got so many erros logs in named.run. I must admit to being a little confused… It *looks* to me like you are forwarding all queries to 8.8.8.8? (If so, I'm a little confused by the "load test" bit). You will almost certainly get rate limited with this setup (assuming you have more than one or two users behind this server… Actually, I am doing load testing with my CACHING DNS SERVER, and for that i setup one client machine which sent queries to CACHING DNS SERVER, and while doing this , i got below given erros in log.So is point to any network problem or any fine tunning / configuration required to bind? I am using google public dns ips as forwarder in named.conf lame server operation cancelled : it means bind cancelled queries which got from client ...is it so ? Regards, Ben W What does it mean by lam servers operation canceled? Is it due to network rechability problem or bandwidth problem or anything others which related to bind? Kindly guide me solve it. 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'osnews.com/MX/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'campaignjobs.asia/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'couponbuddy.s3.amazonaws.com/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'ms-frontend.hse.ru/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'chriss2d.deviantart.com/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'www.cintegral.cl/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'krisknits.blogspot.com/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'css3.info/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'aventuras.isladejuegos.es/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'aliner.com/MX/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'uprl.kandk.ru/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'hospiceheart.org.s8a1.psmtp.com/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.730 lame-servers: info: error (operation canceled) resolving 'orig-10060.conduit.cotcdn.net/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.731 lame-servers: info: error (operation canceled) resolving 'sjc-dns1.ebaydns.com/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.731 lame-servers: info: error (operation canceled) resolving 'sisar4k.com/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.731 lame-servers: info: error (operation canceled) resolving 'musica.itematika.com/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.731 lame-servers: info: error (operation canceled) resolving 'video-6.filmix.net/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.731 lame-servers: info: error (operation canceled) resolving 'shop.ebay.com/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.731 lame-servers: info: error (operation canceled) resolving 'mediawiki-lb.eqiad.wikimedia.org/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.731 lame-servers: info: error (operation canceled) resolving 'www.carascorridas.com/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.731 lame-servers: info: error (operation canceled) resolving 'technologie.gazeta.pl/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.731 lame-servers: info: error (operation canceled) resolving 'ns1.kasperskylabs.net/A/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.732 lame-servers: info: error (operation canceled) resolving '142.192.186.24.in-addr.arpa/PTR/IN': 8.8.8.8#53 10-Jul-2012 11:47:42.732 lame-servers: info: error (operation canceled) resolving 'geo.tp-cdn.com/A/IN': 8.8.8.8#53 Regards, Ben ___ 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-users Digest, Vol 1255, Issue 2
On 7/11/12, bind-users-requ...@lists.isc.org wrote: > Send bind-users mailing list submissions to > bind-users@lists.isc.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.isc.org/mailman/listinfo/bind-users > or, via email, send a message with subject or body 'help' to > bind-users-requ...@lists.isc.org > > You can reach the person managing the list at > bind-users-ow...@lists.isc.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bind-users digest..." > -- Sent from my mobile device Doug Barnes Email: dxbar...@gmail.com Phone: (219) 973-2213 ___ 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: check-names via command line
On Jul 10 2012, Evan Hunt wrote: >Well, I have to take that back. As far as I can see the -k option of >named-checkzone has no effect at all, despite the man page, at least >with BIND 9.8.3-P1. > Thank you. Maybe this will be fixed? It would be great to have named-checkzone be an authoritative tool as far as zone: Syntax, rules and other error checking goes. It works for me. What errors are you trying to check for that named-checkzone -k isn't finding? Well, it worked for me once I did the tests with the right zone file (and remembered that check-names doesn't check CNAME labels) ... :-( Apologies for the FUD. -- Chris Thompson Email: c...@cam.ac.uk ___ 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: What is the deal on missing "Authority Section" and "additional section" from google's DNS servers?
On 7/10/2012 6:37 PM, Michael Hoskins (michoski) wrote: -Original Message- From: Ted Mittelstaedt Date: Tuesday, July 10, 2012 6:24 PM To: "bind-users@lists.isc.org" Subject: What is the deal on missing "Authority Section" and "additionalsection" from google's DNS servers? I can't seem to find an option to turn off additional data. How does Google and OpenDNS do it? WHY do they do it? have you tried "minimal-responses yes;"? That did it, thanks! it can increase name server performance, but can also increase client workload (e.g. lead to additional queries). some might also feel it's best to be "conservative in what you send". I would then have to assume that Google and OpenDNS are aware of bugs in specific resolver implementations - very likely in certain firmware versions of the small Dlink/Linksys/etc. routers - and have turned off the additional data in order to make their stuff as compatible as possible so that as few people as possible complain. It would be nice if anyone could confirm this. It would be nicer if Google or OpenDNS would confirm they are doing it and why. No doubt both regard it as some sort of trade secret. Ted ___ 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
