dynDNS service down?

Is the service for dynDNS currently down? If I want to register a domain on the main page, the “dynDNS account” option is grayed out and only “Managed DNS account” is available. Also if I try to register a new dedyn.io domain from an existing account via the REST API following this scheme I found in another forum post:

curl -X POST https://desec.io/api/v1/domains/ \
    --header "Authorization: Token {token}" \
    --header "Content-Type: application/json" \
    --data '{"name": "example2.dedyn.io"}'

With that I only get the following error response:
{"name":["This domain name conflicts with an existing zone, or is disallowed by policy."]}%

On the registration page the following notice


It’s likely that we won’t be able to use new domains with dedyn.io with old accounts either.

We are waiting for the situation to develop

Hi,

Last week, we had thousands of account signups and domain registrations that caused various issues, (e.g. email queue, computationally intense re-signing of the dedyn.io domain every few seconds, and some temporary replication problems).

While we’re happy to make our operations support such numbers, we found that pretty much all of these registrations were not intended to be used with our security-focused DNS hosting service, and instead tried to register a free domain under dedyn.io and then change the NS records to move the domains to Cloudflare.

However, all these setups are invalid (because a child-side NS record change is only half the story; the parent-side NS and DS records would have to be changed, too). It is deSEC’s mission to provide fully automatic DNSSEC hosting. One aspect of this is that all domains under dedyn.io automatically get correct DS records on the parent side.

In other words, domains offered by deSEC are meant as an easy way to benefit from automated DNSSEC hosting, and the way they are set up is incompatible with using external nameservers (see: Does it support cloudflare? - #2 by peter).

First, existing domains continue to work.

Second, we are not planning to permanently suspend registration of dedyn.io domains. We’re planning to re-enable it after making some improvements (such as avoiding the above problems). However, we don’t have an ETA for this yet.

Stay secure,
Peter

3 Likes

Thanks for your answer!

Is this also the reason for the REFUSED error message while trying to renew a Let’s Encrypt wildcard certificate via DNS Challenge for an existing dedyn.io domain?

error message:

... last error: NS ns1.desec.io. returned REFUSED for _acme-challenge......

Best regards,
Patrick

@patrick

So no, probably a different issue.

Note: I have never used the DNS-01 challenge type or wildcard certificates with deSEC/Let’s Encrypt. So I can only take guesses.

Maybe your token is invalid/expired?

Or you are exceeding the Rate Limits?

HTH
fiwswe

1 Like

Do you think there’s a connection to Freenom leaving the domain market?

No. There’s a connection to YouTube videos from Asia, suggesting one could use dedyn names for setting up Cloudflare workers.

(One cannot, because this would require delegating the domain to Cloudflare, and we don’t do that. deSEC is not a full-fledged registry.)

Since this occurred, we’re still getting 20-30 support tickets every week from people trying to do that. Pretty annoying.

Stay secure,
Peter

2 Likes

That’s weird. Please contact support.

Stay secure,
Peter

1 Like

Hi patrick,

Have you found a solution to your problem?

I have a similar error message when I try to renew my wildcard certificate via traefik or lego.

The problem was that I had installed a * CNAME on my domain that pointed to my myfritz.net address. This worked perfectly for several years.

Recently traefik/lego checks such CNAME entries before it tries to create the TXT record _acme-challenge which is needed for the check. As far as I understand it, it tries to create the _acme-challenge entry at myfritz.net which led to the REFUSED in my case.

Solution was to deactivate the CNAME check in traefik/lego with the environment variable
LEGO_DISABLE_CNAME_SUPPORT=true

Maybe this will also help you.

1 Like

Has there been any developments since then? Lack of trustworthy and reliable subdomain registration service like desec.io is sorely missed.

Hi h9px732v,

Thanks for your message, and welcome to deSEC! :slight_smile:

We are planning to re-enable registrations under .dedyn.io at the end of this year or early next year.

With the re-enabled service, it will not be possible to change the domain’s NS records. Domains under .dedyn.io will be required to be hosted at deSEC.

(This was already the case previously. However, during the issue in the beginning of the year, most of the problematic registrations seemed to be attempting to mess with NS records – so we will block such changes, and are hoping to prevent the associated problems from returning.)

Stay secure,
Peter

3 Likes

Thank you Peter, that’s great news. Fingers crossed it will all work out okay.

Eagerly waiting for the dedyn.io to be available again. Do we have any date for this yet, Peter? I already have one for my nextcloud and want another for a self-hosted service. Would be good to have them on the same platform. Thank you.

Just in case it isn’t obvious: If you already have a domain at desec.io, managed or dynamic, you can use dynamic DNS with different subdomains of that for services that need different records. The updates don’t just work with names directly under dedyn.io.

Edit to expand on that: Let’s say your domain is example.dedyn.io, then you can use nextcloud.example.dedyn.io for your Nextcloud, pbx.example.dedyn.io for your phone system, minecraft.example.dedyn.io for your Minecraft server, and so on. This also has the advantage that you can get a wildcard certificate for *.example.dedyn.io and don’t have to get one certificate each for all your domain names.

1 Like

This worked for me, I created a CNAME in my existing domain as the services pointed to the same IP.

I guess the big benefit of dedyn.io was a 300 s TTL (5 minutes) – instead of dedyn.io’s hard 3600 s (1 hour). Also hope you’ll manage to bring back dedyn.io

That’s not correct:

  • Records set through our web interface or REST API have a minimum TTL of 3600s.
  • Records set through our dynDNS interface have a TTL of 60s.

Note that these rules apply regardless of whether the domain name is under dedyn.io or not. In other words, you can have 60s TTL on your A/AAAA records even with a custom domain, if you update them through the dynDNS interface.

(You mentioned 300s, but that TTL has no particular meaning at deSEC.)

We’re working on it, see resurrect dedyn.io registrations by peterthomassen · Pull Request #1014 · desec-io/desec-stack · GitHub.

Stay secure,
Peter

3 Likes

Ah, I can use that on my domains in desec.io then?! Wonderful

We’ve re-enabled registration of domains under .dedyn.io.

Stay secure,
Peter

6 Likes