starred/acme-dns

Fork 0

mirror of https://github.com/acme-dns/acme-dns.git synced 2026-04-27 12:55:48 +03:00

[GH-ISSUE #48] CNAME records are returned as NXDOMAIN #13

New issue

Closed

opened 2026-03-13 15:21:40 +03:00 by kerem · 12 comments

kerem commented

2026-03-13 15:21:40 +03:00

Owner

Originally created by @Yannik on GitHub (Mar 2, 2018).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/48

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.

Originally created by @Yannik on GitHub (Mar 2, 2018). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/48 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.

kerem closed this issue

2026-03-13 15:21:45 +03:00

kerem commented

2026-03-13 15:21:51 +03:00

Author

Owner

@MrBMT commented on GitHub (Mar 2, 2018):

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.

@MrBMT commented on GitHub (Mar 2, 2018): 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.

kerem commented

2026-03-13 15:21:56 +03:00

Author

Owner

@Yannik commented on GitHub (Mar 2, 2018):

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 commented on GitHub (Mar 2, 2018): 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.)

kerem commented

2026-03-13 15:22:01 +03:00

Author

Owner

@Yannik commented on GitHub (Mar 2, 2018):

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 commented on GitHub (Mar 2, 2018): 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. ```

kerem commented

2026-03-13 15:22:06 +03:00

Author

Owner

@Yannik commented on GitHub (Mar 2, 2018):

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 notifications@github.com 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:
https://github.com/joohoi/acme-dns/issues/48#issuecomment-369988871

@Yannik commented on GitHub (Mar 2, 2018): 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 <notifications@github.com> 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: >https://github.com/joohoi/acme-dns/issues/48#issuecomment-369988871

kerem commented

2026-03-13 15:22:11 +03:00

Author

Owner

@MrBMT commented on GitHub (Mar 2, 2018):

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.

@MrBMT commented on GitHub (Mar 2, 2018): 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.

kerem commented

2026-03-13 15:22:16 +03:00

Author

Owner

@Queuecumber commented on GitHub (Aug 14, 2018):

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

@Queuecumber commented on GitHub (Aug 14, 2018): 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

kerem commented

2026-03-13 15:22:21 +03:00

Author

Owner

@Yannik commented on GitHub (Aug 14, 2018):

@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.

@Yannik commented on GitHub (Aug 14, 2018): @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.

kerem commented

2026-03-13 15:22:26 +03:00

Author

Owner

@joohoi commented on GitHub (Aug 14, 2018):

@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.

@joohoi commented on GitHub (Aug 14, 2018): @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`.

kerem commented

2026-03-13 15:22:31 +03:00

Author

Owner

@Yannik commented on GitHub (Aug 14, 2018):

@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)

@Yannik commented on GitHub (Aug 14, 2018): @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)

kerem commented

2026-03-13 15:22:36 +03:00

Author

Owner

@joohoi commented on GitHub (Aug 14, 2018):

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

@joohoi commented on GitHub (Aug 14, 2018): Oh, and I'm sorry. I pinged the wrong user as well, just checked the username from the last comment :)

kerem commented

2026-03-13 15:22:41 +03:00

Author

Owner

@Yannik commented on GitHub (Aug 14, 2018):

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

@Yannik commented on GitHub (Aug 14, 2018): @joohoi Okay. The reason why this works is, that the client does recursively resolve the CNAME that is returned by acme-dns.

kerem commented

2026-03-13 15:22:47 +03:00

Author

Owner

@Queuecumber commented on GitHub (Aug 14, 2018):

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

@Queuecumber commented on GitHub (Aug 14, 2018): @Yannik Yup you're correct, using ping the name is fully resolved, I incorrectly assumed dig would do the same. Thanks for the advice!