Subject: [dnsext] Fwd: RFC 2308 & RFC 4035

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Feb 2011 14:41:15 -0500

I have a question referring to two sections in two RFCs, prompted by 
the resimprove draft.

RFC 4035:
5.4.  Authenticated Denial of Existence
...
    o  If the requested RR name matches the owner name of an
       authenticated NSEC RR, then the NSEC RR's type bit map field lists
       all RR types present at that owner name, and a resolver can prove
       that the requested RR type does not exist by checking for the RR
       type in the bit map.  ...

And in RFC 2308:
5 - Caching Negative Answers
...
    A negative answer that resulted from a no data error (NODATA) should
    be cached such that it can be retrieved and returned in response to
    another query for the same <QNAME, QTYPE, QCLASS> that resulted in
    the cached negative response.

Let's aay this happens:

at 10am a cache receives a response to a query for example.tld./IN/A that says

example.tld.   3600    NSEC3   a.example.tld.  SOA NS DNSKEY RRSIG NSEC

at 10:15am the cache gets a query for example.tld./IN/AAAA.

Should the cache rely with a NoData response or should it try to 
query for the AAAA?

If the answer to the previous is "it should rely on the cached NSEC:" 
What if I said that at 10:10am, the authority was updated with a new 
zone that had an AAAA RRset at the apex?

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

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "George Barwood" <[email-masked]>
Date: Fri, 25 Feb 2011 20:08:24 -0000

----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 25, 2011 7:41 PM
Subject: [dnsext] Fwd: RFC 2308 & RFC 4035

> zone that had an AAAA RRset at the apex?

I think this is addressed by

http://tools.ietf.org/html/rfc4035#section-4.5

<<
   In theory, a resolver could use wildcards or NSEC RRs to generate
   positive and negative responses (respectively) until the TTL or
   signatures on the records in question expire.  However, it seems
   prudent for resolvers to avoid blocking new authoritative data or
   synthesizing new data on their own.  Resolvers that follow this
   recommendation will have a more consistent view of the namespace.

George

---

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Feb 2011 15:24:33 -0500

>    recommendation will have a more consistent view of the namespace.

Good observation.  Question to those who've written caches, what 
strategy seemed best.

It's passages like the quoted that should be firmed up when and if 
DNSSEC is ever a Draft Standard/Full Standard.

And getting back to the resimprove draft, I'd wager that a BCP 
shouldn't disagree with a Standards Track document.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Brian Dickson <[email-masked]>
Date: Fri, 25 Feb 2011 16:48:43 -0400

>>   recommendation will have a more consistent view of the namespace.

However, this is immediately following (in 4.5):
   2.  NSEC RRs received to prove the non-existence of a name could be
       reused by a security-aware resolver to prove the non-existence of
       any name in the name range it spans.

So, I'd say there are two distinct cases:
- the NSEC *might* be used to deny the existence of a double
(QNAME,QCLASS) in the range
  (e.g. if "next domain name" were b.example.net, and the QNAME were
a.example.net)
- the NSEC is used to deny the existence of an RRTYPE not listed in the NSEC

The former falls in the "it seems prudent" category.

The latter, I think, does not, in which case, using the NSEC to
generate a NODATA answer is appropriate.
It would never be *wrong* to query the authority server, but it might
be unnecessary, e.g. 99.9999% of the time.

There is one other conflict, I think, which could occur - if an NSEC
is cached, but an RRTYPE not found in the NSEC, is also cached at the
same QNAME,QCLASS.
Is that bad or broken? (Should adding/removing an RRTYPE, or
adding/removing a name, result in selective re-generation of
NSEC/NSEC3 records and their signatures)?
Does it matter which order the two responses arrive? (If it does, I
think that indicates that there's a protocol problem....)
Should it trigger discarding or non-caching of the NSEC record? (I
think not, modulo the question on re-generation/re-signing NSEC/NSEC3
data)

> Good observation.  Question to those who've written caches, what strategy
> seemed best.
>
> It's passages like the quoted that should be firmed up when and if DNSSEC is
> ever a Draft Standard/Full Standard.
>
> And getting back to the resimprove draft, I'd wager that a BCP shouldn't
> disagree with a Standards Track document.

Agree.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Feb 2011 16:14:07 -0500

>think that indicates that there's a protocol problem....)

Order does matter, but that is not a problem in the protocol.  The 
DNS, prior to DNSSEC, had no concept of absolute (wall-clock) time 
for any reason.  Using UDP furthers the problem of trying to sequence 
the actions that occur in the system.

There was a conversation during the DNSSEC development years on 
whether the expiration/inception times could be used to try to 
sequence the values in an RRset, but this failed to come to fruition, 
partly because there is no guarantee that, for instance 
InceptionTime1>InceptionTime2 ==> ExpirationTime1>ExpirationTIme2.

Since then we've been wary of letting wall-clock time creep into DNS. 
To stop replay attacks, we need it but that's as far as it should 
really go.  This is why I once barked when someone did a survey of 
the clocks on authority servers - they shouldn't need to know the 
time of day.

What I meant to say is that the DNS protocol has the property that it 
is impossible to determine the sequence of messages in the system. 
If we built in some way to "make order unimportant" we'd severely 
crimp the protocol's scalability.  (All that locking and 
synchronization and all.)

The topic I am trying to tease out here is the question of how much 
"authority" is given to caches in generating answers.  The protocol 
is very conservative on this, as evidenced in RFC 2308's description 
of negative caching.  Again DNSSEC has tempted us to open this up, as 
quoted in the passages in the thread.

>think not, modulo the question on re-generation/re-signing NSEC/NSEC3

In the sense that code rules and specs walk, it would be good to get 
opinions from those who have written caches.  (I asked before, this 
isn't another nudge, I just want to emphasize this isn't mean to be a 
discussion over words in a static document.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Paul Vixie <[email-masked]>
Date: Fri, 25 Feb 2011 22:53:11 +0000

> Date: Fri, 25 Feb 2011 15:24:33 -0500
> From: Edward Lewis <[email-masked]>
> ...

right.  hwoever, resimprove does not deal with NSEC or DNSSEC issues at all.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Sat, 26 Feb 2011 11:32:13 +1100

> zone that had an AAAA RRset at the apex?

Nothing worse than having asked for the AAAA record at 10:00 am.
The zone administrator has to assume that AAAA queries will have
been made prior to adding the AAAA records.  This will almost
certainly be the case if there were A queries.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Sat, 26 Feb 2011 09:05:56 +0100

Hi Ed,

On 02/25/2011 08:41 PM, Edward Lewis wrote:
> I have a question referring to two sections in two RFCs, prompted by the
> resimprove draft.

> Should the cache rely with a NoData response or should it try to query
> for the AAAA?

I think they should use the passage quoted by George.  NSECs are used
for exactly the qname,qtype,qclass that solicited them (NODATA and
NXDOMAIN).

> zone that had an AAAA RRset at the apex?

- From an efficiency point, using cached NSECs helps; but for caches the
nxdomain and nodata traffic is a lot smaller than e.g. for roots.

Best regards,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Sat, 26 Feb 2011 10:50:32 -0500

>certainly be the case if there were A queries.

I think my question wasn't understood.

Do cache implementers use the fact that the proof of no A record 
coincidently shows there is also no AAAA record when processing a 
subsequent AAAA query.  (Meaning, there's no other entry for the AAAA 
alredy in the cache.)

If a cache does do this kind of proof by inference, what does the 
implementer think about the situation in which there is a "race 
condition" - that the proof of non-existence has been obviated by 
actions outside of it's sphere?  (Like the subsequent adding of the 
AAAA set in the authority.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Mark Andrews <[email-masked]>
Date: Sun, 27 Feb 2011 10:42:37 +1100

> AAAA set in the authority.

We do this for NXDOMAIN today.  If we ask for A foo.example and get
back a NXDOMAIN then the cache gets asked for AAAA foo.example we
use that NXDOMAIN.  Using the NSEC/NSEC3 that matches the <qname,qclass>
really no different.

The much more interesting question is infering NXDOMAIN for a
<qname,qclass> we havn't asked for.  Named already does this when
looking for DLV records when validating but is expected by all
parties involved.

Mark

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Sun, 27 Feb 2011 12:00:15 +0100

Hi,

> looking for DLV records when validating but is expected by all

Unbound does not use this, also not for NXDOMAINs and other types.

We infer NXDOMAINs and NODATA for DLV records, like named does, because
the RFC says so.

Qtype DS is also inferred from NSECs, an artifact of the implementation.
 It should never have the problem that you describe because if the
domain suddenly got signed, you would get the DS with the referral, and
having an old referral means that exactly what Mark said earlier 'there
was a referral query 10 minutes ago', otherwise you would not have the
NS data anyway and get the DS information if you were to need new NS data.

Best regards,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Sun, 27 Feb 2011 09:37:40 -0500

At 10:42 +1100 2/27/11, Mark Andrews wrote:

>use that NXDOMAIN.

That's cool - it complies with NCACHE (in a part I didn't quote).  I 
know you (as author know that, but I'm just saying it here.

>Using the NSEC/NSEC3 that matches the <qname,qclass>
>really no different.

There's a bit if difference.  I've been dealing with zones that are 
highly dynamic.  Signing such zones can be a challenge.  Besides the 
number of signatures needed for the positive answers, which is simply 
part of the workload is the generation and signing of the negative 
answers.

The way that NCACHE is written today, a simplifying assumption can be 
made for the NSEC/3 bit map if the negative cache is really type 
specific, basically returning a bit map that says "I don't have 
*that*".  If the negative cache is going to be name specific then the 
NSEC/3 has to state exactly what is there at the moment.

I'm asking this in the sense that on paper I would only need to send 
back "I don't have that" but if the deployed code tries to be 
tighter, I have to craft bit maps for each combination.  In addition 
to the provisioning and signing overhead, having to determine what's 
present "right now" will have to be done.

Even if that is pulled off, negative caches could be subject to 
higher false-positive negative-cache hits when sets become available. 
This could be a case where over-tightening on the security checks is 
a bad thing.   In this case, it isn't really the security, but the 
inferences made about the authority by the cache.

>looking for DLV records when validating but is expected by all

Again, this is forbidden in RFC 2308 but brought up in resimprove.  I 
have to say there's something seductive about the idea, but it's like 
a siren's call to make caches take over being authorities.  I think 
that's something that should be resisted.  (And this also related to 
inferring across types at a name.)

---

From: Edward Lewis <[email-masked]>
Date: Sun, 27 Feb 2011 09:40:38 -0500

>We infer NXDOMAINs and NODATA for DLV records, like named does, because

Thanks for the info.  And, if the RFC says so...;)

---

From: John Levine <[email-masked]>
Date: 27 Feb 2011 18:30:42 -0000

>nxdomain and nodata traffic is a lot smaller than e.g. for roots.

Don't assume that.  If the zone is a DNSBL, there will be a whole lot
of nxdomain queries, particularly in an IPv6 world where spamware hops
to a new IP on every message.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Feb 2011 19:54:20 +0000

> Date: 27 Feb 2011 18:30:42 -0000
> From: John Levine <[email-masked]>
> 
> ... If the zone is a DNSBL, there will be a whole lot of nxdomain
> queries, particularly in an IPv6 world where spamware hops to a new IP
> on every message.

i expect that most dnsbl's who evolve into ipv6 will also evolve a /64
"wildcard" strategy to cope with malware-controllable low order bits.

but i also agree that the importance of negative caching and synthetic
nxdomains is usually underestimated and will rise as the network grows.
(in an internet of things, most things searched for, will not exist,
whereas in the internet of today, most queries are for a small set of
not-existing objects.)
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: John Levine <[email-masked]>
Date: 27 Feb 2011 20:13:42 -0000

>"wildcard" strategy to cope with malware-controllable low order bits.

I expect that WLs will be more important than BLs, but they both have
the same cache blasting problem if there's a different query for every
IP.

>nxdomains is usually underestimated and will rise as the network grows.

Right.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Feb 2011 20:59:06 +0000

> Date: 27 Feb 2011 20:13:42 -0000

having been sued out of the reputation business early on, i know the whole
of the sherman antitrust act as well as i know the vein pattern on the back
of my hand.  there's a lot more trouble waiting for a WL operator than for
a BL operator.  noting, IANAL and this is not a technical thread any more.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Feb 2011 10:08:03 -0500

>nxdomains is usually underestimated and will rise as the network grows.

The "importance" mentioned above has to be put into the context of 
the shift of "power" this represents, the shift from authority to 
caches.  That has architectural implications.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468