I’m reminded of a quote from “2010 The year we make contact”:
“Just because our governments are behaving like asses doesn’t mean we
have to.” (Roy Scheider as Dr. Heywood Floyd)
Breaking any communications facility is, IMHO, counterproductive to all sides.
Communication is almost always the key to ending conflict.
In this case, it might require more than just communications, but breaking the
.RU domain almost certainly isn’t going to help resolve the situation.
The internet should, ideally, continue to treat governments behaving like asses
as damage and route around them.
Owen
> On Mar 15, 2022, at 02:07 , Patrick Bryant <patr...@pbryant.com> wrote:
>
> I propose dropping support of the .ru domains as an alternative to the other
> measures discussed here, such as dropping Russian ASNs -- which would have
> the counterproductive effect of isolating the Russian public from western
> news sources. Blocking those ASNs would also be futile as a network defense,
> if not implemented universally, since the bad actors in Russia usually
> exploit proxies in other countries as pivot points for their attacks.
>
> Preventing the resolution of the .ru TLD would not impact the Russian
> public's ability to resolve and access all other TLDs. As I noted, there are
> countermeasures, including Russia standing up its own root servers, but there
> are two challenges to countermeasure: 1) it would require modifying evey
> hints file on every resolver within Russia and, 2) "other measures" could be
> taken against whatever servers Russia implemented as substitutes. Dropping
> support for the .ru TLD action may incentivize the Russian State to bifurcate
> its national network, making it another North Korea, but that action is
> already underway.
>
> Other arguments are political, and I do not presume to set international
> political policy. I only offer a technical opinion, not a political one. The
> legalistic arguments of maintaining treaties is negated by the current state
> of war.
>
> On Tue, Mar 15, 2022 at 2:29 AM Fred Baker <fredbaker.i...@gmail.com
> <mailto:fredbaker.i...@gmail.com>> wrote:
> My viewpoint, and the reason I recommended against it, is that it gives Putin
> something he has wanted for a while, which is a Russia in which he is in
> control of information flows. We do for him what he has wanted for perhaps 20
> years, and come out the bad guys - “the terrible west gut us off!”. I would
> rather have people in Russia have information flows that have a second
> viewpoint other than the Kremlin’s. I have no expectation that it will get
> through uncensored, but I would rather it was not in any sense “our fault”
> and therefore usable by Putin’s propaganda machine.
>
> Sent from my iPad
>
>> On Mar 14, 2022, at 2:14 PM, Brian R <briansupp...@hotmail.com
>> <mailto:briansupp...@hotmail.com>> wrote:
>>
>>
>> I can understand governments wanting this to be an option but I would let
>> them do blocking within their countries to their own people if that is their
>> desire. This is another pandoras box. Its bad enough that some countries
>> control this already to block free flow of information.
>> If global DNS is no longer trusted then many actors will start maintaining
>> their own broken lists (intentionally or unintentionally).
>> This will not stop Russia, they will just run their own state sponsored DNS
>> servers. We can imagine what else might be implemented on that concept...
>> Countries or users that still want access will do the same with custom DNS
>> servers.
>> This will take us down another path of no return as a global standard that
>> is not political or politically controlled.
>> The belief that the internet is open and free (as much as possible) will be
>> broken in one more way.
>> This will also accelerate the advancement of crypto DNS like NameCoin (Years
>> ago I liked the idea but I don't know how it is being run anymore.) or
>> UnstoppableDomains for example. Similar to what is starting to happen to
>> central banking as countries start shutting down bank accounts for political
>> reasons.
>> I am glad to see soo many people on here and many of the organizations
>> running these services state as much.
>>
>> Brian
>>
>>
>> From: NANOG <nanog-bounces+briansupport=hotmail....@nanog.org
>> <mailto:hotmail....@nanog.org>> on behalf of Patrick Bryant
>> <patr...@pbryant.com <mailto:patr...@pbryant.com>>
>> Sent: Saturday, March 12, 2022 2:47 AM
>> To: nanog@nanog.org <mailto:nanog@nanog.org> <nanog@nanog.org
>> <mailto:nanog@nanog.org>>
>> Subject: Dropping support for the .ru top level domain
>>
>> I don't like the idea of disrupting any Internet service. But the current
>> situation is unprecedented.
>>
>> The Achilles Heel of general public use of Internet services has always been
>> the functionality of DNS.
>>
>> Unlike Layer 3 disruptions, dropping or disrupting support for the .ru TLD
>> can be accomplished without disrupting the Russian population's ability to
>> access information and services in the West.
>>
>> The only countermeasure would be the distribution of Russian national DNS
>> zones to a multiplicity of individual DNS resolvers within Russia. Russian
>> operators are in fact implementing this countermeasure, but it is a slow and
>> arduous process, and it will entail many of the operational difficulties
>> that existed with distributing Host files, which DNS was implemented to
>> overcome.
>>
>> The .ru TLD could be globally disrupted by dropping the .ru zone from the 13
>> DNS root servers. This would be the most effective action, but would require
>> an authoritative consensus. One level down in DNS delegation are the 5
>> authoritative servers. I will leave it to the imagination of others to
>> envision what action that could be taken there...
>>
>> ru nameserver = a.dns.ripn.net <http://a.dns.ripn.net/>
>> ru nameserver = b.dns.ripn.net <http://b.dns.ripn.net/>
>> ru nameserver = d.dns.ripn.net <http://d.dns.ripn.net/>
>> ru nameserver = e.dns.ripn.net <http://e.dns.ripn.net/>
>> ru nameserver = f.dns.ripn.net <http://f.dns.ripn.net/>
>>
>> The impact of any action would take time (days) to propagate.
>>
