Over the years more than 1000 subdomains accumulated on *.gentoo.org Not all were cleaned up, when the project was cancelled. Please check, which subdomains are still in use/available. Ideally with a script once a year. One example for an unreachable subdomain is http://nightheron.gentoo.org/ Reproducible: Always
1. What's your metric for "dead"? 2. How are you building your entire list of "subdomains" 3. How are you differentiating subdomains from DNS entries that don't represent a server? TLSA, SSHFP, SRV but to name a few nightheron for example, was a recently (Jan 2021) decommissioned server. The IP is still "ours" for using. At least 3 sponsors have some placeholder entries like this. - does it respond on IPv4: no, some servers are v6-only - does it respond on IPv6: no, some servers are v4-only - does it have HTTP/HTTPS: some infra servers don't run a web server today - does it respond to ICMP: some sponsors firewall that - does it respond to SSH: most of the servers today SHOULD, but firewalls that limit source IPs have been used in the past I'd say only a tiny fraction are actually dead, and they are concentrated in stuff like the old numeric rsync records, rsyncN.CC.gentoo.org.
(In reply to Robin Johnson from comment #1) > 1. What's your metric for "dead"? > 2. How are you building your entire list of "subdomains" > 3. How are you differentiating subdomains from DNS entries that don't > represent a server? TLSA, SSHFP, SRV but to name a few > > nightheron for example, was a recently (Jan 2021) decommissioned server. The > IP is still "ours" for using. At least 3 sponsors have some placeholder > entries like this. > > - does it respond on IPv4: no, some servers are v6-only > - does it respond on IPv6: no, some servers are v4-only > - does it have HTTP/HTTPS: some infra servers don't run a web server today > - does it respond to ICMP: some sponsors firewall that > - does it respond to SSH: most of the servers today SHOULD, but firewalls > that limit source IPs have been used in the past > > I'd say only a tiny fraction are actually dead, and they are concentrated in > stuff like the old numeric rsync records, rsyncN.CC.gentoo.org. I mean FWIW I mostly read this bug and said "cool" and then almost closed it as wontfix; but I'm happy to leave it open. Unless its causing an actual problem though I'm not sure I care too much about prioritizing any fixes. On the list of stuff I care about this is very near the bottom[0]. -A [0] Having 100% correct DNS entries has been at the bottom of...basically every place I have ever worked; curious if others have had different experience. IMHO you need pretty complex business processes to ensure everything is right and the risk of carrying 'outdated entries' is typically 0 and the risk of breaking something by deleting stuff you think is not in use is typically non-trivial; leaving us where we are.
1) I suggest to use "dead" for subdomains which were created for a service, but do not respond for a given time for this service. I do not know how the subdomains are managed now, but it should be easy to script. 2) by using DNS repositories 3) I did not walk through all my self. I think it is enough if a script supports us to keep the DNS up to date.
(In reply to Jonas Stein from comment #3) > 1) I suggest to use "dead" for subdomains which were created for a service, > but do not respond for a given time for this service. I do not know how the > subdomains are managed now, but it should be easy to script. > > 2) by using DNS repositories > > 3) I did not walk through all my self. I think it is enough if a script > supports us to keep the DNS up to date. I'm mostly going to assert that this is nice in theory but I've never seen it work in practice in any environment and the impact of having 'dead' names is minimal. If you can articulate some downside to keep..dns resolution working for various things I'd at least be convinced to prioritize this work against the other 280 bugs we have ;)
