Hi,
is it normal that Knot resolver can’t handle CNAME on root level? I can’t resolve cutcaptcha.com, it fails always, if i ask 1.1.1.1 or 8.8.8.8 directly, i can resolve it. This is very annoying, can i change some option to make it work?
Thanks for help
CNAME at a zone cut is breakage of standards. If you disable forwarding, it should mostly work. (That’s also why it works on 1.1.1.1 – they use knot-resolver.)
Hi @vcunat,
thank you for you reply, what do you mean by disabling forwarding? Running it in recursive mode? Beside that i know that it is a breakage of standards, but can’t i put something in the option with ‘allow strange shit: “yes”’?
In /foris/config/main/dns/ uncheck “use forwarding”. It means to switch from recursive to iterative, if you use that terminology.
We don’t intentionally break this case. You can’t obtain e.g. DNSKEY or DS through a forwarder when the apex is a CNAME, because the forwarder will (and is supposed to) return records from the target. These records are necessary to validate the answer.
Currently i use DNS over TLS via Cloudflare, for that i followed Using dns over tls or https if i understand what you posted correctly my options are turning the forwarding off and ask the root servers myself, or maybe turning off DNSSEC in Knot if that is even possible?
The 1st one is bad for performance, the 2nd for security. I guess fuck cutcaptcha.com then and do nothing 
If i got there something wrong please correct me 
Thank you for your fast help
Yes, unchecking DNSSEC validation on that same page would also work around that problem, I think.
This seems to be a knot specific issue, or DNS forwarding set on the WAN and thus potentially conflicting with knot specific forward settings).
With unbound, DNS forwarding on WAN disabled, DNSSEC enabled and DoT enabled (subsequent DNS forwarding enabled in the backend) no issue in resolving:
# dig cutcaptcha.com
; <<>> DiG 9.11.2-P1 <<>> cutcaptcha.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32147
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cutcaptcha.com. IN A;; ANSWER SECTION:
cutcaptcha.com. 1799 IN CNAME bullads.net.
bullads.net. 60 IN A 185.117.74.21;; AUTHORITY SECTION:
bullads.net. 99201 IN NS dns2.registrar-servers.com.
bullads.net. 99201 IN NS dns1.registrar-servers.com.;; ADDITIONAL SECTION:
dns1.registrar-servers.com. 1207 IN A 216.87.155.33
dns2.registrar-servers.com. 69931 IN A 216.87.152.33
dns1.registrar-servers.com. 521 IN AAAA 2620:74:19::33;; Query time: 622 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Nov 02 12:11:31 CET 2018
;; MSG SIZE rcvd: 200
As I wrote, with disabled forwarding the name works on otherwise default Omnia.
Indeed. And I trust that the root cause is the conflict of DNS settings at different locations Turris OS 3.11 in RC! and that is not documented/clear which DNS setting takes precedence over which
No, this isn’t about settings, really. Knot-resolver just doesn’t support CNAMEs at top of zones. It’s relatively widely known to be a standard-breaking condition; it’s been “forbidden” for decades. Without forwarding it works “by accident”, because it doesn’t cause much trouble in that case.
But DoT forwards the query to the upstream server as well, only difference is the port and that TLS is deployed. Why does that work but option forward_upstream not?
Right, I see now. I got confused by you writing that forwarding is disabled. I read too fast.