Switch to *.dnslink.example.com

[lidel]

We just realized it causes issues at PL infra because we have two sources of truth for this domain.

README states:

dnslink-test comes automatically with a dns server that is run on the localhost's udp and tcp port

@martinheidegger what is the use case for setting those *.t*.dnslink.dev records via dnsimple-update-script.js?
Ideally, we would not be dependent on real world DNS and have tests self-contained – using local/embedded DNS server.

[martinheidegger]

The local/embedded DNS server works indeed without the dns entries. The original reason why I set it up was that an implementation of dnslink-std may not want or have access to a configurable dns endpoint (thinking of some sandbox environments).

In the meantime the *.t*.dnslink.dev came in unexpectedly handy when testing the browser UI for the website. I would be using the test entries to see how the UI reacts without needing to start a local server.

What issues are they causing?

[martinheidegger]

The tests now encompass entries that can not be reasonably represented on the public server. Specifically: custom RCODE responses and non-existent TLD's. These can not be represented on the domain.

It is still useful to have the setup online somewhere to test systems manually or for documentation. Would it be a good idea to publish the DNS entries on a specific subdomain? t01.dnslink.dev → t01.try.dnslink.dev? This way an implementation can not confuse the DNS entries with the ones provided by the DNS server that comes with the test system. Alternative we could also change the t to a d for the DNSimple integration: t01.dnslink.dev → d01.dnslink.dev. (d for demo)

[lidel]

What issues are they causing? [..]
It is still useful to have the setup online somewhere to test systems manually or for documentation.

• Moving domains to a new DNSSimple account caused some issues at the old infra (split-brain situation around TLS certs) and requires additional cleanup. I noted that we only need dnslink.dev so .io may get migrated back to solve those issues, hopefully that will be the end of this, but the level of complexity this introduced across the org is a bit awkward.
• I am worried about people being lazy and using public DNS in their interop tests. If we only have embedded/local DNS option documented, then people will always do the right thing.

Sounds like test suite already needs to be run locally, and the only value of public records are demo purposes.
If you feel there is value in that, let's use *.example.dnslink.dev subdomain (similar to example.com)

[lidel]

Concern

• Reliance on DNS records at *.dnslink.dev is too brittle and does not cover all tests.

Ask

• Remove use of dnslink.dev in tests – we require built-in DNS server anyway now.
• Switch everything (tests, --help text) to use domain names under *.dnslink.example.com – this will remove any ambiguity and follows best practices (https://en.wikipedia.org/wiki/Example.com)