Beating an Old Horse, but....

[Brian]

Hello,

Does anyone know of any existing branches / work being done for DNSCache
to support DNSSEC validation?

-brian

[Sascha Silbe]

Post by Brian
Does anyone know of any existing branches / work being done for DNSCache
to support DNSSEC validation?

Personally I'd be more interested in DNSSEC support for tinydns. Either
as some kind of preprocessor or directly. Even a recipe to leverage the
BIND tools would be welcome.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

[Colm MacCárthaigh]

A preprocessor wouldn't do. The name-server would need to support EDNS0, and
the smarts to include DS and RRSIG records correctly. Additionally, in order
to support NSEC and NSEC3 there would need to be a lexicographically ordered
index available - a CDB backend won't do. It's a fairly large undertaking.

On Mon, Oct 4, 2010 at 12:13 PM, Sascha Silbe <

Post by Sascha Silbe

Post by Brian
Does anyone know of any existing branches / work being done for DNSCache
to support DNSSEC validation?

Personally I'd be more interested in DNSSEC support for tinydns. Either
as some kind of preprocessor or directly. Even a recipe to leverage the
BIND tools would be welcome.
Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/

[Hauke Lampe]

Colm MacCárthaigh wrote:

----- Original message -----

Post by Colm MacCárthaigh
A preprocessor wouldn't do. The name-server would need to support EDNS0,
and the smarts to include DS and RRSIG records correctly.

NSEC3 needs even more server-side processing for each query.

Post by Colm MacCárthaigh
It's a fairly large undertaking.

It took BIND several years to implement and debug.

Even if you do manage to add all the code necessary to support DNSSEC, where's the point in running _tiny_dns?

I like tinydns. It can serve large zones from a small memory footprint. I wouldn't want to load the 400MB copy of asn.routeviews.org into BIND.

But for DNSSEC zones, I rather use one of the not-so-tiny implementations, e.g. BIND or NSD. PowerDNS
is coming along, too, and with Unbound, I have a validating resolver small enough to run on my mobile phone/computer gadget.

IMHO, DNSSEC is out of scope for tinydns and that's not necessarily a bad thing.


Hauke

[Mark Johnson]

Post by Colm MacCárthaigh
A preprocessor wouldn't do. The name-server would need to support EDNS0,
and the smarts to include DS and RRSIG records correctly. Additionally, in
order to support NSEC and NSEC3 there would need to be a lexicographically
ordered index available - a CDB backend won't do. It's a fairly large
undertaking.

For those not familiar with the guts of the various RFCs, could you perhaps
expand on that statement a little? Note that I'm not disagreeing with you,
I just don't understand the details enough to follow from your premise to
your conclusion.

[Colm MacCárthaigh]

Post by Mark Johnson

Post by Colm MacCárthaigh
A preprocessor wouldn't do. The name-server would need to support EDNS0,
and the smarts to include DS and RRSIG records correctly. Additionally, in
order to support NSEC and NSEC3 there would need to be a lexicographically
ordered index available - a CDB backend won't do. It's a fairly large
undertaking.

For those not familiar with the guts of the various RFCs, could you perhaps
expand on that statement a little? Note that I'm not disagreeing with you,
I just don't understand the details enough to follow from your premise to
your conclusion.

Sure. NSEC and NSEC3 are how DNSSEC may be used to validate the
non-existence of a name. If "NXDOMAIN" was merely a zone-signed response,
then it would be replay-able against arbitrary names from that zone. An
attacker could forge that any name did not exist.

So instead a consistent ordering of records is signed. E.g. lets say you
have the records; apple.example.com and carrot.example.com. With DNSSEC,
you generate a signature that says "apple.example.com
andcarrot.example.com exist
and are lexicographically adjacent". Then if someone queries for "
banana.example.com" at run-time, a record which doesn't exist - and isn't in
any DB - the server finds the nearest match (in this case the apple/carrot
adjacency) and responds with that NSEC signed response.

The querier can then infer "I've been told that nothing between apple and
carrot exist, therefore banana really does not exist". The response is
re-playable against other names that lie between apple and carrot, but
that's ok - they don't exist.

NSEC3 is more or less the same as the above, except that instead of the
plain lexicographic ordering of the names, it's an ordering of hashes of
those names. So the name server must hash the name at runtime, and then look
that up in its lexicographically ordered index to find the nearest match.

For the EDNS0 and DS/RRSIG statements - those are implied by DNSSEC too.
DNSSEC uses the DO bit and other EDNS extended rcodes as a signaling
mechanism. For practical reasons too DNSSEC responses generally require
EDNS0-sized payloads. As for the DS and RRSIG responses - those should be
returned to any DNSSEC querier as part of various signed responses. You can
see these in action with dig +dnssec . , you can also see that "
a.root-servers.net" and "ac." are the first two names in the root zone, and
are adjacent.

(Incidentally, if none of the above is news to someone, my team is hiring -
get in touch!).

[Mark Johnson]

On Mon, Oct 4, 2010 at 2:13 PM, Sascha Silbe <

Post by Sascha Silbe

Post by Brian
Does anyone know of any existing branches / work being done for DNSCache
to support DNSSEC validation?

Personally I'd be more interested in DNSSEC support for tinydns. Either
as some kind of preprocessor or directly. Even a recipe to leverage the
BIND tools would be welcome.
Sascha

Somebody contacted me about adding DNSSEC to tinydns, asking whether I'd
consider merging patches for it into zinq-djbdns. I indicated I would, but
I haven't heard anything back. Contact me off list if you'd like more
information, but the most I can offer is try and put you in touch with the
individual that contacted me.

[Dean Anderson]

The reason the horse is dead is that DNSSEC isn't secure, but is a DDOS
vector awaiting serious exploits. DJBDNS is really a server for smart
people, and smart people don't use DNSSEC...

Wait, aren't you the same Brian that I traced down to be a shill for
Vixie and Kaminsky? And connected spammer Scott Richter? Yes! Yes,
indeed you are the one! God I love the web. I have to get caught up on
my web pages on the scammers....

--Dean


---------- Forwarded message ----------
Date: Sat, 6 Mar 2010 03:23:56 -0500 (EST)
From: Dean Anderson <***@av8.com>
To: Brian <***@comwired.com>
Cc: Paul Vixie <***@isc.org>, ***@ops.ietf.org,
namedroppers-***@lists.iadl.org, ***@list.cr.yp.to,
***@comwired.com
Subject: Re: Brian Smith asks: Who is Dean Anderson?

Well, isn't facebook a wonderful thing. Turns out Brian Smith is a
friend of Dan Kaminksy. Yes, the Dan Kaminsky of the Vixie/Kaminsky DNS
Cache Poisoning scam, the one tried to get people to switch to OpenDNS,
and tried to get DJBDNS to implmement "security" patches that weaken its
security.

Even more interesting was that Sean Stafford (CEO of comwired.com) is a
friend of uber-spammer Scott Richter, of Optinrealbig.com infamy.
That's the guy that MAPS employees were working for in 2003 doing
listwashing (removing spamtrap addresses).

And strangely, is also a friend of Tim Cole of ICANN.

I think the term for what Brian has done here is "Water Carrier" or
perhaps even "Mugging".

Richter's facebook page:
http://www.facebook.com/group.php?gid=54075122043#!/scottrichter?ref=sgm

Stafford's facebook page:
http://www.facebook.com/group.php?gid=54075122043#!/seanstafford?ref=sgm

Smith's facebook page:
http://www.facebook.com/pingwin?ref=sgm

Slam and Dunk.




--Dean

Post by Brian
Hello,
Does anyone know of any existing branches / work being done for DNSCache
to support DNSSEC validation?
-brian

[Andrew Edelstein]

Post by Dean Anderson
The reason the horse is dead is that DNSSEC isn't secure, but is a DDOS
vector awaiting serious exploits. DJBDNS is really a server for smart
people, and smart people don't use DNSSEC...
Wait, aren't you the same Brian that I traced down to be a shill for
Vixie and Kaminsky? And connected spammer Scott Richter? Yes! Yes,
indeed you are the one! God I love the web. I have to get caught up on
my web pages on the scammers....

Oooh, if I "friend" Brian on Facebook, can I be part of the conspiracy
to? <eye-roll>