Issue with resolving hostname when using Turris resolver

Software SW bugs discussion
1

Hello, I would like to know, why Turris DNS resolver does not resolve correctly domain name www.autickar.cz (DNS forwarding is switched off, when switched on, it works correctly).

dig www.autickar.cz
...
;; ANSWER SECTION:
www.autickar.cz.        38400   IN      CNAME   core.miniserver.cz.
...

When using Google’s DNS it looks like this:

dig @8.8.8.8 www.autickar.cz
...
;; ANSWER SECTION:
www.autickar.cz.        10260   IN      CNAME   core.miniserver.cz.
core.miniserver.cz.     10260   IN      A       109.123.222.144
...
2

I mean the Turris DNS resolution is OK. You are asking for www.autickar.cz and correct answer is not the IP address but the name core.miniserver.cz. Reason is the www.autickar.cz is CNAME (i.e. alias) DNS record. It is not A-record.
Google DNS automatically appends second answer for supposed (but not sent!!!) next request:
What is IP address for core.miniserver.cz?

DNS normal resolution procedure:

  1. Client (e.g. web browser) sends DNS request: What is IP for www.autickar.cz?
  2. DNS server sends back a response: core.miniserver.cz (The record is CNAME)
  3. Client sends DNS request: What is IP for core.miniserver.cz?
  4. DNS server sends back a response: 109.123.222.144

Tracing:

dig  +trace www.autickar.cz
dig  @8.8.8.8  +trace www.autickar.cz

DNS fault would be if your router does not send response for request:
What is IP for core.miniserver.cz?

3

Thank you for the explanation, but where is the issue then? When I set Turris DNS resolver, it won’t open the page www.autickar.cz. IP address for core.miniserver.cz is mentioned above - 109.123.222.144.

4

seems like almost every public resolver includes the a-record in the answer for the cname.

but on a quick look i have not found a option for unbound/knot which would enable this.
you probably have to switch to dns-forwarding with dnsmasq for now, if you depend on this behavior.

5

That resolution is not OK, as following the CNAME is a mandatory part of recursive service.

@riham (or anyone else reproducing this) I’m unable to reproduce this particular problem locally, even with knot-resolver-1.1.1. Do you have any non-standard resolver settings? Does it still (sometimes) fail? I wonder if something around NS autickar.cz might’ve changed in the meantime.

As the case seems rather similar to Domény třetího řádu , I’d hope that our recent changes also fix your problem (not released yet).