Most of the time, but not always, turris omnia fails to resolve new tlds like https://www.ilockit.bike
Chrome returns “DNS_PROBE_FINISHED_NXDOMAIN”
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 www.ilockit.bike 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 www.ilockit.bike
; <<>> DiG 9.11.2-P1 <<>> www.ilockit.bike
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62213
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.ilockit.bike. IN A
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu May 17 12:42:28 CEST 2018
;; MSG SIZE rcvd: 45eventually 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
/etc/config/network
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
2 Likes
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:
https://doc.turris.cz/doc/en/howto/dnsdebug
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.
Hi,
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...
Downloading https://repo.turris.cz/omnia/packages//turrispackages/resolver-debug_0.0.1-3_mvebu.ipk
1 Like
Oh, Indeed. Just hadt to hit the Button to update the list 
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 172.27.10.1):
PC:~ snoki$ dig cs83.salesforce.com @172.27.10.1
; <<>> DiG 9.10.6 <<>> cs83.salesforce.com @172.27.10.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63343
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cs83.salesforce.com. IN A
;; ANSWER SECTION:
cs83.salesforce.com. 240 IN CNAME cs83-frf.salesforce.com.
cs83-frf.salesforce.com. 240 IN CNAME cs83-frf.frf.r.salesforce.com.
;; Query time: 48 msec
;; SERVER: 172.27.10.1#53(172.27.10.1)
;; WHEN: Mon Jul 02 09:46:28 CEST 2018
;; MSG SIZE rcvd: 100
and resolving directly trough google dns is working
PC:~ snoki$ dig cs83.salesforce.com @8.8.8.8
; <<>> DiG 9.10.6 <<>> cs83.salesforce.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54281
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;cs83.salesforce.com. IN A
;; ANSWER SECTION:
cs83.salesforce.com. 299 IN CNAME cs83-frf.salesforce.com.
cs83-frf.salesforce.com. 299 IN CNAME cs83-frf.frf.r.salesforce.com.
**cs83-frf.frf.r.salesforce.com. 29 IN A 85.222.129.172**
**cs83-frf.frf.r.salesforce.com. 29 IN A 85.222.128.44**
**cs83-frf.frf.r.salesforce.com. 29 IN A 85.222.129.44**
;; Query time: 60 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; 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: http://dnsviz.net/d/cs83.salesforce.com/WznnEA/dnssec/ 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: https://en.wikipedia.org/wiki/Salesforce.com
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 https://ednscomp.isc.org/ednscomp/e3d275dff4 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 
If you want to avoid issues I suggest you to submit support request to Salesforce and request standards compliance for their DNS, possibly referencing https://dnsflagday.net/ 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?