nanog mailing list archives
Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
From: Jared Mauch <jared () puck Nether net>
Date: Tue, 4 Aug 2015 15:03:47 -0400
On Tue, Aug 04, 2015 at 01:48:56PM -0400, Joe Abley wrote:
Hi Jared, On 4 Aug 2015, at 12:00, Jared Mauch wrote:I recommend using DNSDIST to balance traffic at a protocol level as you can have implementation diversity on the backside. I can send an example config out later for people. You can balance to bind NSD and others all at the same time :-) just move your SPoFAs someone who once hosted TLD zones in a way that a query to a particular nameserver could be answered by either NSD or BIND9, my advice would be "don't do that". You're setting yourself up for troubleshooting hell.
I'm not suggesting you have an unpredictable set of things you route queries to. I have a very simple config I'll share with you off-list. One should route things in a predictable manner. This is why people want operators who can code and operate a service vs just operate it, or just code. Those are the people in the highest demand in my narrow experience.
You can include different nameservers in the set for a single zone. Using different software for different nameservers can be sensible. Using different software for the same nameserver can be a nightmare.
Proper logging and instrumentation is essential. DNSDIST can be configured to fail over to something else while one server or daemon is offline and being serviced or restarted. This can also be done with other tools like "stupid routing tricks" aka anycast. For a resolver I want to "just work" for servers that need to do e-mail etc this works well for me. The fact I can have it point to a BIND process on localhost on a different port, or nsd, etc.. provides flexability that others don't do as easily. - Jared -- Jared Mauch | pgp key available via finger from jared () puck nether net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Current thread:
- Re: RES: Exploits start against flaw that could hamstring huge swaths, (continued)
- Re: RES: Exploits start against flaw that could hamstring huge swaths Joe Greco (Aug 04)
- Re: RES: Exploits start against flaw that could hamstring huge swaths Baldur Norddahl (Aug 04)
- Re: RES: Exploits start against flaw that could hamstring huge swaths Christopher Morrow (Aug 04)
- Re: RES: Exploits start against flaw that could hamstring huge swaths Baldur Norddahl (Aug 04)
- Re: RES: Exploits start against flaw that could hamstring huge swaths of Valdis . Kletnieks (Aug 04)
- Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica Mark Andrews (Aug 04)
- Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica Damian Menscher via NANOG (Aug 04)
- Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica Jared Mauch (Aug 04)
- Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica Joe Abley (Aug 04)
- Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica Jared Mauch (Aug 04)
- Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica Randy Bush (Aug 04)
- Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica Jared Mauch (Aug 04)