AWS re:Invent 2016: DNS Demystified: Amazon Route 53, featuring Warner Bros. (NET202)

all right welcome everybody my name is Sean Beck Leigh I'm with the Amazon ruff decree team with me is varam sue kiaus from warner brothers entertainment this is DNS demystified the intro to dns for Amazon Web Services just to quick show of hands to kind of level set how many folks in the room are familiar with route 53 Wow awesome how many have used a different DNS provider but not rough 53 cool how many have never touched DNS one guy nice and who how many are in the wrong session great all right so this gold is that this session is to really just give you what you the real basics of what you need to know to get up and running with DNS for your first application in AWS and so if you have your applications already running great you know maybe a primer refresher on some some topics talk about some features that you may not have known about but really to get you to that basic level of functional with DNS for AWS so we'll start the session with hopefully under five minute discussion of what is DNS so then a high-level how it works how it connects your users or your clients to your servers into your applications again what you need to know without going over overboard we'll talk then step by step of what you need to do to get DNS working to connect a user to your first application in AWS we'll talk a bit about some of the advanced features that AWS or rep 53 offers to improve the performance and availability of your applications in AWS using DNS and then I'll end it over to varam who will talk about Warner Brothers entertainment migration of very many domains over to route 53 for DNS so first what is DNS and under five minutes so let's say that you've launched your first web server and you want to serve a website using this server your server that's connected to the Internet will have an IP address let's say it's 1.2.3.4 the IP address is what is used for any type of client whether it's you know humans laptops web browser or another server somewhere on the Internet it's going to use the IP address to actually connect and talk to this web server however humans don't really like numbers they prefer names easier to memorize easier to type in and so let's say that you want to serve a website that has a human readable address let's call it WWE example com well you need something to translate WWE example comm into an IP address so that the browser or other client can it connect to this that's where DNS comes into the picture so let's say that you're hosting your website your web server in AWS have gotten ec2 instance and Scott might be address now you have a user with a computer and they want to go to WWE exsample comm it needs to be some type of lookup here so enter DNS DNS is basically a phonebook for the internet it changes names into IP addresses so computers can talk to each other DNS isn't just one server it's not just one system it's actually a very large distributed system with servers all across the internet belonging to different entities they all talk to each other and there's no single source of truth all of this lookup information this phone book is actually a very distributed system and any one server any one piece of the DNS system only knows a little piece it only knows kind of what its responsible for and then it knows pointers to other parts of the system which are responsible for other bits so this domain name is actually going to get broken up into pieces and you'll see how different parts of that domain name are known about by different parts of the DNS system so first you're the client is going to talk to a DNS server nearby a special server called a resolver and that resolver is typically run by that user's internet service provider so when you sign up for any internet service automatically you'll be configured to use the nearest resolver and the resolvers job is to take queries so for example whereas example.com and translated that into answers and the resolver does all the legwork of looking up different parts of that name to get a complete answer and then returns that to the client so the first part the first thing it does is ask the root nameserver the root name server is actually a set of name servers only know about the the last part of that domain name so ComNet org dot uk' and so on and it will return a pointer to the next part of the chain so the root name server will be get asked where is w WM comm and it will reply I don't know about WWE exsample comm but I do know about comm that's my job and so what it returns is a reference to another name server and this other name server then knows about com so the resolver takes that bit of information and then asks the same question to the name server for com where is w WM comm the name server for comm doesn't know about wwm comm but it does know about example.com so what returns a response saying I know who knows about what you're looking for it's actually route 53 so go ask route 53 who is the name server for example.com wait a second how does it name server for comm know that route 53 is the DNS provider for example.com well actually if you register that domain name you told comm about your DNS provider it may have happened without you knowing about it but when you register a domain name one of the most important things your registrar does is update that name server for the top-level domain so calm if it's a dot-com domain name with information about who your DNS provider is you can change that information if you want to switch DNS providers at some point so now the DNS resolver has information about route 53 knowing about this domain name so it asks the same questions rep 53 says where is it w WL com route 53 actually knows it gives back an IP address it's wwm com is at the following IP address now how does route 53 know well when you chosen route 53 as your DNS provider you create something inside of route 53 a resource called a hosted zone a host of zone is like a container for all of the individual records or trees for things in that domain name WWF calm food example calm bharden example calm and so on you create these individual DNS records inside that hosted zone something other resolver has a complete answer says back to the client and says here's the IP address the client then uses that IP address to connect over HTTP or whatever appropriate protocol to your server and you have a successful web transaction now all of this happens behind the scenes for basically any type of website lookup or any client to server communication across the internet just generally a DNS lookup followed by the actual connection to the server that you want to talk to this all happens generally without the users knowledge the web browser in this case is what's doing all of this these transactions okay so that's DNS in a nutshell you can run your own DNS server many people our customers do it however a managed service like route 53 provides several key advantages first route 53 doesn't just run out of one location or one server we have an anycast network which means that we have over 50 locations around the world generally going to be some very close to your end-users which provide a high degree of redundancy and also provides higher performance because those DNS queries don't have to go halfway around the world to be answered they'll be answered by a location is quite close to your end user because we have redundant locations as well as many other layers of redundancy we're able to provide 100% SLA on returning answers to DNS queries which is obviously very important because you need that DNS lookup to succeed in order for someone to reach your website you can also do some advanced routing using DNS for example based on the end users location you can give them a different IP address so you can route an end user to a location if you're running in multiple regions you could grab that user to a region that's closest to them for example you can also have 53 monitor each of your locations or each of your servers and if one of those servers were to go down or become unreachable route 53 can automatically respond by giving up a different IP address back up location so you can route your users around failed locations route 53 provides some integrations with AWS services it makes it easier to route traffic to things like elastic load balancing CloudFront distribution f3 website elastic beanstalk environments as well we'll talk about that later and lastly is easy to manage you can use the web console but there's also full support of managing anything interrupt 53 via the API command-line tools SDKs as well as a robust set of third-party tools so now let's look at the steps involved in creating and setting up DNS for your first website or web application okay so here's our diagram we're going to do four steps first you need a domain name so we'll register a domain name next and roughly threes DNS interface you're going to create something called a hosted zone in that host of zone you're going to create several DNS records that will point traffic to specific IP addresses or specific resources in AWS and then lastly we'll connect the domain name to the host as owned this is a very important step called delegation where you basically update your registrar with the correct name servers for your route 53 hosted zone this is what connects everything it makes everything work the first step going to be registering a domain name now route 53 actually provides a domain name registrar within the roughly three console and API so you can register new domain names throughout claim 53 will show a brief overview of how to do that you can also register a domain name somewhere else as many well-known registrar's that you can use and you can then connect those to route 53 will show both techniques so first this is the route 53 management console you log in go to route 53 and one of the things you see right there on the front page is a search box just like at any other registrar where you can search for domain names so here we'll search for example.com obviously the real world example com is taken but for the sake of this presentation we'll assume that it's available so we'll buy the domain name exam komm add to your shopping cart you can register for multiple years at the ten years will also automatically renew enter your contact information for the registration you can hide most of your contact details for most top-level domains which helps eliminate spam against your contact info and you complete the purchase and then we're done when you've registered a new domain name in route 53 will automatically create the matching hosted zone for you and do that delegation piece so you don't have to worry about okay however if you a disturbed domain name through an existing or other registrar let's say you already own a domain name through some other registrar you're going to have to eventually update some information at the other registrar specifically that something called name service so if you've already registered a domain name with a different registrar you're not yet using ref 53 chances are that you're getting free DNS service from that registrar so here you'll see this is the other registrar's web console you'll see some listings under name servers we'll come back to this in a bit we're going to actually update this section with you route 53 name service so that's domain name registration either through route 53 or through another registrar now let's create the host is up again if you've already registered domain name in route 53 we've created this hostess out for you however you allow you to create one a few registered to a different registrar so we'll look at the hosted zone you go to the hostess owns tab in Roth 53 see example.com listed you click on the name and now we're in the hosted zone you see that there's already two DNS records created in this houses own for you automatically these are the default records in every host ism the one that we're most concerned about is the top one of type NS or name server and you'll see that there's four entries here these four entries are the four specific name servers for this hosted zone in route 53 now every host is own by default gets a unique set of the four name servers so it is very important when you're using route 53 to enter these exact values for whatever host is that you have at your registrar so now let's assume that we've registered the domain name through route 53 as well go to your registered domains tab you'll see your domain name you look through and you see now some name servers listed for your domain name since you registered this domain name in route 53 we've already connected everything for you and so those name server names match exactly this is what you want this means that route 53 is DNS service will be serving DNS traffic for this domain name now if you've registered the domain name through a different registrar you're going to need to create a HOSA zone so you go to the hosted zones tab click create hosted zone enter the domain name this has to obviously exactly match the domain name that you own you can create a comment if you want and then you're going to leave the type drop-down to its default setting of public hosted zone so now you'll see some records in this hosted zone again the NS record is the one that is most important to look at for now you'll see for name servers listed again these are going to be unique to this hosted zone now that we're in your route 53 hosted zone we're going to create some records that actually direct traffic to your web server now you can create records for your domain name itself so example.com we call that the root domain as well as names inside or sort of children of that domain so for example you can create wwl com my site example.com food bar.example.com and so on these are called subdomains lastly you can create records that match any other name that someone might enter into their web browser that would be a subdomain that you don't have an explicit record for so these are called wildcard records ok so we'll create all of these and show show what that looks like ok so looking at your hosted zone you click create records set now you're presented with a dialog that gives you a couple options here the first is a name field now we're going to create a record for example komm first so we've already filled in the example.com part because that's your hosted zone so you don't actually need to type anything into that text box at the top down below in the value field you're going to enter the IP address of your web server and click create and now you see the record listed now let's create the same thing for wwx ample com so here in the name field you're going to enter your subdomain which is WWE value you can enter the same IP address or if it's going to a different web server you could enter a different IP address if you want multiple domain names or subdomains to be served by the same IP address there's actually several other options you can use here we'll talk about those in a minute where you don't have to enter the same IP address over and over again so we'll do that we'll take one of these other options something called a cname we're going to create our wildcard record so the symbol for wildcard is a star or asterisk so we'll create the record start at example.com and the type we're going to change that for the default we're going to select something called a cname a cname means you're not going to give an IP address instead you're going to give another name another DNS name and when that DNS lookup happens the user is ultimately going to get the IP address belonging to that other name so here we're going to enter as the value for the cname record example.com what this means is that when a user makes a query for something that's answered by this record they're going to get the IP address back for example.com click Save and now we have three records created in our hosts and sewn in addition to the default two now there's another option that's important to think about for route 53 which is if you are creating a domain name or DNS name that you want to point to something like an elastic load balancing load balancer elastic beanstalk environment s3 website bucket or CloudFront distribution all of those things have IP addresses that can change and so you don't want to hard-code the IP address for those resources also you can't create see name at the root domain so for example calm that name itself can't have a cname record having a cname record at that point in your host as though it actually breaks DNS lookups and so it's not allowed instead this is feature called alias alias tells route 53 to go fetch the current IP address for whatever resource you've aliased to and give that back as a response so what we're going to do here is create an alias record and you can create that alias record and point that to your elastic load balancer or any of those other resources I've mentioned route 53 will always fetch in real time the correct set of IP addresses for those resources so to create an alias record you're going to select the radio button for alias and you'll be presented with a drop-down list where you can select all of your resources and you can select which resource you want to alias to you can also then alias to other DNS records in that same hosted zone if you want so again the services that route 53 currently integrates with for alias functionality are the following for the last cue cloud from s3 website there is another consideration here which is that you need to configure your resources in those services to look for that same domain name in other words your CloudFront distribution you need to create something called an alternate domain name that exactly matches your domain name and the s3 website bucket if you're going to use that the s3 bucket name actually also has to exactly match the DNS name so if I want to create an s3 website bucket for wwl com when I create the SPO website bucket I have to call that bucket WW example.com other types of records that you'll likely want to create in your host is own it would be for example an MX record an MX record is for email if you want to receive email at this domain name your email service provider will give you all the information you need to create that MX record MX stands for mail exchanger txt is a text record you can store arbitrary bits of text in those records typically used for things like validating that you have or that you're the authorized sender for email from that domain name also used for setting up web analytics in many cases for your website it's also a common way for vendors of SSL Certificates to verify that you actually own that domain name they'll give you a text string tell you to create the following text record in that hosted zone when you create that and your certificate vendor will know that you actually only control that domain name so now we've created your hosting zone but all the records in there that you need next step is to delegate which means to connect your domain name to route 53 so that route 53 starts serving DNS traffic for that domain now if you view is route 53 as a registrar we've already done that for you we've already created the hosted zone and domain name and delegated between them again the name server addresses are going to be listed for your host zone in that NS record in your host is up the four name servers the term for that that set of four is called delegation set again that delegation set is going to be unique to you as a customer no other customers HOSA zone will share that same set of four name servers this carries the benefits for example as something there were to be some type of issue with another customers hosted zone you're isolated from that because you have who will have at least two mini cases three or three or four different names or addresses from that affected customers so every customer is isolated across name server addresses also makes it very important that you copy and paste the exact name server names for your host of zone so now again this is the graph the three registrar interface will already populate this for you in the name servers section with your name servers if you're with a different registrar you're going to go to that other registers web console go to the name service section and replace what's already in there with your delegation set your 4:53 name servers and now you're done you've made all the entries that you need to do for reps you're free to start serving traffic for your website however this if you're already using a different DNS provider that change can take - two days 48 hours to become fully effective and the reason is that these nameserver entries are cached or saved for periods of time across the DNS network around the world and those are typically cached with time to live of 48 hours which means that lead to expire before rep d3 is fully serving all of your traffic so to recap we've done four things we've got a domain name created a hosted zone created records in the Xhosa zone and then we delegated to it now there are some tools that you can use to verify that you've got everything set up correctly the most popular tools are dig in the Linux environment and nslookup in the Windows environment we'll look at dig here nslookup functions in a very similar way so here we have our Linux prompt going to type dig example.com and this is the response you get back so there's a lot of information here the thing we're looking for is in the answer section that example.com was answered with an a record and with the following IP address so we see that we were able to get an IP address back for example.com another useful query to do via this dig tool is to make sure that you have the right name servers configured so here you do dig in the s uppercase example.com and here we're not getting back an IP address we're getting a list of the name servers active for example.com here you can see the route 53 name servers shown another useful option is to skip all of the cached or saved DNS responses and make a query directly to each of those name servers that we showed in that diagram starting with the root name server then the name server for your top-level domain and then route 53 and so on you do this by doing dig than the domain name and then with the option plus trace the response is going to be very verbose it's going to scroll off your screen but we've condensed it a bit here to show of each of the different queries that happened first was a query against your root name server that's the top row that gave back in answer for com query against that name server then gave back an example or the response for example.com and finally the query against route 53 gave back the IP address which is shown as 170 5.41 dot 145 dot 117 all right so that's basic DNS now you have DNS working for your first website we'll talk a bit about some of the advanced features you can look at in RUP 53 as you grow your application first is when you move from a single server to multiple servers serving your application well say that you're within a B PC or virtual private cloud it's not just users humans that want to use DNS in very many cases for machine to machine communication DNS is also going to be involved so for example if a server wants to connect to a database typically there will be a DNS lookup involved for DNS within your VPC you can create something called a private DNS hosted zone this allows you to create DNS records for all the internal pieces of your architecture and it has several advantages over Public DNS one is you can use any domain name you want you don't actually have to own the domain name so I could call this my domain name Shawn internal for example without actually having to own that next is private DNS is only visible inside your V PC so users on the public Internet can't find out the guy P addresses of the pieces of your application and they also can't find out the names so you're able to hide your topology if your work or our protector as well as the actual IP addresses another useful feature for Public DNS is health checks and failover so this allows you to set up things like a backup web server in case your primary web server were to become unreachable RUP d3 can provide a health check for you of that primary web server and if that shows that your primary web server is no longer reachable route 53 will automatically stop giving out the IP address of that primary server and instead give the IP address of your backup web server you can also run multiple active servers at the same time each with a health check and at any of those servers were to go down or becoming unreachable route 53 would simply remove those from the response it gives two uses you can use several different routing techniques for multi region applications so let's say you want to run a multiple AWS regions to get closer to each of your end-users around the world route 53 offers a couple of different routing techniques to route based on either the fastest internet connection between your users location and the region or by geography so you can do Geographic restrictions they all uses from countries X Y & Z must go to this region or some combination of those different routing logics and lastly if you want to get very sophisticated and have multiple levels of routing decisions so by continent and then also by internet latency and then also let's say with failover between different regions you could combine all of these using a tool called traffic flow traffic flow gives you an intuitive web console based a sort of flow chart you can build out these routing decisions with each of the different rules geography round-robin distribution failover and so on that ultimately would lead to a given end user being routed to one of the multiple servers or multiple locations this traffic flow flow charts are then called a policy and that policy is also represented in text format you can export that version control it you can also then roll back to previous versions if he was very nice way to manage sophisticated routing without having to and add a whole bunch of individual DNS records traffic flow we have a session coming up tomorrow encourage you to visit that session if you want to learn more about it now I'm going to hand it over to varam who will talk about Warner Brothers Entertainment vibration throughout 53 Thank You Shawn thanks for having me hello everyone my name is varm sukhiya I'm the VP of application infrastructure and operations thank you over our warner brothers quick show of hands how many of you are considering migrating your public dns to route 53 ok so I have some particularly useful information for you which I hope will save you some time if you're not considering it I hope I saw some good info for you should be able to wrap up ahead of schedule so if you have questions again feel free to line up at the microphone happy to take them so before I get into our migration tale our story of how we moved all of our public dns traffic to Roth 53 I like to set some context first so I'll talk a little bit about Warner Brothers who we are valuable context how we use AWS and how we've used it over the years what our DNS setup look like prior to moving to route 53 the road we took to route 53 no pun intended our results and what's next for us so who are we we are a global leader in the creation production distribution licensing and marketing of all forms of entertainment now most of you I'm sure know us for movies and TV shows we also have big gaming divisions so for you gamers I'm sure you've played several of our titles before but that's who we are now I put the word global in bold and italics for a very important reason I'll cover that in a second but with all of these divisions that produce all this content and entertainment comes a lot of applications and a lot of domain names to the tune of over 25,000 which I'll talk about a little bit more in a bit so how we use AWS in the past we actually have a long history with AWS we have some divisions that have been using AWS for many years most notably brands such as TMZ and their main website tmz.com DramaFever one of our gaming studios turbine and others but there are some units some groups such as ours that are in the process as we speak of migrating our applications to the public cloud namely AWS so the primary drivers and this is speaking across my interactions with different people at the studio the primary reasons for moving to the cloud is the four that are in the middle of screen there so application isolation and billing clarity go hand in hand a very common pattern across WB is is a group stands up a data center they start pouring a few hundred applications into the data center they're all you know sitting on maybe you I don't know how many VLANs maybe one maybe ten but ultimately over time what happens is you lose the true cost of ownership of an app of an application so we take what I'll call you know quote unquote micro data center strategy we stand up these little virtual micro data centers in a cloud we have over 150 as we speak and those accounts lose map map loosely to an application sometimes it's you know an environment of an application sometimes it's a group of similar applications but point being we're now further isolated which gives you security benefit if something happens to one application the odds of it impacting another one in another account that's now gone right so security comes hand-in-hand not to mention the the automation and security features that come to AWS but that's not what this talk is about agility is your the one I'm sure you all love spinning up VMs and having it come up in two minutes that's also a big factor for us we enjoy that as well so what did our setup look like before moving to route 53 um it was an on-premise solution well I'm premise was a little bit of an incorrect term there we had two VMs running in AWS one in East one in West one VM running in a datacenter and those were three name servers running by nine no cell service so my group manages most of the domains across the studio like I said over 25,000 of them that means that if someone wanted to do some kind of maintenance 2:00 a.m. on a Saturday it's a ticket that comes in to my group someone has to wake up at 2:00 a.m. take care of them resolve the ticket off we go not the mo friction-free way of doing things so self-service is an important consideration for us with these three VMs also comes poor fault tolerance our three VMs are far less than the points of presents that are available in route 53 and we all saw what happened a month ago with that big DNS outage right so if that could get overpowered imagine what you could do to three VMs poor geographic distribution like I said one in East Coast two on the west coast that means that international lookups suffer we are global company as I said earlier so why should the experience from Europe or Asia or anywhere else suffer because we're not properly geographically distributed it's a very often overlooked component of application performance if you could get DNS performance increased your application will respond quicker just easy win 25,000 plus domains that that was a scope of what we had to migrate some zones were quite big Warner Bros comm has over 10,000 records within that zone file but ultimately the takeaway for any of you that are running an on-premise DNS solution whether it's bind or tiny DNS or whatever you have out there Microsoft DNS ultimately the one takeaway and I'm a big believer in this is is if you operate DNS without an API in front of it it's pure misery and that's one of the things that we of course got as part of our migrations about 53 so prior to doing the move we had a few things to consider one was the domain registration process when you have 25,000 Domonique warming and that process have to continue running smoothly we also have to devise a scheme for reusable and hopefully WB branded delegation sets then we have to find a way to import and validate thousands of zones and mind you we did a lot of this work behind the scenes we did notify some groups of course but at least to the average WV employee this was happening very much behind the scenes if we missed one record during the import process and an application went down because of it that's a big problem so we were shooting for 100% accuracy anything less than that is a failure then we also have to verify that that I am and zone delegation works exactly as advertised because what would be the point of moving to route 53 and then not be able to give someone self service to manage their own zone kind of defeat the purpose so we have to check that box and then we have to worry about raising several around 53 default limits so this is a screenshot taken maybe a month or two ago I don't know if anything has changed but of the default limits that you get with route 53 so we spun up an AWS account that's where all of our zones were going to go into and then we proceeded to raise limits so 500 zones per account that's obviously way too low for us we got that raised reusable delegation sense I'll talk about the importance of why that is in a second but we bumped that limit to 2000 which I believe is the highest it goes that's for hosting cells per delegation set yep and then we have to bump the resource record set limit like I said we had some zones on 15,000 records within them so we're now done our limit for delegation sets us 2,000 that means we can migrate zones and chunks of 2,000 domains so imagine having to work with your registrar and telling them we want to cut over this many domains right the bigger that list is the easier it is for us and our goal is to finish this project in roughly six weeks pretty short timeframe considering that volume of domains so the bigger that limit was the more chunks the more domains we could fit in the chunk less work we have to the Registrar speeds things up so in order to fit in that six week time frame we're talking two to three batches of 2000 domains per week very next up we had to write a tool to validate those zones as we transfer that as we transfer them to route 53 to ensure for that hundred percent accuracy so we did that and then we wrote a tool to easily set up new domains so if you're the person in charge of acquiring domains for WB and you have to guess which delegation set isn't exceeded kind of hard right so we abstracted that logic now they could go in register the domain it automatically creates the zone file within route 53 and it assigns it to a delegation set that's available then we have to lower TTLs so this is a fail-safe we lowered it on the bind side then imported into route 53 if something were to go wrong for whatever reason the time to cut back would be shorter while we figured out what what happened luckily we didn't need to do this so then we picked up the phone and gave Shawn and his team a call and we talked about what the right way was to do is and they recommended an open-source tool called CLI 53 it worked for the most part and this is what I mean by the most part so what you're looking at here is a pull request that is now thankfully merged into the project so this is actually a documentation fix believe it or not in route 53 when you create a zone there's a name with the zone and then there's a zone ID doing lookups by zone ID is quicker and when you're trying to import 2000 domains at a time it slows down drastically if you try to do things by name you have to delete the zone it slows it down so we couldn't even tactically accomplish that those chunks of 2000 by passing in names to CLI 53 now it turns out that this wasn't a big deal because the code have a concept of zone IDs but the documentation didn't States though so the pull request literally changes the argument flag to say hey you could pass a name or you could pass an ID great now we're good the second issue we found for the most part zone IDs are 12 characters so we got through I don't know how many thousands of zones that we imported successfully and then boom hit a bug it would not import why the zone ID was 11 characters I believe it could also be shorter than that so technically this isn't 100% accurate but this enabled us to complete the project we didn't hit that bug again so simple fix to a regular expression to shorten the character length enforcement of a zone idea so hopefully that doesn't happen to anyone else here hopefully we paved the road for you guys but that's what those two fixes work so what were our results 25,000 zones got it done in under six weeks pretty impressive the big takeaway was that upfront investment in automation made all the difference in the world to my knowledge no one picked up the phone and said my application is down because some record didn't come in so as far as I'm concerned it was a slam dunk hundred percent air free and now of course we have the benefit of allowing people to self-service on there zones big win everyone's happy and excited of course we also gain the soft benefit of that greatly reduced risk of a DDoS attack taking down DNS like I said earlier I'm sure Amazon's network is is considerably more capable of taking that on than our three VMs were and last but not least increased performance that I alluded to earlier so this is a map of what it looked like before this is using a synthetic monitoring tool that my group uses called cashpoint it's a geographic map of DNS latency around the globe so what this is literally doing is doing like in Shawn's example earlier earlier a dig against what was n s Warner Bros comm I believe and then recording the latency so Green is close to zero makes sense right westcoast has has some has some good numbers east coast a little bit better a little bit we're sorry going out to Europe and Asia awful at the end of the date speed of light you're not going to solve that by simply being in the East Coast and this is afterwards you can see our European customers are now a lot happier a lot more green they're some bread in China India so I was actually talking to Shawn about this earlier this is going against one of the name servers that is that is associated with a domain behind the scenes that gets shorted out to multiple locations so if the test were to occur across all four name servers that would get flattened out and fortunately couldn't do that in the tool but overall lesson learned more of the story performance got significantly better around the globe and here's a screenshot of what it looks like these are a branded delegation sets so this is a DNS lookup against four NS records against Warner Bros com and you can see it's branded with a WB name NS one through four is a standard convention and then the part after the - that's how we cycle through delegation sets so A to Z 1 to 9 and that gives us plenty of headroom you know a mm per per delegation set then we could fit an eternity worth of domains I'm sure so what are our next steps while we have self-service at the zone level what we don't have today is self-service at the individual resource record level Warner Bros comm as I said earlier 15,000 individual resource records underneath it different groups control those individual resource records or should have ownership over those resource records we don't have that fine grain level of allocation to those groups so something we're looking forward to solving in 2017 hopefully they beat us to the punch we'll find out of a little race and then of course we also want to start leveraging the advanced traffic policies and health checks that Shawn's spoke of earlier lots of benefits to doing that but we simply didn't have in the bind world and last but not least we're certainly not a two year old startup it's amazing how much cruft builds up in DNS over time and I never seen that before and not having worked at a company that's been around for as long as Warner Bros before in my past but lots of clean up to do unfortunately you know groups often times will retire an application they'll forget about retiring DNS it stays in DNS forever what that means downstream is paying more for zones that are no longer needed slower API responses because your zone has 15,000 records underneath it whereas if they have you know five or ten things are faster so it's a good hygiene measure that we'll be taking in 2017 as well and with that thank you very much if you have any questions feel free to step up to the mic

Channel: Amazon Web Services

Views: 29,733

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud, AWS re:Invent 2016, aws reinvent, reinvent2016, aws, cloud, amazon web services, aws cloud, re:Invent, Networking, NET202, Sean Meckley, Introductory (200 Level)

Id: AAq-DDbFiIE

Length: 42min 59sec (2579 seconds)

Published: Sat Dec 03 2016