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

[Brian Wellington <[e-mail]>]

On Fri, 27 Jul 2001, Ted Lindgreen wrote:

> [Quoting Brian Wellington, on Jul 26, 18:06, in "Re: I-D ACTION:draft ..."]
> > On Thu, 26 Jul 2001, Ted Lindgreen wrote:
> >
> > > Note: It would have been different, if BIND in the "recursive view"
> > > would actually check the data it is authorative for query-time,
> > > but as far as I know this is not in the code at the moment.
> >
> > You missed the point again.  In the "recursive view", there is no
> > authoritative data.  There is only cached data.  If the cached data is
> > obtained from the "authoritative view", it's treated just like data
> > obtained from any other source, meaning it is validated at the time it's
> > received and the TTL is properly clamped.
>
> Dear Brian,
>
> I stand corrected, indeed, I did not understand that from the
> same server, you get different answers, depending on to what view
> you belong. Your answer made me further very happy, as it now
> appears, that with some careful configuration the software can do
> something close to what we want (be careful not to advertize data
> with bad and/or outdated sig's).

Good.

> However, my happiness did not last very long :-(
>
> Of course, I tried it out immediately to see how we can adopt
> this scheme in our DNSSEC testbed for .nl.nl.
>
> However, after trying out various configuration setups I found out,
> that setting up multiple views is extremenly tricky, especially if
> your systems are authorative for various domains at different levels
> in the tree. Although we are doing something special with DNSSEC,
> I don't think our tree-structure is very uncommon in the real world.

It shouldn't be tricky.  If you describe what you did (to a more
appropriate place, like bind9-users), someone might be able to find the
problem.

> After reconfigurating for 6 hours now, I still have not found
> a configuration, that would reliably produce verified data where
> I want it to do that, and to provide authoritive data where it must
> do that to prevent the delegations from getting lame.

Yes, this is a real problem.  Fortunately, I'm one step ahead of you.
Added yesterday:

 945.   [func]          Add the new view-specific options
                        "match-destinations" and "match-recursive-only".

"match-recursive-only" will allow recursive clients to match the recursive
view, while non-recursive clients (such as forwarding servers and zone
transfer clients) to match an authoritative view.  This will be in BIND
9.2.0b2, due (I think) Monday.

> I've given up now, and only left the testdomain "ted.dnssec.nl.nl"
> secured on a dual view server in case any anyone is interested to
> look at it: sanne.nlnetlabs.nl is the dual-view server, and
> auth-parent-servers plus its own secondaries are in the auth. view;
> the rest of the world in the recursive view; with
>  dig @sanne.nlnetlabs.nl +dnssec -t txt ted.dnssec.nl.nl
> you can see, that sometimes the answer is as Brian predicted above,
> and sometimes you get "SERVFAIL". I have not been able to find out
> what the reason for this inconsistance is.

It's probably that problem with nonauthoritative answers.  Can you try
the same setup with 9.2.0b2 when released?

> Because of trickyness and the stability problem, I reverted to the
> old setup for all other domains, where bad and outdated sigs are
> happily provided.
>
> PS. To go back on topic: I still think that it's a hack, and that
> it is better to have the AD-bit to mean the same thing in every
> view or context.

It does mean the same thing in every context.  The current version of BIND
9, for example, only sets AD when the data has been verified.  Unless I'm
mistaken, this is exactly what you're arguing for.  The "bad or outdated"
SIGs are coming from an authoritative zone, and the AD bit is not set.

Brian




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