Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt

From: Brian Wellington <[email-masked]>
Date: Mon, 23 Jul 2001 11:10:41 -0700

On Mon, 23 Jul 2001, Edward Lewis wrote:

> >I think Jakob was talking about an authoritative server, though.  The
> >answer is probably "no", but enforcing this has major implications on the
> >server, since it requires the server to inspect the data it's returning
> >for every query, rather than just finding it and sticking it in the
> >response.
>
> So am I...Jakob and I (I think) both agree that the answerer (especially on
> authoritative servers) should verify-on-reply.

Nobody seems to understand that verify-on-reply is a bad idea.  An
authoritative server is designed to serve data, that's it.

> >This sounds like another reason to split authoritative and caching
> >service.  The recursive server will be doing the validation anyway, and
> >can clamp the TTL based on the expiration time.
>
> I think Brian's presumption is that the authortitative server should not
> verify its own data because this represents a waste of time.  Others have
> expressed the opinion that having the authoritative server verify on send
> has two advantages.

Yes.

> First is that verify-on-send would allow the AD bit to be sent, thus making
> the resolver look just for the AD bit to see if an answer is "secured."
> (Let's not debate "secured" this instant.)  Currently, a resolver would
> have to check the AA or AD bit to see if the answer is "secured or I
> personally known it" (speaking for the answering server).  This current
> situation slightly complicates the resolver.

This goes away if the resolver only talks to a caching server.

> Second is that the verify-on-send ensures that there is a currently valid
> signature for the answer.  In the case of a temporal-swiss-cheese zone
> (meaning there are temporal gaps in signature coverage) an answer shouldn't
> emerge that might be accepted by a stub resolver.

And this does too.  There's no reason to put DNSSEC goop in an
authoritative server, when caching servers already need it.

> My opinion is that I would like to have the option of having my server
> verify-on-send.  I think a resolver should still accept an AD with TSIG on
> par with AA with TSIG.  And I think any set in a signed zone that is not
> properly signed should be seen as a SERVFAIL answer.
>
> Okay, Brian, disagree away...;)

See above.

DNSSEC is very complicated to implement, but all of the complication lies
in the validation.  The only changes necessary to make an authoritative
server support DNSSEC are the ability to return SIGs when necessary and
NXTs.  That's it.  Easy.  Making the server validate on queries requires a
complicating the code path (violating "optimize for the common case"), and
is a huge performance hit.  Even if the signatures are valid, the server
will need to unpack them and check the times.

Please tell me why, if you want your resolver to get the AD bit, you don't
just point it at a caching-only server.  It works now, and it's the Right
Answer (tm).

Brian

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Jul 2001 11:58:33 -0700

>will need to unpack them and check the times.

This is a pertinent arguement if the only thing you care about is the
construction of the code.  There are two reasons I see for verify-on-send
(query):

1) Checking the validity period of the signatures.
2) Checking to make sure the key chain is still accessible.

IOW - don't hand out data that isn't verifiable.

I'm not arguing that these are the concerns of some domains, but they are
of others.  (See my reiterated point below.)

I would like to experiement with these options - possibly verifying-on-send
only if TSIG is being used.

As far as "violating 'optimize for the common case,'" maintaining this
optimization is fine, but don't code only for the common case.

>just point it at a caching-only server.  It works now, and it's the Right

In the previous mail I sent (I'm catching up out of order), I sent an
answer to this - basically, my recursive server is also authoritative for
most of my queries.

To reiterate my point from the other message - please don't force me to use
DNS the way you think it should be used.  The "Right Answer" shouldn't be
the "Only Solution."

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Jul 2001 11:58:38 -0700

I can't resist the following observation:

>authoritative server is designed to serve data, that's it.

Ergo, the consensus is that verify-on-reply is a good idea?

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 23 Jul 2001 12:39:53 -0700

> authoritative server is designed to serve data, that's it.

whether it is bad idea or not to do verify-on-reply is up to the server
administrator, not the people writing the specifications.

> This goes away if the resolver only talks to a caching server.

but the caching server might also be your authorative server. in reality
most authorative server also serve as caching server for some local
clients.

verify-on-send could of course be configurable, as recursion is in some
servers.

	jakob