Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 24 Feb 2010, Phillip Hallam-Baker wrote:

I would like to see us create an assumption that a given machine will
only use recursive resolution services from a specific trusted source.

Trust no one. More and more devices will do their own DNSSE validation,
and just use caches to get the data. That's the beauty of DNSSEC and
one of the two main bottlenecks of DNSCurve (the other is requiring cpu
for crypto on every packet)

This in turn requires us to add some features to the protocol as we
need to add mechanisms for access control.

There is already access control possible, eg TSIG/SIG(0). Just no one
seems to use it on the stub resolvers.

We also need to make some
changes to get around widespread DNS hacks used to support roaming
WiFi provision.

Most of those have moved away from DNS already and just hijack the IP
port 80 stream instead.

[Oh we are so not close to being done with deployment here. If turning
on DNSSEC means the typical Web surfer cannot get their WiFi access at
Panera without reconfiguring their machine then DNSSEC is stone cold
dead.]

The fix for this will come from the browsers, who have to deal with this
situation anyway to avoid your 20 open tabs from reloading into a portal
page.

Rather than using the approach in DNScurve, I would want to see
something like the following:

* When a new machine is brought up the configurer is asked which
network they want it to be a part of, identified by a DNS name. This
will be the place that the system will use to look for the trusted DNS
resolution service. Since I use 8.8.8.8 I would enter 'google.com'.
The default could be taken from DHCP
* New RR to allow a machine to locate a trusted resolution service for
the network and authentication protocols supported. The initial
bootstrap could be taken from the DHCP service.
* Key agreement mechanism that allows the client to establish a
persistent binding represented by a kerberos style ticket
* Packet encapsulation mechanism that enables a kerberos style ticket
to be entered into client request packets.

Seems much easier to me to store 1 DNSSEC root key and do it yourself.

Paul
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]