[nycbug-talk] dns abuse

Wed Jan 21 17:07:01 EST 2009

Miles Nordin wrote:
>>>>>> "y" == Yarema  <yds at coolrat.org> writes:
> 
>      y> I can't say enough good things about djbdns.
> 
> I can say a few bad ones.

As a disclaimer, I'm not a djb/qmail fanboy, I just happen to like and
use djbdns with an eye towards migrating my setup to ldapdns, a drop in
replacement for djb's tinydns.  I never claimed that djbdns doesn't have
its share of shortcomings.  Simplicity and "security by default" happen
to be it's strong points.

> no support for ipv6, no standards-compliant secondary dns.  no support
> for dyndns and dnssec and thus no support for wide-area dns-sd.

IPv6 is supported with a patch selectable in the FreeBSD port.  I don't
really care, I don't currently use IPv6.  And I don't really care that
it's a patch and not port of the "official distribution".  It's there if
needed.

If you mean "standards-compliant secondary dns" == AXFR then AXFR can be
done with djbdns, but rsync is simpler to do if both the primary and
secondary are under your control and running djbdns.  And it does come
with axfrdns in case you need to support a BIND or what-have-you AXFR
secondary.  So that's not an issue.
See http://cr.yp.to/djbdns/tcp.html#intro-axfr

> dns-sd is the best example of DJB's wrong-headedness.  It's a
> well-liked protocol which is becoming important, and it gracefully
> builds on standards the rest of us have been carefully laying, one
> stone upon another, for future protocols we couldn't imagine yet
> (dnssec, dynamic updates, IXFR), and now dns-sd comes along as such an
> unimagined protocol using all the prior work.

As far as dnssec, dynamic updates, IXFR not being supported, I currently
don't have a need for any of them.  When and if I do I'll explore a
solution which offers them.  However I agree that djb often paints
himself into a corner by not supporting what the rest of the world seems
to be moving towards.  This latter point is why I haven't used qmail for
the past 10 years.  Postfix offers all the standards support missing
from qmail as well as cdb if you count that as an advantage of qmail.
But this is a different tangent altogether.  Just making a point here
that I agree that djb can be wrong-headed.

>      y> my servers were not contributing to any DDSing since they
>      y> returns nothing to the . NS query.
> 
> which may well violate some standard, or make something else harder to
> debug.

Maybe, but I've yet to run into a situation where this was the case.  In
the case of this latest spoof attack it seems to me like everyone was
scrambling for a way to disable answering the "." zone.  Was everyone
trying to figure out a way to violate "some standard" as a way of
protecting their DNS servers?

tinydns rejects zone-transfer requests, inverse queries,
non-Internet-class queries, truncated packets, and packets that contain
anything other than a single query.  And it only answers queries for
zones that it is configured for.  It is never configured to answer the
"." zone unless it's being used on a root server I suppose.  Even then I
don't understand why anyone needs to serve the "." zone.  That's what
the root hints file is for.  This hints file is only useful to the
resolver.  tinydns is not a resolver, it only serves authoritative
replies.  dnscache, the resolver half of djbdns, has no problem serving
up the "." zone:

; <<>> DiG 9.4.3-P1 <<>> . NS @127.0.0.1
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 991
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			518273	IN	NS	L.ROOT-SERVERS.NET.
.			518273	IN	NS	C.ROOT-SERVERS.NET.
.			518273	IN	NS	D.ROOT-SERVERS.NET.
.			518273	IN	NS	H.ROOT-SERVERS.NET.
.			518273	IN	NS	F.ROOT-SERVERS.NET.
.			518273	IN	NS	A.ROOT-SERVERS.NET.
.			518273	IN	NS	I.ROOT-SERVERS.NET.
.			518273	IN	NS	G.ROOT-SERVERS.NET.
.			518273	IN	NS	J.ROOT-SERVERS.NET.
.			518273	IN	NS	B.ROOT-SERVERS.NET.
.			518273	IN	NS	M.ROOT-SERVERS.NET.
.			518273	IN	NS	E.ROOT-SERVERS.NET.
.			518273	IN	NS	K.ROOT-SERVERS.NET.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan 21 16:07:19 2009
;; MSG SIZE  rcvd: 228

So having said all that I'm now convinced that tinydns is doing the
Right Thing(TM) by not replying to queries for the "." zone, because no
one has any business asking my authoritative servers for the "." zone.
Go ask your ISP's DNS cache for the "." zone or your local DNS cache.
Don't be asking my authoritative DNS server for "." cuz I'm not
authoritative for the "." zone.

> 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.  That just happens to not be the case this time---it's
> security through obscurity.

Doesn't this apply equally to any DNS server out there?  Looks like
we're looking at a new(?) DDoS threat regardless of which DNS server
implementation anyone uses, no?  Seems like Max's pf throttling rule
from the post which started this thread is a good practice no matter
what..  cuz filtering on packet size is not fool-proof nor is filtering
the spoofed "victim" IPs (like I've done) much good in the long term.

> but as you said it's easier.  Maybe this stripped-down
> linksys-router-style simplified software is an effective, sort of,
> civil-disobedience backpressure on bloated standards.

Maybe..  I certainly gravitate towards simplicity whenever available.

> Also his separating the resolver from the server is proper.  Though
> you can see the crazed zealot's limitations again here in that he
> didn't really deliver a full resolver because he didn't deliver the
> library piece of it.  libresolv comes with BIND and gets built into
> libc's, then you use that with dnscache---but the idea of making a
> resolver by having a library send recursive queries to a DNS server is
> a BIND idea, of which DJB hijaacked half.  Bigger, more complicated
> libresolv's that do their own cachinig and deviate from the BIND model
> are built into Solaris and Mac OS X.

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

It's upto each OS vendor to implement whatever DNS resolver they happen
to go with.  Into libc or what have you.  But it's probably best that
BIND's libresolve or compatible is the standard since it pretty much
guarantees a consistent API across the board for Unix-like OSes.

See the "crazed zealot's" libresolv security disaster rant:
http://cr.yp.to/djbdns/res-disaster.html
There he explicitly states that his resolver library is in the public
domain so there shouldn't be any licensing related concerns in using it.

As for client applications they are also free to chose whichever
resolver implementation they wanna program for.  Though I don't know of
any software besides djb's using his resolver lib, I do know plenty of
software which uses libadns http://www.chiark.greenend.org.uk/~ian/adns/
instead of BIND's libresolve.

-- 
Yarema