[prev in list] [next in list] [prev in thread] [next in thread] 

List:       djbdns
Subject:    Re: CurveDNS 0.87
From:       Harm van Tilborg <list () zeroxcool ! net>
Date:       2010-12-29 20:12:40
Message-ID: 4D1B9638.6010202 () zeroxcool ! net
[Download RAW message or body]

On 29-12-2010 16:03, David Nicol wrote:
> On Tue, Dec 28, 2010 at 3:01 AM, Harm van Tilborg <list@zeroxcool.net> wrote:
>>
>> We have just released a new version of CurveDNS:
>> http://curvedns.on2it.net/180/curvedns-0-87
> 
> Awesome! A use case that appears missing from the instructions is when
> you would like one CurveDNS instance to front multiple domains,
> possibly with with different public keys.

The different key approach is currently not supported by NaCl (that
supplies DNSCurve's cryptographic primitives). What we could do is
trying to decrypt (or: unbox, to stay in NaCl terminology) the packet
for each and every configured private key. Without any numbers, I have
the feeling this is not a feasible solution.

There are rumors that adding such feature -- supplying multiple private
keys and a ciphertext -- natively to NaCl would only increase
performance with around 20%...

> Would one have to set up a
> caching forwarder for the multiple authoritative regular servers and
> give all the new NS records the same public key prefix?

I do not understand what you mean here exactly? What do you mean with a
caching forwarder?

> 
> 
> I think I would do it like so with the current CurveDNS capabilities:
> 
> 1: create a dnscache instance that knows via configuration about the
> authoritative servers for the domains I want to curvify, and does not
> know root servers
> 
> 2: configure curveDNS to consult that cache
> 
> 3: add NS records, probably out-of-bailiwick,  prefixed with the
> public key something like
> halottmarhahalottmarhahalottmarha.nevermeta.com for all the domains (
> http://translate.google.com/#auto|en|halott%20marha )
> 
> This seems more complex than it would be if CurveDNS accepted a more
> complex configuration with a list of domain -> (ip, port) tuples
> instead of just one, so that's my wishlist item.

I see what you are trying to achieve. Yes, it's on CurveDNS'
todo-/wishlist. It's listed as: 'forwarding depending on domain name'.
Meaning that indeed a list containing the domain name that states where
to forward the packet to (IP + port), is considered first. In my head I
see a role for cdb in this. But as I will be traveling for quite a while
starting in January I don't see it implemented before June 2011. Or
someone...

> 
> Also it seems that each domain might have its own public key instead
> of the public key being per-server, but that last is probably just
> faulty intuition talking, so that's my question for the FAQ.

You are right that each domain /might/ have its own public key, however
because -- like I just mentioned -- there is currently no native support
for it in NaCl, plus the fact this would increase complexity of key
management, the disadvantages of this approach are clear.

Therefore, every domain hosted on the same authoritative name server
should use the same public key. Meaning the DNSCurve public key can be
considered a server specific key.

-- 
Kind regards,
Harm van Tilborg
[prev in list] [next in list] [prev in thread] [next in thread]