Under Response Code Selection we already have:
For unimplemented type codes, and in the absence of other
errors, the only valid response is NoError if the qname
exists, and NameError (NXDOMAIN) otherwise. For Meta-RRs
NOTIMP may be returned instead.
> On 6 Nov 2019, at 13:03, Viktor Dukhovni wrote:
>
>> On Nov 4, 2019, at 3:32 PM, internet-dra...@ietf.org wrote:
>>
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-14
>
> Two comments:
>
> ---
>
> Section 3.1.2 discusses non-response to unexpected qtypes, but there
> is a closely related case that I think warrants a mention. For example,
> the nameservers for mail.protection.outlook.com (which don't support
> EDNS, returning FORMERR, hence "+noends") mishandle TLSA and other
> unexpected queries:
>
> i. A TLSA (unexpected qtype) query elicits an incorrect "NOTIMP" response:
>
> $ dig +norecur +noedns -t tlsa _25._tcp.mail.protection.outlook.com
> @ns1-proddns.glbdns.o365filtering.com.
> ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 5167
> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;_25._tcp.mail.protection.outlook.com. IN TLSA
>
> ii. An "A" query for the same qname correctly returns "NXDOMAIN":
>
> $ dig +norecur +noedns -t a _25._tcp.mail.protection.outlook.com
> @ns1-proddns.glbdns.o365filtering.com.
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23790
> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;_25._tcp.mail.protection.outlook.com. IN A
>
> This demonstrates misuse of "NOTIMP" to signal an unknown qtype,
> where a simple NODATA or NXDOMAIN suffices. The NOTIMP rcode is only
> appropriate for unsupported opcodes as explained in section 3.1.4.
> While I got a response, it is a "bad" response, not substantively
> better than no response at all.
>
> So I'd like to see text that makes it clear that unexpected qtypes
> MUST return the same RCODE as would be returned if the qtype were
> some expected value, for which no RRset is present in the zone at
> the requested qname. If the zone is signed, and the EDNS "DO" bit
> is set in the request, any (untruncated) NODATA or NXDOMAIN response
> MUST of course include the requisite denial of existence proof.
>
> ---
>
> In section 8.2.3, the correction from:
>
> OLD: Any unassigned EDNS option code could have be choose for this test.
>
> to
>
> NEW: Any unassigned EDNS option code could have been choose for this test.
>
> was incomplete, it needed to also s/choose/chosen/, to match an identical
> sentence in 8.2.6.
>
> --
> Viktor.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
