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

From: [email-masked] (Ted Lindgreen)
Date: Wed, 25 Jul 2001 08:05:17 -0700

[Quoting Roy Arends, on Jul 25, 15:33, in "Re: I-D ACTION:draft ..."]

> On Tue, 24 Jul 2001, Ted Lindgreen wrote:

> If you are referring to my mail from today which stated "as an
> administrator", this was merely an alternative for validation at query
> time, using views. Works like a charm.
> 
> Please enlighten me why it does not fit in many (most?) situations, like
> nameservers on company, university, etc. networks.

OK, these guys (their sysadm's) usually have one or more nameservers,
being authorative for the local domain and acting as caching
forwarders for their local users. Usually for many years, and many
of those sysadm's have experience with various BIND versions over
the years. Many of them are not really affraid of upgrading to
the next BIND release. However....

With multiple views, either the views must somehow be able to
determine for which one an incoming query was meant, or the query
must be sent to the right view directly. Since the former is not
possible (queries from a stubresolver and from a caching forwarder
look the same, at least without further protocol extentions), one
must do the latter.

So, now we have two named-processes on one machine, either listening
on different port numbers, or listening on different IP-numbers.
Exploring the first possibility:
  the sysadm has has no control over all cachers in the world, so
  asking them to use a special portnumber does not work. So, your
  authorative view must keep listening on port 53.
The next possibility:
  the sysadm asks and assists all of its local users to change the
  portnumbers where their stubresolvers send queries. If at all
  possible on the various OS-flavors, "as an administrator" you
  should know how happy such a job will make most sysadm's ;-)

So, we are stuck with the last option: run the nameservers on a
multihomed host, with different IP-numbers for the different views,
and either go to the parent (.com, .nl, .de, etc.) to change the
delegation, or to all local users who have hardcoded the local
dnsservers in their resolve.conf or M$-equivalent to have them
change their setup.

So, setting up a multihomed host, setting up multiple named-views
and getting either TLD or local users to do some administration
right is not a job that the average sysadm really looks forward
to. That's what I meant with "does not fit".

-- ted.

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

---

From: Roy Arends <[email-masked]>
Date: Wed, 25 Jul 2001 16:05:32 -0700

> > nameservers on company, university, etc. networks.

[cut]

> to. That's what I meant with "does not fit".

Ofcourse, the solution would not fit a TLD, since it is not scalable. That
is the reason why servers serving TLD's do (should) not allow recursion.
And for the same reason (i.e. scaling) administrators administring TLD's
probably don't (shouldn't) want crypto-validation on the authoritative
servers.

This scheme would be perfect for those entities who are authoritative for
some zone and offer recursion for their constiuency all on one server. The
phrase "don't look forward to" does not really hold, since there are
more issues at hand when using DNSSEC then this simpel configuration
scheme. Multihomed has really nothing to do with this.

Roy Arends
Nominum.

-------------------------------------------------------
Appendix:

I know that the following is totally off-topic, my apologies to the list
for that, but since I had a few requests for this, here is how the scheme
I mentioned recently can be configured:

solution:

one server (bind-9), one ip-address. two views.

1) constituency queries recursive view.
2) recursive view queries authoritative view.

Config example:

Say machine has ip address 192.168.1.1

BEFORE:

 zone "."                     {type hint;  file "named.root";};
 zone "0.0.127.IN-ADDR.ARPA." {type master;file "localhost.rev";};
 zone "example.com." 	      {type master;file "example.com.signed";};

AFTER:

 trusted-keys { example.com. .. .. .. ..; };

 view "authoritative" {
    match-clients { 192.168.1.1; };
    recursion no;
    zone "example.com."   {type master;file "example.com.signed";};
 };

 view "recursive" {
    match-clients { !192.168.1.1;any; };
    recursion yes;
    zone "."                     { type hint;  file "named.root";};
    zone "0.0.127.IN-ADDR.ARPA." { type master;file "localhost.rev";};
 };

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 25 Jul 2001 19:38:00 -0700

> look the same, at least without further protocol extentions), one

No - one must do the former.  There is no need to distinguish between
local stub resolvers and local caching forwarders - you typically want
to provide cryptographically validated results to both.  If a local
caching forwarder wants to do its own validation, it will set the CD
bit.

Any existing security conscious DNS installation already makes a
distinction between local clients (whether stubs or forwarders) that
are authorized to use their caching servers for recursive queries and
external clients that are not.  This distinction may be implemented
using separate servers and a firewall, BIND 9 views, or a simple
"allow-recursion" ACL, but it is there.

To use a separate view for DNSSEC validation, you simply make the view
match the clients that are currently authorized to perform recursion.
-- 
Andreas Gustafsson, [email-masked]