Subject: [dnsext] nsec3 and wildcards

From: Miek Gieben <[email-masked]>
Date: Mon, 24 Jan 2011 15:09:33 +0100

Hello,

I was wondering if there was a way to limit the amount of nsec3s that
are returned for name-error responses. Right now, one of the nsec3s is there
to signal that there is no wildcard present.

Would it be possible to use the flags field (in the remaining nsec3s) to
signal 'oh, and btw, there also wasn't a wildcard'?

Somehow this shouldn't work, but I cannot see why...

Kind regards,

--
 Miek
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Mon, 24 Jan 2011 09:24:36 -0500

>Somehow this shouldn't work, but I cannot see why...

Hey Miek, long time, no hear....

The top limit is 3 now (no more than 3 nsec3's per response).  And if 
a nsec3 can prove more than one "point" the number will be less.  I 
say this to estimate if this endeavor would be worth it.

The problem with using a flag for this is...

...if a wildcard is added to the zone, all NSEC3's in place would 
have to be changed (and signed and all this propagated).

...a cached NSEC3 could be misleading.  (I'm just saying, cached data 
could always be out of date.)

...we don't have a flags field now, so we'd be "borrowing" from the 
type-bit map.  So servers would have to know about this special 
processing.  (Since an authority server doesn't know how "old" a 
cache is, the authority won't know when to add the bit and not send 
the 3rd NSEC3, etc...)

Just some thoughts....

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

With a week old newborn at home, I've discovered that the only 
difference between him and me is that I have to go to work daily. 
That's not fair!  Ma!
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Miek Gieben <[email-masked]>
Date: Mon, 24 Jan 2011 15:32:45 +0100

[ Quoting Edward Lewis in "Re: [dnsext] nsec3 and wildcards"... ]
> Hey Miek, long time, no hear....

yes, I'm sort of back in the DNS game :-)

> The top limit is 3 now (no more than 3 nsec3's per response).  And
> if a nsec3 can prove more than one "point" the number will be less.
> I say this to estimate if this endeavor would be worth it.
> 
> ...a cached NSEC3 could be misleading.  (I'm just saying, cached
> data could always be out of date.)
> 

Correct me if I'm mistaken, but there is a flag field, RFC 5155:

3.1.2.  Flags

   The Flags field contains 8 one-bit flags that can be used to indicate
   different processing.  All undefined flags must be zero.  The only
   flag defined by this specification is the Opt-Out flag.

We do have to define a *new* flag.

grtz,
    Miek

---

From: Edward Lewis <[email-masked]>
Date: Mon, 24 Jan 2011 09:51:39 -0500

>We do have to define a *new* flag.

Ah, I'd forgotten.

But you still have the issue of an upgraded server not knowing if the 
requestor understands the flag so the extra NSEC3 is still needed.

---

From: Miek Gieben <[email-masked]>
Date: Mon, 24 Jan 2011 16:06:54 +0100

> But you still have the issue of an upgraded server not knowing if
> the requestor understands the flag so the extra NSEC3 is still
> needed.

True. 

But to come back to my original question:

    Would it be possible to use the flags field (in the remaining
    nsec3s) to signal 'oh, and btw, there also wasn't a wildcard'?

You are not denying that this could work...?

grtz,
    Miek

---

From: "George Barwood" <[email-masked]>
Date: Mon, 24 Jan 2011 15:07:42 -0000

----- Original Message ----- 
From: "Miek Gieben" <[email-masked]>
To: "dnsext List" <[email-masked]>
Sent: Monday, January 24, 2011 2:09 PM
Subject: [dnsext] nsec3 and wildcards

> Somehow this shouldn't work, but I cannot see why...

Well the question would be "what wildcard"?

Remember there are a (practically) unlimited number of queries, which the server answers
using a relatively small number of signed records. The design  choice was to minimise the number of RRsets
that have to be signed. It might have been possible to have a different design with a larger number
of things to be signed but smaller responses ( with less signatures ).

Regards,
George