Subject: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for empty non-terminals

From: Tony Finch <[email-masked]>
Date: Mon, 28 Mar 2011 15:24:08 +0100

Arising from the discussion at the meeting about treating a cached
NXDOMAIN as applying to all child domains...

The main concern about this clarificationin is buggy implementations that
give an NXDOMAIN for empty non-terminal names that have non-empty child
domains. The examples cited were DJBDNS and in particular rbldnsd. (I
presume there are others that we don't know about.)

We care about rbldnsd because it is widely deployed and there are a lot of
empty non-terminals in RBL zones. However the bug will not normally be
triggered by a mail server since mail servers don't query for the
non-terminal domains. But there is a serious risk if the mail server is
sharing a cache with untrusted clients, since they can make a query that
gets an NXDOMAIN response and thereby make the cache think that vast
sections of the DNSBL are empty.

This is of course a special case of the general problem with this
clarification. I don't know if it affects how much we care about it or if
it just means we should worry more about the buggy DNS servers that we
don't know about.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southwest Forties, Cromarty, Forth: Southwesterly 4 or 5, occasionally 6,
becoming variable 3 later. Slight or moderate. Occasional rain. Good,
occasionally poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "George Barwood" <[email-masked]>
Date: Mon, 28 Mar 2011 22:29:20 +0100

----- Original Message ----- 
From: "Tony Finch" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 28, 2011 3:24 PM
Subject: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals

> presume there are others that we don't know about.)

Could the new interpretation be restricted to cases where there are NSEC or NSEC3 records
that show that there are no child sub-domains?

That would seem to avoid any compatibility problems.

I'd also like to see the standard updated to allow resolvers to infer NoData conditions
from NSEC/NSEC3 records ( the standard does not exactly forbid this at present, but
there is discouraging language ).

Finally, I'm happy to support the adoption of draft-vixie-dnsext-resimprove

George

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Mar 2011 09:27:12 -0400

At 22:29 +0100 3/28/11, George Barwood wrote:

>I'd also like to see the standard updated to allow resolvers to infer
>NoData conditions from NSEC/NSEC3 records ( the standard does not exactly
>forbid this at present, but there is discouraging language ).

http://www.ietf.org/mail-archive/web/dnsext/current/msg10820.html

One motivation is to pursue "tricks" like RFC 4470 but applied to the 
type bitmap.  A signer may decide not to include all types in the 
NSEC it hands out.  Or the answering server will be synthesizing the 
answer dependent on the query.

By enlarging the role of caches, the authoritative server choices are shrunk.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Tue, 29 Mar 2011 15:03:42 +0100

----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 29, 2011 2:27 PM
Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals

> answer dependent on the query.

If a signer or server does this, all security is lost, because an attacker can use
the incomplete NSEC records to deny the existence of RRsets.

So allowing this (standard breaking) possibility does not seem at all useful.

What is the motive for this "trick"? Saving bandwidth??

George

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 Mar 2011 15:04:10 +0100

Edward Lewis <[email-masked]> wrote:
>
> One motivation is to pursue "tricks" like RFC 4470 but applied to the type
> bitmap.  A signer may decide not to include all types in the NSEC it hands
> out.

I think that would be an outright lie, not a white lie.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Utsire, South Utsire: Northwesterly 4 or 5, occasionally 6 in South
Utsire, veering easterly 3 or 4 later. Moderate or rough. Occasional rain.
Moderate or good.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Mar 2011 10:14:18 -0400

>I think that would be an outright lie, not a white lie.

Define "truth."

Seriously, keeping this engineering, what is the difference between 
"crafting replies" to queries (which some call lying) and rapidly 
updating the zone?

Would cache operators prefer that the TTL is dropped to nearly zero 
to force more cache misses?

The goal here is to retain the authority of the authority servers and 
still make use of caching.  If you increase the synthesis of answers 
in caches, you are removing authority from the authoritative servers 
and placing that in the caches.

Debating the utility of rapidly changing zones, alternate forms of 
answer synthesis, and "lying", if taken up, should happen in a 
different form than this subject line.  For now, if we empower 
caches, we stifle exploration in the authority server space.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Mar 2011 10:45:22 -0400

>What is the motive for this "trick"? Saving bandwidth??

There are zones which do not exist in total at any given point in 
time.  These are zones that do not conform to a zone "file" and 
cannot be represented in an AXFR.  For these zones, a statement of 
what exists can be made "locally" but generating a "universal" list 
would be impossible.  Answering only the query at hand is the concern 
because the current protocol rules say caches don't synthesize 
answers from what they cache.  (They can repeat answers in the cache, 
not synthesize them.)

---

From: "George Barwood" <[email-masked]>
Date: Tue, 29 Mar 2011 17:16:33 +0100

----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>
Sent: Tuesday, March 29, 2011 3:45 PM
Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals

> answers from what they cache.  (They can repeat answers in the cache, 

I agree it's quite common for zones to give non-deterministic positive answers
as a form of load-balancing, where a limited set of A records is randomly 
(or otherwise) selected from a large set. This is not affected.

It's quite hard to see how it could be useful to have inconsistent NSEC bitmaps though.
Can you give any kind of hypothetical use case?

George

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Mar 2011 12:29:23 -0400

>(or otherwise) selected from a large set. This is not affected.

Using that...when you have A, AAAA, and fallback answers like DNAME 
and CNAME, for example.  It might not be just which A to return, but 
whether to withhold the AAAA and or use a query redirection tool. 
Consider that ANY queries may come.

With IPv6 whitelisting 
(http://tools.ietf.org/html/draft-livingood-dns-whitelisting-implications-01) 
as an example, I might want to withhold the existence of a AAAA 
record from some queriers but not others.

The way the standards read now, it's possible to generate NSEC/3's 
owning a private type for all names that warrant one (NSEC does not 
represent empty non-terminals, NSEC3 does) claiming just a private 
type and things would work.  That's because you don't get a NSEC/3 in 
a positive answer (other than ANY).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: "George Barwood" <[email-masked]>
Date: Tue, 29 Mar 2011 18:16:28 +0100

----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>
Sent: Tuesday, March 29, 2011 5:29 PM
Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals

> record from some queriers but not others.

That's adjusting the response based on the identity of the client.
But what I'm asking for is a use case for sending inconsistent NSEC bitmaps
to the same client. I think that's hard to envisage.
 
> a positive answer (other than ANY).

Right. What I'm saying is that an NSEC bitmap tells a client the complete set
of types that don't exist for a domain, and it's reasonable for a client to
use all of that information ( rather than just for the type requested ).
You don't seem to have come up with a plausible example where that
could be a problem, and I cannot see one either.

George

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Mar 2011 13:28:26 -0400

At 18:16 +0100 3/29/11, George Barwood wrote:

>What I'm saying is that an NSEC bitmap tells a client the complete set
>of types that don't exist for a domain,

That's wrong.  The bitmap presents information signed by the 
authority demonstrating that the type you requested does not exist at 
the name.

The way it is supposed to work is - you ask for fqdn.tld. A record. 
The response comes back with an empty answer section and an SOA and 
NSEC/3 in the authority demonstrating that the requested type is not 
there.

The tradeoff here is that the NSEC can be replayed to deny the 
existence of another type to save having to manage multiple NSEC 
records for a name.

I'm not going to debate the tradeoff.  Obviously there are two sides 
to the story, and whether there is a gain in reducing the number of 
NSEC/3's to manage.  But I am against changing the specification to 
close off the debate.

If the specifications are changed, the net result is giving more 
authority to the caches and taking the debate away from the 
authoritative portion of the system.  That is why I resist extending 
the inferences based on NSEC/3 bitmaps.

The subject line was NXDOMAIN.  I'm not talking about that.  We 
already carefully considered that in the development of DNSSEC and 
have the results documented.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: "George Barwood" <[email-masked]>
Date: Tue, 29 Mar 2011 19:14:38 +0100

----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>; "Edward Lewis" <[email-masked]>
Sent: Tuesday, March 29, 2011 6:28 PM
Subject: bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals

> authority demonstrating that the type you requested does not exist at 

The standard ( http://tools.ietf.org/html/rfc4034#section-4.1.2 ) says

   The Type Bit Maps field identifies the RRset types that exist at the
   NSEC RR's owner name.

That's clear and unambiguous, I cannot see how you can read that any other way.
But I'm going to stop here and see if others have views on this.

George

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Mar 2011 14:33:35 -0400

>    The Type Bit Maps field identifies the RRset types that exist at the

It doesn't say "MUST".  That's giving the semantic meaning of the 
field.  And it doesn't say "when" existence is tested.

>But I'm going to stop here and see if others have views on this.

The problem is determining a if there is a protocol violation.

If you get this:

t=0 (Q:fqdn.tld./IN/AAAA):
fqdn.tld.   3600 IN NSEC other.tld. priv_type
t=5 (Q:fqdn.tld./IN/A):
fqdn.tld.   3600 IN A 127.0.0.1

How can you tell if I generated the NSEC regardless of the A record 
or just before the A record was added to the zone?  In the latter 
case, if you asked for the A you don't get the would-be-new NSEC.

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 30 Mar 2011 13:39:12 +0200

> field.  And it doesn't say "when" existence is tested.

It does not say 'MAY depend on type' either :)

> How can you tell if I generated the NSEC regardless of the A record or
> just before the A record was added to the zone?  In the latter case, if
> you asked for the A you don't get the would-be-new NSEC.
> 

as with another example you used in a previous discussion, it would seem
you are arguing for not doing negative caching at all (i.e. if an A
record is queried, does not exist, is then added, and queried again it
would show the same behavior as when you ask for a different type and
derive data from the nsec bitmap). Taking that further, what if
something is removed between t=0 and t=5, should we also not do positive
caching? :)

IMO whether or not aggressive caching should be done or allowed, giving
different answers where one would expect the same (i.e. different NSECs
depending on the qtype, in this case) makes me slightly nauseous :p But
that is probably not much of a protocol qualification.

Jelte

---

From: Edward Lewis <[email-masked]>
Date: Wed, 30 Mar 2011 08:10:02 -0400

>something is removed between t=0 and t=5, should we also not do positive

Caching is a pain, it complicates the work at the authority server. 
Without caching we wouldn't need the complicated key rollovers and 
such.  However, caching is an integral part of the DNS protocol. Not 
to say we are stuck with it, it also boosts performance and lets the 
system achieve the stated goals of scaling, reliability, low latency.

I'm not advocating the removal of caching.  I'm advocating the status 
quo.  With caching being good and bad, the optimum position is a 
balance.  If we push it in one direction too far, pressure is put on 
other parts of the architecture.

If changing caching improved the lot of a authority servers, I'd be 
for it.  Change is good too, but it's not free of concerns.

>that is probably not much of a protocol qualification.

It's going to happen.  Even if we throw out the "tailored responses" 
issue, there's the element of time.  Although the DNS protocol does 
not integrate time into the data model, there's the real world that 
does.  Zones get updated and reloaded, so a cache will have to deal 
with inconsistent NSEC/3 bitmaps.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 30 Mar 2011 12:21:09 -0400

On Wed, Mar 30, 2011 at 8:10 AM, Edward Lewis <[email-masked]> wrote:
> It's going to happen.  Even if we throw out the "tailored responses" issue,
> there's the element of time.  Although the DNS protocol does not integrate
> time into the data model, there's the real world that does.  Zones get
> updated and reloaded, so a cache will have to deal with inconsistent NSEC/3
> bitmaps.

It might be worth discussing how caches could/should handle NSEC/3
responses when time and/or bitmaps change.

The idea is, to find a happy balance between caching NSEC/3 responses,
associating those with bitmap bits, and limiting cache bloat.

When a cache has no entry for a given tuple (name, class, type),
obviously it has to then query the auth server. If it gets an answer
where the name exists but type doesn't, it should get an NSEC/3 record
as well.

The cache should only return that cached NSEC/3 when it sees queries
that match already-answered (by the auth server) queries, and new
types should result in new queries to the auth server.

The questions that arise are:
- What if the same NSEC/3 answer is returned for the new type?
- What if a different NSEC/3 answer is returned, but which is
consistent with previous NSEC/3 answer(s) already cached for other
types?
- What if a different NSEC/3 answer is returned, but which is not
consistent with previous NSEC/3 answer(s) already cached for other
type(s)?

My suspicion is that:
- It would be reasonable to keep a bitmap of queries/answers for which
a given NSEC/3 has been returned. E.g. If the NSEC/3 has bits clear
on, for example, SOA and NS, and has been returned along with empty
data on queries for SOA and NS for a given name and class, then it
would be reasonable to associate the same NSEC/3 with those types, and
return it for subsequent queries for those tuples.
- It would be reasonable to replace older NSEC/3 answers with newer
NSEC/3 answers, if the type associations (of previous queries/answers
that generated the cached entry) and bitmap of the newer NSEC/3 were
consistent (and thus also implicitly consistent with the bitmap of the
older NSEC/3)
- It would be necessary to retain multiple NSEC/3 answers if there
were inconsistencies between types and bitmaps across those answers

The benefit is, even if the time changes, if the bitmap doesn't
change, or doesn't change in a manner that is inconsistent, that the
number of NSEC/3 records doesn't have to increase, even if additional
queries to the auth server are needed because the particular type's
NSEC/3 hasn't been cached (or associated with the cached entry yet).

A secondary benefit is that a rolling window of TTLs resulting in
refreshing of NSEC/3's rather than expiry of NSEC/3's, can have some
beneficial effect on the auth server(s) without introducing
inconsistencies. A newer NSEC/3 (with newer signature) essentially
restarts the TTL clock when it replaces the older NSEC/3.

Or, the cache could decide to re-query candidate NSEC/3 records for
the types with the older NSEC/3 entries, and only if the new NSEC/3 is
returned, do the replacement. It is a time/space/bandwidth trade-off.

Brian