ndb-dns-empty-noerror
=====================

ndb/dns: return NOERROR (RCODE 0) for unsupported RR types instead
of NOTIMP (RCODE 4), with SOA in authority section when authoritative.


PROBLEM
-------

`/sys/src/cmd/ndb/dnserver.c` responds with `Runimplimented` (RCODE 4
/ NOTIMP) when queried for a record type ndb does not recognize.

This breaks any modern public-internet deployment.  In particular:

  - CAA queries (RFC 8659) during certificate issuance.  Modern
    publicly-trusted certificate authorities are required to check
    CAA records before issuing a certificate.  NOTIMP responses fail
    the check, so any Plan 9 host serving authoritative DNS for its
    own zone cannot obtain a certificate from a public CA.

  - TLSA (RFC 6698, DANE) - same NOTIMP issue.
  - SVCB / HTTPS (RFC 9460) - same.
  - DNSKEY / RRSIG / NSEC (DNSSEC) - same.


WHY NOTIMP IS WRONG
-------------------

RFC 1035 Section 4.1.1 defines RCODE 4 as:

    "Not Implemented - The name server does not support the requested
     kind of query."

The phrase "kind of query" refers to the OPCODE field (QUERY/IQUERY/
STATUS), not to the QTYPE.  NOTIMP is for unsupported query *opcodes*,
not unsupported record *types*.

RFC 3597 Section 3 (Transparency) requires:

    "name servers and resolvers MUST handle RRs of unknown type
     transparently."

RFC 8659 Section 6.2 (Mis-Issuance) explicitly identifies the broken
behavior:

    "Some authoritative nameservers respond with REJECTED or NOTIMP
     when queried for an RR type they do not recognize... Per
     [RFC1034], the correct response RCODE for unknown RR types is 0
     ('No error condition')."

This is a named "deployment problem" callout that matches Plan 9's
current behavior.

Other widely-deployed authoritative DNS implementations return
NOERROR-empty for unknown types.  Plan 9 ndb/dns is the outlier.


FIX
---

Replace the `Runimplimented` response in the `!rrsupported(...)` arm
of `dnserver.c` with:

  - For queries within an authoritative area:
    NOERROR (Rok) + AA (Fauth) + SOA in authority section
    (per RFC 2308 Section 3 negative caching).

  - For queries outside an authoritative area:
    bare NOERROR-empty (no Fauth, no SOA).

The class check and AXFR/IXFR check keep NOTIMP, which is correct
per RFC 1035 Section 4.1.1 (class is protocol-level) and RFC 5936 (AXFR is
an opt-in feature).


SCOPE
-----

Single concern: only the unsupported-type response in dnserver.c.
No other files touched.  No new RR types added to dns.h or
dblookup.c - the patch fixes the response semantics, not the type
support.


CITATIONS
---------

  RFC 1034, 1035          DNS specification (RCODE definitions)
  RFC 2308 Section 3      SOA in authority for negative caching
  RFC 3597 Section 3      Unknown RR type transparency MUST
  RFC 6895 Section 2.3    RCODE IANA registry
  RFC 8659 Section 3      CAA mechanism
  RFC 8659 Section 6.2    "Deployment problem" callout for NOTIMP-on-unknown


APPLY
-----

    cd /
    ape/patch -p0 < ndb-dns-empty-noerror.diff
    cd /sys/src/cmd/ndb
    mk install
    echo restart >/net/dns


TEST
----

  1. `dig CAA <your-zone>` against the patched server - expect status
     NOERROR, no answer records, SOA in AUTHORITY section.
  2. `dig TLSA _25._tcp.<your-zone>` - same shape.
  3. `dig A <your-zone>` - unchanged behavior (returns the A record).
  4. `dig AXFR <your-zone>` - unchanged (NOTIMP, by design).
  5. From an external recursive resolver after cache expiry:
     `dig CAA <your-zone> @1.1.1.1` - NOERROR (no SERVFAIL).
  6. An ACME client issuance attempt - the CAA gate passes; cert
     issued (assumes other prerequisites are satisfied).


FILES
-----

    README                            this file
    ndb-dns-empty-noerror.diff        the patch (apply with -p0 from /)