RFC 7626

DNS Privacy Considerations

📅 published August 2015, from ietf

RFC 7626: DNS Privacy Considerations 🎀

okay bestie, this one is an Informational RFC by S. Bortzmeyer from AFNIC, published in August 2015 (ISSN 2070-1721). It's not a Standards Track spec, so it's an analysis, not a rulebook. The title block doesn't list anything it obsoletes or updates. 💅

Abstract ✨

this doc is about the privacy issues that come with Internet users using the DNS. it's meant as an analysis of how things are right now, and it doesn't prescribe any solutions 🌸

Status of This Memo 📝

this is not an Internet Standards Track spec. it's published for informational purposes 🦋

this is a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 🧚

for info on the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7626 💜

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. please read these carefully, because they spell out your rights and restrictions for this doc 🫶

if you pull Code Components out of this doc, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions. they come without warranty, as the Simplified BSD License describes 🔥

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  2.  Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
    2.1.  The Alleged Public Nature of DNS Data . . . . . . . . . .   4
    2.2.  Data in the DNS Request . . . . . . . . . . . . . . . . .   5
    2.3.  Cache Snooping  . . . . . . . . . . . . . . . . . . . . .   6
    2.4.  On the Wire . . . . . . . . . . . . . . . . . . . . . . .   7
    2.5.  In the Servers  . . . . . . . . . . . . . . . . . . . . .   8
      2.5.1.  In the Recursive Resolvers  . . . . . . . . . . . . .   8
      2.5.2.  In the Authoritative Name Servers . . . . . . . . . .   9
      2.5.3.  Rogue Servers . . . . . . . . . . . . . . . . . . . .  10
    2.6.  Re-identification and Other Inferences  . . . . . . . . .  11
    2.7.  More Information  . . . . . . . . . . . . . . . . . . . .  11
  3.  Actual "Attacks"  . . . . . . . . . . . . . . . . . . . . . .  11
  4.  Legalities  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
  6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
    6.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
    6.2.  Informative References  . . . . . . . . . . . . . . . . .  13
  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
  Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction 🌈

this doc is an analysis of DNS privacy issues, in the spirit of Section 8 of [RFC6973] 💖

the Domain Name System is specified in [RFC1034], [RFC1035], and a bunch of later RFCs that never got merged into one. it's one of the most important pieces of Internet infrastructure, and honestly it's super overlooked and misunderstood, even by plenty of professionals 😭 almost every Internet activity starts with a DNS query (and often several), so its privacy implications are huge. this doc is an attempt at a complete and accurate list 👑

quick refresher on how DNS works (see also [DNS-TERMS]) ✨ a client, the stub resolver, sends a DNS query to a server called the recursive resolver (also called a caching resolver, full resolver, or recursive name server). let's use the query "What are the AAAA records for www.example.com?" as our example. AAAA is the QTYPE (Query Type), and www.example.com is the QNAME (Query Name). the walkthrough below assumes a cold cache, for example because the server just started 🧚

the recursive resolver asks the root name servers first. in most cases they send back a referral, and here the referral points to the .com name servers. the resolver repeats the query to one of the .com name servers. the .com name servers refer it to the example.com name servers, and the example.com name server returns the answer. the root name servers, the .com name servers, and the example.com name servers are all called authoritative name servers 🦋

here's the important part for privacy: every one of those servers gets the original question, not a derived one. the root name servers get "What are the AAAA records for www.example.com?", not "What are the name servers of .com?". by repeating the full question instead of only the relevant piece to the next server in line, DNS hands the name server more info than it needs 👀

caching changes things a bit, so the process above is more complicated, and not every question reaches the authoritative name servers. say a few seconds later the stub resolver asks the recursive resolver, "What are the SRV records of _xmpp-server._tcp.example.com?". the recursive resolver already knows the example.com name servers, so it just queries them and skips the root and .com. since there's typically no caching in the stub resolver, the recursive resolver sees all the DNS traffic, unlike the authoritative servers 🌸 (apps like web browsers may cache in ways that don't follow DNS rules, for example by ignoring the TTL. so the recursive resolver doesn't see all the name resolution activity 🙈)

also, DNS recursive resolvers sometimes forward requests to other recursive resolvers, usually bigger machines with a larger, more shared cache. the query hierarchy can go even deeper, with more than two levels of recursive resolvers 🍓 from a privacy point of view, these forwarders act like resolvers, except they don't see every request, because the first resolver's cache handles some of them.

almost all of this DNS traffic is currently sent in clear (unencrypted) 😳 there are a few cases with some channel encryption, like an IPsec VPN, at least between the stub resolver and the resolver.

today, almost all DNS queries go over UDP [thomas-ditl-tcp]. that matters a lot when you think about encrypting the traffic as a privacy fix, because some encryption solutions are only designed for TCP, not UDP 💅

another key thing to remember: DNS requests a server receives can be triggered for different reasons. say an eavesdropper wants to know which web page a user is looking at. for a typical web page, three kinds of DNS requests get sent out 🔥

  • Primary request: this is the domain name in the URL that the user typed, picked from a bookmark, or clicked on as a hyperlink. presumably this is what the eavesdropper cares about.
  • Secondary requests: these are the extra requests the user agent (here, the web browser) makes without the user's direct involvement or knowledge. on the Web, they're triggered by embedded content, Cascading Style Sheets (CSS), JavaScript code, embedded images, and so on. sometimes a single web page can involve dozens of domain names across different contexts.
  • Tertiary requests: these are the extra requests the DNS system makes by itself. for example, if an answer is a referral to a set of name servers and the glue records aren't returned, the resolver has to make more requests to turn those name servers' names into IP addresses. similarly, even when glue records are returned, a careful recursive server will make tertiary requests to verify the IP addresses in those records 🧚

also, a typical web browser sends more DNS requests than strictly necessary, for example to prefetch resources the user might visit later, or while autocompleting the URL in the address bar. both are a big privacy concern, since they can leak info even about actions the user never explicitly took. for instance, just reading a local HTML page, without clicking any hyperlinks, can trigger DNS requests 😭

for privacy-related terms, this doc uses the terminology from [RFC6973] 📚

2. Risks ⚠️

this doc mostly studies privacy risks for the end user (the person making DNS requests) 🫶 we consider the risks of pervasive surveillance [RFC7258] as well as the risks from more focused surveillance. privacy risks for the holder of a zone (the risk that someone gets the data) are discussed in [RFC5936] and [RFC5155]. non-privacy risks, like cache poisoning, are out of scope 🙅‍♀️

2.1. The Alleged Public Nature of DNS Data 🫣

for a long time people have claimed that "the data in the DNS is public". that makes sense for an Internet-wide lookup system, but the data and metadata involved have multiple facets that deserve a closer look 🔍 first, even with access control lists and private namespaces, DNS assumes that public-facing authoritative name servers will answer "usual" DNS queries for any zone they're authoritative for, without authenticating or authorizing the client (resolver). because there's no search capability, only a specific QNAME reveals the resource records tied to that name (or shows that the name doesn't exist). in other words, you have to know what to ask for in order to get an answer 🧠 the zone transfer QTYPE [RFC5936] is often blocked or restricted to authenticated and authorized access to enforce this difference (and maybe for other reasons too).

another distinction to make is between the DNS data itself and a particular transaction (a single DNS name lookup). DNS data and the results of a DNS query are public within the limits described above, and they may not have any confidentiality requirements. the same isn't true of a single transaction or a sequence of transactions: that transaction is not / should not be public 🙈 a classic example from outside the DNS world: the website of Alcoholics Anonymous is public, but the fact that you visit it should not be 🌈

2.2. Data in the DNS Request ✨

okay so a DNS request has a lot of fields in it, but bestie, two of them are the main characters when it comes to privacy: the QNAME and the source IP address 💅. When I say "source IP address" I'm being a little loose, because I really mean "source IP address + maybe source port" 🎀. The port is in the request too, and it helps tell apart several users sharing one IP address (like behind a Carrier-Grade NAT (CGN), for instance [RFC6269]) 🌸.

The QNAME is the full name the user sent 🔥. It spills what the user is up to. "What are the MX records of example.net?" basically means they probably want to email someone at example.net 📧. That domain might be used by only a few people, so it's super revealing about who's talking to who 👀. Some QNAMEs are way more sensitive than others 💀. Asking for the A record of a super well-known web statistics domain tells you almost nothing, because everybody visits sites that use that analytics service 🌈. But asking for the A record of www.verybad.example, where verybad.example belongs to an organization some people find offensive or objectionable, could cause real trouble for the user 😬. Also, sometimes the QNAME carries the software you're running, and that can be a privacy issue too 🙈. Check this one out: _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org. Some BitTorrent clients also look up an SRV record for _bittorrent-tracker._tcp.domain.example 🧚.

Now here's the part that makes me lowkey panic 😭. The future usages of QNAME privacy matter SO much. Right now, the lack of privacy is kind of blocking people from putting potentially sensitive or personally identifiable data in the DNS 🚫. Today your DNS traffic might show that you're doing email, but not who you're emailing 📬. If your Mail User Agent (MUA) starts looking up Pretty Good Privacy (PGP) keys in the DNS [DANE-OPENPGPKEY], then privacy becomes a whole lot more important 🔐. And email is only one example. There would be plenty of other really cool uses for a more privacy-friendly DNS 🦋.

For the conversation between the stub resolver and the recursive resolver, the source IP address is the address of the user's machine 💻. So every issue and warning about collecting IP addresses applies here too 🚨. For the conversation between the recursive resolver and the authoritative name servers, the source IP address means something different. It doesn't have the same status as the source address in an HTTP connection 🤔. This time it's the IP address of the recursive resolver that, in a way, "hides" the real user 🫣. Still, hiding doesn't always work. Sometimes [CLIENT-SUBNET] is used (see its privacy analysis in [denis-edns-client-subnet]) 👀. Sometimes the end user runs a personal recursive resolver on her own machine 🖥️. In both cases, the IP address is just as sensitive as it is for HTTP [sidn-entrada] 😤.

A quick note about IP addresses ✨: there's currently no IETF document that goes into detail on all the privacy issues around IP addressing 📚. In the meantime, the discussion here is meant to cover both IPv4 and IPv6 source addresses 🌐. Their assignment and utilization characteristics are different for a number of reasons, and that might change the details of what information leaks when source addresses get collected 🧩. (For example, a specific IPv6 source address seen on the public Internet is less likely than an IPv4 address to come from behind a CGN or other NAT 💜.) Even so, for both IPv4 and IPv6 addresses, it's really important to remember that source addresses travel along with queries, and they carry metadata about the host, user, or application that sent them 🫶.

2.3. Cache Snooping 🍓

The contents of a recursive resolver's cache can reveal data about the clients using it 👀. (How risky that is depends on how many clients there are.) Sometimes someone can look at that information by sending DNS queries with RD=0 to inspect the cache contents, paying special attention to the DNS TTLs [grangeia.snooping] 🔍. Since this is also a reconnaissance technique for later cache poisoning attacks, some countermeasures have already been developed and deployed 🛡️.

2.4. On the Wire 🕵️‍♀️

DNS traffic can be seen by an eavesdropper, just like any other traffic 👁️. It's typically not encrypted 🙅‍♀️. (DNSSEC, specified in [RFC4033], explicitly leaves confidentiality out of its goals 🙃.) So if an initiator starts an HTTPS communication with a recipient, the HTTP traffic will be encrypted, but the DNS exchange that happens before it won't be 😬. As other protocols get more privacy-aware and better protected against surveillance, DNS might become "the weakest link" in privacy 🔗💔.

Here's an important quirk of DNS traffic: it may take a different path than the communication between the initiator and the recipient 🛤️. For instance, an eavesdropper might be unable to tap the wire between the initiator and the recipient, but still have access to the wire going to the recursive resolver, or to the authoritative name servers 🎣.

From an eavesdropper's point of view, the best place to tap is clearly between the stub resolvers and the recursive resolvers, because traffic isn't limited by DNS caching 🎯.

The attack surface between the stub resolver and the rest of the world can vary a LOT depending on how the end user's computer is configured 🌍. From smallest attack surface to biggest, it goes like this 📈:

  • The recursive resolver can be on the end user's computer. In a (currently) small number of cases, individuals may choose to run their own DNS resolver on their local machine 🧑‍💻. Here, the attack surface for the connection between the stub resolver and the caching resolver is limited to that one machine 🔒.
  • The recursive resolver may be at the local network edge. For many or most enterprise networks, and for some residential users, the caching resolver may live on a server at the edge of the local network 🏢. In this case, the attack surface is the local network 🏠. Note that in large enterprise networks, the DNS resolver may not be at the edge of the local network but rather at the edge of the overall enterprise network 🏙️. When that happens, the enterprise network could be thought of as similar to the Internet Access Provider (IAP) network mentioned below 🧠.
  • The recursive resolver can be in the IAP premises. For most residential users, and potentially other networks, the usual setup is that the end user's computer gets configured (usually automatically through DHCP) with the addresses of the DNS recursive resolvers at the IAP 📡. So the attack surface for on-the-wire attacks runs from the end-user system across the local network and across the IAP network to the IAP's recursive resolvers 🕸️.
  • The recursive resolver can be a public DNS service. Some machines may be set up to use public DNS resolvers, such as those operated today by Google Public DNS or OpenDNS 🌐. The end user may have configured their machine to use these DNS recursive resolvers themselves, or their IAP may have chosen to use public DNS resolvers instead of running its own 🏳️. In this case, the attack surface is the entire public Internet between the end user's connection and the public DNS service 🌊.

2.5. In the Servers 🖥️

Using the terminology of [RFC6973], DNS servers (recursive resolvers and authoritative servers) are enablers 🧚. They make communication between an initiator and a recipient possible without being directly in the communications path 🛣️. Because of that, they often get forgotten in risk analysis 🫥. But, to quote [RFC6973] again: "Although [...] enablers may not generally be considered as attackers, they may all pose privacy threats (depending on the context) because they are able to observe, collect, process, and transfer privacy-relevant data." 🚩 In [RFC6973] parlance, enablers become observers once they start collecting data 👁️‍🗨️.

There are LOTS of programs that collect and analyze DNS data on servers 🧐. You've got the "query log" in some programs like BIND, tcpdump, and more sophisticated tools like PacketQ [packetq] [packetq-list] and DNSmezzo [dnsmezzo] 🧰. The organization running the DNS server can use this data itself, or it can become part of a surveillance program like PRISM [prism] and pass the data along to an outside observer 🫣.

Sometimes this data is kept for a long time and/or distributed to third parties for research purposes [ditl] [day-at-root], security analysis, or surveillance tasks 📦. These uses are sometimes covered by contracts with various limitations, for instance on redistribution, because the data is so sensitive 🔏. There are also observation points in the network that gather DNS data and then make it accessible to third parties for research or security purposes ("passive DNS" [passive-dns]) 🌀.

2.5.1. In the Recursive Resolvers 🧠

Recursive resolvers see all the traffic, since there's typically no caching in front of them 👀. To sum it up: your recursive resolver knows a LOT about you 🫣. The resolver of a large IAP, or of a large public resolver, can collect data from many users at once 📈. If you want an idea of what gets collected, you can read the privacy policy of a big public resolver, for example https://developers.google.com/speed/public-dns/privacy 📜💖.

2.5.2. In the Authoritative Name Servers

okay so authoritative name servers are a little different from recursive resolvers 👀 because caching hides a lot of traffic from them. they only see the requests where the answer wasn't already in the cache. for aggregated stats like "What is the percentage of LOC queries?" 📊 that's totally enough, but it means an observer can't see everything. still, they catch a chunk of the traffic, and that chunk can be enough to break some privacy expectations 😬

also, the end user usually has a legal or contractual relationship with the recursive resolver (they picked their IAP, or they picked a specific public resolver 🫶). meanwhile they have zero control over authoritative name servers and maybe no idea those servers can watch their queries 💀

as we said before, using a local resolver or one close to the machine shrinks the attack surface for an on-the-wire eavesdropper ✨ but here's the twist 🙈: it can make things worse for privacy against an observer sitting on an authoritative name server. that server sees the IP address of the actual end client instead of the address of a big recursive resolver that's shared by tons of users.

this "protection" you get from using a large resolver with lots of clients? 🫠 gone if [CLIENT-SUBNET] is used, because then the authoritative name server sees the original IP address (or prefix, depending on the setup).

as of today, all the instances of one root name server, L-root, together get around 50,000 queries per second 🤯 most of that is "junk" (errors on the Top-Level Domain (TLD) name), but it gives you an idea of how much big data pours into name servers. and even "junk" can leak info! like, if there's a typo in the TLD, the user ends up sending data to a TLD that isn't the usual one 🙃

lowkey this one is so important: lots of domains, including TLDs, are partially hosted by third-party servers, sometimes in a different country 🌍 the contracts between the domain manager and those servers may or may not take privacy into account. whatever the contract says, the third-party hoster may be honest or not, but either way it has to follow its local laws ⚖️ so requests to a given ccTLD may end up at servers run by organizations outside that ccTLD's country. end users probably aren't expecting that when they do their security analysis 😭

and it seems (see the survey described in [aeris-dns]) that authoritative name servers are heavily concentrated among "popular" domains (like the Alexa Top N list) 👑 for instance, among the Alexa Top 100K, one DNS provider hosts 10% of the domains today 😱 the ten biggest DNS providers together host one third of the domains. so with control over (or the ability to sniff the traffic of) a few name servers, you can gather a LOT of info 🕵️‍♀️

2.5.3. Rogue Servers

the previous paragraphs talked about DNS privacy assuming all the traffic went to the intended servers and the potential attacker was purely passive 👀 but in reality, we can have active attackers redirecting the traffic. not to change it, just to observe it 🧚

for example, a rogue DHCP server, or a trusted DHCP server whose configuration got altered by bad actors, can point you at a rogue recursive resolver 😈 most of the time that's done to divert traffic by feeding lies for some domain names. but it could also just be used to capture the traffic and gather info about you 💅

other attacks besides DHCP are possible too 🙀 the traffic from a DNS client to a DNS server can be intercepted on its way from the originator to the intended source, for instance by transparent DNS proxies in the network that divert traffic meant for a legitimate DNS server. that rogue server can pretend to be the intended server and reply to the client with data 🎭 (rogue servers that inject malicious data are possible too, but that's a separate problem and not relevant to privacy, so we're leaving it there ✋)

a rogue server may respond correctly for a long time, which means it avoids getting detected 🫣 this might be done for reasons that sound good, like optimization or caching, but it still leads to reduced privacy compared to a situation with no attacker present 💔 also, malware like DNSchanger [dnschanger] can change the recursive resolver in the machine's configuration, or the routing itself can be subverted (for instance, [ripe-atlas-turkey]) 🌸

bestie takeaway: a practical consequence here is that solutions for DNS privacy may have to address authentication of the server, not just passive sniffing 🔐✨

2.6. Re-identification and Other Inferences

an observer doesn't just have access to the data they directly collect 🔍 they also get the results of various inferences about that data. iykyk 😌

for instance, a user can be re-identified via DNS queries 🫢 if the adversary knows a user's identity and can watch their DNS queries for a while, that same adversary may be able to re-identify the user just from their pattern of DNS queries later on, no matter where the user makes those queries from 🗺️ one study [herrmann-reidentification] found that this re-identification is possible: "73.1% of all day-to-day links were correctly established, i.e. user u was either re-identified unambiguously (1) or the classifier correctly reported that u was not present on day t+1 any more (2)." 😳 that study was about web browsing behavior, but equally characteristic patterns can show up in machine-to-machine communications too, or without a user doing anything on purpose, e.g., at reboot time if a characteristic set of services gets accessed by the device 🤖

for instance, one could imagine an intelligence agency identifying people who go to a site by putting in a very long DNS name and looking for queries of a specific length 🕵️‍♀️ that kind of traffic analysis could weaken some privacy solutions 💀

the IAB privacy and security program also has a work in progress [RFC7624] that looks at these inference-based attacks in a more general framework 📚

2.7. More Information

if you want more background, useful info can be found in [tor-leak] (about the risk of privacy leaks through DNS) and in a few academic papers: [yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], and [federrath-fuchs-herrmann-piosecny] 🎓🌈

3. Actual "Attacks"

a very quick look at DNS traffic might lead you to the false conclusion that pulling the needle out of the haystack is hard 🪡 "interesting" primary DNS requests get mixed in with useless (for the eavesdropper) secondary and tertiary requests (see the terminology in Section 1). but in this era of "big data" processing 💻 powerful techniques now exist to get from the raw data to what the eavesdropper is actually after 😤

lots of research papers about malware detection use DNS traffic to spot "abnormal" behavior that can be traced back to malware on infected machines 🦠 yes, this research was done for the good, but technically it's a privacy attack, and it shows just how powerful observing DNS traffic is ✨ see [dns-footprint], [dagon-malware], and [darkreading-dns].

passive DNS systems [passive-dns] can reconstruct the data of sometimes an entire zone 🗂️ they get used for many reasons, some good and some bad. well-known passive DNS systems keep only the DNS responses, and not the source IP address of the client, precisely for privacy reasons 🫶 other passive DNS systems may not be so careful 🙄 and there are still potential problems with revealing QNAMEs.

and then there's the MORECOWBELL surveillance program [morecowbell]. the revelations from the Edward Snowden documents (leaked from the National Security Agency (NSA)) say it uses the DNS, both passively and actively, to quietly gather information about users 😱 that's another great example showing that the lack of privacy protections in the DNS is actively exploited. it's giving surveillance 👁️🔥

4. Legalities

to our knowledge, there are no specific privacy laws for DNS data in any country 🙃 interpreting general privacy laws like [data-protection-directive] (European Union) in the context of DNS traffic data is not an easy task, and we don't know of a court precedent here ⚖️ see an interesting analysis in [sidn-entrada] 💅

5. Security Considerations

okay this section is literally the whole point 🔐 this document is entirely about security, more precisely privacy. it just lays out the problem; it does NOT try to set requirements (with the choices and compromises they imply), and it definitely doesn't define solutions 🙅‍♀️ possible solutions are discussed in other documents (there are currently too many to mention them all 😭). see, for instance, [QNAME-MINIMIZATION] for minimization of data or [TLS-FOR-DNS] for encryption 🦋

6. References

6.1. Normative References

[RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
           STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
           <http://www.rfc-editor.org/info/rfc1034>.

[RFC1035]  Mockapetris, P., "Domain names - implementation and
           specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
           November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
           Morris, J., Hansen, M., and R. Smith, "Privacy
           Considerations for Internet Protocols", RFC 6973,
           DOI 10.17487/RFC6973, July 2013,
           <http://www.rfc-editor.org/info/rfc6973>.

[RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
           Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
           2014, <http://www.rfc-editor.org/info/rfc7258>.

6.2. Informative References 📚

Okay bestie, these are the receipts 🧾✨ Every source the doc leans on, listed so you can go find the originals. Some are drafts still in progress, so the text might have shifted by the time you look.

Acknowledgments ✨

Big thank-yous, bestie 🫶 Nathalie Boulvard and the CENTR members get the first shoutout for the original work that kicked this whole thing off 🌸 Ondrej Sury gets love for the super interesting discussions 💬 Mohsen Souissi and John Heidemann did the proofreading, and Paul Hoffman, Matthijs Mekking, Marcos Sanz, Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari did the proofreading, technical remarks, and a ton of readability glow-ups 💅✨ Dan York, Suzanne Woolf, Tony Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis brought the good written contributions 📝 And finally, thanks to the IESG members for the last remarks 🎀

Author's Address 🦋

Stephane Bortzmeyer
AFNIC
1, rue Stephenson
Montigny-le-Bretonneux  78180
France

Phone: +33 1 39 30 83 46
Email: bortzmeyer+ietf@nic.fr
URI:   http://www.afnic.fr/
📦 where this page comes from