[nycbug-talk] dns abuse

[Yarema]

Miles Nordin wrote:
>>>>>> "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.

DJB is not shoving his software down anyone's throat.  When DNSSEC
becomes a serious requirement djbdns will either have to offer a
solution or fall by the wayside.

>      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.

Well, the time stamp on djbdns sources is Feb 11, 2001.  That probably
predates IXFR.  and the reason I haven't even looked at IXFR is because
I use djbdns + rsync-over-ssh to push/pull updates.  Circular argument,
I know.  Seems to me that AXFR/IXFR both exist because BIND loads it's
entire zones into memory.  Therefore rsync is not a viable option when
using BIND.  So they needed to reinvent what rsync does.  This is where
I do like the djbdns approach, everything is always read from the
data.cdb file.  CDB is optimized exclusively for read access and
guarantees that each record will be read in at most two disk accesses.
There's never any need to reload the zones.  This makes rsync perfectly
viable for pushing/pulling changes.

I also like the the ldapdns approach.  It's using a threaded core and
the development version does not even rely on OpenLDAP libraries.  So it
claims to "outperform bind and djbdns on medium to large installations,
and will scale well both up and down. ...because it queries the ldap
server directly, updates are immediate. you don't have to rebuild
constant databases, or wait for bind to get it's shit in gear."  Again
AFXR/IFXR become irrelevant.  Even the rsync approach falls by the
wayside.  For redundancy you have master/slave ldapdns servers talking
to the one or more backend LDAP server(s).

>      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).

I don't know if it's a BIND "bug" rather it seems like a byproduct of
having the authoritative server and caching resolver be part of the same
app.  And putting the burden on admins to craft their configs to
seperate the two functionalities.  The djb approach avoids the issue by
having separate server for each functionality.  This djb approach can be
implemented without djbdns.  If, as you pointed out, the OS has a
caching resolver like OS X or Solaris, then dropping in ldapdns offers
up the same division of labor solution of not putting the burden on the
(possibly clueless) admin to secure his config.  All this without any
djb written software.

As for the "security through obscurity" argument.  Now that I've thought
about it I do not believe it applies with this attack.  If the attacker
sends queries to which my server replies because it is authoritative for
that zone -- then only my servers will be "flooding" the spoofed
address.  It stops being a DDoS attack because no one else's servers
will respond to such queries and therefore the victim's spoofed address
will not be flooded like it is with a query for the "." zone.  Queries
for com, org, net, &c. &c. zones also do not get amplified by a server
not set up as authoritative for those zones.  The more I think about it
the more it seems like an exploit of the fact that many BIND servers do
not properly configure the split between serving authoritative records
and resolving/caching.

>      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.

I agree with the broader sentiment that people should resist idolizing.
Period.  If a tool solves the problem at hand use it.  Something better
comes along or you outgrow the tool you've been using, move on.  Without
sentiment.  There are plenty of artists who's work I like even though I
might think the author/creator of that work is a douchebag.  I don't
really care if djb is a douchebag or not.  Some of the stuff he released
is top notch, like the djbfft library used by some opensource multimedia
projects.  cdb is pretty kick ass and in this case tinycdb seems like
the preferred implementation, both faster and cleaner API than djb's
own.  Maildir is still widely used by many non djb servers.

It's easy to say that djb's stuff is long in the tooth.  It is.  A lot
of it has not seen an update in years.  And a lot of it should be
abandoned in favor of more modern approaches.  Having read djb's "Some
thoughts on security after ten years of qmail 1.0" paper
http://cr.yp.to/qmail/qmailsec-20071101.pdf I realized that, simply put,
 he's a mathematics professor, with an ability to write his own
replacements for software he finds inadequate AT THE TIME.  The "at the
time" bit seems to be missed by both djb zealots and detractors alike.
He seems to have little interest in building any sort of community
around what he's written.  He just puts it out there, and moves on,
updating the documentation once in a while.  Or just teaching his
courses.  Chances are he never would have written qmail if Postfix was
already around.  In the same spirit as the points you've made above, djb
seems to say "there's a better way".  And he writes code to show what he
means by that.  NOW there often is a better way other than djb's.
Sometimes as a direct result of the direction djb pointed out.  At the
time he was making his statement by coding an alternate solution there
often was no better alternative.  djbdns was written mostly in response
to BIND 4.x.x.  The fact that it's still useful and secure today speaks
to the fact that he did something right.  Comparing djbdns to BIND 9's
features is just out of context.  BIND has continued to evolve
reinventing itself several times in the process.  djbdns is pretty much
the same today as it was 10 years ago.

-- 
Yarema