GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Rob Ricci (ricci@discuss.systems)'s status on Monday, 28-Apr-2025 07:32:29 JST Rob Ricci Rob Ricci

    I was asked a really interesting question about whether the US government (or others, but we all know why people are worried about the US right now) could seize domain names, and what would happen if they did.

    This is:

    * An excellent question
    * Quite important to answer
    * Probably impossible to answer in practice

    :thread: 1/?

    Let's dig in, based on what I know (which to be clear is mostly on the technical side, I don't know a lot on the legal side; I invite additional information added or corrected by people with more knowledge):

    The question here is about the vulnerability of the DNS to government-level attacks. I am going to limit the scope of this post to the DNS; there are plenty of potential nation-state attacks on the Internet, I can't talk about all of them nor am I qualified to.

    The good news is that this is, in fact, the kind of attack that people have thought about quite a bit when designing and deploying these systems. That does not, however, mean that they are invulnerable to or that there are not hidden dependencies or vulnerabilities - and honestly the reason why this question is impossible to answer is that there are probably enough hidden dependencies that we just don't know what will fail until (if) somebody tries it.

    If someone tries to seize domain names, either one at a time or in bulk, the direct point of attack would be against the domain registrars; these are the entities who you pay to register the name, and who maintain the top-level information about them, such as whose name they are registered in, the contact information for those parties, and which DNS servers are authoritative for providing further information about those domains. Note that those DNS servers *may* be provided by the registrar, but they don't have to be. More about domain name registrars here: https://en.wikipedia.org/wiki/Domain_name_registrar

    So what's the attack? The government tries to force the registrar to either de-register the names, or re-register them to another party. They would do so by applying legal pressure on the registrar.

    This is one place where there is probably a very thorny legal question: who *owns* the domain name, really? Does the registrar own it? Does the registrant own it? There may be law on this, but I'm not aware of it; I do know that there have been cases regarding trademark law to reassign domain names, some of which have been successful. I'd love (for some definition of "love") to learn more here if folks have good sources to contribute.

    The good news on this front is that there are lots of registrars. Tons. One would assume that a government would have the most leverage, by far, against registrars in their own jurisdiction. Registrars are, however, spread out all across the world, and most domains are portable across registrars - you can move your domain to a different registrar just like you can move your mobile phone number to a different carrier in many (most?) countries. Most TLDs (the last bit in the domain name, such as .com. .org, .social, etc.) are handled by a large number of registrars. So, for most domain names, there is a fairly straightforward step to take for protection: transfer the domain to a registrar outside the jurisdiction you are concerned about. There is, for example, no registrar one can go to in order to seize all .com domains for a given country. (Some TLDs have different rules, but I'm not going to get into that here.)

    Basically, attacking this at a large scale is not impossible, but it would require a lot of resources and can only move so fast, giving domain name owners a chance to try to take proactive steps. It could certainly be disruptive, and targeted attacks against certain domains are possible, but there is enough resiliency that it's very, very hard to snatch the whole thing in one go.

    So, let's go deeper: who gives the registrars the ability to register individual domain names?

    In fact, let's go straight to the root: IANA: https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority . This is the standards organization that administers the list of TLDs and the information in the root DNS servers. It is international; that probably makes it hard for individual governments to assert control over it, though it's hard to say, maybe it means any member is a point of vulnerability instead. IANA more or less delegates responsibility to administering specific TLDs to other organizations; for example, .com is administered right now by Verisign: https://en.wikipedia.org/wiki/.com . Those organizations are themselves a potential point of vulnerability for seizing individual domain names; the system overall does have enough resiliency built in that if one domain name is seized, this does not prevent the person or organization that registered it from getting a new domain name in a different TLD: this is commonly done by sites that are not legal in certain jurisdictions, for example.

    In conversation about 20 days ago from discuss.systems permalink

    Attachments



    1. Domain not in remote thumbnail source whitelist: upload.wikimedia.org
      Internet Assigned Numbers Authority
      The Internet Assigned Numbers Authority (IANA) is a standards organization that oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System (DNS), media types, and other Internet Protocol–related symbols and Internet numbers. Currently it is a function of ICANN, a nonprofit private American corporation established in 1998 primarily for this purpose under a United States Department of Commerce contract. ICANN managed IANA directly from 1998 through 2016, when it was transferred to Public Technical Identifiers (PTI), an affiliate of ICANN that operates IANA today. Before it, IANA was administered principally by Jon Postel at the Information Sciences Institute (ISI) of the University of Southern California (USC) situated at Marina Del Rey (Los Angeles), under a contract USC/ISI had with the United States Department of Defense. In addition, five regional Internet registries delegate number resources to their customers, local Internet registries, Internet service providers, and end-user organizations. A local Internet registry is an organization that assigns...
    2. Domain not in remote thumbnail source whitelist: login.wikimedia.org
      .com - Wikipedia
    • pistolero likes this.
    • pistolero repeated this.
    • Embed this notice
      Fish of Rage (sun@shitposter.world)'s status on Monday, 28-Apr-2025 07:40:25 JST Fish of Rage Fish of Rage
      in reply to
      @ricci don't they already do this a lot
      In conversation about 20 days ago permalink
      pistolero likes this.
    • Embed this notice
      Rob Ricci (ricci@discuss.systems)'s status on Monday, 28-Apr-2025 07:43:27 JST Rob Ricci Rob Ricci
      in reply to

      🧵 2/2

      IANA is administered by ICANN: https://en.wikipedia.org/wiki/ICANN . Again, ICANN is an international organization, but its headquarters are in the United States. I would compare this to the United Nations, which also has its headquarters on US soil. Yes, the US could put the organization's property and some of its personnel under threat, and it could be quite disruptive, but the organization is global enough that it almost certainly could continue its operations and maintain its desired policies under such an attack.

      Let's also talk about the physical infrastructure at the root of the DNS. When you look up example.com, your DNS resolver (conceptually) goes to the root to ask where the DNS servers for .com are, then asks those servers where the DNS servers for example.com are. These root servers are extremely important, if utterly invisible to most people. There are currently thirteen root DNS servers: https://en.wikipedia.org/wiki/Root_name_server . However, each 'root server' is actually a bunch of root servers, many of them spread across the globe in various countries. The picture attached to this post shows where the physical servers are. Most of the operators of the root servers are American companies, but there are also companies headquartered in the Netherlands, Sweden, and Japan. We are probably pretty safe on this front.

      Let's wrap up by moving a level up, to the DNS server closest to your own computer.

      Unless you've done any special configuration (and you will know if you have...) you are probably using either one two DNS servers: most devices and software on your network are probably using your ISP's DNS server, and your browser *might* be using a third-party DNS server via DoH.

      Could a government compel your ISP to hijack DNS requests? Legally, I don't know, but on a technical level, mostly yes. Doing so would involve adding entries to their DNS servers that differ from the "real" ones, and returning those to you instead. This would essentially hijack the domain for all customers of that ISP. An attacker would have to do this ISP by ISP; this is easier in some places than others - in some countries the ISPs are already functionally arms of the government, in others they are independent but have consolidated down to just a few options, and others have more diversity.

      Ah, but, you say, DNSSEC! And yes, DNSSEC! For most of its history, the DNS has not provided a way to verify that the answer you get is legitimate instead of, say, replaced by your ISP as described above. Some time back, a set of extensions to DNS was put together to prevent such attacks: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions . There is more detail here than I could possibly go into, but this mechanism is (1) deployed on some TLDs but not all, (2) deployed only spottily on domains within the TLDs that support it, and (3) not universally checked by all resolvers. So: yes, DNSSEC helps - it generally protects the domains that have deployed it from being hijacked, even under threat to the ISP, but its effects are uneven.

      ISPs can relatively easily block you from using DNS servers other than their own - AFAIK, most don't, currently, but they can, because DNS requires UDP port 53, so it's easy to recognize and block.

      So, let's talk about DoH - this is DNS over HTTPS, and it gives you an encrypted way to make DNS requests and uses the same TCP port as HTTPS, making it harder for an ISP to block. Like DNSSEC, the more DoH there is in use, the less effective ISP-level domain hijacking is. Lately, browser vendors have started experimenting with making DoH the default for at least some users in at least some places; both Firefox and Chrome turned it on by default for some users in 2020: https://en.wikipedia.org/wiki/DNS_over_HTTPS . But, this is not 100% a win for freedom from government attacks: Chrome uses Google's DNS servers by default, and Firefox uses CloudFlare's - this can be changed, but it's a re-centralization, and therefore an attractive attack target for governments that have leverage over these two organizations.

      So to conclude: the DNS is a very messy system with lots of points that could be attacked by a government, but it is also comprised of enough systems, organizations, and protocols that attempts to seize domain names are likely to be hard to do at scale, and while the opportunity for mass disruption does exist, it is unlikely to meet with much long-term large-scale success.

      In conversation about 20 days ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        Example Domain

      2. No result found on File_thumbnail lookup.
        Domain Name System Security Extensions
        The Domain Name System Security Extensions (DNSSEC) is a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality. Overview The original design of the Domain Name System did not include any security features. It was conceived only as a scalable distributed system. The Domain Name System Security Extensions (DNSSEC) attempt to add security, while maintaining backward compatibility. RFC 3833 of 2004 documents some of the known threats to the DNS, and their solutions in DNSSEC. DNSSEC was designed to protect applications using DNS from accepting forged or manipulated DNS data, such as that created by DNS cache poisoning. All answers from DNSSEC protected zones are digitally signed. By checking the digital signature, a DNS resolver is able to check if the information is identical (i.e. unmodified and complete) to the information published by the zone owner and served...

      3. https://fd.discuss.systems/media_attachments/files/114/412/301/801/658/092/original/d1047d411d346b46.png
      4. Domain not in remote thumbnail source whitelist: upload.wikimedia.org
        ICANN
        The Internet Corporation for Assigned Names and Numbers (ICANN EYE-kan) is a global multistakeholder group and nonprofit organization headquartered in the United States responsible for coordinating the maintenance and procedures of several databases related to the namespaces and numerical spaces of the Internet, ensuring the Internet's stable and secure operation. ICANN performs the actual technical maintenance work of the Central Internet Address pools and DNS root zone registries pursuant to the Internet Assigned Numbers Authority (IANA) function contract. The contract regarding the IANA stewardship functions between ICANN and the National Telecommunications and Information Administration (NTIA) of the United States Department of Commerce ended on October 1, 2016, formally transitioning the functions to the global multistakeholder community. Much of its work has concerned the Internet's global Domain Name System (DNS), including policy development for internationalization of the DNS, introduction of new generic top-level domains (TLDs), and the operation...
      5. Domain not in remote thumbnail source whitelist: upload.wikimedia.org
        Root name server
        A root name server is a name server for the root zone of the Domain Name System (DNS) of the Internet. It directly answers requests for records in the root zone and answers other requests by returning a list of the authoritative name servers for the appropriate top-level domain (TLD). The root name servers are a critical part of the Internet infrastructure because they are the first step in resolving human-readable host names into IP addresses that are used in communication between Internet hosts. A combination of limits in the DNS and certain protocols, namely the practical size of unfragmented User Datagram Protocol (UDP) packets, resulted in a decision to limit the number of root servers to thirteen server addresses. The use of anycast addressing permits the actual number of root server instances to be much larger, and is 1,733 as of March 4, 2024. Root domain The DNS is a hierarchical naming system for computers, services, or any resource participating in the Internet. The top of that hierarchy is the root domain. The root domain does not have a formal name and its label in the DNS hierarchy...
      6. Domain not in remote thumbnail source whitelist: upload.wikimedia.org
        DNS over HTTPS
        DNS over HTTPS (DoH) is a protocol for performing remote Domain Name System (DNS) resolution via the HTTPS protocol. A goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver. By March 2018, Google and the Mozilla Foundation had started testing versions of DNS over HTTPS. In February 2020, Firefox switched to DNS over HTTPS by default for users in the United States. In May 2020, Chrome switched to DNS over HTTPS by default. An alternative to DoH is the DNS over TLS (DoT) protocol, a similar standard for encrypting DNS queries, differing only in the methods used for encryption and delivery. Based on privacy and security, whether either protocol is superior is a matter of controversial debate, while others argue that the merits of either depend on the specific use case. Technical details DoH is a proposed standard, published as RFC 8484 (October 2018) by the IETF. It uses HTTPS, and supports the wire format DNS response...

      pistolero likes this.
    • Embed this notice
      Rob Ricci (ricci@discuss.systems)'s status on Monday, 28-Apr-2025 08:00:54 JST Rob Ricci Rob Ricci
      in reply to
      • Fish of Rage

      @sun some, on an individual case by case basis. I may not have made it clear enough that the attack scenario I'm considering here is a more bulk seizure at large scale

      In conversation about 20 days ago permalink
      Fish of Rage likes this.
    • Embed this notice
      Fish of Rage (sun@shitposter.world)'s status on Monday, 28-Apr-2025 08:01:20 JST Fish of Rage Fish of Rage
      in reply to
      @ricci thanks for the clarification, I understand better now.
      In conversation about 20 days ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.