Aux root
.dom
Domain Engineering TLD
KASTALIEN peer-peer name system ¹
Beginning in 2019, a migration of content from random distribution over my longstanding 3 ICANN domains*, is in progress, with the goal of almost all content being alt-routed, either same named, ICANN suffix to .dom, or the ICANN/IANA TLD just dropped. As used here. alt root refers to an autonomous peerage that routes TLDs upon discretion of the operators. A reasonable effort for a free service level is committed that just works by:
adding the following name servers, which are non-recursive, in desired order to your active resolver(s):
- ns.<DS_ZONE>.<IANA_ZONE>
- . . .
- ns<n>.<DS_ZONE><IANA_ZONE>
where «IANA_ZONE», the linking zone or domain in the priced name system and, <n> is currently 2, or their ip addresses if your resolver requires it and
where the linking zone uses the designated
<IANA_ZONE>
- Donuts live thru 2022-10;
- Neustar biz thru 2025-02 .
- TBA by 4722
and <DS_ZONE> ::= "sameboat"
The changing linking zone is key to my version of the alt root concept. Stability is supplied by at least 1 year advance notice in the list above. Generally content is unaffected.
A simple mapping from state actor name systems such as IANA into this private one is to simply drop the public suffix or replace it with one(s) the name owner uses here.
Names wholly within the alt system are not affected by linking suffix migration, only the alt-public/wild boundary is affected when the system linking zone changes.
* An example is thoughtcrime.biz, thoughtcrime.dom is already the reference domain but tcb.biz will route publicly for a while and then only via my root for the .biz suffix. ** will be routed publicly via Neustar for a while after but not as linking zone.
Paid²[2]users have access from recursion and additional basic name services for users below developer class up to continuous live maintenance by intelligent agency for operators.
As used here, the background operation of the public priced name systems are assumed as needed, excluded where desirable, e.g. for privacy or security. Our system is constructed using the standard unix networking software and forms a superspace of the public name system with these properties:
- Individual operators of the system determine which TLDs they recognize. The system administered here only allocates the TLDs FCFS to operators, it doesn't have the intent of acting as a sole authoritative source even for the .dom name, which operators may override to establish cooperating alt roots. The TLD operators in essence agree to a common real TLD space which they may present internally differently, but which starts with the common public systems plus a single reserved name: ".dom" for their private/peer namespace.
- IPV6 and TLS are defaults, 4 and plain text special cases.
- Simple name seeking registrars are prohibited. Registrars must offer the name service free bundled with value added services.
- A rich default common systems application environment which operators may optionally use is provided in which all users are identified and at least in principle, traceable.
An equivalent function is assumed for peer operators, as provided by my DNS/EPP tooling merged with the FRED Czech NIC software as maintained by me for my Ubuntu LTS targets. End users of the "sameboat/C-六" core PHP-Python CMS have significant consumer level DNS functionality upon sufficient entitlement.
³ "clean" means a newly formatted host OS instance; Our modifications of various elements such as letsencrypt included in the SaaS, woven through various process such as SSO, registration, etc.
