Объяснение происхождения имен серверов Cloudflare: от решения технических конфликтов до ниндзя-ниндзя

What's the story behind the names of CloudFlare's name servers? We're going to do a series of blog posts about some of the inner workings of CloudFlare. One of the questions we get often is what the names of our name servers mean. Here's the story. Two Names Enter When someone signs up for CloudFlare, we give them two domains for their name servers. For example: - bob.ns.cloudflare.com - lola.ns.cloudflare.com So who are Bob and Lola? To understand, you have to understand a bit about a problem we were trying to solve. Slick signup We worked to make the sign-up process for CloudFlare as easy as possible. Typically, it takes users about 5 minutes to complete. Imagine you own example.com and want to sign up. You enter example.com on our sign-up form, we slurp your DNS records and allow you to add any we've missed, then we give you your two name servers that you enter at your registrar. We have systems that almost instantly push your records to our DNS servers at the edge of CloudFlare's network. As a result, when you switch to our name servers at your registrar, your site will be served as normal without any downtime. In most cases, this is all easy. One problem we worried about early on was simply: what would happen if two people signed up the same domain at the same time? Resolving Conflicts Imagine two people sign up example.com at the same time. We now have two sets of DNS records and it's not clear which one is accurate. We needed a clear way to tell which record is authoritative. What we needed was a way to embed a code in the name server names themselves so that, when we saw the first DNS request on our network, we could test what name servers domains were authoritative for the domain and return the correct DNS records. In the first iteration of CloudFlare's signup process, the name server names were in a relatively standard format: - dns1.cloudflare.com - dns2.cloudflare.com - Etc… We would pair those together to create a unique combination. If Alex signed up example.com he may get dns7.cloudflare.com and dns23.cloudflare.com. If Betty then signed up example.com then she may get dns3.cloudflare.com and dns84.cloudflare.com. When we received our first DNS request for example.com then we'd test what name servers were actually entered at the registrar. Assuming it was dns3 and dns84, then Betty's sign up would be considered valid and the DNS records she entered would become authoritative. Out clevering clever users What we found was that a lot of people saw these DNS domain names and tried to be clever. While it may seem that the two domain names only point to two physical servers, in fact they reference potentially hundreds of servers running in all of our global data centers. While we tried to explain that adding more domains wouldn't actually result in your queries being served by any more name servers, we found users tried anyway. Betty may have received dns3 and dns84, but we found sometimes she'd try and enter dns3, dns4, dns5, dns6, and so on. Not only did this not actually add any benefit, it would cause our verification to fail. Our solution was to come up with domain names where the sequence wasn't obvious. We spent an afternoon generating a list of one hundred common 2- to 4-letter names, like Bob and Lola. We then used them to create the domain names we handed out at signup. Initially there were 50 boys names and 50 girls names. Everyone who signs up gets one of each, allowing for 2,500 unique combinations. One side note on this point: we once had someone write in to support criticizing us based on the fact that our name server convention is hetro-normative. I will simply say that just because you get two name servers doesn't mean they're in any kind of relationship. I do, however, believe that diversity in the workplace is a good thing. The story of Woz To add some personality to the name servers we commissioned an artist to draw representations of the 100 name servers as if they were ninjas. While we've never done much with the drawings, we liked the metaphor of two ninja name servers protecting your website. As a perk, we allowed some of CloudFlare's early team members (e.g., Lee Holloway & Ian Pye), investors (e.g., Ray Rothrock & Carl Ledbetter), and even Sam Coates, our corporate counsel, to pick the representations of their namesake ninjas. One of the drawings featured a smiling ninja on a Segway. It immediately reminded us of Apple co-founder Steve Wozniak, who lived not far from our office which was at the time in Palo Alto, California. It wasn't uncommon to see Steve, who was affectionately known as Woz, scooting around town on his Segway. I'd been a fan of Woz since I was a kid, having learned to program on an Apple GS. When I was 7 and graduated from that to a limited edition, Wozniak-signed Apple. While it wasn't a name on our original list of 100, when we saw the ninja on the Segway it was obvious we needed to include "Woz." We'd already put the 100 name server names into production, so we couldn't just eliminate Bill to make room. So we appended a 101st name (51 boys, 50 girls). As of today, there are 13,899 CloudFlare customers who have Woz as one of their name server domains. Two domains, many combinations, many servers Given the 51 boy name server names and the 50 girl name server names, we have 2,550 unique combinations. This has been more than enough to ensure that the correct DNS records are pushed to our network, even when two people attempt to sign up the same domain. Once the verification step is complete, the names of the name servers lose their technical importance. The servers in CloudFlare's infrastructure are configured to be able to respond to any request for any one of our customers. This allows us to granularly load balance across our entire infrastructure. While we typically provide just two domain names, in fact they reference many servers running across CloudFlare's network of 23 data centers distributed around the world. While you may get Bob and Lola, and someone else may get Stan and Amy, in fact they are both sending requests to the same elastic pool of resources. This flexibility has allowed us to build one of the fastest, most robust Authoritative DNS networks in the world. And, while the names may have seemed like just a cute addition, like most things we do, there was actually a good, technical reason for why we did what we did.