[SOLVED] [dyndns update] ipv6 only: Failed to resolve A for hostname.nohost.me

[alb1]

My YunoHost server

Hardware: LXC container, host is a NUC
YunoHost version: 4.2.8.3
I have access to my server : As root through lxc-attach
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : yes
If yes, please explain:

See bellow.

Description of my issue

Hello,

I use yunohost dyndns update in an ipv6 only environment.
I applied a fix to to update my ipv6 in Yunohost DNS resolvers, see this post: [SOLVED] [dyndns update] ipv6 only.
The fix works fine.

A minor issue is that I get spammed by the following crontab:

root@hostname:~# cat /etc/cron.d/yunohost-dyndns
SHELL=/bin/bash
*/10 * * * * root : YunoHost DynDNS update; sleep $((RANDOM\%60)); test -e /var/run/moulinette_yunohost.lock || yunohost dyndns update >> /dev/null

Indeed, in dyndns.py, the fix modified the definition of local function resolve_domain() in dyndns_update().
But this local function is called twice to dig my domain from Yunohost DNS resolvers:

    old_ipv4 = resolve_domain(domain, "A")
    old_ipv6 = resolve_domain(domain, "AAAA")

The second call raises no error as I already registered my ipv6.
The first call raises an error as there is no registered ipv4 for my domain in Yunohost DNS resolvers:

Error: Failed to resolve A for hostname.nohost.me

This error is raised by the following code at the end of function resolve_domain():

        raise YunohostError(
            "Failed to resolve %s for %s" % (rdtype, domain), raw_msg=True
        )

I believe this error is pertinent and should not be masked regarding the result of dig(dyn_host, "A").
According to me, there is no correlation between:

• “being able to dig Yunohost DNS resolver from ipv4”
• and “having no registered ipv4 in Yunohost DNS resolver”.

So, this annoys me because of my context, which is specific.

I patched my environment with a quick and dirty solution, in the crontab:

• in the call of yunohost dyndns update, I redirected stdout to /dev/null and stderr to stdout
• then I piped it into a grep to filter my error
• and I redirected stdout back to stderr so that I receive an email in case of an other error

root@hostname:~# cat /etc/cron.d/yunohost-dyndns
SHELL=/bin/bash
*/10 * * * * root : YunoHost DynDNS update; sleep $((RANDOM\%60)); test -e /var/run/moulinette_yunohost.lock || yunohost dyndns update 2>&1 1>/dev/null | grep -v 'Failed to resolve A for hostname.nohost.me' 1>&2

But I am not satisfied with this as I might have to apply this patch after every migration/upgrade.
So, the question I come up with is: “Is there a possibility to filter this error from within the moulinette?”

Thank you,

[Aleks]

eeeeeeh i think that you’re misinterpreting the issue here ? Even if you server has no IPv4 nor A record, it should still be able to call resolve_domain which in the case of your (non-existent) A record should return None

I think even if you swap the two lines old_ipv4 = and old_ipv6, you should see the issue happening also for the AAAA record…

Instead, I think what’s happening is that dyndns.yunohost.org / ns0.yunohost.org was down this morning … ? Can you confirm that you started to see this only today ? (The issue should be fixed now btw, and this behavior is to be improved in version 4.3.x)

[alb1]

Hello @Aleks,

Thank you for your answer.

eeeeeeh i think that you’re misinterpreting the issue here ?

It is highly possible, networking is not exactly my thing.

Instead, I think what’s happening is that dyndns.yunohost.org / > ns0.yunohost.org was down this morning … ? Can you confirm that you started to see this only today ?

I cannot confirm that I started to see this only today because I deleted the mails (I know…).

(The issue should be fixed now btw, and this behavior is to be improved in version 4.3.x)

Nevertheless, you are probably right as I do not observe the error anymore ; and if the issue you mentioned is now fixed, this would explain it.

Apologies for taking your time, this is my first attempt with ipv6 only and my install is still new.

Again, thank you.

@alb1

[Aleks]

Don’t worry, it’s nice to see somebody trying the challenge of running Yunohost in IPv6-only context so that we can slowly debug the whole thing