| BBlack added a comment. |
There are different layers of "handing off" DNS management which are being conflated, but to run through them in order:
- "Point the A record to the right place" - We don't support this, and can't realistically. We need control of the zone data directly on our nameservers for a variety of technical reasons (e.g. setting policy controls like CAA authorizations, future ESNI-related records, etc), and we don't use simple A-records, we use a dynamic system that hands out any of a number of addresses to the nearest of our global edge datacenters, and these things evolve over time on a technical level. If we're going to host something in our production infrastructure and manage it correctly, we have to move to at least the next level of handoff:
- Leaving the registration of the domain with WMDE and their registrar, but having the Nameservers pointed at WMF nameservers. This is what we've already done earlier in the ticket and where we're at now. Currently the domain is registered to WMDE (presumably, it's hidden in public view) via registrar "united-domains", and the nameserver values are set to the 3x WMF nameserver hosts (ns0.wikimedia.org, ns1.wikimedia.org, and ns2.wikimedia.org, at specific IP addresses for each). This allows the WMF nameservers and SRE staff to do all the basic technical things referenced above, and is the first logical step before:
- Switching the registration to WMF's registrar/ownership. This is more on a policy/standards/legal level, and maybe @CRoslof can give more details than me on that front about legal-related things. It would be odd in the general case to be canonicalizing a WMF domain without registrar control though, as it could be swapped out from under us at any time. However, even on a purely technical level it matters to us as well: we have future plans to deploy more authdns servers, change their IPs, and deploy anycasted authdns as well, all of which require WMF to have tight control over the registrar settings for all the domains we host resources for so that we can get through transition periods smoothly as those ns[012] hostnames and their IPs change. It's not scalable for those processes to involve contacting N third parties and having them all indirectly contact their registrars on our behalf, etc.
TASK DETAIL
EMAIL PREFERENCES
To: Dzahn, BBlack
Cc: Abraham, Franziska_Heine, CRoslof, MasinAlDujailiWMDE, WMDE-leszek, abian, BBlack, Lucas_Werkmeister_WMDE, Stashbot, gerritbot, Dzahn, Lydia_Pintscher, mark, PokestarFan, faidon, Ladsgroup, Ivanhercaz, Addshore, Jonas, JeroenDeDauw, hoo, JanZerebecki, Aklapper, Legado_Shulgin, Nandana, thifranc, AndyTan, Davinaclare77, Qtn1293, Lahi, Gq86, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, LawExplorer, Zppix, _jensen, Wong128hk, Wikidata-bugs, aude, Mbch331, Jay8g, fgiunchedi
Cc: Abraham, Franziska_Heine, CRoslof, MasinAlDujailiWMDE, WMDE-leszek, abian, BBlack, Lucas_Werkmeister_WMDE, Stashbot, gerritbot, Dzahn, Lydia_Pintscher, mark, PokestarFan, faidon, Ladsgroup, Ivanhercaz, Addshore, Jonas, JeroenDeDauw, hoo, JanZerebecki, Aklapper, Legado_Shulgin, Nandana, thifranc, AndyTan, Davinaclare77, Qtn1293, Lahi, Gq86, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, LawExplorer, Zppix, _jensen, Wong128hk, Wikidata-bugs, aude, Mbch331, Jay8g, fgiunchedi
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
