Coredns: NXDOMAIN returned when the domain exists

[SivaKesava1]

What happened:

Hi,

CoreDNS returns NXDOMAIN for queries with no matching type, but the domain name exists.

| | | | |
|- |- |- |- |
| example.com. | 500 | SOA | ns1.outside.com. root.example.com. 3 604800 86400 2419200 604800 |
| example.com. | 500 | NS | ns1.outside.com. |

For the query __, the Coredns server returns the following response:

          "opcode QUERY",
          "rcode NXDOMAIN",
          "flags QR AA",
          ";QUESTION",
          "example.com. IN A",
          ";ANSWER",
          ";AUTHORITY",
          "example.com. 500 IN SOA ns1.outside.com. root.example.com. 3 604800 86400 2419200 604800",
          ";ADDITIONAL"

What you expected to happen:
The query name example.com. exists, but the requested type A does not, so the rcode should be NOERROR instead of NXDOMAIN. The response code is important as resolvers can use QNAME minimization as described in RFC 7816: QNAME Minimization when resolving names like child.foo.example.com and will wrongly conclude that there is nothing at example.com. as well as below it.

Environment:

• the version of CoreDNS: CoreDNS-1.8.0 linux/amd64, go1.14.13, 31abdc2f
• Corefile:

example.com:53 {
    file db.example.com
    log
    errors
}

• OS: Ubuntu 18
-

[miekg]

this is indeed wrong

[miekg]

ok, this is only true when you zone doesn't contain any other data which would be weird. I'm inclined to not fix this because it needs a separate branch to handle this.

[SivaKesava1]

I am not sure how common it is in the wild, but my university has divided the namespace into 800 zone files (each department and sub-department), and a lot of the zone files have only 4-5 records, of which one is SOA, 2-3 NS records, 1-2 MX records and 1-2 IP records all at the zone domain itself. In some cases, there is a www. <zone domain> record, which I think will make the above error not occur.

[miekg]

[ Quoting [e-mail] in "Re: [coredns/coredns] NXDOMAIN retu..." ]

I am not sure how common it is in the wild, but my university has divided the
namespace into 800 zone files (each department and sub-department), and a lot
of the zone files have only 4-5 records, of which one is SOA, 2-3 NS records,
1-2 MX records and 1-2 IP records all at the zone domain itself. In some cases,
there is a www. record, which I think will make the above error
not occur.

yes anything more than SOA + NS will make this go away. This stems from the optimization
of putting the APEX record (SOA+NS) not in the tree (less and less convinced that was a
good idea).

/close