[Dnsmasq-discuss] Automatic DNSSEC-signing of ressource records

[Rene Bartsch]

Am 2014-09-12 19:25, schrieb Jim Gettys:
> On Fri, Sep 12, 2014 at 7:44 AM, Rene Bartsch <ml at bartschnet.de>
> wrote:
> 
>> Am 2014-09-12 10:17, schrieb Jeroen van der Ham:
>> 
>>> Ah you mean you want to use DNSmasq to do the automatic
>>> translation
>>> from DHCP leases to DNS, and then automatically sign them. I
>>> would
>>> still advise you to use a secondary nameserver, unless you’re
>>> not
>>> running any mission-critical systems (in which case I think this
>>> is
>>> somewhat over the top)
>> 
>> You need secondary nameservers, of course. Secondary nameservers
>> are cheap or even for free. When I studied I was in a group of
>> students each running a root server as primary nameserver for his
>> domain(s) and we shared the root servers as secondary nameservers
>> with each other.
> 
> ​Several years ago, before Paul Vixie left ISC, we had a discussion
> about whether ISC could act as secondary name servers at scale (at a
> minimum for the U.S., for everyone's personal domains).  Paul thought
> that they could without it being a serious load for them (ISC runs one
> of the root name servers).
> 
> I've also had a similar set of discussions with the person who used to
> be in charge of Comcast's excellent DNS infrastructure, and he was
> interested, to the point of prototyping automating the delegation of
> the zone provided by the ISP (certainly Comcast allocates a name for
> each and every customer, it turns out) and doing the handshake for
> signing keys.​ He has since left Comcast, so we'd have to start
> over, but from my previous interactions with the technical folk at
> Comcast, I'm optimistic.
> 
> If/when I can track down the right Googler who runs their DNS
> infrastructure, I'd like to have a similar conversation with them as I
> have had with Paul and Comcast in the past.
> 
>>> What I have trouble with though is that DNSSEC is not yet at a
>>> stage
>>> where it is easy to use. It certainly is still not easy to
>>> troubleshoot and pinpoint problems. This goes beyond having an
>>> easy
>>> interface to the DNS system itself, or automatic signing of
>>> records.
>> 
>> I'm running my three private domains with hosted DNSSEC without any
>> problem. The only drawback is my registrar does not provide DynDNS
>> and lacks some resource records - and Google Public DNS has a
>> wildcard-resolution bug. The main problem is registrars usually lack
>> important features for consumers, may mit be DNSSEC, DynDNS for
>> dynamic IPs, IPv6 glue-records, some resource records or a usable
>> interface for consumers.
>> 
>> My dream is a consumer router at which the consumer just enters his
>> public domain name(s) and the hostnames/IP addresses of Dnsmasq
>> instances he wants to be secondary nameservers (and provide
>> secondary nameserver service for). The router would just display the
>> secondary nameserver hostnames/Glue-Records and the Zone-Signing-Key
>> or DS-Key to be sent to the registry via the registrar. As the
>> Key-Signing-Keys are kept on the router you just have to check if
>> the registry publishes the correct ZSK/DS-record to be sure your
>> zone has not been tampered with. The router can even scan the hosts
>> in the LAN for services (e.g. TLS) and add records automagically
>> (e.g. TLSA-RRs for DANE). In expert mode additional records could be
>> added manually.
> 
> ​The ​above conversations I had with Paul Vixie and Comcast
> bothmake me optimistic something can get worked out eventually, and
> that this is not merely a pipe-dream.
> 
> People with technical smarts understand that typing addresses
> 2601:6:6800:724:466:4d34:949:1003 by hand really sucks and that fixing
> naming as presumed by IPv6 design needs to happen. User friendly, it
> isn't, much less aged parent friendly. And everyone has
> parents/grandparents they are sysadmin for making this pretty clear in
> a first hand way. .local addresses you can't use with others just
> don't hack it, and renumbering, which often happens, makes doing
> things manually a PITA.
> 
> Note also this scales well, as to where the signing occurs.  And it
> means that the keys don't have to leave the customer's control.
> 
> Now we just have to make the dream a reality.  I think we can find
> people in the DNS core to work with to test it out.
> 
>                                          - Jim

To be honest I'm not very fond of centering all secondary nameserver 
service on one operator which would gain the power to control the name 
resolution of most of the internet.

The DNSSEC-cache of a resolver is a signed data table which makes it 
simple to share it via a Kademlia-like protocol. If all Dnsmasq 
instances share their DNSSEC-cache all instances with a public static IP 
address can be used as secondary nameservers. You don't even have to 
configure a Dnsmasq instance to be a secodary nameserver for a domain. 
Just enter the IP-addresses of trustworthy Dnsmasq instances as NS-RRs 
in your zone and as Glue-Records at your registry. This would also allow 
to run your Dnsmasq as a hidden primary nameserver behind a dynamic IP 
address or even NAT.


-- 
Best regards,

Renne