Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica

Jared Mauch jared at puck.Nether.net
Tue Aug 4 19:03:47 UTC 2015


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 SPoF
> 
> As 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 at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.



More information about the NANOG mailing list