DNS diagnosis for A record fails even though the records are OK

[kuba-orlik]

My YunoHost server

Hardware: VPS bought online
YunoHost version: 4.3.5
I have access to my server : Through SSH
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

Description of my issue

Recently whenever I add a new domain to Yunohost, the Diagnosis check reports an error with the A and AAAA records of the domain, if the domain settings were changed to point at my Yunohost server.

It looks like whatever method is being used to detect the DNS settings, it uses cached results.

It happens when there’s a difference in results for quering a domain with dig vs dig +trace. The +trace option queries from root servers down, takes a bit longer, but doesn’t have to wait for “propagation” to finish.

Due to Yunohost not using the equivalent of +trace, I have to wait for propagation to finish to e.g. set up the SSL cert via the GUI.

[wbk]

@kuba-orlik

Due to Yunohost not using the equivalent of +trace, I have to wait for propagation to finish to e.g. set up the SSL cert via the GUI.

It doesn’t solve the diagnosis problem, but when you already set up DNS, you can skip diagnosis for the certification request via the CLI :

$ sudo yunohost domain cert-install --force [domain]

Does that help?

[Aleks]

@wbk

$ sudo yunohost domain cert-install --force [domain]

Or rather --no-checks maybe ?

[wbk]

@Aleks

Or rather --no-checks maybe ?

My bad

[kuba-orlik]

I have been using the --no-checks option to work around this problem, yes. But it would be way more convenient if I didn’t have to log in via SSH and just do it in the GUI

[arkadi]

@wbk

m, but when you already set up DNS, you can skip diagnosis for the certification request

Yes! Could have something ask you, “would like you like to do it with ‘no checks’? Warning do not do this if you don’t understand what you’re doing. (or something equally ominous)”

[kuba-orlik]

Yes! It would make my life so much easier

Still, I believe a mor thorough solution would be for the DNS check to not use cache and just do the equivalent of dig +trace during diagnosis, to rule out false negatives in general

[Aleks]

(Theoretically that’s what it does, i dont remember the specifics, but it’s supposed to contact the authoritative server for the zone …)