Problem with new TLDs

Most of the time, but not always, turris omnia fails to resolve new tlds like


Any idea? I have the latest update installed.

I haven’t heard of such issues around knot-resolver yet (which I develop upstream), and my Omnia resolves this particular domain without any problems (stable 3.10, almost default setup). Still, I must admit I rarely visit such new TLDs myself.

Do you use forwarding? Output of command dig contains status: SERVFAIL or another one?

Faced same/similar issue and I have mine solved by turning off the DNSSEC option.

@chouputra not sure that is the desired solution, probably a workaround whilst debugging though.

I would also reckon like @vcunat initmated it being rather an issue with DNS forwarding probably to the ISP DNS resolvers.

My end is having the ISP’s DNS resolvers disabled and DNS forwarding disabled in Foris but utilizing unbound as local resolver with forward-tls-upstream and there was no issue in accessing that particular TLD

I do not use forwarding, this adds some privacy, doesn’t it?
DNSSEC is enabled (not disabled in foris)

Here’s the output of dig:


; <<>> DiG 9.11.2-P1 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62213
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;              IN      A

;; Query time: 3 msec
;; WHEN: Thu May 17 12:42:28 CEST 2018
;; MSG SIZE  rcvd: 45

eventually any DNS query not yet cached (by knot or any other DNS cache) gets forwarded to an upstream resolver. The privacy depends on which upstream resolver is being utilized (and dns-over-tls). You could check DNS Leak Test | Perfect Privacy which upstream resolver is utilized your end.

If you do not want your ISP’s DNS resolver and make sure of it I suggest adding

    config interface 'wan'
    	option peerdns '0'

If you make such change it perhaps requires /etc/init.d/network restart. And for for good measure /etc/init.d/resolver restart


I faced same issue (with and without dns forwarding, with dnssec enabled) in Chrome and Vivaldi browsers.

After some checks i’ve added second “DNS” to be provided by my DHCP , so clients are using Turris as primary and some public one as secondary ( LUCI>Interfaces>LAN …down there , there is “advanced options” where you have “DHCP-Options” field , just add your favorite dns there. )

That did not solve it completely (TLD fixed, but non-TLD were giving me same error), so i was looking around forums and there is quick-fix for browsers using same engine as chrome.

Type “chrome://flags/” in address bar and hit Enter.
Now Click on “Reset all to Default” button from Right hand side.
Close Chrome and Open it again.
Try to open the Webpage now.

That worked fine for me, all is fine now.

Please follow debugging guide here:
and send logs to the Turris support.

We will check what is happening and determine if it is a problem with DNS on Omnia or a glitch at ISP DNS.

Thank you for cooperation!

1 Like

Unfortunately I cannot install resolver-debug:

Update: nevermind, it’s there, just forgot to hit the button to update package lists.

did you run opkg update before opkg install resolver-debug?

The package should be there, because I have just tested it:

root@turris:~# opkg install resolver-debug
Installing resolver-debug (0.0.1-3) to root...
1 Like

Oh, Indeed. Just hadt to hit the Button to update the list :smiley:

But now the WEbsite in question is working flawlessly. Will create a log as soon as I encounter more problems…

1 Like

here is example where the knot doesn’t resolve the name in first step (turns omnia has the ip

PC:~ snoki$ dig @
; <<>> DiG 9.10.6 <<>> @
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63343
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;		IN	A


;; Query time: 48 msec
;; WHEN: Mon Jul 02 09:46:28 CEST 2018
;; MSG SIZE  rcvd: 100

and resolving directly trough google dns is working

PC:~ snoki$ dig @

; <<>> DiG 9.10.6 <<>> @
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54281
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;		IN	A

** 29 IN	A**
** 29 IN	A**
** 29 IN	A**

;; Query time: 60 msec
;; WHEN: Mon Jul 02 09:46:36 CEST 2018
;; MSG SIZE  rcvd: 148

as you see in the second answer are the A - records provided. Sometimes, they in some of subsequent queries the A records are provided trough knot but it isn’t stable

Well, that particular domain is broken in some respects: I tried several attempts (with clear cache) didn’t manage to reproduce a SERVFAIL with forwarding or without; maybe I’m just lucky or it might be related to the servers you forward to. In any case, I’m not particularly motivated to spend much time on domains that don’t follow basic RFCs.

Hi Vladimir,

thanks for your message. As Salesforce user, I don’t have possibility to correct it.
So currently the only one possible workaround to get it work, is to not to use knot for the name resolving.

As you heard, they are lot of business users of this software worldwide (small and big companies) of salesforce, you can also take a look at the company/software here:

Ok, you can leave the problem as is, but on mid/long term you will exclude all companies/private persons using Salesforce from usage of knot, reducing the popularity of such excellent software as knot is.
You can also reconsider you motivation.

unbound (1.7.3) is resolving any of those aforementioned (problematic) domains with no issues.

Well, this case has two aspects:

  • This domain is seriously broken.
  • Older resolvers decided to workaround all sorts of weird behavior.

As a result, Salesforce and other offenders are not motivated enough to fix their stuff. Knot Resolver is stricter than e.g. Unbound.

Luckily EDNS compliance report indicates that this domain will break at beginning of 2019 in all major resolvers, assuming Salesforce does not fix it before. As a result the incentive to fix their DNS will rise :smile:

If you want to avoid issues I suggest you to submit support request to Salesforce and request standards compliance for their DNS, possibly referencing to get more information.

1 Like

This seems strange and and curious in contrast that SF is not adhering to DNS standards…

In the DNS world, we have the unique situation that (resolver) operator feedback is largely absent. Only a few operators manifest themselves in the standardization community (Cloudflare, Comcast, Google, Salesforce being notably present).

Not sure whether the EDNS Compliance Tester is not flawed, at least in parts is seems troubled - particularly cookies (lots of timeouts)

But that is perhaps for another place to be discussed, just saying it might not be 100% reliable.

Hello @Snoki,

As Salesforce user, I don’t have a possibility to correct it.

Yes, you do. If you have the account there, you can reach their support or ask on social media like Twitter, Facebook, Reddit, but to be honest, sometimes it requires a lot of patience and of course time.

Anyway, as I don’t have registration on their website I tried to reach them first via Twitter (@salesforce), but after 2 weeks I received a response that I should write to @asksalesforce, which I did almost immediately once I received the response from @salesforce. The guy, whom I spoke, unfortunately, don’t understand what I want and in the end, he gave me the link for this website, which tells me to reach their support directly, which I will do this week.

In the meantime, when I was spoken to my colleague (@vcunat) he finds the email address for somebody, who is responsible for DNS in Salesforce. I wrote the email on 26/07/2018 and the same day I have received a response from her that they will look into this and that she will get back to me soon.
I requested the update on 7/08/2018, but I didn’t hear any response.

Also, I tried to reach Reddit moderators of subreddit Salesforce, but they didn’t even reply to me and I have asked them on 8th July. As I said my next step is to create the account and reach their support on their website and I’ll see how it goes. I’ll keep you updated.

I almost forget as my other colleague said 2 posts above of this post the domain will break at the beginning of 2019, so I hope that companies and also others will be more motivated to fix their DNS issues.

1 Like

@Pepe why is the TO team spending time/effort trying to sort DNS issues on a domain entirely unrelated to TO? Are there not more pressing issues pending with TO itself?