Add IPv64.net Domains - DynDNS Service

[dschroed3387]

Public Suffix List (PSL) Pull Request (PR) Template

Each PSL PR needs to have a description, rationale, indication of DNS validation and syntax checking, as well as a number of acknowledgements from the submitter. This template must be included with each PR, and the submitting party MUST provide responses to all of the elements in order to be considered.

Checklist of required steps

• Description of Organization

• Robust Reason for PSL Inclusion

• DNS verification via dig

• Run Syntax Checker (make test)

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _PSL txt record in place in the respective zone(s) in the affected section

Submitter affirms the following:

• We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)

• This request was not submitted with the objective of working around other third-party limits

• The Guidelines were carefully read and understood, and this request conforms
• The submission follows the guidelines on formatting and sorting

---

For Private section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

• Yes, I understand. I could break my organization's website cookies etc. and the rollback timing, etc is acceptable. Proceed.

---

Description of Organization

IPv64.net mainly offers a DynDNS service with multiple domains. The DynDNS service is adapted so that many end systems can communicate with the Dyn service without any problems. Furthermore the Healthcheck functionality is offered with additional integrations for notifications.

Organization Website: https://ipv64.net

Reason for PSL Inclusion

The main reason for this request: Let's Encrypt
Restricting cookie setting
Restricting the setting of the document.domain property
Domain highlighting in the URL bar

Number of users this request is being made to serve:

At the moment there are about 4000 users registered with over 5000 DynDNS subdomains. Number strongly increasing.

DNS Verification via dig

dig +short TXT _psl.ipv64.net
"#1687"
dig +short TXT _psl.ipv64.de
"#1687"
dig +short TXT _psl.any64.de
"#1687"
dig +short TXT _psl.eth64.de
"#1687"
dig +short TXT _psl.home64.de
"#1687"
dig +short TXT _psl.iot64.de
"#1687"
dig +short TXT _psl.lan64.de
"#1687"
dig +short TXT _psl.nas64.de
"#1687"
dig +short TXT _psl.srv64.de
"#1687"
dig +short TXT _psl.tcp64.de
"#1687"
dig +short TXT _psl.udp64.de
"#1687"
dig +short TXT _psl.vpn64.de
"#1687"
dig +short TXT _psl.wan64.de
"#1687"
dig +short TXT _psl.root64.de
"#1687"
dig +short TXT _psl.dns64.de
"#1687"
dig +short TXT _psl.route64.de
"#1687"
dig +short TXT _psl.dyndns64.de
"#1687"
dig +short TXT _psl.api64.de
"#1687"
dig +short TXT _psl.dynipv6.de
"#1687"

Results of Syntax Checker (make test)

PASS: libpsl_icu_load_dafsa_fuzzer
PASS: libpsl_icu_fuzzer
PASS: libpsl_icu_load_fuzzer

Testsuite summary for libpsl 0.21.2

TOTAL: 3

PASS: 3

SKIP: 0

XFAIL: 0

FAIL: 0

XPASS: 0

ERROR: 0

============================================================================
Making check in tests
CC test-is-public.o
CC test-is-public-all.o
CC test-is-cookie-domain-acceptable.o
CC test-is-public-builtin.o
CC test-registrable-domain.o
CCLD test-is-public
CCLD test-is-public-all
CCLD test-is-cookie-domain-acceptable
CCLD test-is-public-builtin
CCLD test-registrable-domain
PASS: test-is-public
PASS: test-is-public-builtin
PASS: test-is-cookie-domain-acceptable
PASS: test-registrable-domain
PASS: test-is-public-all

Testsuite summary for libpsl 0.21.2

TOTAL: 5

PASS: 5

SKIP: 0

XFAIL: 0

FAIL: 0

XPASS: 0

ERROR: 0

============================================================================
Making check in msvc

[jonasled]

Result from make test:

============================================================================
Testsuite summary for libpsl 0.21.2
============================================================================
# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

[dschroed3387]

Is there anything else that needs to be done from my side? Do I still have to deliver something? Thanks a lot

[otbutz]

@dschroed3387 you can meanwhile opt-in for higher LE limits directly: https://forms.gle/JVKTgfMYUm7dLjfq5 (source: https://letsencrypt.org/docs/rate-limits/)

Adding the domains to the public suffix list is still important to ensure proper cookie isolation, etc.

[simon-friedberger]

Since the main reason for this request is given as letsencrypt and that is dealt with above I am closing this.

[otbutz]

@simon-friedberger ipv64.net is a public dnydns provider. Bypassing LetsEncrypt limits is one thing, but cookie restrictions and domain highlighting in browsers are certainly still valid reasons to add the domain.

[simon-friedberger]

Please update the description!

[otbutz]

Description of Organization

IPv64.net mainly offers a DynDNS service with multiple domains. [...]

[simon-friedberger]

I am saying your comment should be part of the description.

The main reason for this request: Let's Encrypt

If cookie separation and url highlighting are desired. They should be listed there.

[otbutz]

@dschroed3387 Could you update the description? The addition to the public suffix list is important IMHO because of the additional security provided by browser vendors for dyndns domains. e.g:

• Restricting cookie setting
• Restricting the setting of the document.domain property
• Domain highlighting in the URL bar

[dschroed3387]

@dschroed3387 Could you update the description? The addition to the public suffix list is important IMHO because of the additional security provided by browser vendors for dyndns domains. e.g:

• Restricting cookie setting
• Restricting the setting of the document.domain property
• Domain highlighting in the URL bar

I have added this to the description.
I have also added 6 new domains to the long domain list.

Thank you for your support.

[simon-friedberger]

Our usual bar for inclusion is at least 1000 active domains. Since this request is being made at only 4k but for 13 domains some additional justification for why this is useful would be great.

[bt90]

According to the stats we're talking about 23k subdomains:

https://ipv64.net/

https://crt.sh/?q=ipv64.net&exclude=expired&group=none

[androidseb25]

Our usual bar for inclusion is at least 1000 active domains. Since this request is being made at only 4k but for 13 domains some additional justification for why this is useful would be great.

with the 6 domains he mean that he saved 6 more domains that a user can choose for a dyndns domain

[simon-friedberger]

with the 6 domains he mean that he saved 6 more domains that a user can choose for a dyndns domain

What I meant is, that it would be easier to get this merged with fewer domains. The goal is to keep the size of the list down by only allowing requests that affect many users. Adding more domains reduces the relative utility of each.

[androidseb25]

...fewer domains...

Did you say this words also to amazonaws, they have hundrets of domains in the list?
I think 19 additional domains didn't increase the size of the list to much...

But hey, I'm not the guy who gets so many requests to add these domains to the list in the future :)

[dschroed3387]

I have sorted the list now. Many Thanks, what can i do next ?

[simon-friedberger]

This is my usual checklist. Getting the expiration dates is not always possible. It seems DENIC does not provide them anymore.

• Expiration (Note: Must STAY >2y at all times)
  • ipv64.net expires 2024-10-09
• DNS _psl entries
  • missing for api64.de, dns64.de, ...
• Tests pass
• Sorting
• Reasoning/Organization description

[simon-friedberger]

@dschroed3387 Do you still want this?