Upcoming changes at deSEC / dedyn.io

[peterthomassen]

Steps To Reproduce

1. Wait until deSEC implements changes
2. Sign up with Nextcloud VM

Expected Result

Should work.

Actual Result

Won't work.

Screenshots, Videos, or Pastebins

No response

Additional Context

deSEC is currently facing significant abuse of registrations under dedyn.io, used primarily for phishing and infringing on other's intellectual property.

deSEC is therefore going to implement additional hurdles that users have to take before a dedyn.io registration goes live. We have not made up our mind yet about what exactly we'll do, but likely it will be one of the following:

• Account registration will yield a 403 HTTP status code (in case sign-up is temporarily disabled)
• Domain registration will yield a 403 HTTP status code (until the user has jumped through the extra hoop, which is to be determined)
• API requests will seem to work fine, but the domain will not be replicated onto production DNS servers immediately (until the user has jumped through the extra hoop, which is to be determined). In this case, we will make this situation queryable through the API.

This is to inform that changes along these lines are going to happen. We suggest to adapt Nextcloud VM code to cope with these situations in a smooth fashion (e.g. go back one step and offer different option to the user, or set up configuration in a way that can deal with asynchronous account/domain setup).

Build Version

current

Environment

By using the scripts

Environment Details

No response

[enoch85]

@peterthomassen Thanks for the heads up! This is bad news! :( This has now become one of our default options, and removing it would hurt. Part for the time invested, and part for the user experience which is much better now with this implemented - and working really well.

Best way for us would be if you could make it possible to register through API as it is right now, but including the extra hurdle in an automated manner. Help would be appreciated code wise to make it happen.

Let's work on this together. I'm willing to implement it if you point me in the right direction.

[peterthomassen]

Thanks. The abuse is indeed bad news, and I really dislike when such things start affecting others.

Sure, let's cooperate! :-) I'll get back to you once we know what we are going to do. (It may take a few days or weeks, depending on how the abuse develops; this was just an early heads-up.) @nils-wisiol

[enoch85]

@peterthomassen I'm almost afraid of asking, but did you make any progress on this?

[peterthomassen]

Not yet, but the abuse problem hasn't subsided. We are still torn about how to address it, so for now we're taking the pain of handling reports manually. But that's not a sustainable solution, and we will do something about it.

[enoch85]

I have no clue, but rather than making it harder to sign up, maybe implement automated reporting for abuse? That would make the code in the repo untouched, and all abuse would be handled automatically.

[nils-wisiol]

How would you handle the abuse automatically? We're worried about both under- and overblocking. We've already made human mistakes in both directions in the past and I currently do not see a way of how a machine could do better than our abuse team.

[peterthomassen]

For the moment, we've implemented a mitigation based on blocklists for IP address records set on domains under the suffix dedyn.io. This has helped significantly. For details, please check out this post: https://talk.desec.io/t/unable-to-add-azure-ip/593/2

For now it doesn't look like we'll have to introduce an additional step for users to take during setup. That is not to say that bad day won't ever come (i.e., we reserve the right to re-open this). But we're keeping our fingers crossed that it won't happen. :-)

[peterthomassen]

... perhaps let me add that for blocked IP address ranges, updating the IP address will fail.

I'm not sure if your code needs to be adapted to handle this. For reference, here's the code that tests these kinds of responses (--> you can use the assertion conditions there to detect that case):

• For updates via update.dedyn.io: https://github.com/desec-io/desec-stack/blob/9da9c0cddc6f9a7a2447e6d72a02f211039204f5/api/desecapi/tests/test_dyndns12update.py#L188-L190
• For the regular DNS api (https://desec.io/api/v1/): https://github.com/desec-io/desec-stack/blob/9da9c0cddc6f9a7a2447e6d72a02f211039204f5/api/desecapi/tests/test_rrsets.py#L1553-L1554

[enoch85]

GREAT news! I'm happy. :)

we've implemented a mitigation based on blocklists for IP address records set on domains under the suffix dedyn.io

If I understand the explanation correctly this is something that you manually maintain? I mean there are a lot of block lists out there already (look at Pi-Hole) they are updated quite frequently. Wouldn't that be a better solution? I don't know at all, just guessing here. :)

Also, do you block the origin IP? I.e if someone with a bad origin IP tries to create an account (or domain?), it will be blocked? Or is it on a domain level? I didn't fully grasp that one...

I'm not sure if your code needs to be adapted to handle this.

We'll see, but probably not since all our users are Home or SME users who deploy on their own servers. If the IP is blocked, well - bad luck - there's probably a reason for it. :)

[peterthomassen]

For details, please check out this post: https://talk.desec.io/t/unable-to-add-azure-ip/593/2