NXDOMAIN returned when the domain exists

[Siva Kesava R Kakarla]

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 <example.com. , A>, 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

[Miek Gieben]

this is indeed wrong

[Miek Gieben]

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.

[Siva Kesava R Kakarla]

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.

[Miek Gieben]

[ 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. <zone domain> 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