CNAME records are returned as NXDOMAIN

[Yannik]

I'm using <uid>.acme-dns.mydomain.org for the letsencrypt TXT records and would like to use acme-dns.mydomain.org as API endpoint.

These are the records I've configured in config.cfg:

records = [ 
    "acme-dns.mydomain.org. CNAME hostname.mydomain.org",
    "acme-dns.mydomain.org. NS hostname.mydomain.org",
]

In the mydomain.org zone I have configured acme-dns.mydomain.org NS hostname.mydomain.org accordingly.

Unfortunately, querying acme-dns.mydomain.org results in NXDOMAIN:
time="2018-03-02T11:45:27Z" level=debug msg="Answering question for domain" domain=acme-dns.mydomain.org. qtype=A rcode=NXDOMAIN

Is it possible to get CNAMEs to resolve correctly? I'd really prefer this over hardcoding an A-record.

[MrBMT]

acme-dns will not serve any DNS records other than those explicitly set in the records section, or the TXT records added via the API.

What you're tying to do here won't work, so you'll need to add an A record for it instead.

[Yannik]

Well, I did set the CNAME record using the records section.
acme-dns just needs to return the CNAME, it does not have to recursively resolve that if that's what you are thinking about.

(In fact, the ADDITIONAL section is only ever added if the CNAME target is in the same zone by most DNS servers.)

[Yannik]

As per rfc 1034:

CNAME RRs cause special action in DNS software.  When a name server
fails to find a desired RR in the resource set associated with the
domain name, it checks to see if the resource set consists of a CNAME
record with a matching class.

[Yannik]

Ben, sorry, but your understanding here seems to be lacking. There is no need to resolve the CNAME upstream. I have opened a PR which returns a cname (existence of such a record permitting) if the queried RR does not exist, as per the ietf dns specification. -- sent from mobile

…

On March 2, 2018 6:21:57 PM GMT+01:00, Ben ***@***.***> wrote: You're missing the point of this application, it's not designed to be a fully-fledged DNS server. It even says in the description _Limited_ DNS server. It has no ability to lookup external records from other DNS servers, which is why your CNAME lookup is not working. The fact is, unless the developer decides to change this (which seems unlikely, considering the project description) what you're trying to do is not going to work; you'll have to hard code an A record instead. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #48 (comment)

[MrBMT]

Oops, sorry; I actually misread what you posted. Re-read it just now and realised I'd done a dumb. Good stuff on the PR.

[Queuecumber]

Is there some trick to making this work? I wanted to use a similar setup but when I try to dig acme-dns.mydomain.org. I just get back the CNAME record, it doesn't resolve to an A. As far as I can tell I have all the other records set up

[Yannik]

@Queuecumber That's normal. Dig does return the response (which is the CNAME target). Your operating system will resolve the CNAME target by querying the DNS server of the cname target. Try ping acme-dns.mydomain.org. That correctly show the ip.

[joohoi]

@Yannik please refer to https://github.com/joohoi/acme-dns#dns-records and note that you need to add the A record for acme-dns.mydomain.org to the acme-dns config.cfg records variable as well, as shown in the default config.cfg.

[Yannik]

@joohoi while that may be used in the default configuration, I definitely do not have any A records in my config.cfg records. (I've been actively using acme-dns with this setup for a long time)

[joohoi]

Oh, and I'm sorry. I pinged the wrong user as well, just checked the username from the last comment :)

[Yannik]

@joohoi Okay. The reason why this works is, that the client does recursively resolve the CNAME that is returned by acme-dns.

[Queuecumber]

@Yannik Yup you're correct, using ping the name is fully resolved, I incorrectly assumed dig would do the same. Thanks for the advice!