Dyndns with nohost.me not working anymore?

lars · January 6, 2018, 5:32pm

Okay, zeroing in on the problem. I think I messed up the configuration by trying to connect to the Pi through another domain. Here is what’s happened:
I did rm /etc/yunohost/dyndns/old_ip
Then I tried to update the dyndns with yunohost dyndns update --verbose
This is the outcome:

Summary

Updated needed, going on…
Now pushing new conf to DynDNS host…
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;mycloud.bz. IN SOA

;; UPDATE SECTION:
_xmpp-client._tcp.klimek.mycloud.bz. 0 ANY ANY
_xmpp-server._tcp.klimek.mycloud.bz. 0 ANY ANY
muc.klimek.mycloud.bz. 0 ANY ANY
pubsub.klimek.mycloud.bz. 0 ANY ANY
vjud.klimek.mycloud.bz. 0 ANY ANY
klimek.mycloud.bz. 0 ANY ANY
klimek.mycloud.bz. 0 ANY ANY
mail._domainkey.klimek.mycloud.bz. 0 ANY ANY
_dmarc.klimek.mycloud.bz. 0 ANY ANY
klimek.mycloud.bz. 0 ANY ANY
*.klimek.mycloud.bz. 0 ANY ANY
klimek.mycloud.bz. 0 ANY ANY
*.klimek.mycloud.bz. 0 ANY ANY
_xmpp-client._tcp.klimek.mycloud.bz. 3600 IN SRV 0 5 5222 klimek.mycloud.bz.
_xmpp-server._tcp.klimek.mycloud.bz. 3600 IN SRV 0 5 5269 klimek.mycloud.bz.
muc.klimek.mycloud.bz. 3600 IN CNAME klimek.mycloud.bz.
pubsub.klimek.mycloud.bz. 3600 IN CNAME klimek.mycloud.bz.
vjud.klimek.mycloud.bz. 3600 IN CNAME klimek.mycloud.bz.
klimek.mycloud.bz. 3600 IN MX 10 klimek.mycloud.bz.
klimek.mycloud.bz. 3600 IN TXT "v=spf1 a mx ip4:89.246.28.112 ip6:2001:16b8:22c:4800:f754:5f3b:e745:84bc -all"
mail._domainkey.klimek.mycloud.bz. 3600 IN TXT “v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCf2bHdUFmXRMQ4/2ZWYDPFVSojOkVd/7ZYWSa2meIJ3Fc3ksmLmt5MUi47VpCiL+0GtrI2AYjkCE8hF43MJEvaaq9xDbR3egAZZAwWCeV/ban7xp7kROzy1xMihtTWxS9j2Amc8MUxRSXjC/Yf9WFTmvDzHjES0aEIMFQcyAj+6wIDAQAB”
_dmarc.klimek.mycloud.bz. 3600 IN TXT "v=DMARC1; p=none"
klimek.mycloud.bz. 3600 IN A 89.246.28.112
*.klimek.mycloud.bz. 3600 IN A 89.246.28.112
klimek.mycloud.bz. 3600 IN AAAA 2001:16b8:22c:4800:f754:5f3b:e745:84bc
*.klimek.mycloud.bz. 3600 IN AAAA 2001:16b8:22c:4800:f754:5f3b:e745:84bc

; TSIG error with server: tsig indicates error
update failed: NOTAUTH(BADKEY)
Error: Unable to update IP address on DynDNS

But klimek.noho.st is still working at the moment. Maybe you can detect the problem here.

lars · January 11, 2018, 6:57pm

Can you point me somewhere I can look for the standard DNS configuration of my Yunohost instance?

Aleks · January 11, 2018, 7:06pm

Eh, you mean the recommended DNS conf ?

It’s available through :

the webadmin in Domains > your.domain.tld > DNS configuration
the CLI, with yunohost domain dns-conf your.domain.tld

lars · January 11, 2018, 7:24pm

The problem is that if I do yunohost dyndns update --verbose I get all those references to another domain that I tried to point to Yunohost and Yunohost tells me that it is unable to update IP address on DynDNS. If I do yunohost dyndns update -d klimek.noho.st --verbose that IP is actually updated. But I do this every day by hand which can’t be the solution. So I want to erase whatever entry there is that points yunohost dyndns update --verbose to the other Domain. Is it clear what I mean?

Aleks · January 11, 2018, 7:26pm

Hmokay, so, what’s the output of this command ?

ls -l /etc/yunohost/dyndns/

lars · January 11, 2018, 7:29pm

total 20
-rw------- 1 root root 59 Jan 2 10:17 Kklimek.mycloud.bz.+157+03954.key
-rw------- 1 root root 165 Jan 2 10:17 Kklimek.mycloud.bz.+157+03954.private
-rw------- 1 root root 56 Nov 12 18:43 Kklimek.noho.st.+157+26362.key
-rw------- 1 root root 165 Nov 12 18:43 Kklimek.noho.st.+157+26362.private
-rw-r–r-- 1 root root 1726 Jan 11 19:26 zone

That might be the problem. Should I delete the keys pointing to the other domain?

Aleks · January 11, 2018, 7:33pm

Yes, I think so. Not sure how you ended up in that state

To do so, you can do rm /etc/yunohost/dyndns/Kklimek.mycloud.bz.*

lars · January 11, 2018, 7:36pm

Thank you. I will see if that did the trick.
Well, I tried to fix the IPv6 issue without knowing about that and that it was a problem on your end and not mine. I found that solution in some thread and since the noho.st domain wasn’t working I tried to make the Pi accessible through the other domain, which did not work for some reason I have yet to find out. But that is another issue to be solved in the future.
Thank you again for now for your quick help!