Subject: NO RR draft announcement

From: Simon Josefsson <[email-masked]>
Date: 24 Jul 2000 13:12:01 +0200

Either I didn't get the announcement, or there wasn't one, anyway:

http://www.ietf.org/internet-drafts/draft-jas-dnsext-no-00.txt

Comments solicited.

As suggested by Olafur Gudmundsson's, the "type bit map" will be
replaced with a sorted list of RR numbers. Also, using a unique
subdomain (pointed out by a SRV record) to store NO records, so they
doesn't interfer with other records, is a likely further enhancement.

I include title and abstract below.

/Simon

   Authenticating denial of existence in DNS with minimum disclosure
               (or; An alternative to DNSSEC NXT records)
                         draft-jas-dnsext-no-00
...

Abstract

   This draft present an alternative to NXT records, used to achieve
   authenticated denial of existence of a domain name, class and type. 
   Problems with NXT records, as specified in RFC 2535, are identified,
   and one solution is presented.

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

---

From: Peter Koch <[email-masked]>
Date: Mon, 24 Jul 2000 14:34:49 +0200

> Either I didn't get the announcement, or there wasn't one, anyway:

It was sent to ietf-announce last Wednesday.

Generally I like the idea, most because it solves the ambiguity at the
delegation point. The chaining prevention is a nice add-on then.

> doesn't interfer with other records, is a likely further enhancement.

OK, this was one of my points - the "no-" prefix only (which is not really
necessary anyway) somehow clutters the namespace in that the NO RRs
deny their own existence. Dedicating a subdomain is a good idea, although
I'd prefer a fixed name relative to the zone apex over a SRV based solution.

I've two further questions:

1) Concerning wildcards, I understand the necessity to prove the absence
   of one or more wildcard owners, but why is the special NO RR for the
   wildcard owner itself needed?

   Consider the zone example.org(*) with only www.example.org in it:

	    example.org	OWH -> 10
	www.example.org	OWH -> 30

   If I ask for mail.example.org (which hashes, e.g. to 20), I receive
   "no-10 NO OWH 30 ... " to prove the non-existence of mail.example.org.
   Then, to prove that no wildcard exists (let OWH(*.example.org) be 40),
   shouldn't it be sufficient to send "no-30 NO OWH 10 ..." ?

   If in the above example the zone also contains

        ftp.example.org	OWH -> 50

   and we ask for "www.sub.example.org" (hashing to 60), you would have to
   also prove the non-existence of "*.sub.example.org" by sending the
   "no-50 NO OWH 10 ...". In this case you cannot prepare the NO RR for the
   wildcard because you can't know in advance what domain names people
   are going to ask for. So, the resolver would have to conclude itself
   that said NO RR is for the "*.sub.example.org" owner. Now, is there
   anything special with the "*.example.org" wildcard that I don't see?

2) How is an empty non-leaf node handled?

   The example.org zone consists of the following owners:

	    example.org
	www.example.org
    www.sub.example.org

   So, there's no RR associated with "sub.example.org", which results
   in NOERROR with empty answer section, if you ask for that domain name.
   The entity generating the NO RRs must then insert a NO RR corrsponding
   to "sub.example.org" with empty type bitmap/list, but I'm not sure that's
   all.

-Peter

PS: (*) minor nit: example domain names best follow RFC 2606 to avoid
    problems for uninvolved parties.

---

From: Simon Josefsson <[email-masked]>
Date: 24 Jul 2000 15:45:38 +0200

First, thanks for your comments.  Answers inline below..

> I'd prefer a fixed name relative to the zone apex over a SRV based solution.

Let's say "_no.example.org".  Perhaps a SRV record isn't necessery.

(The "no-" prefix is necessery to make sure that base32 encoded domain
names doesn't start with 0-9, which is forbidden.)

>    shouldn't it be sufficient to send "no-30 NO OWH 10 ..." ?

Yes.  You're right, generating NO records for non-existing wildcard
domains are redundant.

>    to "sub.example.org" with empty type bitmap/list, but I'm not sure that's

Yes, this should be pointed out in the document.  I don't see other
issues, but perhaps there are.

>     problems for uninvolved parties.

Of course, I've updated this.  Thanks.

/Simon

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 25 Jul 2000 09:50:51 -0700 (PDT)

> names doesn't start with 0-9, which is forbidden.)

No, it's not.  Consider for example the IN-ADDR.ARPA tree, where
most labels consist solely of digits.  Also see RFC2181 section 11.
-- 
Andreas Gustafsson, [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: 26 Jul 2000 13:35:32 +0200

> most labels consist solely of digits.  Also see RFC2181 section 11.

You're right.  So, it would be possible to drop the base32 encoding
from the draft.  RFC 2181 indicate this, but I'm not familiar with if
existing servers handle it correctly, are they?  It has also been
suggested that a new EDNS label could be used, for storing hashed
domain names.

/Simon

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 26 Jul 2000 09:20:31 -0700 (PDT)

> from the draft.

Not the encoding, just the "no-" prefix.  The base32 encoding (or
equivalent, personally I would prefer base16) is still necessary
becase of case folding.
-- 
Andreas Gustafsson, [email-masked]

---

From: Peter Koch <[email-masked]>
Date: Wed, 26 Jul 2000 18:49:38 +0200

> existing servers handle it correctly, are they?  It has also been

It would probably be kind of a benchmark.

> suggested that a new EDNS label could be used, for storing hashed

That's a good idea because it could help solve another problem:
What happens if I explicitly ask for the NO-RR attached to "no-42.example.org"?
While that NO RR might exist, there's also information in the other NO RRs
that the owner name "no-42.example.org" does not exist, because the NO RRs
were constructed before they got inserted into the zone. You cannot change
that without constructing and endless loop (or at least a chain as long
as the "collision distance" of the underlying hash function).

So, choosing a different namespace (I've thought about a CLASS "INC", like
the "complement" to IN, but that won't work), e.g. by using another label
type could solve this. That label in a query would lead to a direct answer,
i.e. not hashed again.

However, there is not yet much experience with the deployment of new label
types and that might become the hard part.

-Peter

---

From: Brian Wellington <[email-masked]>
Date: Wed, 26 Jul 2000 13:42:02 -0700 (PDT)

On 26 Jul 2000, Simon Josefsson wrote:

> It has also been suggested that a new EDNS label could be used, for
> storing hashed domain names.

When first reading the draft, I thought that using a binary label
(bitstring) would be a good choice, since it isn't subject to case
folding.  The problem is that it's a label type that isn't understood by
most resolvers.  It's fairly easy for a resolver to skip NXT records,
since it's just an unknown type, but I wouldn't be surprised if there were
resolvers that did very bad things when seeing an unknown label type.

Using a new label type would be even worse, because there are some
resolvers that understand binary labels, but none that would understand
the new type.

Brian

---

From: Simon Josefsson <[email-masked]>
Date: 27 Jul 2000 16:54:19 +0200

> as the "collision distance" of the underlying hash function).

I'm not sure I see the point here, why would you want to authenticate
denial for NO records?  I've made a change in the draft to point this
out, ala "NO records (together with SIG) are used to authenticate
denial of other types". But I'm not sure we should try very hard to
make NO records authenticate denial for themself. Am I missing
something?

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: 27 Jul 2000 17:01:08 +0200

> resolvers that did very bad things when seeing an unknown label type.

Would these bad things be any more harmful than not being able to
authenticate denial for records?  If so, I don't think it's worth
persuing the idea, since a alternative that is backwards compatible
can work equally well.

---

From: Brian Wellington <[email-masked]>
Date: Thu, 27 Jul 2000 17:11:50 -0700 (PDT)

> persuing the idea, since a alternative that is backwards compatible

Got me.  That's the point - I don't know if all resolvers properly handle
unknown label types.  New record types are added fairly often, but until
binary labels, no new label types had been introduced for a long time.  I
don't think it's possible to fully parse a message containing an unknown
label type.

Brian