4 Oct 2010 20:46
4 Oct 2010 21:13
Re: Beating an Old Horse, but....
Sascha Silbe <sascha-ml-reply-to-2010-3 <at> silbe.org>
2010-10-04 19:13:40 GMT
2010-10-04 19:13:40 GMT
Excerpts from Brian's message of Mon Oct 04 20:46:22 +0200 2010: > 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/
4 Oct 2010 23:37
Re: Beating an Old Horse, but....
Colm MacCárthaigh <colm <at> allcosts.net>
2010-10-04 21:37:52 GMT
2010-10-04 21:37:52 GMT
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 <sascha-ml-reply-to-2010-3 <at> silbe.org> wrote:
Excerpts from Brian's message of Mon Oct 04 20:46:22 +0200 2010:Personally I'd be more interested in DNSSEC support for tinydns. Either
> Does anyone know of any existing branches / work being done for DNSCache
> to support DNSSEC validation?
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
5 Oct 2010 01:11
Re: Beating an Old Horse, but....
Hauke Lampe <lampe <at> hauke-lampe.de>
2010-10-04 23:11:21 GMT
2010-10-04 23:11:21 GMT
Colm MacCárthaigh wrote: ----- Original message ----- > 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. > 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
5 Oct 2010 04:00
Re: Beating an Old Horse, but....
Mark Johnson <johnsonm <at> gmail.com>
2010-10-05 02:00:30 GMT
2010-10-05 02:00:30 GMT
2010/10/4 Colm MacCárthaigh <colm <at> allcosts.net>
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.
5 Oct 2010 04:22
Re: Beating an Old Horse, but....
Colm MacCárthaigh <colm <at> allcosts.net>
2010-10-05 02:22:25 GMT
2010-10-05 02:22:25 GMT
On Mon, Oct 4, 2010 at 7:00 PM, Mark Johnson <johnsonm <at> gmail.com> wrote:
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.
2010/10/4 Colm MacCárthaigh <colm <at> allcosts.net>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.
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!).
--
Colm
5 Oct 2010 03:53
Re: Beating an Old Horse, but....
Mark Johnson <johnsonm <at> gmail.com>
2010-10-05 01:53:23 GMT
2010-10-05 01:53:23 GMT
On Mon, Oct 4, 2010 at 2:13 PM, Sascha Silbe <sascha-ml-reply-to-2010-3 <at> silbe.org> wrote:
Excerpts from Brian's message of Mon Oct 04 20:46:22 +0200 2010:Personally I'd be more interested in DNSSEC support for tinydns. Either
> Does anyone know of any existing branches / work being done for DNSCache
> to support DNSSEC validation?
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.
12 Oct 2010 03:15
Re: Beating an Old Horse, but....
Dean Anderson <dean <at> av8.com>
2010-10-12 01:15:08 GMT
2010-10-12 01:15:08 GMT
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 <dean <at> av8.com>
To: Brian <brian <at> comwired.com>
Cc: Paul Vixie <vixie <at> isc.org>, namedroppers <at> ops.ietf.org,
namedroppers-honest <at> lists.iadl.org, dns <at> list.cr.yp.to,
sean <at> 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
On Mon, 4 Oct 2010, Brian wrote:
> Hello,
>
> Does anyone know of any existing branches / work being done for DNSCache
> to support DNSSEC validation?
>
> -brian
>
>
--
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 256 5494
12 Oct 2010 06:06
Re: Beating an Old Horse, but....
Andrew Edelstein <andrew <at> pure-chaos.com>
2010-10-12 04:06:41 GMT
2010-10-12 04:06:41 GMT
On 10/11/2010 8:15 PM, Dean Anderson wrote: > 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>
RSS Feed