Subject: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

From: Edward Lewis <[email-masked]>
Date: Mon, 26 Sep 2016 17:42:31 +0000

#2.  Rule
#
#   When an iterative caching DNS resolver receives a response NXDOMAIN,
#   it SHOULD store it in its cache and all names and RRsets at or below
#   that node SHOULD then be considered to be unreachable.  Subsequent
#   queries for such names SHOULD elicit an NXDOMAIN response.
#
#   But if a resolver has cached data under the NXDOMAIN cut, it MAY
#   continue to send it as a reply (until the TTL of this cached data
#   expires), since this may avoid additional processing when a query is
#   received.  Section 6 provides more information about this.

For consistency, the SHOULD's in the first paragraph ought to be MAY's.  (Logically, it has to be.  If I treat it as SHOULD, I'd never discover data below that I MAY elect to return.)

As the authority server may change its version of a zone and the SOA (with serial) is not in every response, it's impossible (computationally undecidable) to know whether the answer with the NXDOMAIN was created before or after lower data.  Maybe the lower data is "currently correct" and the NXDOMAIN is stale-ish.  Or not.

DNSSEC does not solve this - the inception time of a RRSIG is a tempting metric of freshness but that timestamp is not reliable for that purpose.  (From the early days, signers would post date the signature on purpose to avoid then-common clock skew issues.)  This would be good to reinforce.

Given a temporally valid answer with data below a temporally denied name is possible (as zones change over time), I'd say that it is up to the implementer to choose one way or the other.  All things being static, an NXDOMAIN would occlude lower data.  But things are not static.

When I wrote "occlude" above I thought of the rule that an NS set occludes data below it the cut.  That is, hide it from answers but include it in zone transfers.  But that doesn't mean we NXDOMAIN the same way - because the rule for NS impacts authorities, the NXDOMAIN issue is in caches.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 Sep 2016 10:49:27 +1000

In message <[email-masked]>, Edward Lewis writ
es:
> For consistency, the SHOULD's in the first paragraph ought to be MAY's.
> (Loically, it has to be.  If I treat it as SHOULD, I'd never discover
> data below that I MAY elect to return.)

No.  SHOULD is not MUST.  Every SHOULD has a implict UNLESS
<unspecified reason>.  In this case we actually have a reason for
the why the second and third SHOULD are not MUSTs.

I could turn first SHOULD into a MUST and still reach the MAY.

> As the authority server may change its version of a zone and the SOA
> (with serial) is not in every response, it's impossible (computationally
> undecidable) to know whether the answer with the NXDOMAIN was created
> before or after lower data.  Maybe the lower data is "currently correct"
> and the NXDOMAIN is stale-ish.  Or not.

Temporal issues are not new.  All DNS caches have them.

> DNSSEC does not solve this - the inception time of a RRSIG is a tempting
> metric of freshness but that timestamp is not reliable for that purpose.
> (From the early days, signers would post date the signature on purpose to
> avoid then-common clock skew issues.)  This would be good to reinforce.
>
> Given a temporally valid answer with data below a temporally denied name
> is possible (as zones change over time), I'd say that it is up to the
> implementer to choose one way or the other.  All things being static, an
> NXDOMAIN would occlude lower data.  But things are not static.
>
> When I wrote "occlude" above I thought of the rule that an NS set
> occludes data below it the cut.  That is, hide it from answers but
> include it in zone transfers.  But that doesn't mean we NXDOMAIN the same
> way - because the rule for NS impacts authorities, the NXDOMAIN issue is
> in caches.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Sep 2016 17:55:38 +0000

>    I could turn first SHOULD into a MUST and still reach the MAY.
 
I have to admit I don't quite understand that response.  (This coming after reading some children's books by Roald Dahl where he just makes up words and tries to explain them.)

I'd written up a response, but perhaps the intent of the text is fine.  The way it is written is what is throwing me.

Perhaps instead of this:

#   When an iterative caching DNS resolver receives a response NXDOMAIN,
#   it SHOULD store it in its cache and all names and RRsets at or below
#   that node SHOULD then be considered to be unreachable.  

When an iterative caching DNS resolver receives a response with RCODE being NXDOMAIN, the resolver SHOULD store the response in its (negative) cache.  During the time the response is cached, any query with a QNAME at or descended from the denied name that is not otherwise cached (positively), can be assumed to result in a name error.  Responses to those queries SHOULD set RCODE=NXDOMAIN (using the DNSSEC records cached as proof).

...that's not the best wording either - but "unreachable" is not a term I'd use.  I'm not sure "negative cache" and "positive cache" are recognized terms.

>Temporal issues are not new.

There is something oddly ironic about that statement.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 27 Sep 2016 14:34:00 -0400

On Tue, Sep 27, 2016 at 1:55 PM, Edward Lewis <[email-masked]>
wrote:

>
> I'd written up a response, but perhaps the intent of the text is fine.
> The way it is written is what is throwing me.
>
> Perhaps instead of this:
>
> When an iterative caching DNS resolver receives a response with RCODE
> being NXDOMAIN, the resolver SHOULD store the response in its (negative)
> cache.  During the time the response is cached, any query with a QNAME at
> or descended from the denied name that is not otherwise cached
> (positively), can be assumed to result in a name error.  Responses to those
> queries SHOULD set RCODE=NXDOMAIN (using the DNSSEC records cached as
> proof).
>
> ...that's not the best wording either - but "unreachable" is not a term
> I'd use.  I'm not sure "negative cache" and "positive cache" are recognized
> terms.
>

I'd suggest replacing "unreachable" with "non-existent":

#   When an iterative caching DNS resolver receives an NXDOMAIN response,
#   it SHOULD store it in its (negative) cache and all names and RRsets at
or below
#   that node SHOULD then be considered non-existent.

-- 
Shumon Huque

---

From: "White, Andrew" <[email-masked]>
Date: Tue, 27 Sep 2016 18:48:42 +0000

Hi Shumon,

What about this?

# When an iterative caching DNS resolver receives a response with RCODE being NXDOMAIN,
# the resolver SHOULD store the response in its (negative) cache.  During the time the response
# is cached, any query with a QNAME at or descended from the denied name that is not otherwise
#cached (positively), can be assumed to result in a name error.  Responses to those queries
# SHOULD set RCODE=NXDOMAIN (using the DNSSEC records cached as proof).

When an iterative caching DNS resolver receives a query response with RCODE as NXDOMAIN,
The resolver should store the NXDOMAIN response in cache. During the time that this response
is cached, any query with a QNAME at or descended from the query that resulted in NXDOMAIN
and that is not already in cache can be assumed to result in a name error. Responses to such
queries SHOULD respond with RCODE as NXDOMAIN using DNSSEC records from cache as proof.

Andrew

NB: I work at Charter and this is not official Charter communications but rather my personal thoughts.

Andrew White
Desk:  314.394-9594<sip:13143949594>  | Cell:  314-452-4386<sip:1-314-452-4386> | Jabber<sip:[email-masked]>
[email-masked]<mailto:[email-masked]>
Systems Engineer III, DAS DNS group
Charter Communications
12405 Powerscourt Drive<https://goo.gl/maps/AH2PXFKnaGU2>,<http://www.html5zombo.com/> St. Louis,  MO 63131

From: DNSOP [mailto:[email-masked]] On Behalf Of Shumon Huque
Sent: Tuesday, September 27, 2016 1:34 PM
To: Edward Lewis
Cc: [email-masked]
Subject: Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

On Tue, Sep 27, 2016 at 1:55 PM, Edward Lewis <[email-masked]<mailto:[email-masked]>> wrote:

Perhaps instead of this:

#   When an iterative caching DNS resolver receives an NXDOMAIN response,
#   it SHOULD store it in its (negative) cache and all names and RRsets at or below
#   that node SHOULD then be considered non-existent.

--
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Tue, 27 Sep 2016 15:10:15 -0400

> queries SHOULD respond with RCODE as NXDOMAIN using DNSSEC records from

Andrew - this looks very similar to Ed's rewrite.

The problem I see with both is that it says to reply with NXDOMAIN for all
names at or below the cut, except for RRsets already positively cached. But
the current draft also allows resolvers to immediately invalidate cached
entries below the cut and also return NXDOMAIN for them. Your rewrite
appears to remove (or at least not mention) that possibility.

-- 
Shumon Huque

---

From: "White, Andrew" <[email-masked]>
Date: Tue, 27 Sep 2016 19:28:57 +0000

Hi Shumon,

True. When a resolver gets an NXDOMAIN for, say x.example.com, would it better to say the resolver SHOULD drop from cache all descendents of x.example.com, or MAY?

It may be computationally expensive to search cache to remove cached NXDOMAIN responses below x.example.com, and I see no harm in letting those cached entries expire as their TTL runs out.

Andrew

NB: This is not official Charter Communications correspondence but rather my personal thoughts.

Andrew White

From: Shumon Huque [mailto:[email-masked]]
Sent: Tuesday, September 27, 2016 2:10 PM
To: White, Andrew
Cc: Edward Lewis; [email-masked]
Subject: Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

On Tue, Sep 27, 2016 at 2:48 PM, White, Andrew <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shumon,

What about this?

Andrew

The problem I see with both is that it says to reply with NXDOMAIN for all names at or below the cut, except for RRsets already positively cached. But the current draft also allows resolvers to immediately invalidate cached entries below the cut and also return NXDOMAIN for them. Your rewrite appears to remove (or at least not mention) that possibility.

--
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Tue, 27 Sep 2016 15:33:26 -0400

> appears to remove (or at least not mention) that possibility.

One other quick comment on the rewrite:

" .. (using the DNSSEC records cached as proof)." is a bit unclear and
perhaps misplaced. I assume here this means signed NSEC or NSEC3 records,
which may or may not exist depending on whether the zone in question is
signed. And even if they exist, the resolver typically doesn't return them
as proof unless the querier sets DO=1. I think we cover this point further
down in the text, which I'll excerpt here:

  "If the NXDOMAIN response due to a cached non-existence is from a
   DNSSEC signed zone, then it will have accompanying NSEC or NSEC3
   records that authenticate the non-existence of the name.  For a
   descendant name of the original NXDOMAIN name, the same set of NSEC
   or NSEC3 records proves the non-existence of the descendant name.
   The iterative, caching resolver MUST return these NSEC or NSEC3
   records in the response to the triggering query if the query had the
   DNSSEC OK (DO) bit set."

Re-reading this paragraph, I think I'd suggest explicitly mentioning that
the NSEC/NSEC3 signatures must be returned also.

-- 
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Tue, 27 Sep 2016 15:37:10 -0400

On Tue, Sep 27, 2016 at 3:28 PM, White, Andrew <[email-masked]>
wrote:

> Hi Shumon,
>
>
>
> True. When a resolver gets an NXDOMAIN for, say x.example.com, would it
> better to say the resolver SHOULD drop from cache all descendents of
> x.example.com, or MAY?
>
>
>
> It may be computationally expensive to search cache to remove cached
> NXDOMAIN responses below x.example.com, and I see no harm in letting
> those cached entries expire as their TTL runs out.
>

It depends on the implementation of the cache. I guess you missed the ~ 100
message thread on this very topic from earlier this year! :-)

-- 
Shumon Huque

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 27 Sep 2016 15:46:16 -0700

> those cached entries expire as their TTL runs out.

Would it be better then to leave early expiry as an implementation choice,
and instead say that the implementation SHOULD respond with NXDOMAIN for
any QNAME at or below a cached NXDOMAIN?

# When an iterative caching DNS resolver receives a response with RCODE
being
# NXDOMAIN, the resolver SHOULD store the response in its (negative) cache.
# During the time the response is cached, any query with a QNAME at or
# descended from the denied name SHOULD be assumed to result in a name
error.
# Responses to those queries SHOULD set RCODE=NXDOMAIN (using the DNSSEC
# records cached as proof).  Any names at or below the name received in the
# NXDOMAIN response MAY be flushed from cache at the time the response is
# received.

If foo.bar.example.org has a cached record, and an nxdomain for
bar.example.org is then cached, further queries for foo.bar.example.org
would also trigger NXDOMAIN for as long as bar.example.org is in the
negative cache.

If the negative response for bar.example.org expires before the positive
response for foo.bar.example.org, then that name could pop up in positive
responses again... if the implementation hasn't chosen to expire it as well.

My rationale is that if foo.bar.example.org were still a valid name at the
time that the bar.example.org NXDOMAIN response was issued, then NXDOMAIN
was not the correct response.  It would be inappropriate to answer for
foo.bar.example.org out of the cache in that case.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Sep 2016 13:42:19 +0000

On 9/27/16, 18:46, "Matthew Pounsett" <[email-masked]> wrote:
>Would it be better then to leave early expiry as an implementation choice

I think it comes down to implementer's choice.  The goal of the (IETF in general) documents is interoperability. Whether or not a cache chooses to keep the cached entries or remove them, or the way in which it chooses which of two (or more) valid answers to give doesn't impact interoperability.  So long as the response given is protocol-appropriate.

The issue is, which response (of a set of possible responses) is correct is not definable within the DNS protocol.  So, there's no winner here.

Implementors ought to be aware of choices, but let them choose because they know best what's optimal for their goals.  Well, "ought" might be too strong, implementors just "need" to produce acceptable responses.  If this is over constrained, goodbye innovation.

For me, I'd never think to cull validated entries because of conflicting information and I'd use the routing-area principle of longest match to decide what to return.  But those are whimsical choices.  I can see that some might want to cull, I just don't see spending cycles managing that.

Ultimately, the goal of the draft is to tell a recursive server that if it can conclusively deduce existence of a name from what it has cached, it is allowed to do so.  Today if the conclusion is positive, that's how it is.  The draft proposes to add negative conclusions as well.  Perhaps getting into the details of managing what's in the cache, which is not covered beyond TTL expiry "rules" is causing the wrapping around the axle.  (We are talking about the fairly odd example of there being conflicting data.)

As far as DNSSEC, this only works with DNSSEC in place, right?  You need the missing span proofs or you are NXDOMAIN'ing entire zones, not just entire domains (within a zone).

---

From: Shumon Huque <[email-masked]>
Date: Wed, 28 Sep 2016 11:21:24 -0400

On Wed, Sep 28, 2016 at 9:42 AM, Edward Lewis <[email-masked]>
wrote:

> I think it comes down to implementer's choice.  The goal of the (IETF in
> general) documents is interoperability. Whether or not a cache chooses to
> keep the cached entries or remove them, or the way in which it chooses
> which of two (or more) valid answers to give doesn't impact
> interoperability.  So long as the response given is protocol-appropriate.
>
> The issue is, which response (of a set of possible responses) is correct
> is not definable within the DNS protocol.  So, there's no winner here.
>

I agree, and this seems entirely in keeping with the loosely coherent
distributed database model of the DNS.

[...]

>
> As far as DNSSEC, this only works with DNSSEC in place, right?  You need
> the missing span proofs or you are NXDOMAIN'ing entire zones, not just
> entire domains (within a zone).
>

The draft does not currently require DNSSEC. It's true that without DNSSEC,
the impact of a spoofed NXDOMAIN is much larger, and for this reason the
draft does mention that implementations could choose to deploy this
enhancement only for signed data (and some implementations have already
taken this route).

To be precise, I would say we are not necessarily always pruning out entire
zones. For a leaf zone, we are pruning all names within that zone below the
nxdomain-cut, modulo cached entries, i.e. a subset of the zone. But yes,
for non-leaf zones, all zones below too are pruned.

-- 
Shumon Huque

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 28 Sep 2016 08:39:35 -0700

On 28 September 2016 at 06:42, Edward Lewis <[email-masked]> wrote:

> Ultimately, the goal of the draft is to tell a recursive server that if it
> can conclusively deduce existence of a name from what it has cached, it is
> allowed to do so.  Today if the conclusion is positive, that's how it is.
> The draft proposes to add negative conclusions as well.  Perhaps getting
> into the details of managing what's in the cache, which is not covered
> beyond TTL expiry "rules" is causing the wrapping around the axle.  (We are
> talking about the fairly odd example of there being conflicting data.)
>
>
Taking the view that this is only about interoperability, then I would say
the implementor MAY treat names below the NXDOMAIN response as nonexistent,
and MAY choose to expire those names early... perhaps with a suggestion
that this might be the better choice for data coherence, but still leave it
up to the implementor if they've got a better reason to do it otherwise.

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 28 Sep 2016 18:44:27 +0200

Moin!

> for non-leaf zones, all zones below too are pruned.
I think we've been down that argument before. Not all cache implementations
have a DNS tree structure and nothing in the DNS protocol requires this AFAIK.
I consider anything in the cache where the TTL is still valid to be valid data
that can be send to clients even if below the nxdomain cut. My understanding
is that this is how the current draft is written.

For new records/delegations of course this would go NXDomain, but what to do
with stuff already in the cache is an implementation choice.

I also don't think this is different with DNSSEC as stuff below the NXDomain
cut still is valid until TTL expires.

So long
-Ralf

---

From: Shumon Huque <[email-masked]>
Date: Wed, 28 Sep 2016 13:03:24 -0400

> is that this is how the current draft is written.

Not exactly. The draft does NOT say that all unexpired cached data below
the NXDOMAIN boundary is still valid. It leaves that up to implementers.
Paraphrasing without 2119 keywords, it says that resolvers should consider
all names below the cut non-existent, but may continue to return positive
answers for existing cached entries. This text was the end result of many
long discussions on the topic earlier this year. I think this accommodates
your position.

> with stuff already in the cache is an implementation choice.

Yes.

-- 
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Wed, 28 Sep 2016 13:29:41 -0400

On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett <[email-masked]>
wrote:

>> Ultimately, the goal of the draft is to tell a recursive server that if
>> it can conclusively deduce existence of a name from what it has cached, it
>> is allowed to do so.  Today if the conclusion is positive, that's how it
>> is.  The draft proposes to add negative conclusions as well.  Perhaps
>> getting into the details of managing what's in the cache, which is not
>> covered beyond TTL expiry "rules" is causing the wrapping around the axle.
>> (We are talking about the fairly odd example of there being conflicting
>> data.)
>>
>>

The draft (by working group consensus) is written as "SHOULD treat names
below as non-existent", but "MAY continue to answer existing positive
cached entries". I think this managed to cover or at least placate all
positions expressed by working group participants leading up to the last
call.

I'm not sure we'll get new agreement on your proposed revision.

-- 
Shumon Huque

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 28 Sep 2016 11:37:56 -0700

On 28 September 2016 at 10:29, Shumon Huque <[email-masked]> wrote:

>> Taking the view that this is only about interoperability, then I would
>> say the implementor MAY treat names below the NXDOMAIN response as
>> nonexistent, and MAY choose to expire those names early... perhaps with a
>> suggestion that this might be the better choice for data coherence, but
>> still leave it up to the implementor if they've got a better reason to do
>> it otherwise.
>>
>
> I phrased that badly.  Since we were on the subject of cached entries
already, I assumed that context in my wording.   I should have said "MAY
treat positively cached names below the NXDOMAIN response as nonexistent,
and MAY choose to expire those cached names early."  I think that's in
keeping with the intent of the current text.

There's probably some value in rewording that text though, if it's going to
cause confusion for implementors.  Maybe invert the text?

# When an interative caching DNS resolver receives a response NXDOMAIN, it
# SHOULD store it in its negative cache.  It MAY choose to immediately
remove
# from its positive cache any previously cached names at or below the
NXDOMAIN
# response.  If the cached entries below the NXDOMAIN response are not
# removed, it MAY choose to continue to answer positively for those names
# until the cached entries expire.

# The resolver SHOULD treat all other names at or below NXDOMAIN response
as
# nonexistant and SHOULD respond negatively to queries for such names.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 29 Sep 2016 07:28:36 -0400

On Wed, Sep 28, 2016 at 2:37 PM, Matthew Pounsett <[email-masked]>
wrote:

> There's probably some value in rewording that text though, if it's going
> to cause confusion for implementors.  Maybe invert the text?
>
I'll wait first for others to weigh in on your proposed rewrite.

-- 
Shumon Huque

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 29 Sep 2016 13:43:23 +0200

On Mon, Sep 26, 2016 at 05:42:31PM +0000,
 Edward Lewis <[email-masked]> wrote 

> For consistency, the SHOULD's in the first paragraph ought to be

Process-wise, I don't think it is reasonable to ask for a change in
RFC2119 terms after the Working Group Last Call *and* the IESG
approval. Otherwise, no work will ever be finished.

In the technical side, see the answers by Shumon Huque.

> (with serial) is not in every response, it's impossible
> (computationally undecidable) to know whether the answer with the
> NXDOMAIN was created before or after lower data.  Maybe the lower
> data is "currently correct" and the NXDOMAIN is stale-ish.  Or not.

As Mark Andrews say, this is a very old DNS issue. Nothing new here,
no new text required.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 29 Sep 2016 13:53:42 +0200

On Wed, Sep 28, 2016 at 01:42:19PM +0000,
 Edward Lewis <[email-masked]> wrote 
 a message of 84 lines which said:

> As far as DNSSEC, this only works with DNSSEC in place, right?  You
> need the missing span proofs or you are NXDOMAIN'ing entire zones,
> not just entire domains (within a zone).

This is covered in section 8 of the draft (and also in 9, about
Unbound). If people want to spend time on an already-approved draft,
could they at least read it?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 29 Sep 2016 13:49:55 +0200

On Tue, Sep 27, 2016 at 03:46:16PM -0700,
 Matthew Pounsett <[email-masked]> wrote 
 a message of 137 lines which said:

> My rationale is that if foo.bar.example.org were still a valid name

By "valid name", do you mean "something which existed less than $TTL
seconds ago"?

> at the time that the bar.example.org NXDOMAIN response was issued,
> then NXDOMAIN was not the correct response.  It would be
> inappropriate to answer for foo.bar.example.org out of the cache in
> that case.

The DNS is full of these (minor) inconsistencies. As Mark Andrews
said, temporal issues are not new.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 29 Sep 2016 13:46:18 +0200

On Tue, Sep 27, 2016 at 07:28:57PM +0000,
 White, Andrew <[email-masked]> wrote 
 a message of 284 lines which said:

> True. When a resolver gets an NXDOMAIN for, say x.example.com, would
> it better to say the resolver SHOULD drop from cache all descendents
> of x.example.com, or MAY?

The current state of the draft is "approved by IESG". Which means
that, unless a serious bug is discovered, it will be published as a
RFC with only editorial changes (by the RFC editor). I don't think it
is a good idea to reopen a discussion which triggered aleady many
emails.

> those cached entries expire as their TTL runs out.

Which is exactly what the draft is saying:

   But if a resolver has cached data under the NXDOMAIN cut, it MAY
   continue to send it as a reply (until the TTL of this cached data
   expires), since this may avoid additional processing when a query is
   received.  Section 6 provides more information about this.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 29 Sep 2016 13:54:49 +0200

On Wed, Sep 28, 2016 at 06:44:27PM +0200,
 Ralf Weber <[email-masked]> wrote 
 a message of 26 lines which said:

> I consider anything in the cache where the TTL is still valid to be
> valid data that can be send to clients even if below the nxdomain
> cut. My understanding is that this is how the current draft is
> written.

Yes (with "MAY" instead of "can").