coredns: How come some resolvers (1.1.1.1) can't resolve CNAME pointing to external domains ?

First thank you for that great project 😃 First of all, I’m puzzled I don’t find anything related to that problem because it seems a frequent usage. I may be misusing CoreDNS or RFC 1035 files, in case I apology 😃 But I’m facing this issue in several environments.

I’m trying to use CoreDNS 1.8.6 (docker img) with file plugin and it can’t resolve CNAME records when they return external domain names ( ie current server is not authoritative), using some resolvers, like cloudflare and others (as stated on dnschecker.org for instance).

Here’s a simple Corefile:

. {
  errors
  log
  reload 30s
  hebergement-web.nc {
     file db.hebergement-web.nc
  }
}

And the zone content :

$TTL 86400
$ORIGIN hebergement-web.nc.
@      IN SOA dns.fenollar.fr. guillaume.fenollar.fr. (
                2022011901 ; serial 
                86400       ; refresh (2 hours)
                86400       ; retry (1 hour)
                1209600    ; expire (2 weeks)
                86400       ; minimum (1 hour)
                )

    86400 IN NS vps.fenollar.fr.
    86400 IN NS dns.fenollar.fr.

test IN CNAME novit.io.

Now a dig using Google resolver

; <<>> DiG 9.16.23 <<>> test.hebergement-web.nc @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31696
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;test.hebergement-web.nc.	IN	A

;; ANSWER SECTION:
test.hebergement-web.nc. 21600	IN	CNAME	novit.io.
novit.io.		3600	IN	A	164.132.97.235

;; Query time: 560 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jan 19 18:16:49 +11 2022
;; MSG SIZE  rcvd: 90

Next same request for 1.1.1.1

; <<>> DiG 9.16.23 <<>> test.hebergement-web.nc @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11915
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 22 (No Reachable Authority): (at delegation hebergement-web.nc.)
; EDE: 23 (Network Error): (139.99.217.72:53 rcode=SERVFAIL for test.hebergement-web.nc A)
;; QUESTION SECTION:
;test.hebergement-web.nc.	IN	A

;; Query time: 1660 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Jan 19 18:17:18 +11 2022
;; MSG SIZE  rcvd: 158

And the according logs

coredns-b49bs coredns [INFO] 172.69.47.71:12082 - 52702 "A IN novit.io. udp 37 true 1452" - - 0 0.002736558s
coredns-b49bs coredns [ERROR] plugin/errors: 2 novit.io. A: plugin/log: no next plugin found

I’m understanding that CoreDNS tries to resolve locally novit.io but is not authoritative so it gives up. Only workaround I found is to specify novit.io NS records by myself in the zone, which does not seems a good idea at scale 😄 Same result if I’m using forward plugin which I would not prefer to for that zone.

What am I doing wrong ? 😃

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 26 (14 by maintainers)

Most upvoted comments

@guillaumefenollar ,

You can use a snippet to shorten your config. e.g.

(common) {
  errors
  log
  reload 30s
  health
}

hebergement-web.nc {
  import common
  file db.hebergement-web.nc
}

example.com {
  import common
  file db.example.com
}

FYI, regarding the way you tried before: When you add a root . block, CoreDNS creates a server to handle .. But if there are no other blocks that handle a given query, and the . block doesn’t contain any plugins that provide an answer for the query, the result will be a SERVFAIL. This is also the case for the original single block configuration.

The reason the working config works, is that it doesn’t create any “dead-ends”. Specifically, there are no serverblocks that encompass zones it cannot answer.

chrisohaver on Mar 10, 2022

I’m pretty sure it’s a recent behavior because it’s very first time this conf have so much repercussions. And talking about the criticity, it’s not only about Cloudflare, but a lot of DNS servers , see by yourself : https://dnschecker.org/#A/test.hebergement-web.nc Thank you for the help

guillaumefenollar on Jan 25, 2022