To deal with inproper nodata notification
I found that bind9.9.2 recursor returns servfail to soa requests when receiving inproper nodata notification that there is just a root SOA RR in the authority section in response from authoritative namservers. Just like this as following. Why does it forward the inproper response to clients? [root@localhost secman]# dig soft.vipbiz.cn ns @localhost ; <<>> DiG 9.9.2-P2 <<>> soft.vipbiz.cn ns @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21576 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;soft.vipbiz.cn.IN NS ;; Query time: 91 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri May 10 23:08:56 2013 ;; MSG SIZE rcvd: 43 Liu Mingxing___ 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 Configuration
On May 9, 2013, at 8:44 AM, Carlos Martinez wrote: > DNS is not the place to solve that problem, it's the routing layer. Yes, but *sometimes* DNS is the right layer for this… For example, if you have 2 sites (so you can remain up when a meteor / flood / avalanche hits one), if you need better latency, etc. I guess the short answer is "Redundancy is hard, lets go shopping…" > > "Use Bgp Luke " :-) > > Sent from my iPad > > On 08/05/2013, at 15:24, Sten Carlsen wrote: > >> I believe your major point is the routing tables because they determine how >> the response is trying to get out. >> >> >> On 08/05/13 22:22, Steven Carr wrote: >>> You will need to have some form of automation in place to update the >>> DNS zone to change the IP address which should now be accessed when >>> one of the links goes down. You will also need to ensure you have a >>> low TTL value on the records you want to update on link change so that >>> the records are refreshed quickly. >>> >>> >>> >>> On 8 May 2013 20:40, Ward, Mike S >>> >>> wrote: >>> Hello all, I was wondering if someone could me out. I am using Bind 9.2 on a Redhat Linux server. We have two ISPS on separate networks Lets call them A and B. My Linux Server can listen on A's Network as well as B's network. I'm using fictitious IPs and names A 111.111.111.1 B 555.555.555.1 Secondary A 111.111.222.1 Redhat & Bind Bind is listening on both IP addresses and we have a secondary server at 111.111.222.1 If A the ISP has a backbone router problem how can I get people trying to get to our web servers to use B's network? I have been think of different ways to do this, but have come up empty. Our network is really simple I just want to be able to use diverse ISPS in case we lose one we still have the other. Can anyone help me out. Any help appreciated. Thanks. == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ 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 >> >> -- >> Best regards >> >> Sten Carlsen >> >> No improvements come from shouting: >>"MALE BOVINE MANURE!!!" >> >> ___ >> 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 -- After you'd known Christine for any length of time, you found yourself fighting a desire to look into her ear to see if you could spot daylight coming the other way. -- (Terry Pratchett, Maskerade) ___ 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: architecture question
On 2013-05-10 16:39, b...@bitrate.net wrote: On May 10, 2013, at 01.18, Dave Warren wrote: On 2013-05-08 11:13, btb wrote: it's also mildly humorous that they used to quite religiously endorse .local, in some documents even categorizing use of the same domain name on an internal and external network as a "security risk". Keep in mind that this was before ubiquitous, always-on TCP/IP was the norm. It was coming, but we weren't there yet and Microsoft was still catching up. i disagree. in 1999, when .local was first referenced [and only in id form], short of perhaps the residential environment, always-on tcp/ip was commonplace - and i'm doubtful you'd even find microsoft references that early to it anyway, since microsoft was still catching up [this i heartily agree with, as they always are] :) In those days, I was in the ISP world and we had a huge number of customers who were just starting to get IP connectivity to their networks, and very few hosted anything themselves, most used us as a web host and had no interest in their internal resources being involved with that internet thing at all. I'm not talking IT companies, I'm talking their clients who were just discovering the internet and still hadn't really figured out it's value, many of which were just starting to consider connecting their computers to the internet in any real way. In this context, a .local type domain isn't actually the worst idea in the world. As far as Microsoft and their documentation and recommendations go, Active Directory development started what, 4-5 years before that? So best practices pre-dated the W2K release when this stuff went live and after that, it was no doubt a fight against inertia to change best practices. I know the courses I took in those days were definitely recommending some sort of internal-only TLD, just as internal-only IPs were recommended. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ 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: architecture question
On May 10, 2013, at 01.18, Dave Warren wrote: > On 2013-05-08 11:13, btb wrote: >> it's also mildly humorous that they used to quite religiously endorse >> .local, in some documents even categorizing use of the same domain name on >> an internal and external network as a "security risk". > > Keep in mind that this was before ubiquitous, always-on TCP/IP was the norm. > It was coming, but we weren't there yet and Microsoft was still catching up. i disagree. in 1999, when .local was first referenced [and only in id form], short of perhaps the residential environment, always-on tcp/ip was commonplace - and i'm doubtful you'd even find microsoft references that early to it anyway, since microsoft was still catching up [this i heartily agree with, as they always are] :) -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
Re: BIND Configuration
DNS is not the place to solve that problem, it's the routing layer. "Use Bgp Luke " :-) Sent from my iPad On 08/05/2013, at 15:24, Sten Carlsen wrote: > I believe your major point is the routing tables because they determine how > the response is trying to get out. > > > On 08/05/13 22:22, Steven Carr wrote: >> You will need to have some form of automation in place to update the >> DNS zone to change the IP address which should now be accessed when >> one of the links goes down. You will also need to ensure you have a >> low TTL value on the records you want to update on link change so that >> the records are refreshed quickly. >> >> >> >> On 8 May 2013 20:40, Ward, Mike S wrote: >>> Hello all, I was wondering if someone could me out. >>> >>> I am using Bind 9.2 on a Redhat Linux server. We have two ISPS on separate >>> networks Lets call them A and B. My Linux Server can listen on A's Network >>> as well as B's network. >>> I'm using fictitious IPs and names >>> >>> A 111.111.111.1 B 555.555.555.1 >>> Secondary A 111.111.222.1 >>> >>> Redhat & Bind >>> >>> Bind is listening on both IP addresses and we have a secondary server at >>> 111.111.222.1 >>> >>> >>> If A the ISP has a backbone router problem how can I get people trying to >>> get to our web servers to use B's network? I have been think of different >>> ways to do this, but have come up empty. >>> >>> Our network is really simple I just want to be able to use diverse ISPS in >>> case we lose one we still have the other. Can anyone help me out. Any help >>> appreciated. >>> >>> Thanks. >>> >>> == >>> This email, and any files transmitted with it, is confidential and intended >>> solely for the use of the individual or entity to which it is addressed. If >>> you have received this email in error, please notify the system manager. >>> This message contains confidential information and is intended only for the >>> individual named. If you are not the named addressee, you should not >>> disseminate, distribute or copy this e-mail. Please notify the sender >>> immediately by e-mail if you have received this message by mistake and >>> delete this e-mail from your system. If you are not the intended recipient, >>> you are notified that disclosing, copying, distributing or taking any >>> action in reliance on the contents of this information is strictly >>> prohibited. >>> ___ >>> 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 > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: >"MALE BOVINE MANURE!!!" > ___ > 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
New BIND Versions are Available: 9.9.3rc2, 9.8.5rc2, and 9.6-ESV-R9rc2
Hello, BIND Users -- The second release candidates for the upcoming maintenance releases of BIND are now available on the ISC FTP server. 9.9.3rc2, 9.8.5rc2, and 9.6-ESV-R9rc2 can now be downloaded; you will find them at http://www.isc.org/downloads/all Also, please recall that in April we posted a change to our announcement policy for new versions. Previously we had announced each new version on each of the ISC public lists for BIND 9, but in order not to duplicate we are now posting only to bind-announce. We will post reminders here for the time being but if you are not subscribed to bind-announce we recommend that you consider it. You can manage your subscriptions for ISC's public mailing lists by visiting https://lists.isc.org/mailman/listinfo Michael McNally ISC Support ___ 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.3b2
On May 10 2013, ixlo...@sent.at wrote: Is there some specific reason you want to test an old, pre-release version, versus the current RC1 release candidate? Actually, 9.9.3rc2 is there at ftp://ftp.isc.org/isc/bind/9.9.3rc2 although it doesn't seem to have been announced on bind-announce yet. -- 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: Bind 9.9.3b2
Is there some specific reason you want to test an old, pre-release version, versus the current RC1 release candidate? On Fri, May 10, 2013, at 12:20 PM, Anderson Alves de Albuquerque wrote: > I want to test Bind 9.9.3b2. > > Why isn't there Bind 9.9.3b2 in download link on the ISC.org? > > Is there recommendation to use the version Bind 9.9.3b2? > I look in http://www.isc.org/software/bind/security/matrix that there > isn't bug in Bind 9.9.3b2. > ___ > 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 -- --- An annoying necessity for those who think mailing rude emails offlist and attempting to hide behind 'prohibited content' clauses is "OK": Do not email me privately or offlist. If you do, any communications to this address will be considered public communication, any prohibitions on content & disposition will be considered accepted by you as null & void, and your email may be responded to or reposted in its entirety on list. --- ___ 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: Response Rate Limiting Patch
Thanks for the quick responses guys. Regards, Lesley-Anne Wilson On 10 May 2013 11:41, Wilson, Lesley-Anne wrote: > Hello, > > Has anyone here implemented Response Rate Limiting? If so have you > experienced any bugs with the RRL Patch for BIND 9.9.2? Can the feature be > implemented successfully without implementing the patch that includes > DNSRPZ as well? > > > Regards, > Lesley-Anne Wilson > > > -- * * -- *Attention:* This e-mail message has been scanned for viruses and content. The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this e-mail. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. -- ___ 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.3b2
I want to test Bind 9.9.3b2. Why isn't there Bind 9.9.3b2 in download link on the ISC.org? Is there recommendation to use the version Bind 9.9.3b2? I look in http://www.isc.org/software/bind/security/matrix that there isn't bug in Bind 9.9.3b2. ___ 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: Response Rate Limiting Patch
On 10/05/13 17:41, Wilson, Lesley-Anne wrote: Hello, Has anyone here implemented Response Rate Limiting? If so have you Yes, recently. experienced any bugs with the RRL Patch for BIND 9.9.2? Can the feature No bugs. I'm not a huge fan of the logging categories, but that's a personal thing ;o) be implemented successfully without implementing the patch that includes DNSRPZ as well? No idea. RPZ is already in bind 9.9. All the patch does it improve performance in some cases, AIUI. If you don't want RPZ, don't turn it on. ___ 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: Response Rate Limiting Patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 2013-05-10 at 11:41 -0500, Wilson, Lesley-Anne wrote: > Has anyone here implemented Response Rate Limiting? Yes. > If so have you experienced any bugs with the RRL Patch for BIND 9.9.2? No. > Can the feature be implemented successfully without implementing the > patch that includes DNSRPZ as well? I am not sure - I picked the rpz+rl-9.9.2-P2.patch, md5sum rpz+rl-9.9.2-P2.patch ec4097a09e91afaa5f9b43e026e4c1b1 rpz+rl-9.9.2-P2.patch It is working nicely here in production. http://www.five-ten-sg.com/mapper/bind -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlGNJfwACgkQL6j7milTFsGD9ACfaNabdRSwyV5ZhvIBc4oeB8QM OPwAnAkSPRmmoFfvhycfuBkbS8x35A4R =nvmN -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
Response Rate Limiting Patch
Hello, Has anyone here implemented Response Rate Limiting? If so have you experienced any bugs with the RRL Patch for BIND 9.9.2? Can the feature be implemented successfully without implementing the patch that includes DNSRPZ as well? Regards, Lesley-Anne Wilson -- * * -- *Attention:* This e-mail message has been scanned for viruses and content. The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this e-mail. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. -- ___ 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