Home / Blogs

What’s Up With WEIRDS?

Protect your privacy:  Get NordVPN  [ Deal: 73% off 2-year plans + 3 extra months ]
10 facts about NordVPN that aren't commonly known
  • Meshnet Feature for Personal Encrypted Networks: NordVPN offers a unique feature called Meshnet, which allows users to connect their devices directly and securely over the internet. This means you can create your own private, encrypted network for activities like gaming, file sharing, or remote access to your home devices from anywhere in the world.
  • RAM-Only Servers for Enhanced Security: Unlike many VPN providers, NordVPN uses RAM-only (diskless) servers. Since these servers run entirely on volatile memory, all data is wiped with every reboot. This ensures that no user data is stored long-term, significantly reducing the risk of data breaches and enhancing overall security.
  • Servers in a Former Military Bunker: Some of NordVPN's servers are housed in a former military bunker located deep underground. This unique location provides an extra layer of physical security against natural disasters and unauthorized access, ensuring that the servers are protected in all circumstances.
  • NordLynx Protocol with Double NAT Technology: NordVPN developed its own VPN protocol called NordLynx, built around the ultra-fast WireGuard protocol. What sets NordLynx apart is its implementation of a double Network Address Translation (NAT) system, which enhances user privacy without sacrificing speed. This innovative approach solves the potential privacy issues inherent in the standard WireGuard protocol.
  • Dark Web Monitor Feature: NordVPN includes a feature known as Dark Web Monitor. This tool actively scans dark web sites and forums for credentials associated with your email address. If it detects that your information has been compromised or appears in any data breaches, it promptly alerts you so you can take necessary actions to protect your accounts.

The IETF WEIRDS working group is defining a follow-on to WHOIS. Since this is the IETF, it’s working on the technical issues about which it can deal with, not policy which is up to ICANN and the country registries.

Somewhat to my surprise, the group is making steady progress. We’ve agreed that the basic model is RESTful, with queries via http, and responses as JSON data structures. The protocol is named RDAP for Registration Data Access Protocol, or maybe RESTful Data Access protocol.

Each request asks one question and requests the response in JSON. (If a server wants to respond with something else like a human-readable web page for requests that don’t ask for a JSON response, that’s fine but it’s also beyond the scope of the spec.) If a different server has the answer, e.g., a registry referring to a registrar, a normal web redirect handles that.

The query and response formats are mostly worked out, both for the numbers registries (IP addresses and related data) and names (registrations in top level domains and the like.) My concern was that the group would get bogged down in nitpicky details, but they seem pretty well under control.

Last week there was a skirmish about search options. ICANN did a WHOIS survey a while ago, and when they asked people what search options they wanted, complex patterns, combinations of fields, pagination to return answers in chunks when there were too many to return all at once, not surprisingly people wanted all of them. Someone claimed these were requirements, which they’re not. Of the existing servers that provide any searching at all, they do a simple prefix match on specific fields, like abc* to match names that start with abc, with a fixed maximum number of results, usually 50. I suggested that’s all we should put in the spec unless we can identify specific registries that plan to implement something fancier, and after a couple of rounds and no registry offering anything fancy, that seems to be the plan. There are still technical details to work out, like how to distinguish searches for ASCII names from Unicode names, but that shouldn’t be too hard.

We’ve also had long discussions about bootstrapping, how to decide which server to ask for each query. For numbers, the assignments of numbers to registries changes very slowly, less than once a year, and the five regional registries (RIRs) know each other and can refer queries to each other, so the bootstrap hardly matters.

If a client program has a built in set of ranges and registries, or just sends all the queries to the local registry, it’ll get redirected if the answer is somewhere else.

For names, the bootstrap is a little harder since there are currently over 300 TLDs, and in the next year or so the number is likely to increase to about 2000. Different TLD registries don’t usually have relationships with each other, so if a query is initially sent to the wrong registry, it has no incentive to redirect to the right one. Given the number of TLDs, a fixed bootstrap would quickly get out of date.

My suggestion was until recently that IANA, the branch of ICANN that among other things handles the names in the root zone, publish the server names in a fixed place in the DNS, e.g., the server for the .foo domain would be at foo.rdap.arpa, so the URL could be something like

http://foo.rdap.arpa/domain/somename.foo

Other proposals were a downloadable web page at IANA, a pool of bootstrap servers (plausible for numbers but completely unworkable for names) or putting the bootstrap info in the TLD itself with a SRV or NAPTR DNS record. I wasn’t thrilled about SRV or NAPTR since they aren’t easily usable from javascript or shell scripts and was pushing for the rdap.arpa approach until at the IETF meeting two weeks ago people from several different TLDs said that dealing with IANA is so tedious that they REALLY don’t want to go that route. So we’ll probably have SRV records in the TLDs. For the benefit of lazy shell and javascript programmers, I’ve reserved rdap-servers.net and hope I can make it work as an informal equivalent of rdap.arpa, extracting the host names from the SRV records.

At this point there are a fair number of technical details left, but nothing that looks terribly hard to work out, so with any luck, we’ll have a new WHOIS design ready to go around the time the new ICANN domains go live early next year.

By John Levine, Author, Consultant & Speaker

Filed Under

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

Related

Topics

IPv4 Markets

Sponsored byIPv4.Global

Cybersecurity

Sponsored byVerisign

DNS

Sponsored byDNIB.com

Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API

New TLDs

Sponsored byRadix