Hi.
Your comment does address the main thrust of my post. Today, a modern DNS
server must have rate limiting, and that any server that publishes numbers
without rate limiting isn't complete. Thus, my server isn't really complete.
However, nobody else is publishing their numbers with rate limiting enabled, so
I haven't gotten around to it. My DNS server is "complete" only for various
levels of completeness: i.e. more complete than djbdns, not as complete as it
needs to be. However, I don't anticipate rate-limiting will have a big
performance impact.
The high query-per-second numbers aren't actually impressive. My other trick is
(which is unrelated to langsec) is that I bypass the kernel, DMAing packets
directly to/from user-mode memory, using my own TCP/IP stack. It's a surprising
result only because people aren't accustomed to it.
Rob.
On Tuesday, July 1, 2014 12:15 PM, Morgon J. Kanter
<morgon.j.kanter...@dartmouth.edu> wrote:
Hey Robert,
Sorry for not addressing the main thrust of your email here...
Those are some pretty impressive QPS numbers but they lack a bit of context.
What hardware are you using to get them? I took a look at the code and didn't
notice any kind of built-in outbound rate limiting, and I wonder if including
that would cause much of a performance loss.
Cheers,
-- Morgon
________________________________
From: langsec-discuss-boun...@mail.langsec.org
<langsec-discuss-boun...@mail.langsec.org> on behalf of Robert Graham
<robert_david_gra...@yahoo.com>
Sent: Monday, June 30, 2014 7:44 PM
To: langsec-discuss@mail.langsec.org
Subject: [langsec-discuss] my langsec DNS server
I’ve been working a DNS server. I mention this because it's Langsec compliant:
it parses DNS packets, and zonefile records, before processing them. It's
complete as far as DNS protocol is concerned: it reads zonefiles and responds
to DNS queries correctly. It's still incomplete for other features, such as
updating configuration/zonefiles while running. It's completeness is a good
evidence that Langsec is practical rather than theoretical.
I point this out because both “Hammer” and “Nail” only partly parse DNS
packets. They leave out the difficult bit of DNS name compression. This isn't a
valid test -- every protocol/format is going to have difficult bits, they
really need to demonstrate how they'd handle name compression. The correct
answer, btw, is to 'punt': it's so specific to DNS that no system can automate
it.
The Nail paper claims they can reduce “by an order of magnitude” the 10k
lines-of-code in djbdns. This is false, because only a tiny bit of code is
involved in parsing. My DNS server is 16k lines-fo-code, but fewer than 200
parse DNS packets -- and that includes name compression.
My DNS server focuses on speed. It’s about 10 times faster than any other DNS
server, and close to 100 times faster than BIND9, doing 10 million
queries/second. The paper that Peter, Sergey, and I collaborated on: you can do
both Langsec and also be very fast. I parse DNS zonefiles faster than ‘wc’ can
count the number of words in them, which I think is a pretty interesting
result. (I'm still not clear on why 'wc' is so slow).
The converse argument is that if you aren’t fast, then why are you insecure?
C/C++ is inherently insecure. My C code is faster than what can be written in
Java, but if your C code isn’t, then why aren’t you writing in Java? In any
event, the new AddressSanitizer feature in gcc/clang means that I may get the
benefit of a high-level language for only a 2x slowdown – meaning my sanitized
C may be faster than their dangerous C. This then has implications for
Nail/Hammer: if they have too high a performance cost, slowing C program down
to Java speeds, then that questions their usefulness. Meredith moved to an
“arena allocator” for this reason – relying upon normal malloc() would’ve
killed performance. (The rule for parsing is that you should have zero
malloc()s when parsing a packet).
My server parses before processing the packets and zonefile records, but that
doesn’t make it immune from Langsec attacks. Consider a wild card record in a
zonefile like “*.example.com”, then a query for a domain with a lot of labels
“a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.example.com”. Instead of
looking up the name directly in one step, I have to step-by-step remove the
labels looking for a wildcard match. Thus, recognized valid input can
nonetheless control a vast amount of processing. I’ve got some creative
solutions to partially mitigate this problem, though I wonder how others solve
it.
By the way, the parser for packets is here:
https://github.com/robertdavidgraham/robdns/blob/master/src/proto-dns-parse.c#L131
One thing to note is that I fully validate a compressed DNS name before
extracting it. Thus, when you look at the “extract” function, it has zero
protection against attacks -- either I trust the "recognizer" or I don't.
_______________________________________________
langsec-discuss mailing list
langsec-discuss@mail.langsec.org
https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
