[DNSOP] how DNS redirect works with empty response

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

(apologize if this point was already discussed in the thread.  I've
read all relevant threads but due to their volume I may miss
something).

I have one quick question about what the DNS redirect service
does/would/should with an empty response in terms of "Web Error
Redirect".

Suppose that a zone "example.com" has a wildcard RR at the apex, a
common practice for catch-all MX configuration:

*.example.com.	IN	MX	  10	mx.example.com.

also assume this zone doesn't have wwww.example.com (four 'w's).

If a user specifies this non-existent name, intending to mean
www.example.com, and the stub resolver queries for A and/or AAAA RRs
of that name, the authoritative server will return a no error, empty
response.  This is a variant of "web error' situation, but it doesn't
result in an NXDOMAIN.

What does a recursive server that implements the DNS redirect service
do in this case?  Does it return the original empty response intact?
Or does it "redirect" such responses too?  If it's the latter, what if
only one of A and AAAA answers is empty (which is actually today's
common situation)?

If it currently returns the original empty response, and our consensus
is it should keep this behavior in the future (even with those who are
for NXDOMAIN redirect), then I guess authoritative server implementors
who don't like NXDOMAIN redirect could introduce a "auto-site-finder"
option, defaulting to yes, which automatically adds a wildcard name
(of some meaningless RR type) at the apex of each authoritative
zone:-)

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

p.s. I also have one very minor nit, which is irrelevant to the
subject of this message, but I think it's too minor to raise in a
separate message...so here it goes:

The draft uses the term "NXDOMAIN", seemingly intentionally.  But if
you eventually want to publish it as an RFC, you may want to know that
when I co-authored RFC4074 one of IESG's DISCUSS comment was "don't
use NXDOMAIN":
https://datatracker.ietf.org/idtracker/draft-ietf-dnsop-misbehavior-against-aaaa/comment/21536/

If the IESG is consistent about their DISCUSS criteria (which I
actually doubt), you may face the same challenge.  So, unless there's
a strong reason for keeping this term, it would be safer to rephrase
it to "name error".