Introducing CurveDNS a DNSCurve forwarding name server

[Harm van Tilborg]

Hello people,

/Not really the appropriate list but I think not much people will
object, since it is quite related to djbdns./

We are happy to announce the first forwarding DNSCurve solution: CurveDNS.

With CurveDNS you are able to transform any authoritative name server in
a DNSCurve capable one. This is done by acting as a kind of proxy, i.e.
listening to DNS or DNSCurve queries and forwarding the non-protected
variants towards the real (existing) name server. The responses are then
send back to the client either protected (if the query was in DNSCurve)
or not.

In short, CurveDNS supports:
* Forwarding of regular (non-protected) DNS packets;
* Unboxing of DNSCurve queries and forwarding the regular DNS packets
* Boxing of regular DNS responses to DNSCurve responses;
* Both DNSCurve's streamlined- and TXT-format;
* Caching of shared secrets;
* Both UDP and TCP;
* Both IPv4 and IPv6.

This entire project is based on a master thesis named 'Shaping DNS
Security with Curves — A Comparative Security Analysis of DNSSEC and
DNSCurve', you can find this thesis at the CurveDNS website too.

Interested? More information, documentation, et cetera can be found at
the CurveDNS website:
http://curvedns.on2it.net/

[Brandon Black]

Post by Harm van Tilborg
Hello people,
/Not really the appropriate list but I think not much people will
object, since it is quite related to djbdns./
We are happy to announce the first forwarding DNSCurve solution: CurveDNS.

Great to see another implementation coming out! Nice work. I've been
on the verge of giving up on DNSCurve for a while now, but it just
keeps hanging in there. Good ideas are hard to kill :)

-- Brandon

[Maciej Żenczykowski]

FYI,
On Fedora 13 x86_64
#include <ev.h> should be #include <libev/ev.h>

./cache_hashtable.h:#include <libev/ev.h>
./ip.h:#include <libev/ev.h> /* libev */
./event.h:#include <libev/ev.h>

Making an installable rpm will be difficult because of the interactive
prompt from configure.curvedns
and because of the auto-tuning of NaCl.
However with the interactivity fixed it should be possible to at least
make a source rpm.

Post by Harm van Tilborg
Hello people,
/Not really the appropriate list but I think not much people will
object, since it is quite related to djbdns./
We are happy to announce the first forwarding DNSCurve solution: CurveDNS.

Great to see another implementation coming out!  Nice work.  I've been
on the verge of giving up on DNSCurve for a while now, but it just
keeps hanging in there.  Good ideas are hard to kill :)
-- Brandon

[Harm van Tilborg]

Hi Maciej,

Thanks for the response.

Ouch, that's quite a non-standard path. Anyone that has some ideas to
deal with this?

The interactive way of `configure.curvedns' can be dealt with, by just
selecting the first entry of `okabi' (which is regularly the 64 bit
version). NaCl's part is another story...
--
Kind regards,
Harm van Tilborg

Post by Maciej Żenczykowski
FYI,
On Fedora 13 x86_64
#include <ev.h> should be #include <libev/ev.h>
./cache_hashtable.h:#include <libev/ev.h>
./ip.h:#include <libev/ev.h> /* libev */
./event.h:#include <libev/ev.h>
Making an installable rpm will be difficult because of the interactive
prompt from configure.curvedns
and because of the auto-tuning of NaCl.
However with the interactivity fixed it should be possible to at least
make a source rpm.

Post by Brandon Black

Post by Harm van Tilborg
Hello people,
/Not really the appropriate list but I think not much people will
object, since it is quite related to djbdns./
We are happy to announce the first forwarding DNSCurve solution: CurveDNS.

Great to see another implementation coming out! Nice work. I've been
on the verge of giving up on DNSCurve for a while now, but it just
keeps hanging in there. Good ideas are hard to kill :)
-- Brandon

[Alejandro Mery]

Post by Harm van Tilborg
Hi Maciej,
Thanks for the response.
Ouch, that's quite a non-standard path. Anyone that has some ideas to
deal with this?

I suppose the right solution is to pass -I/usr/include/libev in an
optional $(LIBEV_CFLAGS) and leave the C code in peace.

Regards,
Alejandro Mery

[Harm van Tilborg]

Hi Alejandro,

Yep, that's probably the easiest way to achieve this.

I'm sorry, my last message was sent too early in the morning to be
totally correct ;]. We already arranged something to easily fix this:
check the header of the Makefile template (Makefile.in):

# If you have libev at a non-standard place, specify that here:
#EV=
#EVCFLAGS=-I$(EV)/include
#EVLDFLAGS=-L$(EV)/lib

So, this would work:

# If you have libev at a non-standard place, specify that here:
#EV=
EVCFLAGS=-I/usr/include/libev
#EVLDFLAGS=-L$(EV)/lib

(Don't know whether the library itself is also in /usr/lib/libev, which
would imply EVLDFLAGS should be altered too.)
--
Kind regards,
Harm van Tilborg

Post by Alejandro Mery

Post by Harm van Tilborg
Hi Maciej,
Thanks for the response.
Ouch, that's quite a non-standard path. Anyone that has some ideas to
deal with this?

I suppose the right solution is to pass -I/usr/include/libev in an
optional $(LIBEV_CFLAGS) and leave the C code in peace.
Regards,
Alejandro Mery

[d***@epfl.ch]

Hey folks,

Do you guys know of any [documented] real case of DNS cache poisoning?

There are a lot of boring technical documents about the flaws of DNS,
but I don't find much about the real damages it did actually make (in
terms of money let's say).

If you have any reference please let me know.

Kind regards,
Dinesh

[Hauke Lampe]

Post by Harm van Tilborg
We are happy to announce the first forwarding DNSCurve solution: CurveDNS.

Nice work.

I installed it on a test server:

dig curvetest.openchaos.org SOA
(fwiw, the zone is also DNSSEC-signed, verifiable via dlv.isc.org)

I had a problem at first where curvedns would bind the listening ports
but could not forward UDP queries when not run as root.
That problem vanished somehow, I don't know why.

A more serious problem was that curvedns did not select a specific
outbound address and I need it to do that, so the authoritative
nameserver responds from the correct view.

I patched it to use the first local address of matching address family,
but it would probably be better if the outgoing addresses could be
configured separately:
https://www.hauke-lampe.de/linkedstuff/curvedns-0.86-outgoing-addr.patch

Ubuntu users find binary and source packages here:
https://launchpad.net/~hauke/+archive/dnscurve/+packages



Hauke.

[Harm van Tilborg]

Hi Hauke,

Post by Brandon Black

Post by Harm van Tilborg
We are happy to announce the first forwarding DNSCurve solution: CurveDNS.

Nice work.
dig curvetest.openchaos.org SOA
(fwiw, the zone is also DNSSEC-signed, verifiable via dlv.isc.org)

Haven't checked it myself yet, but DNSSEC queries

Post by Brandon Black
I had a problem at first where curvedns would bind the listening ports
but could not forward UDP queries when not run as root.

curvedns usually binds to port 53 to listen for incoming queries, which
implies root privileges are needed (since port < 1024). After curvedns
has bound itself to that port, it degrades itself to the user that is
specified in the UID and GID environment variables.

Post by Brandon Black
That problem vanished somehow, I don't know why.
A more serious problem was that curvedns did not select a specific
outbound address and I need it to do that, so the authoritative
nameserver responds from the correct view.

I see why this would be handful for people.

Post by Brandon Black
I patched it to use the first local address of matching address family,
but it would probably be better if the outgoing addresses could be
https://www.hauke-lampe.de/linkedstuff/curvedns-0.86-outgoing-addr.patch

I will release a new version that will include a patch similar to this
one (probably tomorrow). However, instead of using one of the listening
addresses, I agree that specifying an address specifically for outgoing
contact with the authoritative name server sounds better. Probably some
environment variable like `CURVEDNS_OUTGOING_SOURCE_IP' will house this
IP address.

Thanks for the patch!

Post by Brandon Black
https://launchpad.net/~hauke/+archive/dnscurve/+packages

Wow, nicely done! I see you have packaged NaCl separately. How did that go?

Post by Brandon Black
Hauke.

[Harm van Tilborg]

Hi Maciej,

You are right. The idea was taken from djb's approach in djbdns --
together with daemontools' envuidgid tool.

I'm changing it in the next release, making it a bit harder to easily
specify the effective uid and gid -- since envuidgid cannot be used anymore.

I think `CURVEDNS_USER' will house the user CurveDNS is about to run
under when root privileges are not needed anymore.

[Hauke Lampe]

Post by Harm van Tilborg
I'm changing it in the next release, making it a bit harder to easily
specify the effective uid and gid -- since envuidgid cannot be used anymore.

I'm not convinced that's a good idea. It was really easy to set up
curvedns _because_ it worked mostly like dnscache or tinydns.

This is the "run" file I use:

#!/bin/sh
exec 2>&1
exec envdir ./env sh -c '
exec envuidgid dnscache /usr/sbin/curvedns "$IP" "$PORT" "$FORWARD"
"$FORWARD_PORT"
'
(yes, I use the same user/group as for dnscache)

Post by Harm van Tilborg
I think `CURVEDNS_USER' will house the user CurveDNS is about to run
under when root privileges are not needed anymore.

Maybe you could make that an additional option and use $UID/$GID if
$CURVEDNS_USER is unset.


Hauke.

[Harm van Tilborg]

Post by Hauke Lampe

Post by Harm van Tilborg
I think `CURVEDNS_USER' will house the user CurveDNS is about to run
under when root privileges are not needed anymore.

Maybe you could make that an additional option and use $UID/$GID if
$CURVEDNS_USER is unset.

Convinced :]. Good solution. Will be in 0.87 that will probably come out
this week.

[Bernd Plagge]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 25 Oct 2010 15:48:27 +0200

Post by Harm van Tilborg
I'm changing it in the next release, making it a bit harder to easily
specify the effective uid and gid -- since envuidgid cannot be used anymore.

Why can't envuidgid not be used anymore?

If so you may want to check runit which you can find here: http://smarden.org/runit/

Cheers,
Bernd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkzFrZoACgkQpYU8M8PbPV47RQCgpysDteppAcLl1IX/PqD42cwr
Y3gAoLwuWTgHneZh1JD98XKdHKrOpU+1
=b3kW
-----END PGP S

[Richard J. Sexton]

In the late 90s Eugene Kashpureff set up some A records for internet.net
so when somebody send mail to him and looked up the MX record for his alternic.net
they got the wrong A records for internic.net which he'd pointed to alternic.net
so when you typed in http://internic.net you were taken to Alternic. In other
words he's hijacked the Internic. As you might imagine, the usual cast
of characters went ballistic, and that's putting it mildly.

Note the mail and www.internic.net were unaffected.

This landed him on both Canadian and American prisons when the FBI
finally found him and on TV on the CBC show "Undercurrents" with
Wendy Mesli. I'm sorta on that show too; I was working with him
previously but I'd had enough of THAT about 6 weeks before he pulled this
stunt and didn't know he'd done it till he did. He didn't tell anybody
before he did it.

This killed the alternative root server movement and "legitimized"
(the need for) icann. It was a stain we could never get rid of. Alternic
had about 3-4% penetration until that day - then it went to zero overnight
and never recovered. All subsequent efforts failed mostly because of this
disaster.

Pretty much nobody has talked to Eugene since then. Dumbest thing ever.

Eugene got off light and as part of the settlement he had to explain to
Mark Kosters at NSI what he'd done and how.

Note that only BIND was susceptible to this. djb was of course unaffected
because it rejects out of balliwick answers.

Post by d***@epfl.ch
Hey folks,
Do you guys know of any [documented] real case of DNS cache poisoning?
There are a lot of boring technical documents about the flaws of DNS,
but I don't find much about the real damages it did actually make (in
terms of money let's say).
If you have any reference please let me know.
Kind regards,
Dinesh

--
Richard J. Sexton ***@rd.vrx.net [phone] skype: rsx11s
http://rs79.vrx.net http://mbz.org http://killi.net http://aquaria.net