Re: UDP client handler shuts down, and BIND stops responding
In message , Corby Bennett writes: > > I am running BIND 9.11.0x64 on Windows Server 2012 R2, and hosting over 35K= > zones. Unfortunately, running on a non-Windows OS is not an option at thi= > s time. > Occasionally BIND will stop responding to queries. The service keeps runni= > ng. Query requests are still logged, but responses are never received by t= > he DNS client on the other end. Restarting the service resolves this until= > the next time it happens. This is what I see in my Default.log after the = > event: > > 31-Oct-2016 21:45:06.830 general: error: socket.c:2525: unexpected error: > 31-Oct-2016 21:45:07.142 general: error: unable to convert errno to isc_res= > ult: 234: More data is available. > 31-Oct-2016 21:45:07.142 general: error: socket.c:2545: unexpected error: > 31-Oct-2016 21:45:07.142 general: error: SOCKET_RECV: Windows error code: 2= > 34, returning ISC error 34 > 31-Oct-2016 21:45:07.142 client: error: UDP client handler shutting down du= > e to fatal receive error: unexpected error > > I don't see any messages logged that would indicate anything out of the ord= > inary happening in BIND. Right before the first error message there are en= > tries for denied dynamic updates, but that is normal for my environment. F= > or now, I have implemented a workaround to automatically restart BIND when = > this problem is detected, but it is a band-aid and I would prefer a real so= > lution. > > Has anyone ever seen anything like this before that can offer me some guida= > nce in troubleshooting? Or, have I uncovered a genuine bug that I should s= > ubmit to ISC? > > > Thank you, > Corby > I've opened a ticket for you. -- 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: The DDOS attack on DYN & RRL ?
Folks, Saw something in a previous posting that should be corrected: > The sticking point seems to be that most DNS providers don't allow zone > transfers from > their servers The customers of Dyn are in the same situation. Actually from personal experience just a few days ago with DYN. On their GUI it is very to setup your own slave servers. They allow you to enter the IPs of machines that should be allowed to perform transfers and you can also designate the machine to receive NOTIFY messages. Tested it and it works great! Best regards! John John Murtari - jm5...@att.com Ciberspring office: 315-944-0998 cell: 315-430-2702 ___ 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
RHEL, Centos, Fedora rpm 9.10.4-P4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 http://www.five-ten-sg.com/mapper/bind contains links to the source rpms, and build instructions. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlgY7CkACgkQL6j7milTFsHodwCfW5pgR7VdbqtMC+L2s/ZzbZLT tTAAoItBpmn/omCo0/chIPUDFNYxBK0x =C9mz -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
UDP client handler shuts down, and BIND stops responding
I am running BIND 9.11.0x64 on Windows Server 2012 R2, and hosting over 35K zones. Unfortunately, running on a non-Windows OS is not an option at this time. Occasionally BIND will stop responding to queries. The service keeps running. Query requests are still logged, but responses are never received by the DNS client on the other end. Restarting the service resolves this until the next time it happens. This is what I see in my Default.log after the event: 31-Oct-2016 21:45:06.830 general: error: socket.c:2525: unexpected error: 31-Oct-2016 21:45:07.142 general: error: unable to convert errno to isc_result: 234: More data is available. 31-Oct-2016 21:45:07.142 general: error: socket.c:2545: unexpected error: 31-Oct-2016 21:45:07.142 general: error: SOCKET_RECV: Windows error code: 234, returning ISC error 34 31-Oct-2016 21:45:07.142 client: error: UDP client handler shutting down due to fatal receive error: unexpected error I don't see any messages logged that would indicate anything out of the ordinary happening in BIND. Right before the first error message there are entries for denied dynamic updates, but that is normal for my environment. For now, I have implemented a workaround to automatically restart BIND when this problem is detected, but it is a band-aid and I would prefer a real solution. Has anyone ever seen anything like this before that can offer me some guidance in troubleshooting? Or, have I uncovered a genuine bug that I should submit to ISC? Thank you, Corby ___ 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: The DDOS attack on DYN & RRL ?
On 2016/11/01 14:45, Ben Croswell wrote: > The other option being having a master owned by your company and then > setting both external providers to secondary from your master. You to > maintain control over data and hqve diversity. Agreed. This works well -- it's what we do. Cheers, Matthew signature.asc Description: OpenPGP digital 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: The DDOS attack on DYN & RRL ?
In article , Ben Croswell wrote: > The other option being having a master owned by your company and then > setting both external providers to secondary from your master. You to > maintain control over data and hqve diversity. Good point, although that means maintaining another service on your own infrastructure. Another thing that makes it hard for many companies to diversify their DNS providers is that they make use of DNS-based load balancing and failure (e.g. Amazon's Route 54, Akamai's Global Traffic Management). These services can't easily update each other. -- 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: The DDOS attack on DYN & RRL ?
The other option being having a master owned by your company and then setting both external providers to secondary from your master. You to maintain control over data and hqve diversity. On Nov 1, 2016 10:42 AM, "Barry Margolin" wrote: > In article , > Ben Croswell wrote: > > > I think what we see as a result of this attack is DNS provider diversity > > being the new buzz phrase. The same as not relying on a single ISP link i > > see more people using multiple DNS providers. > > The size of these attacks will grow as IoT continues to grow. It makes > > sense to have diverse providers to ensure your domains are serviceable > if a > > provider gets attacked. > > My boss asked me to look into this after the attack. The sticking point > seems to be that most DNS providers don't allow zone transfers from > their servers. We currently get our auth DNS from SoftLayer, the hosting > provider for our primary web, application, and database servers. I > contacted them to find out if it's possible to enable zone transfers to > a third party slave service, they said no; they suggested that we simply > set up both services as masters, which would mean we'd have to update > them independently (or write our own scripts that make use of each > service's API). The customers of Dyn are in the same situation. > > Maybe last week's incident will prompt enough big customers to demand > this that they'll change their policies. > > -- > 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 > ___ 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: The DDOS attack on DYN & RRL ?
In article , Ben Croswell wrote: > I think what we see as a result of this attack is DNS provider diversity > being the new buzz phrase. The same as not relying on a single ISP link i > see more people using multiple DNS providers. > The size of these attacks will grow as IoT continues to grow. It makes > sense to have diverse providers to ensure your domains are serviceable if a > provider gets attacked. My boss asked me to look into this after the attack. The sticking point seems to be that most DNS providers don't allow zone transfers from their servers. We currently get our auth DNS from SoftLayer, the hosting provider for our primary web, application, and database servers. I contacted them to find out if it's possible to enable zone transfers to a third party slave service, they said no; they suggested that we simply set up both services as masters, which would mean we'd have to update them independently (or write our own scripts that make use of each service's API). The customers of Dyn are in the same situation. Maybe last week's incident will prompt enough big customers to demand this that they'll change their policies. -- 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: The DDOS attack on DYN & RRL ?
My co-authors and I wrote a paper about the events at the DNS root servers on 2015-11-30. On this date, the root servers received a high number of queries (but by far not as many as Dyn) and since most of the Root letters were using anycast, we were able to observe how this had an impact on their reachability. One of our takeaways was, that more DNS anycast site did have an impact on the reachability. http://www.isi.edu/%7ejohnh/PAPERS/Moura16a.pdf Moritz > On 31 Oct 2016, at 22:39, Jim Popovitch wrote: > > On Mon, Oct 31, 2016 at 12:21 PM, Tony Finch wrote: >> Jim Popovitch wrote: >>> >>> It seems to me that anycast is probably much worse in the Mirai botnet >>> scenario unless each node is pretty much as robust as a traditional >>> unicast node. >> >> This blog post is a pretty good intro to how anycast can help with DDoS >> mitgation, though I think Cloudflare are overstating how unique they are - >> there are other older DNS services that distribute load over large anycast >> clouds of commodity hardware. >> >> https://blog.cloudflare.com/how-cloudflares-architecture-allows-us-to-scale-to-stop-the-largest-attacks/ >> > > Thanks for linking that Tony. The take-away that I get from that > article is that CF can deal with DDoS because of link capacity in each > POP, and/or re-route legitimate traffic via BGP. The principle > reason they can do this is because their main biz involves packets > larger than those traditionally seen with DNS. The comments in that > article mention 10 TB of capacity, how's that compare to any of the > capacities of the various DNS providers? > > -Jim 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 > signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
