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

From: Brian Wellington <[email-masked]>
Date: Mon, 23 Jul 2001 13:43:53 -0700

On Mon, 23 Jul 2001, Jakob Schlyter wrote:

> On Mon, 23 Jul 2001, Brian Wellington wrote:
>
> > Nobody seems to understand that verify-on-reply is a bad idea.  An
> > 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.

It's also up to the server authors.  Speaking as the person most likely to
implement this, I think it's a really bad idea.

> > > 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.
>
> 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.

I'd much prefer to see a server with a "recursive" view and an
"authoritative" view, where all recursive querie went through the
recursive view.  This would allow the server verify authoritative data
(when the query has the RD bit set), without complicating the
authoritative server.

I don't know how difficult it would be to add this functionality to BIND
9, and I'm way too busy with other things to try.

Brian

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

---

From: Randy Bush <[email-masked]>
Date: Mon, 23 Jul 2001 15:11:31 -0700

> implement this, I think it's a really bad idea.

whoops!  while implementors certainly deserve our sympathy, we need to also
be conscious of what users want and what is the technically best protocol.
i hope you can separate your roles as document editor and as implementor.

randy