Remove inactive or expired yombo domains

[groundcat]

This PR is to remove ybo.faith, homelink.one, ybo.party, ybo.review, ybo.science, and ybo.trade due to evidence suggesting domain inactivity.

General Evidence (applies to all domains):

• Attempts to contact via email ([email protected]) were unsuccessful – no MX record at yombo.net. No mail servers found.
• The organization website (https://yombo.net) is no longer functioning and now points to a stationary print business.
• Unable to identify any email address. @yombo.net has no MX.

As identified in #2172:

ybo.faith TIMEOUT
ybo.party TIMEOUT
ybo.review SERVFAIL
ybo.science TIMEOUT
ybo.trade TIMEOUT

Domain-Specific Checks:

---

1. ybo.faith

• The Google search and Bing search show no results for the domain.
• Certificate Transparency reveals no active SSL certificates in use.
• Running dig +short TXT _psl.ybo.faith no longer returns the required record value. Not required at the time.
• No subdomains were found by third-party tools [1] [2].

---

2. homelink.one

• WHOIS Creation Date: 2021-12-10T19:56:27Z > PSL inclusion (pre-GitHub). The WHOIS creation dates for the domains are later than the PSL inclusion dates, suggesting the domains were likely allowed to expire.
• The Google search and Bing search show 1 results for the domain.
  • Led to This domain is available for sale! page.
• Certificate Transparency reveals no active SSL certificates in use.
• Running dig +short TXT _psl.homelink.one no longer returns the required record value. Not required at the time.
• No subdomains were found by third-party tools [1] [2].

---

3. ybo.party

• The Google search and Bing search show no results for the domain.
• Certificate Transparency reveals no active SSL certificates in use.
• Running dig +short TXT _psl.ybo.party no longer returns the required record value. Not required at the time.
• No subdomains were found by third-party tools [1] [2].

---

4. ybo.review

• The Google search and Bing search show no results for the domain.
• Certificate Transparency reveals no active SSL certificates in use.
• Running dig +short TXT _psl.ybo.review no longer returns the required record value. Not required at the time.
• No subdomains were found by third-party tools [1] [2].

---

5. ybo.science

• The Google search and Bing search show no results for the domain.
• Certificate Transparency reveals no active SSL certificates in use.
• Running dig +short TXT _psl.ybo.science no longer returns the required record value. Not required at the time.
• No subdomains were found by third-party tools [1] [2].

---

6. ybo.trade

• The Google search and Bing search show no results for the domain.
• Certificate Transparency reveals no active SSL certificates in use.
• Running dig +short TXT _psl.ybo.trade no longer returns the required record value. Not required at the time.
• No subdomains were found by third-party tools [1] [2].

---

7. yombo.me to be revisited

• The Google search and Bing search show 1 result (a DDNS homepage) for the domain but no subdomain.
• Certificate Transparency reveals few active SSL certificates in use.
• Running dig +short TXT _psl.yombo.me still returns the required record value along with a note "reserved for upcoming projects"
• For this PR, keeping this entry just in case, but I will revisit after November to check for CT again. Likely this should be removed too by that time.

[danderson]

I don't have approval powers, but this matches what I saw as part of implementing TXT record validation, and brief digging to figure out if my code was wrong or if these suffixes were in fact dead. 👍

[simon-friedberger]

yombo.net redirects to cubefinds which seems to be run by the same Mitch Schwenk. Maybe it's worth trying to contact somebody there.

yombo.me says it is still running a DNS service just not accepting users. Which leads me to my next question: If somebody is running a local gameserver or voip server on johndoe.ybo.party or just using that to SSH into a local machine, would your checks find that?
This boils down to two issues:

1. Are we checking if DNS for the domain still works?
2. Does the fact that DNS doesn't work for ybo.party imply that it doesn't work for johndoe.ybo.party?

I think the answer for (2.) might technically be "no" but I'm not sure and I'm not sure if that actually ever happens in practice.

[groundcat]

yombo.net redirects to cubefinds which seems to be run by the same Mitch Schwenk. Maybe it's worth trying to contact somebody there.

The whois record for yombo.me shows a creation date of 2023-11-30, which is years after its inclusion in the PSL, so the current holder might not be the original requestor. However, I also noticed that it displays a landing page that claimed to be a DDNS service, and as you mentioned, it is difficult to detect any usage that does not involve web browsing (such as SSH tunnels, game servers, TV consoles, etc. that do not serve web pages or use SSL certificates). To be cautious, I did not remove this domain in this PR. It is possible that the domain was allowed to expire and has since changed hands, and considering that all reliable means (email, website) to contact the original requestor are no longer available, perhaps it should be removed as well?

Does the fact that DNS doesn't work for ybo.party imply that it doesn't work for johndoe.ybo.party?

I think so, if DNS resolution for the primary domain ybo.party results in NXDOMAIN, this generally implies that DNS will also fail for any subdomain under it, such as johndoe.ybo.party because as far as I know DNS relies on the hierarchical structure. If the authoritative DNS servers cannot find a record for the main domain (ybo.party), then they are not able to resolve subdomains like sub.ybo.party

Testing ybo.party with https://www.nslookup.io/domains/ybo.party/dns-records/#authoritative shows:

None of the authoritative DNS servers are available

However, an exception could occur in cases like Internal vs. Public DNS. For instance, DN42 operates within an isolated network context. The fact that a domain is unavailable or returns NXDOMAIN in the public DNS does not necessarily mean the same within the DN42 DNS system, but I think this is not within the scope of PSL since it would involve an alternative DNS system. From the guideline:

We do not accept entries with TLDs that fall into 'Alternative' naming systems. ICANN's Office of the CTO has published [OCTO 034 Challenges with Alternative Name Systems](https://www.icann.org/en/system/files/files/octo-034-27apr22-en.pdf) which explains the variety of different systems and approaches, as well as the hazards. This 'nope' rule is here to allow discussion and energy that develop around this topic to happen elsewhere.

[simon-friedberger]

(Note: I accidentally edited your comment before.)

because as far as I know DNS relies on the hierarchical structure. If the authoritative DNS servers cannot find a record for the main domain (ybo.party), then they are not able to resolve subdomains like sub.ybo.party

Testing ybo.party with https://www.nslookup.io/domains/ybo.party/dns-records/#authoritative shows:

None of the authoritative DNS servers are available

So, can I not have records delegating subdomains to different servers.
In pseudo-code something like:
example.org. 86400 NS ns1.example.org.
sub.example.org. 86400 NS ns2.example.org.

My reading of https://www.rfc-editor.org/rfc/rfc1034#section-5.3.3 is that this should work. On the other hand, I'm not sure how that would interact with query minimization (https://datatracker.ietf.org/doc/html/rfc9156).

[groundcat]

So, can I not have records delegating subdomains to different servers.
In pseudo-code something like:
example.org. 86400 NS ns1.example.org.
sub.example.org. 86400 NS ns2.example.org.

Oh, I see what you mean. Yes, I think the pseudo-code scenario you described should work. foo.bar.example.com and bar.example.com can have different nameservers, and it should work without issues when both sets of nameservers are running properly.

It's probably a dumb way to figure it out😂, but to try to replicate something similar in practice, I spent $1 and got the domain publicsuffix.buzz to experiment on:

The experiment

1. Third-level's impact on fourth-level - Scenario when bad.publicsuffix.buzz is a non-resolving PSL entry and returns SERVFAIL but good.bad.publicsuffix.buzz resolves:

To start, I used the registrar's default (and working) nameservers for the second-level domain publicsuffix.buzz. At the zone for publicsuffix.buzz., I added a pair of intentionally invalid nameservers (invalid-ns1.example.org. and invalid-ns2.example.org.) at the third-level domain bad.publicsuffix.buzz. to ensure the third level would return SERVFAIL. As expected, the third level now returns SERVFAIL.

This would be something look like:

$ORIGIN publicsuffix.buzz.
bad     IN  NS  invalid-ns1.example.org.
bad     IN  NS  invalid-ns2.example.org.

This example tries to replicate a scenario where bad.publicsuffix.buzz is a Public Suffix List entry, and volunteers discover that the nameserver is not working.

$ dig NS bad.publicsuffix.buzz

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> NS bad.publicsuffix.buzz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54392
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; Query time: 1329 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)

Then, at the second-level zone of publicsuffix.buzz., I also added a pair of functioning nameservers (ns5.private-nameserver.net. and ns6.private-nameserver.net.) for the fourth-level domain good.bad.publicsuffix.buzz. These nameservers are different from those at the second and third levels.

This would be something look like:

$ORIGIN publicsuffix.buzz.
good.bad   IN  NS  ns5.private-nameserver.net.
good.bad   IN  NS  ns6.private-nameserver.net.

As expected, it resolves without issue (NOERROR returned):

$ dig NS good.bad.publicsuffix.buzz

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> NS good.bad.publicsuffix.buzz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10145
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

And, of course, if there is a client's website running at good.bad.publicsuffix.buzz, it should work fine (the A record resolves as well):

$ORIGIN good.bad.publicsuffix.buzz.
@     IN  A  192.0.2.1

$ dig A good.bad.publicsuffix.buzz

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> A good.bad.publicsuffix.buzz
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58461
;; ANSWER SECTION:
good.bad.publicsuffix.buzz. 3260 IN     A 192.0.2.1

So, in cases where bad.publicsuffix.buzz is not resolving and returns SERVFAIL, it does not mean that the fourth-level domain like good.bad.publicsuffix.buzz will also fail. As long as the nameservers at publicsuffix.buzz are functioning AND their zone file contains the correct records for good.bad.publicsuffix.buzz, it should work.

2. Second-level's impact on third-level - Scenario when foo.publicsuffix.buzz or publicsuffix.buzz is a non-resolving PSL entry and returns NXDOMAIN:

To reproduce an NXDOMAIN error for a domain (assuming publicsuffix.buzz is a PSL entry under review), I set the nameservers of publicsuffix.buzz to a pair of intentionally non-existent nameservers:

$ORIGIN buzz.
publicsuffix   IN  NS  invalid-ns1.example.test.
publicsuffix   IN  NS  invalid-ns2.example.test.

$ORIGIN buzz.
foo.publicsuffix   IN  A  192.0.2.1  ; glue record

Even though I set a glue record at the registry level (directly in the buzz. zone) for the third-level domain foo.publicsuffix.buzz and pointed it to an IPv4 address, running dig A foo.publicsuffix.buzz returned SERVFAIL. It appears that publicsuffix.buzz still requires functioning authoratative nameservers to resolve any subdomains at the third or fourth levels.

Query against 8.8.8.8:

$ dig A foo.publicsuffix.buzz @8.8.8.8

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19715
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Thus, in this experiment, if publicsuffix.buzz is found to be NXDOMAIN, it is safe to assume foo.publicsuffix.buzz will not resolve either, even if a glue record exists at the buzz registry level. The registry server tends to query the authoritative nameservers (which are not functioning in this case):

Query against ns1.dns.nic.buzz:

$ dig A foo.publicsuffix.buzz @ns1.dns.nic.buzz

; <<>> DiG 9.18.27 <<>> A foo.publicsuffix.buzz @ns1.dns.nic.buzz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17446
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.publicsuffix.buzz.         IN      A

;; AUTHORITY SECTION:
publicsuffix.buzz.      3600    IN      NS      invalid-ns1.example.test.
publicsuffix.buzz.      3600    IN      NS      invalid-ns2.example.test.

It could also be that the glue record was not successfully added to the registry's zone:

$ dig A foo.publicsuffix.buzz +trace

; <<>> DiG 9.18.27 <<>> A foo.publicsuffix.buzz +trace
;; global options: +cmd
.                       87203   IN      NS      c.root-servers.net.
.                       87203   IN      NS      b.root-servers.net.
.                       87203   IN      NS      j.root-servers.net.
.                       87203   IN      NS      k.root-servers.net.
.                       87203   IN      NS      f.root-servers.net.
.                       87203   IN      NS      a.root-servers.net.
.                       87203   IN      NS      l.root-servers.net.
.                       87203   IN      NS      i.root-servers.net.
.                       87203   IN      NS      h.root-servers.net.
.                       87203   IN      NS      d.root-servers.net.
.                       87203   IN      NS      m.root-servers.net.
.                       87203   IN      NS      g.root-servers.net.
.                       87203   IN      NS      e.root-servers.net.
.                       87203   IN      RRSIG   NS 8 0 518400 20241015210000 20241002200000 61050 . k1usKmpL0lfxPVMOOwr3e6gzP1DTWU6EbHK2dTYiluoH4CIr+ubmv59B QHJwbxrHrTWCrAiiUdRaILzJFA5E3eSuGG54RtI5xzmR9s9VdA0k+Rko Tup3pv7WVPyX1FJGXqqkDL95LFLlfv1BBqIZzqmBcSPht3SfQmJTWtRT euY5HkIGnZBa1xhTMP5XF5516XKgKa2Uey2R/Dc6W8m76MfliClqcXLK LruUAYe6jtgaHiWMswDh5T3BGxH1TZ5VPjCNkpeu967hDvf+YILAv+/2 inr3LvfYRUwg1PmfMWfQvdhEWHKusquQr1Vf9MFVMXKjqInzv33h+rT+ b38iWw==
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 1 ms

buzz.                   172800  IN      NS      c.nic.buzz.
buzz.                   172800  IN      NS      ns2.dns.nic.buzz.
buzz.                   172800  IN      NS      a.nic.buzz.
buzz.                   172800  IN      NS      ns3.dns.nic.buzz.
buzz.                   172800  IN      NS      b.nic.buzz.
buzz.                   172800  IN      NS      ns1.dns.nic.buzz.
buzz.                   86400   IN      DS      60340 8 2 FBA59E35952704AE0656BC122AEC20528C8D49600E314E8BDF0AE00C E8C336B7
buzz.                   86400   IN      RRSIG   DS 8 1 86400 20241015210000 20241002200000 61050 . se16Q1GyIJ41TNjxQtPvqdw+rUNNys10xS1FUA6tw6J/qnqrrvhLwdXh 4iYteYWUbQ//TzMYF7NRQ3Tbjc/g4ouTHSBDAOY3+CQ1GK+jherUoZms I8Ew8WpkD4MbdRA6aaSTf09FWnLmj/e3TRQbloLbQQQUZLzSMxO9fNAG 0MdQd7P+eXM3R6FWbMMNWNdTCbbxzSKyWblLvAoK7aKzxmfwFFYBcuNI In3sr4yPFMNhx7MrxbtLaeR9S7Ub8RYSOjC6weTMMnqm6GaqZ407fXEJ rJxt3c1chXJnALZLme11uc0Al4/yWrTUPTXVCGmtAZ1VffGWaR55/p+6 C4RXMQ==
;; Received 759 bytes from 198.41.0.4#53(a.root-servers.net) in 16 ms

publicsuffix.buzz.      3600    IN      NS      invalid-ns1.example.test.
publicsuffix.buzz.      3600    IN      NS      invalid-ns2.example.test.
pcglc2oj7fv61c90up3ehtq34n1ktkbr.buzz. 900 IN NSEC3 1 1 0 - PCNV8CT2D4KOBPT9N68LVA1Q0HG9F62T NS SOA RRSIG DNSKEY NSEC3PARAM
1iasbm6gpka9m66s5hr4hmo1u9liunpq.buzz. 900 IN NSEC3 1 1 0 - 1ICR0KG0TLTS6IMSLCCOI2FNT2U59AMR NS DS RRSIG
1iasbm6gpka9m66s5hr4hmo1u9liunpq.buzz. 900 IN RRSIG NSEC3 8 2 900 20241029193425 20241003030439 62313 buzz. uC8B+o2BAwKm52N2KFhqvGc6JU5c+U6GLYkI8IqZKP/YRwzqWPlit+w+ DHr8TR6b0W+ia7wY0AjGBQgi2FurwEP5lKnIVjum9byVLzqqGrANYGJn 2ZFo1W4JUgT9az3xm/3K7B411AFLA/hUwLirP51h0YWpmsYI08g7uKxf ZggnoecdQowSwKDCEfc486WrV3v1sSjExL/BAZX+LfgOrQ==
pcglc2oj7fv61c90up3ehtq34n1ktkbr.buzz. 900 IN RRSIG NSEC3 8 2 900 20241031015741 20241001013007 62313 buzz. XvpNqDCqMSMdCHXayk66MgQus98LEEal1nhqqlpaDAV/KnuBanLZOigg DU0GXD/TEj6RYxInPZD8WuPYDpSl+WkkZHfvxmz4qIuDtDyyugZRRnCx dh2Pj1C+wL9IwHKsGxG59JTr1S2EnM0AYT6530v0EAn3W6QfuTJ72CZr BETfF/SKEcQnwckG2WXOT+8CT6GUQqaFsMZKLdq6hMf+Gw==
couldn't get address for 'invalid-ns1.example.test': not found
couldn't get address for 'invalid-ns2.example.test': not found
dig: couldn't get address for 'invalid-ns1.example.test': no more

However, adding glue records is not a typical use case - it does not make sense to allow people to add glue records to the TLD zone file for subdomains just to make something work like running websites. Glue records are typically used for branded nameservers or to avoid loops when querying nameservers on the same domain. For Public Suffix List users, this use case does not apply. So, if example.com returns an NXDOMAIN error, it is safe to assume that *.example.com will not work either.

I am not sure if this is the best way to replicate an NXDOMAIN situation to answer the question when example.com returning NXDOMAIN from the TLD registry server, does this absolutely mean all its subdomains will fail too?

Maybe @dnsguru or @wdhdev has some better insights?

[wdhdev]

I believe if the root domain is returning NXDOMAIN, the entire domain is unresolvable as the TLD servers cannot find anything at the 2nd level, so it will not attempt to find anything above that. However with subdomains you can have 4th level subdomains resolvable with their own NS records without the 3rd level subdomain even existing.

Example: my.fourth.leveldomain.com has NS records and is resolvable whilst fourth.leveldomain.com doesn't have any records and is unresolvable.

[groundcat]

I believe if the root domain is returning NXDOMAIN, the entire domain is unresolvable as the TLD servers cannot find anything at the 2nd level, so it will not attempt to find anything above that. However with subdomains you can have 4th level subdomains resolvable with their own NS records without the 3rd level subdomain even existing.

Example: my.fourth.leveldomain.com has NS records and is resolvable whilst fourth.leveldomain.com doesn't have any records and is unresolvable.

Yeah, from my findings above #2173 (comment) it does seems that

• It is possible for
  • Third-level domain bad.publicsuffix.buzz returns SERVFAIL due to invalid nameservers and
  • Fourth-level domain good.bad.publicsuffix.buzz resolves successfully using a different set of valid nameservers.

i.e., even if a third-level domain fails, a fourth-level domain can still resolve independently with proper nameservers.

• While it is not possible for
  • Second-level domain publicsuffix.buzz returns an NXDOMAIN error and
  • For foo.publicsuffix.buzz or anything further to resolve in the meanwhile.

i.e., if a second-level domain fails to resolve, all dependent third-level domains also fail, despite glue records.

To provide more live examples for research, here is the official zone file for the .gov TLD: .Gov zone file. For example, running dig NS dnsops.gov currently returns SERVFAIL, even though the following line (glue record) exists in the TLD zone file:

monitor.dnsops.gov.	3600	IN	A	129.6.100.203

Despite this entry being present in the .gov zone file, the third-level domain monitor.dnsops.gov. does not publicly resolve (against resolvers like @8.8.8.8)