[nycbug-talk] dns abuse

[Miles Nordin]

>>>>> "y" == Yarema  <yds at CoolRat.org> writes:

     y> As far as dnssec, dynamic updates, IXFR not being supported, I
     y> currently don't have a need for any of them.

I do.

I also want the infrastructure in place, including at my friends' who
are secondarying for me, so that when I want to do IPv6, dns-sd, or
dynamic updates, it's not like running in molasses.  But I'm already
doing two of those things, so I'm unable to take djbdns secondaries.

This DJB guy is going to completely fuck us when we start to get
serious about dnssec, too.

     y> And it does come with axfrdns in case you need to support a
     y> BIND or what-have-you AXFR secondary.

okay, well, welcome to 1992.  BIND is already using IXFR even for
flat-file zones, though.  They seem to have some kind of dnsdiff
thread built in there somewhere.  And I do dynamic updates, so I need
IXFR.

     y> In the case of this latest spoof attack it seems to me
     y> like everyone was scrambling for a way to disable answering
     y> the "." zone.  Was everyone trying to figure out a way to
     y> violate "some standard" as a way of protecting their DNS
     y> servers?

probably, yes.  Both goals are semi-hysterical.

     y> So having said all that I'm now convinced that tinydns is
     y> doing the Right Thing(TM) by not replying to queries for the
     y> "." zone, because no one has any business asking my

    >> And it provides no real security because I can still do a query
    >> for something for which your server is authoritative and get it
    >> to amplify an attack.

     y> Doesn't this apply equally to any DNS server out there?

yes, to any server including djbdns, which is my point.

It's security through obscurity, possibly at the expense of
standards-compliance (though possibly not.  i'm still not sure whether
it's a BIND bug, or an intentional feature complying to the letter of
some standard or working around some resolver's corner case).

     y> The "crazed zealot" did deliver the library piece of the
     y> resolver: http://cr.yp.to/djbdns/blurb/library.html

okay I guess I'm wrong.  It's still mostly a wheel-reinvention, in
that it preserves the BIND architecture of implementing a resolver
through a stateless client stub library plus a recursive resolver.
He's just stirring around the bowl full of dust a bit, arguing about
the exact order to put function arguments or how to allocate memory.
Even BIND's lwres is probably a more relevant re-invention than his.

The Mac OS X and Solaris resolvers seem to include more client-side
caching and an abstract interface that's not DNS-specific, is generic
for looking up ``directory'' information or netinfo.  In both cases
they used this abstraction to move from their old directory protocols
(NIS+ and Netinfo) to LDAP.  and in Apple's case the hostname lookup
part includes seamless dns-sd/zeroconf support which requires a lot of
resolver state to be performant.  I brought them up because they're
more genuine examples of what it really means to separate the resolver
from the server, and of what sorts of refactoring is possible once you
do this---DNS caching gets mixed in with caching other directory data,
and the API gets simpler and more powerful.  DJB's separation is more
just copying BIND and then applying a bunch of NIH ranting against it.
not pointlessly, but it's just OCD screaming, not the actual
creativity you can find among younger developers.  That's why I think
sysadmins should resist a temptation to idolize him, and sort of
embrace all this bloated buggy modern crap a little more readily,
learn how to recognize the good and bad among it, and exist in a world
built from it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <http://lists.nycbug.org/pipermail/talk/attachments/20090121/706a9f50/attachment.bin>