Subject: Re: I-D regarding access control in DNS

From: "Scott Rose" <[email-masked]>
Date: Wed, 5 Feb 2003 12:25:56 -0500

I don't know if this is something the WG should be looking at.  Besides
making a decision not to include confidentiality into the DNSSEC extensions
and I believe there are good reasons not too:

1.  Many DNS implementations have some sort of acl functionality built in.
It is also easier to do access control outside of the DNS protocol.
2. IPSec can be used to provide confidentiality at a lower level (hard to
imagine DNS would be the only network traffic that a network wants
encrypted).

minor problems
3.  New records will have to be introduced for the ACL (TXT RRs probably
won't do),
4.  new RCODEs would have to be introduced/redefined for security.  That
might affect backwards compatibility when older resolvers try to communicate
with a AC aware server.

I do not believe that the benefit of adding this functionality outweights
the cost and burden it would place on the DNS.  This benefit already exists
to some degree by other protocols and implementations.

Scott

----- Original Message -----
From: "Tatsuya Baba" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 05, 2003 10:14 AM
Subject: I-D regarding access control in DNS

> Hi all,
>
> I wrote an I-D regarding access control in DNS.
>
>    draft-baba-dnsext-acl-reqts-00.txt
>
> I know that DNSSEC specification states "the DNS design philosophy calls
> for all DNS data to be public."  However, I also know that there are
> many people who would like to control access to DNS data.
>
> Is there anyone who is interested in this area?
>
> Any comments, questions, or corrections are appreciated.
>
> Regards.
>
> -- Tatsuya Baba
>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Tatsuya Baba <[email-masked]>
Date: Mon, 10 Feb 2003 18:28:33 +0900

Scott, thank you for your comments.

> It is also easier to do access control outside of the DNS protocol.

Yes.
I know that BIND has access control functionality based on TSIG, but I
think that TSIG does not scale.
Moreover, BIND controls access based on entire zone (not indivisual
RRset).

But I don't know about other implementations.

> imagine DNS would be the only network traffic that a network wants

If the authoritative name server is also deployed in the network
protected by IPsec, this is the case.

IPsec can be used to provide confidentiality if resolver can control
IPsec policy and set up security associations between clients and
authoritative name servers when required.  But I think it is difficult.

> 3.  New records will have to be introduced for the ACL (TXT RRs probably

Yes. I think new RRs should be introduced.

> might affect backwards compatibility when older resolvers try to communicate

It might be, but I would like to avoid discussions about actual
protocols now.  I think this functionality should not affect existing
resolvers.

> to some degree by other protocols and implementations.

It is not required to introduce this functionaly on root/TLD servers.
Only those who want to control access to RRsets on their name servers
should introduce this functionality on their servers and their user's
clients.

To summarize draft,

1) client identification and authentication using SIG(0) (or TSIG)
2) direct communication between client and server
   (bypassing caching name server)
3) ACL in zone file using new RR (or TXT RR?)
4) DNS message encryption using new RR (or IPsec?)

Above (1) and (2) do not affect existing DNS protocol.
(3) and (4) require standard action, but if TXT RR and IPsec can be
used for this, no standard action is needed.

This draft is intended for starting point of discussions.
Any comments are appreciated.

-- Tatsuya Baba

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 19 Mar 2003 04:13:42 +0100

> Is there anyone who is interested in this area?

Having seen your presentation I would like to stand on the traditional side
and argue that creating a data hiding mechanism in the public DNS is
contradictional with both intention and perception of the DNS system; and
most of the ACL mechanisms presently available are frequently breaking
service, most often due to the administrator failing to comprehend the
scope of his or her actions. So, we have all the foot-shot armament we
could use. 

Best regards, 
-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.