[resending it after resolving the mismatched sender address...] (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". _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
