See also https://tools.ietf.org/html/draft-andrews-dns-no-response-issue-07

6.  Response Code Selection

   Choosing the correct response code when fixing a nameserver is
   important.  Just because a type is not implemented does not mean that
   NOTIMP is the correct response code to return.  Response codes need
   to be chosen considering how clients will handle them.

   For unimplemented opcodes NOTIMP is the expected response code.

   In general, for unimplemented type codes Name Error (NXDOMAIN) and
   NOERROR (no data) are the expected response codes.  A server is not
   supposed to serve a zone which contains unsupported types ([RFC1034])
   so the only thing left is return if the QNAME exists or not.  NOTIMP
   and REFUSED are not useful responses as they force the clients to try
   all the authoritative servers for a zone looking for a server which
   will answer the query.

   Meta queries type may be the exception but these need to be thought
   about on a case by case basis.

   If you support EDNS and get a query with a unsupported EDNS version
   the correct response is BADVERS [RFC6891].

   If you do not support EDNS at all FORMERR and NOTIMP are the expected
   error codes.  That said a minimal EDNS server implementation just
   requires parsing the OPT records and responding with a empty OPT
   record.  There is no need to interpret any EDNS options present in
   the request as unsupported options are expected to be ignored
   [RFC6891].


In message <[email protected]>, Viktor Dukhovni 
writes:
> On Tue, Feb 17, 2015 at 06:46:13PM -0500, Paul Wouters wrote:
> 
> > Why does postfix care about the security of the A/CNAME results before
> > asking for TLSA records?
> 
> Because "nist.gov" would otherwise receive no email:
> 
>     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18665
>     ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>     ;nist.gov.              IN MX
>     nist.gov.               MX      0 nist-gov.mail.protection.outlook.com.
> 
>     ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53098
>     ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>     ;_25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA
> 
> The nameservers for the unsigned zone of nist.gov's MX hosts are
> allergic to TLSA queries.  They return "NOTIMPL" instead of:
> 
>     ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28627
>     ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>     ;_25._tcp.nist-gov.mail.protection.outlook.com. IN A
> 
> You can try it for yourself
> 
>     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37877
>     ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>     ;mail.protection.outlook.com. IN        NS
>     mail.protection.outlook.com. NS ns1-proddns.glbdns.o365filtering.com.
>     mail.protection.outlook.com. NS ns2-proddns.glbdns.o365filtering.com.
> 
>     $ dig +norecur +dnssec +noall +comment +qu -t tlsa 
> _25._tcp.nist-gov.mail.protection.outlook.com. @ns1-proddns.glbdns.o365
> filtering.com.
>     ;; Got answer:
>     ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 19776
>     ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
>     ;; WARNING: EDNS query returned status FORMERR - retry with '+nodnssec 
> +noedns'
> 
>     $ dig +norecur +nodnssec +noedns +noall +comment -t tlsa 
> _25._tcp.nist-gov.mail.protection.outlook.com. @ns1-proddns.glbdn
> s.o365filtering.com.
>     ;; Got answer:
>     ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 56709
>     ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> This was discussed quite some time ago, and has been in the SMTP
> draft since.  The domain "nist.gov" is not a comprehensive list of
> problem domains.  The SMTP draft avoids sending queries for "exotic"
> RR-types to "minimal" nameservers that don't support DNSSEC.
> 
> > Why isn't it asking for TLSA records, and if those are secure, don't
> > care about the AD bit for the A/AAAA/CNAME.
> 
> Because those queries would all too often spuriously fail, and with
> "discovery" of TLS support (opportunistic DANE TLS), would lead to
> loss of connectivity, since the failures are indistinguishable from
> downgrade attacks.
> 
> -- 
>       Viktor.
> 
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email protected]

_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane

Reply via email to