Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

resurrect dedyn.io registrations #1014

Merged
merged 10 commits into from
Feb 5, 2025
Merged

Conversation

peterthomassen
Copy link
Member

No description provided.

@peterthomassen peterthomassen force-pushed the 20250125_resurrect-dedyn branch 2 times, most recently from e60918c to 362a348 Compare January 27, 2025 19:13
@peterthomassen peterthomassen marked this pull request as ready for review January 27, 2025 19:36
@peterthomassen
Copy link
Member Author

After this is deployed, the plan is to send out messages like the following (with bullet points included as appropriate):

Dear deSEC user,

We have noticed that you have modified the NS records of your dedyn.io domain(s) in a way that is technically not meaningful. The modifications are not compatible with the automatic DNSSEC services that we provide, in line with our mission to improve Internet security.

You might have changed these records with the intention to delegate your domain(s) to a different DNS operator. However, domains under dedyn.io cannot be moved to a different operator. This is because each domain is tied to deSEC's cryptographic keys, which means that DNS responses from another operator are invalid, leading to DNS resolution failures.

To remediate the situation, we will implement the following changes:

- Starting immediately, it is no longer possible to modify NS records for
  domains under dedyn.io.

- The main NS records of the following domains have been replaced completely,
  and they don't contain any deSEC nameservers anymore. As a result, they are
  dysfunctional:

    * <masked>.dedyn.io:
        igor.ns.cloudflare.com.
        kinsley.ns.cloudflare.com.

    * <masked>.dedyn.io:
        henrik.ns.cloudflare.com.
        kia.ns.cloudflare.com.

    * <masked>.dedyn.io:
        bethany.ns.cloudflare.com.
        sullivan.ns.cloudflare.com.

  The above domain(s) will be deleted during the week of February 10, 2025.
  If your account does not contain any other domains at this time, we will
  delete your account as well.

- The NS records of the following domains have been modified such that they
  contain some deSEC nameserver(s), but also some other nameserver(s):

    * <masked>.dedyn.io:
        ns1.desec.io.
        ns1.desec.org.  (unofficial)

  During the week of February 10, 2025, we will replace these NS records with
  our standard NS records (ns1.desec.io and ns2.desec.org).

Thank you for your understanding! If you have any questions, please let us know.

You are welcome to use deSEC in the future. However, please note that deSEC does not support third-party DNS operators for domains under dedyn.io; we will make no exceptions. To use another operator, please register a domain name elsewhere.

dependabot bot and others added 3 commits January 30, 2025 00:50
Updates the requirements on [django](https://github.com/django/django) to permit the latest version.
- [Commits](django/django@5.1.4...5.1.5)

---
updated-dependencies:
- dependency-name: django
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
Updates the requirements on [psycopg[binary]](https://github.com/psycopg/psycopg) to permit the latest version.
- [Changelog](https://github.com/psycopg/psycopg/blob/master/docs/news.rst)
- [Commits](psycopg/psycopg@3.2.3...3.2.4)

---
updated-dependencies:
- dependency-name: psycopg[binary]
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
@peterthomassen peterthomassen force-pushed the 20250125_resurrect-dedyn branch 2 times, most recently from 457d9f6 to e6cba2b Compare February 4, 2025 15:15
Copy link
Contributor

@nils-wisiol nils-wisiol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some concerns around policy. Nits on code style.

api/desecapi/tests/base.py Outdated Show resolved Hide resolved
api/desecapi/tests/test_rrsets.py Show resolved Hide resolved
api/desecapi/tests/test_rrsets.py Show resolved Hide resolved
api/desecapi/serializers/records.py Show resolved Hide resolved
api/desecapi/views/records.py Show resolved Hide resolved
api/desecapi/tests/test_rrsets.py Show resolved Hide resolved
@peterthomassen
Copy link
Member Author

I've addressed all comments, except one (pls continue conversation).

Would also be interested in your opinion on #1014 (comment) (including "no opinion").

@nils-wisiol
Copy link
Contributor

For the email you propose - I'm afraid it will take a while to craft the emails and it might generate a bulk of support workload. I was going to propose to silently remove or fix these but Sec. 4 of the Terms mentions there "may be" a removal warning.

If you share my concern, I think fixing without warning is an acceptable way forward. I don't think we need to support dysfunctional (or slow) resolution of certain names. Removing without warning is also a possibility but perhaps a bit of a stretch of the terms (which could be clarified in this regard).

If you do not share the concern (or think the benefits outweigh), my only comment on the text is that I believe most users that are affected aren't well-trained in DNS things. To ease their understanding, I'd suggest to simplify the language and shorten it.

Previously, the serializer would fall back to the default empty subname.
On non-apex records, this resulted in an attempt to change the subname
value, which previously was rejected (with a different error). For apex
names, the operation would continue (because the default subname would
mean no change).
This reverts commit 477b6c8.

Deployment should be accompanied by a corresponding change in the
DESECSTACK_API_REGISTER_LPS variable in the Docker environment.
@peterthomassen peterthomassen force-pushed the 20250125_resurrect-dedyn branch from 2e63541 to 64c7f77 Compare February 5, 2025 14:20
@peterthomassen
Copy link
Member Author

For the email you propose - I'm afraid it will take a while to craft the emails

I already have a script for that, which works off a database query CSV output.

and it might generate a bulk of support workload.

I'm prepared to take that :)

If you share my concern, I think fixing without warning is an acceptable way forward.

Ack

Removing without warning is also a possibility but perhaps a bit of a stretch of the terms (which could be clarified in this regard).

I'd rather not do apply that retroactively.

If you do not share the concern (or think the benefits outweigh), my only comment on the text is that I believe most users that are affected aren't well-trained in DNS things. To ease their understanding, I'd suggest to simplify the language and shorten it.

I'll try, but if I don't have good ideas I'll leave (nearly) as is. I'll add a link to the forum so people can gather there and don' have to repeat their questions.

@peterthomassen
Copy link
Member Author

(the push was just an autosquash)

@peterthomassen peterthomassen merged commit 64c7f77 into main Feb 5, 2025
5 checks passed
@peterthomassen peterthomassen deleted the 20250125_resurrect-dedyn branch February 5, 2025 14:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants