Hi all, Following the mention by Kim that .internal is indeed the string to be used (for which, thank you!), I have decided that I want to take steps to implement this. To be fair, "only a couple of zone files" downplays the changes required by quite a lot. Whether that was intentional or not, we will never know. I have a tendency to either hold or fold.
Either way, this change is significant and will likely take years to fully propagate. Even for the little networks like this (~100 hosts perhaps). It's not just about the zone files themselves, but everything that relies on their contents. So with something so impactful, we need an action plan, don't we? First up, I want to consider which string I want to pick, and provide rationale for each. Much like in the email from before, this will be 3 domains - nixmagic.com, roover.eu.org, and internal. - nixmagic.com (Namecheap, commercial) A commercial domain, with yearly lease. If I peg my infrastructure against it and forget about renewal, someone else will likely squat it and inflate its price for me. Excusez-moi pour parler en français, but I would be fucked. However, I would have receipts and contracts for the scenario in which Namecheap decides to take the domain down (e.g. alleged abuse). Legal recourse might be an option. But not something I like to do. - roover.eu.org (nic.eu.org, personal) A personal domain, granted for life if the usage is personal. This is nice, and I love that these things exist. Also a lot more interpersonal and stable than something like Freenom, which has a track record of taking domains away for somewhat arbitrary reasons. Not that I expect eu.org to do such a thing, but if they do, there's no legal recourse. I would have to bite the bullet and go full damage control. - internal (ICANN / IANA, special-use) A make believe domain, that will probably only ever anchor itself in the root servers and internal networks. Unlike the previous two, there is no means of assuming public authority over it to absorb the leaked traffic. However, on account of the overseeing organizations, it's likely to be written in stone. That means that it is extremely stable. Given this, my preference would likely go to internal. But perhaps nixmagic.com could also be an option, for the sake of exerting public authority and absorbing the leakage. Not only out of kindness (I am not a kind person), but also because I neither want to go on the wall of shame, nor do I want the root server operators to learn about my internal network details. Which brings me to management, making the case for this within a company. I consider myself to be in a somewhat unique position because I have nobody but myself to answer to. If I think that this is "the right thing to do", then that is what I will do. And only my own tenacity can stop me. If you have a friendly neighborhood suit in your vicinity meanwhile... Good luck presenting to them that you want to overhaul the entire IT stack because someone on the internet asked you to. Kindness is not the answer, otherwise the textile industry would've also cared more about the people downstream the river. But they don't, in their minds those people are likely to be utterly irrelevant. And for all the prestige of ICANN and IANA, as well as the IETF.. the same is probably true for you as well. So instead of kindness, I would rather bring it with the spice of security. That every DNS request leaked into the root servers opens the door to either them or an attacker along the way mapping the whole internal networks and using it for a security breach. Management might still not care, but you might have ever so slightly less of an uphill battle. And if it works, then for God's sake _do it_. Networks tend to grow, so the longer you wait, the harder it's going to be. Lastly, to actually put this thing to work. I think what I will start with is to allocate a new zone for each of the internal networks, that will have the current contents copied in. Fortunately, I do have tooling that can generate these zone files. And if you have relative records (not ending in .), you might be able to do it with a single string for the zone as well. For a while, these will run together with the existing zones. Over time then, I will change all of the clients that rely on these old records, to use the new ones. That's where the long game begins. It might be worthwhile to monitor requests being made to the old zones too, so that it's known when it's safe to sunset them. Until then though, they have to be kept to prevent an enormous amount of leakage and breakage. And finally, I want to use this as a test bed to then bring this to the attention of other regulatory bodies like the EU. There too, citizen IDs are national and not recognized cross-border. They will need something similar, but as a prefix. And while certainly a moonshot, if I can prove that it's possible.. then perhaps they'll start thinking about it too. Essay over. Thanks for your attention. And good luck. Both you and I are going to need it. -- Met vriendelijke groet, Michael De Roover Mail: [email protected] Web: michael.de.roover.eu.org _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
