Subject: Re: [DNSOP] dns data exchanged between host and local dns-sever

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 Apr 2009 13:38:22 +0200

On Thu, Apr 23, 2009 at 06:32:38PM +0800,
 ???? <[email-masked]> wrote 
 a message of 85 lines which said:

> while DNSSEC fails to give a means by which the DNS queries or
> responses transmitted between a host and a recursive server could be
> guaranteed integrity and authentication. 

Not really true. Many people think that the validating resolver should
be on the host itself. This would use DNSSEC to secure even the last
mile.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 23 Apr 2009 14:34:14 +0200

Stephane,

> be on the host itself. This would use DNSSEC to secure even the last

Presumably it would still forward queries to a nearby recursive
resolver, so there would be some shared caching going on?

Has anybody ever written this down anywhere? (Sorry if I missed it.)

--
Shane

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 23 Apr 2009 14:40:49 +0200

> Has anybody ever written this down anywhere? (Sorry if I missed it.)

It is called a validating stub.

Best regards,
   Wouter

---

From: Shane Kerr <[email-masked]>
Date: Thu, 23 Apr 2009 14:54:20 +0200

Wouter,

> It is called a validating stub.

Okay, that's defined in RFC 4033, but has anybody ever written down that
this is the way everybody should do DNSSEC from now on?

I also didn't see anything about caching behavior in RFC 4033, but I
admit I might have missed it.

Cheers,

--
Shane

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 23 Apr 2009 09:26:07 -0400

> this is the way everybody should do DNSSEC from now on?

Given that the largest provider of host operating systems currently
deployed is not planning to do DNSSEC this way, won't we have some
trouble if we start suggesting it's the right way?  (I.e. won't this
be another occasion of the IETF providing advice that is flagrantly
ignored by large chunks of the Internet, in much the way that BCP38
might be considered "best" but not actually "current"?)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: [email-masked]
Date: Thu, 23 Apr 2009 13:41:30 +0000

On Thu, Apr 23, 2009 at 06:32:38PM +0800, i),h?* wrote:
> Hi, folks.
>  
> As we all know, DNSSEC provides origin authentication and integrity assurance services for DNS data exchanged between DNS resolver and name-sever, while DNSSEC fails to give a means by which the DNS queries or responses transmitted between a host and a recursive server could be guaranteed integrity and authentication. For example, a malicious attacker might hijack the DNS query form a host and fake a response which will help he commit phishing. So I wonder, is there someone having a certain solution, more exactly a software implementation on host, to protect against such attack?
> 
> 2009-04-23 
> 
> [email-masked]

As mentioned elsewhere,  TSiG, GSS-TSiG,  and IPSEC are all forms of channel security. The 
unfortunate truth is, these are unwieldy when managing large numbers of connections.  for a 
slightly more scaleable solution, you might consider SIG(0).  -  All of these are defined in
RFC's and there are several interoperable implementations.

Other channel security ideas that are floating around (but have nto gained traction in the
IETF or market) are:

	EDNS-PING
	DNS-CURVE

--bill

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Apr 2009 09:45:46 -0500

On Apr 23, 2009, at 8:26 AM, Andrew Sullivan wrote:
> trouble if we start suggesting it's the right way

We can't force anybody to do anything.   However, if this is really  
the right way to do it, then any vendor who is sensitive to security  
issues will eventually come around.   If it's the wrong way to do it,  
we shouldn't be suggesting it.   The vendor you happen to have  
mentioned participates in IETF; perhaps they could weigh in on why  
this is the wrong thing to do, if in fact it is.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Apr 2009 11:07:29 -0400 (EDT)

> Other channel security ideas that are floating around (but have nto gained traction in the

dnscurve can never work. It removes ALL caching infrastructure from the
internet. Please, send it the way of the OSI model and never mention it
again.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Apr 2009 11:15:36 -0400 (EDT)

On Thu, 23 Apr 2009, Andrew Sullivan wrote:

> trouble if we start suggesting it's the right way?

If you start on that path, you might as well let that vendor run IETF.

As for this specific issue, Fedora-12 is planned to have "dnssec on
the desktop". I am sure someone will come with an OSX app as well,
and someone is bound (sorry) to ship unbound as a windows app too.

Think of it as the firewall and antivirus solutions. It starts as an
addon and then is integrated in the OS.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Apr 2009 11:19:01 -0400 (EDT)

> It is called a validating stub.

And thanks to Wouter, unbound can now handle the case where the
DHCP obtained forwarder can be updated into a running unbound,
even if it means switching back and forth to being able to use
dnssec with the forwarder.

Now we just need something clever for hotspots that mangle DNS, though
I think more and more are using IP redirection instead of DNS mangling.

Paul

---

From: David Conrad <[email-masked]>
Date: Thu, 23 Apr 2009 08:43:03 -0700

On Apr 23, 2009, at 5:34 AM, Shane Kerr wrote:
>> be on the host itself.

Many?  I can only dream.

>> This would use DNSSEC to secure even the last mile.
>

You could do that, sure.  It would be a reasonable optimization, but I  
don't expect it actually necessary (one could look at the amount of  
crap hitting the root servers). However the point is that you need to  
do the validation someplace you can talk securely to.  The easiest  
answer is to simply do the validation on the same host.

I figure stub resolvers were needed when cpu/bandwidth/memory were a  
bit more expensive than now.  It seems a shame to constrain our  
architecture to the '80s...

Regards,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Thu, 23 Apr 2009 12:52:37 -0400

At 8:43 -0700 4/23/09, David Conrad wrote:

>root servers). However the point is that you need to do the validation
>someplace you can talk securely to.  The easiest answer is to simply do the
>validation on the same host.
>
>I figure stub resolvers were needed when cpu/bandwidth/memory were a bit
>more expensive than now.  It seems a shame to constrain our architecture
>to the '80s...

OTOH, for the one of the same reasons DHCP is so popular, that is 
centralized local management, it is desirable (in some instances) to 
have the validation done in the commons and not in end hosts.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: [email-masked]
Date: Thu, 23 Apr 2009 17:37:22 +0000

> have the validation done in the commons and not in end hosts.

	locus of control.

	i happen to agree w/ David here.  there really is no serious technical
	hurdle for moving a full-bore DNS IMR into most platforms these days
	(modulo the RFIDs and some of the IoT stuff).

	the upsides are huge for mobility, ad-hoc, and temporally disconnected
	networks.

	the downsides are the LEOS (protecting our security), and the Shylocks
	who need to collect what remains of the lunch money.  

--bill

---

From: John Schnizlein <[email-masked]>
Date: Thu, 23 Apr 2009 14:11:44 -0400

Locus of control?  Or that pesky old trust anchor?

Separable issues: where the validation computations are done, and  
setting (and updating) the trust anchor.  For computation, the  
advantage of caching after validation in the (shared) recursive  
resolver probably does not keep up with the performance improvements  
of (end) hosts.  Distributing trust anchors to hosts is another scale  
step harder than maintaining them on (shared - validating) recursive  
resolvers.

Speaking of the popularity of DHCP, that is all about distributing  
current parameters to (end) hosts.  If only there were a trustworthy  
way to do that.  DHCP could do that, except for the key distribution  
problem (again).  But some sort of key distribution is necessary to  
protect the hop from a stub resolver and the recursive resolver also.

My guess is that the solutions for updating (end) host software will  
get trustworthy enough to be used for DNSSEC trust anchors, and the  
validation will end up in the (end) host.  Until the host OS  
manufacturers realize this is worth their while, validation in hand- 
crafted recursive resolvers can get things started.

John

---

From: [email-masked]
Date: Thu, 23 Apr 2009 18:18:32 +0000

locus of control.  centralization of resource control.
 lack of autonomy in an end-to-end system.   trust anchor placement
 is "just another brick in the wall" here.  but i have now dragged out 
 my soapbox and i'm pretty sure this is not speakers corner... 
 
 so i'll shut up and go back in the woodwork.

--bill

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Apr 2009 13:35:59 -0500

> crafted recursive resolvers can get things started.

Every current O.S. out there (Windows, Mac OS X, Redhat, Ubuntu, etc)  
already has a trust anchor model, which they use to validate  
updates.   So the trust anchor problem is already, to a great extent,  
solved.   It's true that a determined on-path attacker could prevent a  
particular end host from getting the updates that would allow them to  
validate DNSSEC responses if they installed from old media.   But in  
practice this problem is already solved, not only by automatic update  
systems, but also by browser vendors.

What remains to be secured is the initial phase of the install media  
distribution process.   We really ought to solve it *before* malware  
authors start to get serious about attacking it.   But once you have  
an install that has valid trust anchor keys in the software update  
system, you do have a secure way to bootstrap DNSSEC (or at least  
securely fail to bootstrap DNSSEC), even if the DNSSEC trust anchor  
that came with your install media has expired.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 23 Apr 2009 15:24:45 -0700

> 	i happen to agree w/ David here.  there really is no serious technical

I would generally encourage that trend.

> 	who need to collect what remains of the lunch money.  

I do not particularly disagree with your conclusion, but I believe
your assessment of the 'downsides' is incomplete in at least one
regard;

The system in place currently has a benefit in that it is trivially
simple.  Very few implementations have gotten this wrong over the
years, and when they have it was trivially simple to debug.  Query,
reply.  Comparatively, DNSSEC recursive resolution is significantly
more complex, and the scope of the deployment of that resolution
becomes a multiplier in the costs to deploy and maintain a web of
interoperating systems.

That said, I think recursive resolution can and should be pushed into
the end hosts, but that solution may not be universal, and it may be
discovered to be intractable, so it is also wise to invest in an
interim solution that can potentially be maintained for an extended
period.

I believe some ideas for that were mentioned already.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

---

From: David Conrad <[email-masked]>
Date: Fri, 24 Apr 2009 17:08:46 -0700

Ed,

> have the validation done in the commons and not in end hosts.

Sorry, not sure I see a valid use case where _security_ (as opposed to  
configuration as would be the case in DHCP) is centralized.  As I  
mentioned, centralization of cached data would be a reasonable  
optimization, but the primary pragmatic reason for stub resolvers  
talking over the wire has been made obsolete by Moore's law.

Regards,
-drc