 I'm Anthony Eden, I am the creator of DNS Simple, which is a hosted DNS service and domain registration provider. And today I want to talk a bit about the domain name system and DNS and how you can use tools that you have right at your disposal, Ruby, the command line, things like that, to do things with it, to query it and also to modify it. So first of all, a little bit of background. The whole point really of the DNS system is so that we don't have to address things by numbers. It's almost like if every one of us in here were addressed when we were speaking to each other by our phone numbers. So it's like, hey, 321-505-0025, how you doing? That wouldn't work very well. So the whole principle behind it is to be able to have a human system that can be used to address machines or devices or whatever, and more importantly, to build a system that would be able to scale out as other systems were added. So a hierarchy was essentially chosen, where you have providers of names at the root, those are guys like com, net, and org. And then at the next level you might have organizations like Google and Apple, things like that. And then internally inside of those organizations you have other subcategories and suborganizations. So it was built, the hierarchical system was built to make it very easy to name and address all of these devices that were starting to get connected to the internet. So the basics of it, the domain system all starts with registering a domain. So that's where everything begins at. And there are, and I'm actually looking here, I don't have my presenter notes. So there's going to be some little tidbits that if you're interested in I can go in afterwards, things like dates. But there's three real entities involved when you register a domain. You've got the registries, so those are the guys that actually manage the massive database of domains. They're the ones you go to say, is this domain available? Is there somebody else who's registered it? You have the registrars, those are the companies that essentially resell those domains. Those are the ones that provide the interaction from the registrons. And that's you guys. So these are the three key players when you talk about domain registration. For those who might not know, the .com and .net space used to be managed by one company at the time. It was network solutions. It was deregulated in 99. And in 99 actually was when I got involved in domain registration. I worked for one of the seven, the first seven domain registrars that was accredited by I can, which is the board that oversees all this, to resell.coms.net and .orgs. So it has a history that goes back even further than that, but that really is the point where things started to grow quickly. Because all of a sudden people could start to speculate on domains. And you saw a very, very rapid uptick in domain registration. Everything from company name registrations to variations on common keywords. And that's grown just exponentially over the years. At this point in time, I think that there's something like 100, almost, I think actually over 200 million domain names registered across all the various TLDs, obviously the largest being in the .com space, which has something like 90 million, I think, somewhere around there at last time we checked. So anyway, the domain registration is the first part that you all probably have done at one point or another. DNS is the second part. This is the point where somebody says, okay, now you've registered a name. And I need to be able to take that name and point it to resources, whether it might be an IP address for a machine. Or I might, that's ultimately where everything sort of gets pointed to. Alternatively, it might provide hints as to what mail exchanges you should use when delivering mail. I'll go over the records in a little bit. So DNS is actually the domain name system. That's the collection of servers that are all over the world that are serving up the domains and the records to anybody who tries to connect and does a lookup. It's a distributed system. There are some main central players. So for example, in the .com space, there are 13 listed name servers. Behind that, there are likely more. So in other words, even though you have a single IP address, most likely that is actually corresponding to multiple machines behind the scene. But the point is that they're distributed all over the world. No one entity controls all of these DNS servers. You have servers that are in the United States, servers that are in Europe, servers that are, I think, Asia and Australia as well. Anyway. So it's a DNS system. And then that, from those routes, it goes out to the DNS systems that the companies and the organizations provide where they can put in records that have been delegated to them. So for example, Google.com gets delegated down to servers that Google manages, which then internally may delegate further down the chain to servers that are managed inside of departments. If you've ever been to school at the university, a lot of universities structure their system so that they really decentralize their DNS and departments might even manage, at least it used to be this way, they might even manage their own DNS servers. So you got DNS at that level. When you talk about DNS, like I was saying, you've got root. So these are essentially the .com, .net, .org, those are the routes that, those are where all the requests go to start. You have authoritative name servers. So these are the name servers that are said, I am actually responsible for the maintenance of these records for this particular domain. And then you have recursive name servers, and these are name servers that are essentially out there that when your computer, your laptop that you might have flipped open or your iPhone goes to look for a name, the first thing it usually does is go ask a recurser, whatever is nearest to it. It says, do you have this? The recurser says, I don't, or I do. And if I don't have it, it says, I don't, but go look here because these guys have it. And essentially then you recurs, it starts back and it says, well, if you don't have something .com, who does? Well, we may not know that, but here's who has .com, goes back down to the roots, says, okay, you have .com. Tell me who has this second level domain. So Google.com. Then it says, oh, that's handled by Google. And then it returns the results. And ultimately that recurser caches that so that lookups are very fast after that first lookup. DNS lookups generally are very fast on a whole relative to a lot of the types of transactions we're used to. A lot of us, I don't know if all of us do, but a lot of us have probably, at one point or another, built a web app. So the times for doing queries onto a DNS server are usually, well, maybe not if you're Google, but in a lot of cases, orders of magnitude faster than what you get to an HTTP server. I don't know if we'll have time to go into why that's the case, but we can talk about that a little afterwards if you're interested. So inside of these DNS servers, you essentially have two things. You have the domain itself, usually, which is the zone. That might be a term that you've heard. And then the zone has a whole bunch of records inside of it. And the records are everything from A records, which represent an address. So it says, OK, this name points to this IP address. That's where everything ultimately resolves to, or in many cases does. You have other records like CNAME records, which are, say, the canonical name for this record is over here. So that's sort of like an alias pointing to another record. And X records, which are for mail exchanges. OK, if you want to hand me mail, here are n number of mail servers that can deliver mail for me. I've given them the ability to do that. And then you've got also more esoteric records, things that you might not have heard of, things like NA pointer records, which are relatively new. How many of you all know what an NAPTR record is? The good news is the software you're using doesn't either, so you're OK for the moment. Eventually it will, and it's used for things like enum, which is reverse lookup from a phone number to a SIP address. So that you can do voice over IP with SIP addresses. There's the potential for what we can do with this huge, but it's relatively young as far as records go. SOA records, which are start of authority. That basically says, hey, I'm actually the authority for this name. I'm start the authority. I may delegate to someone else. But this is where authority starts for this particular name, TXT records, which can essentially be any sort of 255 byte text blob, if you will. And you can actually have more, but it's kind of weird how that works. PTR records, which are reverse lookups, so that you can say, given this IP address, give me the name that is actually supposedly attached to it. Those are usually reserved for servers where you're trying to do some sort of verification that something coming from this IP address actually is connected to a particular domain that it's saying it's connected to. Used to be used for things like email delivery to ensure that whoever was sending an email was actually the IP address that was authoritative. There are better ways to do that, but that was one of its original uses. So a little bit about the DNS, wow, that is super dark. Can you guys see that? Okay, great, I can't, so I'll just assume you'll be able to. So protocol, this is a little bit about, what? Oh yeah, that's right. This isn't questions and answers like you ask me questions and answers. That's the DNS protocol. Okay, so the DNS protocol, essentially, I put together a packet that has a question in it or multiple questions, actually. And it might say, here is the name, google.com. The question is, give me the A records for that domain, all right? And then I shift that off to my local recurser, so it might be on my machine or it might be my ISP that's providing that local recurser. And I say, give me the A records for this and it goes through that cycle where it does the lookup. And ultimately, what happens is that the authoritative name server ultimately, hopefully, if the name is delegated properly, will answer it. It will return you the same packet, essentially, with the question and then the answer attached onto it. And the answer might be the authoritative answer. It might be additional records that are glue records that they're called. So that's saying, here I'm gonna tell you instead of, I can't give it to you, but I can give the name server to you where it's found, which is a name. And I also happen to know the IP addresses for that name server. So I'm gonna give those to you now, so that you don't have to go look those up separately. So it might have an additional section there and it might have other information as well related to that record. If you have, for example, I'm trying, there's not a lot of good examples. A good one is that historically, you could actually send the root name servers back as well, so that if something couldn't find, if it didn't find it locally, it might tell you, I don't have it. But here's the entity that might have it. So it basically says, pick from these lists of 13 name servers that you can go ask to work your way back up the chain. There are two underlying, basically DNS uses both UDP and TCP. By default, when you first send out that packet, it's UDP. So it's basically a fire, you fire out that UDP packet and then you might get a UDP packet back to your endpoint, essentially. And it's done so that it's really fast, it's lightweight. Those packets have to be extremely small. As soon as they exceed a particular length, and I think it's 512 bytes, if I recall correctly, it's small. It's a pretty small amount. Then it'll say, I can't actually give you back that packet at that size. So I'm going to switch you over to TCP, and then you can get back a larger packet. Unfortunately, a lot of, that's interesting. The timer's not moving down here, so you guys are gonna have to watch my time. The unfortunate side of it is that there's a lot of resolvers that still don't understand TCP very well. So the falling back over to TCP means that you may actually lose some DNS traffic. And with DNS simple, we actually saw an instance of this when we started hosting RubyGems, where people were saying, I can't resolve RubyGems properly, but it was only happening about 20% of the time. And when we dug into it, it turned out that it's because the main record was resolving to a very long CNAME that pointed to Amazon. And that plus the other data that was in there weren't fitting. So it was trying to resolve that CNAME, and then it would return another. And it wasn't fitting in the packet size, and it would switch to TCP. But they were using resolvers that didn't handle TCP, and therefore it didn't resolve. So there's actually some strange issues that you have to be careful of. Especially true when you start talking about more modern records that are starting to come into play, like DNSSEC, which is the security layer that now is coming inside of DNS. They actually have had to change and expand the protocol and enlarge the packet size limit, since you can fit an entire DNSSEC response into a UDP packet. So I think they've actually upped it to 1,024 bytes now, if I recall correctly. Suffice to say that there are still open issues with these large packet size. And so you have to be very careful about exceeding the packet limits. But the DNS protocol was designed to be able to swap from UDP to TCP if it exceeded a certain size. The other thing that's great about the protocol is the protocol itself has basically said we're going to define how caching exists. And essentially the caching comes in through those recursors. And the interesting thing is that you might go through multiple recursors to ultimately find your answer. You might literally have a recursor on your local machine that once you've cached that answer, a lookup is just asking your local recursor. So any of you who've ever had, you've went to look up a site and it didn't work, and then you made a change in the DNS somewhere. And then you said, okay, now I want to go look up at this site here. And it still didn't work. And you're like, what's going wrong? And then you go do a little query on Google and it says you need to flush your local DNS cache. Okay, so essentially that's telling your local recursor. Forget about what I told you before and start using this, like go look again, essentially. And I'll talk a little bit more about negative caching as well, which is a feature of DNS. So caching is built all throughout the system. The recursors are essentially caching. Even inside of the authoritative name servers, there's caching going on in most cases. So for example, in bind with zone files, it just essentially, most bind instances, load the entire zone file into memory. So you essentially have the zone file cached in memory. Things that are using a little bit more advanced back ends do caching as well. So speaking of bind, let's talk a little bit about the servers that you can use to do DNS, authoritative DNS. And a lot of these actually do recursors as well. Bind is sort of the most well known DNS server, both authoritative and recursive. It's been around for a long time. It's at version nine dot something other now, nine dot two. It's sort of the, what would you call it? It's the reference implementation, if you will. It's not a bad piece of software. It's just, as you can imagine, being the most widely used piece of software on the internet essentially. It gets attacked a lot. And also DNS happens to be a good attack point if you want to do bad things and take over networks. And so bind, you'll hear a lot of people bemoan bind because they say, well, it's just, it's super vulnerable. And it's vulnerable, that's true. It's very true, but it's also vulnerable because it's just so widely used that people are always attacking it. And it's also a fairly complicated piece of software because it is the reference implementation. So they try to implement all the new stuff that's coming out. So for example, the DNS sex stuff, a lot of that was first implemented in bind as a reference implementation. Another example that a lot of sysadmins really like if they want to do simple DNS resolution is DJB DNS, also known as Tiny DNS. It was built specifically as the antithesis of bind, super small, very lightweight, handles both authoritative and recursive, very fast and extremely secure. So much so that there was always an open invitation. Hey, if you can break into it, I will essentially, and I can't remember what the prize was. I'll give you a prize, right? And as far as I'm aware, I don't think anybody's ever broken into it, but I could be wrong about that. So, or found a vulnerability in it. The third one that, this is actually the one that we use and the one that I think is sort of a nice middle ground between those two. It's not bind, but it's not so simple as DJB DNS. So this is Power DNS. It's open source. There's also a business that sits behind it that can help to answer questions. They can provide service contracts and things like that. Power DNS is really great though, because it supports multiple backends. It's fast. It has all kinds of caching built into it. But you can actually have bind backends. So it can read bind zone files. You can have database backends, both MySQL Postgres and SQLite. We happen to use MySQL as the backend for our databases because of replication. So it's really good. Since MySQL has historically had replication for longer that's a little bit more stable, we use that for our backends. And it's really fast because it actually caches questions that have come through and has its own internal mechanisms for faster cache clearing for particular questions that are coming in. Looks at the time to live on the DNS records, things like that. You can also, and this is kind of cool, so in addition to the database backends, you can have what are called pipe backends. And this to me is one of those, this actually first brought me into Power DNS and got me interested in it. So we had to do, let's see if I can explain this here a little bit. I used to run the root. I still do run the root for .mp, which is a Marianas Pacific Islands. And if you all remember back a while ago, Verisign attempted to make all .coms that did not resolve, actually point to a page that they put up because they were helping everybody. That was the site finder or something like that. Yeah, you can supply your own air quotes. Well, we did the same thing for .mp. The differences were small enough, so nobody cares. But essentially what we did is we said, we want all things that don't resolve to something else to go to answer to this other system. But it turns out that if we tried to do that at the root level, then we would actually get blocked by a lot of recursors. That's how they fixed the problem initially when Verisign came out with that, is they put in a patch of the recursors that said, roots are not allowed to answer questions themselves. They must delegate to somebody else for answering the questions, except for certain cases. So there were exceptions this rule. So the interesting thing is you can actually write Ruby code that sits behind Power DNS and delegates things depending on what the query that was coming in. So it turns out I probably didn't need to do this, but at the time this was the way to build the solution. So here's a little bit of code for you. I know you guys like that font there, that one's for you there, Ben. So this actually is a stripped down version of the code that was sitting behind the root for .mp. And essentially I pulled some of the things out, but this is a protocol that Power DNS has, which is basically using standard in and standard out and standard error as the mechanism for communicating between Power DNS and the script. It uses co-processes, so it actually will essentially launch up instances of your script and keep them in memory so it doesn't have to launch the script every time. And then it essentially, through standard in, sends the line that is the question and you can send back any type of response that you want. And you write it back essentially as tab delimited output. Surprisingly simple, works fantastically well. And you can do all kinds of things. Imagine for a second that what you really wanna do is every time you got a particular query, say for a text record, you wanted to return something random, all right? You could do that. You could absolutely have a random number generator that was built on top of DNS. That would actually randomly return some value every time you asked for a particular text record with a particular name. And you could do that in Ruby, Perl, Python, whatever. It's essentially anything that supports standard in, standard out, and standard error. So anyways, to me that was what got me interested in Power DNS, what's kept me with Power DNS is it's stable, it's fast, and it's basically a joy to use. So, okay, moving on. Now I've spoken a little bit about the basic protocol, a little bit about the servers that sit behind it. What I really wanna talk about here are the tools that you can use that are at your disposal to query and to find out when something's going wrong or when you need to make changes, what can you use to do it? So the first, the Power tool if you will, for anybody dealing with DNS is dig. Dig is a command line tool that's pretty much available on a post-6 environment. It's, some of you might have heard of NS Lookup. NS Lookup is sort of like the old tool. Dig is the one really that most people use now. Dig lets you essentially query for all the different types. I'll show you some examples here in a little bit. All different types of records. You can query for reverse records. You can talk IPv6, IPv4, do all kinds of things with it. Very powerful tool. But since we're, most of us here I think are, do use a little bit of Ruby, and certainly this is a Ruby conference. We have some other tools at our disposal as well. From stuff built into the standard library, like resolve.rb. So this is actually included in the standard libraries for one eight, basically every standard library. It's a simple resolver. So it's a little bit of software. They can sit and talk to your upstream resolver and say, give me all the records of this type. So respond and give me all the records of this type. So it doesn't support all of the different record types. In fact, none of the software out there in Ruby land supports all the different record types, but it's pretty easy to extend to add in another record type. It took me about an hour to extend to add in any pointer records, for example, in something I was working on. So it's pretty straightforward. You essentially have to open up some classes and do a few little things, a little badness, but it does work. The more powerful version, which is, this is not in the standard library, but it's available both through GitHub and also as an installable gem, is Net DNS. It's modeled after Perl's Net DNS, but sort of with some redesigns that make it a little bit more idiomatic inside of Ruby. The neat thing about Net DNS is you could actually write a server that use Net DNS under the hood, because it has the ability to read and write the raw data that's inside those packets. So you could actually build a DNS server in Ruby. The Resolve library that's built into Standard Lib doesn't, it just lets you ask questions. This one you could actually build an entire, I don't do this, but you could build an entire DNS server in Ruby with that. Even that though doesn't support things like any pointer. So there are a lot of, and none of them support the newer DNS sex stuff either. I imagine that's coming, but it's still limiting. You'd have to extend it if you're gonna build a real full-fledged DNS server. That one's available up on GitHub. So you've got Dig, which is your command line tool. That's like your quick go-to, it's gonna output text. You've got Resolve, if you need something that's in the Standard library that you can get at, that you can essentially query things really quickly. You got Net DNS, if you need something that has a bit more power and they could potentially allow you to serve things up. And then that essentially covers the DNS side of it. There's one more thing that's, I think, kind of interesting and kind of useful. There's this thing called Who Is. So Who Is is essentially a public database that is used by registries and registrars to publish information about ownership and management for a second level domain, or a third level domain or whatever. So for example, I can look up Google.com and it's a, the protocol is extremely simple. It's like, answer on this port, there's gonna be just the name that comes in. Give us back a big text string. We don't care what you put in it, just give us back a big string of text, okay? So the upside is it's really easy to implement. The downside is that nobody's implemented the same. All right, so if you actually wanna go in and look at Who Is data, you've got several challenges ahead of you. The first being that you're gonna have to actually parse out the data. The second being that you're gonna have to find out for each TLD which Who Is server you need to go to. There's no real easy way to do that. There are attempts to improve the protocol, to make it recursive. So if you ask for something and it doesn't have it, it can tell you who does have it, but those are still early stage. Anyway, there's a cool tool though that actually is called Who Is. You can just do gem install Who Is. And it's available on GitHub. This tool is designed to simplify the parsing of that data. It basically has all the regular expressions and stuff built into it to handle and parse a whole bunch of different provider output so that you can ask it questions that are a little bit more Ruby level, like, hey, are you registered? Yes, I don't have to parse out to determine if this domain is registered. The downside is is that even at .com, if I look at a couple different .coms, it doesn't handle a lot of these. So there's still a lot of room for improvement. The good news is on GitHub, it's forkable, and the guy who maintains it, who's in Italy, is very open to accepting patches. But it's a useful tool. An example of how we use it inside of DNS simple. Inside of DNS simple, we have a deal that lets you leave GoDaddy at cost. So you can transfer out of GoDaddy at what it costs us to transfer you out. In order to determine if you're inside of GoDaddy, there's no service that lets me say, hey, is this name registered with GoDaddy? The registries don't tell us that. All right, at least through the protocol that I have to use, you can do it through the registries if you go directly to the registry registrar protocol, but I don't have access to that. So what I do is I just say, okay, who is? I'll grab the who is data and tell me who the registrar is for this. And then it works pretty well because the comm for just telling us who the registrar is is somewhat standardized. Granted, they can still block me, so in certain cases, it still doesn't figure out it's supposed to be GoDaddy, but that's one example of use for it. So let's take a look at some of the code that I've prepared. I assume that there's not gonna be much of an internet connection. So I've gone through and sort of run through some of this stuff back at the apartment. So here's some examples. Can everybody see this okay? Because I don't think I can get it much larger, but I'll do the best that I can here. So here's an example on the command line if I said, okay, diganthony.com. All right, so I get an output that's essentially shows me, and interestingly enough, this is kind of the bind output format. That's what it is. It's the same format that bind uses in its own files. It tells me what version of dig it's using. It tells me the answer, the question in the answer, so you see the question section. It repeats that back to me, but as a comment. In the original one, that would have been uncommented if you looked at that. Gives me back an answer. It tells me what IP address it's on. Tells me the time to live in my local recurser. So that tells me how many seconds are left before my local recurser will consider that record dirty, and then it needs to be looked up again. By default, it could be anything. By default, at DNS symbol, we run about an hour, but you could run anything from zero all the way up to huge numbers. It also tells me, I won't go into why it uses the in and stuff like that, but it tells me it's an A record. It tells me how long it took the query. It tells me what server I use. Now notice in this case, I use 8.8.8.8. That's the Google public servers. It could show your local IP address. It could show an upstream address. Great, so it tells me when I did it and how big the message size was that was received. The next record down, I asked it for the MX record. Okay, so MX record's the mail exchange. This time, it shows me an answer with multiple values in it. It shows me the various MX records. These things can actually be ordered in any way, and in fact, there's no guaranteed order for how DNS returns its values, and that's actually a good thing, because it should be purely random so that if there are multiple servers, in the case of like A records, for example, so that you might pick off the first one, but every time you might get back a different one. In this particular case, the order is gonna be somewhat controlled by those numbers that appear next to the MX. That shows a priority. So it says, okay, lower priority numbers, we should try first, and then work our way down. If we find things that are matching priority, then just grab the first one. So let's say I exhaust all of my 10s, then I wanna try the 20s and the 30s, things like that. And those numbers can be anything. There's no hard and fast rule. The standard is sort of 10, 20, 30, 40, 50, things like that. Okay, moving down, there's also a nice way to do any. So in this particular case, I say, give me any record that you know about on this name. Now the interesting thing is this will not cover subdomains. So there's no way for you to say, give me any record plus all subdomains and all subdomains of that, that doesn't exist. You can't actually ask the DNS servers to that using something like dig. So, but what it will tell me is, it will tell me all of the various types of things that I do have on this. So I've got some MX records, some NS, which says, hey, this is who's authoritative. I've got a text record, which is my site verification. I've already verified, hopefully Google won't screw me if you guys start using it. I've got the start of authority record, which says DNS simple, ns1.dns simple is the authority, if you will. And I could have other records in there as well. So any is very useful for getting the entire list of records that's known about a particular name, but not subdomains. That's actually not possible to get. Okay, so in this particular case, I can add at symbol and then a name, and that's actually it says, use this name server specifically to go look up this data, all right? So it can say, okay, I wanna use the ns1.dnssimple.com name server. This is useful for testing. Let's say you're getting ready to migrate from one set of name servers to another. You can leave your stuff public, but you can then use dig to verify that everything matches up. So do the same query on the, without the at, and then with the at, compare the results. Do that for each one of your subdomains, and you should be able to pretty much prove to yourself that this server is gonna resolve correctly. Other things that's interesting, trace plus trace. Now not all names are not all resolvers will allow you to do this. So for example, right now, if you tried to do it on this network here, it's not gonna let you do it, it's gonna stop you. But if you can get out to Google Poly name servers, which actually you can't do from this system either, you could though, if you shelled into some place else, then you're gonna trace. What this does is it actually says, show me the trace back from the roots all the way down as it's resolving through com, then through anthenian.com. So first it says, okay, these are the root name servers. Notice it says look for dot. It's basically trying to say give me all of the root. These are all the available root name servers. Those then say, well now I wanna look for com. And it says, these are the servers that know about com. These are the GTLD servers. Notice they're different there. And then I say, okay, it tells me, go ahead and use a.root-servers.net. And then that says, hey, what we know is we delegate to ns1 through ns4.dn is simple, all right? And IGTLD server actually answered that. And then ns2 answered the final request, which was, hey, here's the A record that you were originally looking for. This is really useful for debugging to try to find out where the breakdown is if you have a domain that's not resolving. You do a plus trace and you could say, oh, it's not resolving because it's not set up properly at your registrar. Didn't put the records in the root properly. It gets to the second level of the root and it goes, oh, I don't know anything about that. Or some other delegation upstream is messed up. So that's a useful tool there as well. Let's see here, digx. So I'm gonna stop here. I'm gonna go into the Ruby code. Point is you can, all this stuff you can do dig-h. You can get all the commands. It's pretty straightforward to use. Let's take a look here a little bit about what you can do inside of Ruby. So I'm gonna start off by looking at the resolve library. So this is what's built in. The first line here, I'm gonna create a resolver. Let me pull this back up here. So I create a resolver there. It gives me back a resolver. And then I can say, okay, give me each resource that's on anthine.com that's of type A. And it basically hands that off to the, it's an iterator. It hands it off to that block. You can do stuff with it. So in this case, I might just simply print it out. And you notice that it shows that it's an IPv4 record. I could actually ask for an IPv6 record as well. Shows me the time to live. That's an object, so I can actually query it. Got 10 minutes left. Excellent. You can also do things like, okay, well, give me back, that's another useful one here. There are MX records. So same thing in this particular case. I'm saying I wanna pull off the MX records there. Pretty straightforward. Any same concept. If you tried to do things like any pointer record, it's gonna blow up, but it'll do that in both cases. Or just ignore it completely. I don't remember what Resolve does. This is giving me a whole bunch of records. I can also get addresses. So I can say, give me the address for this particular name. And it'll give me back the IPv4 address. I can change names. This case, I'm switching over now. Yeah, I'm still using that. So I can say, use this name server instead. That's the equivalent of using the at. So in this case on line 133 there. So on and so forth. All right, moving down, I can use net DNS resolvers instead. Notice this one actually gives me a little bit more information. So here in this case I started up. It says, okay, I'm gonna use resolve.com, which is a standard configuration. I'm gonna set things up. Give me data about what was just set up by default. I can query it. And it will give me back actually very similar output to what I would see if I did a dig. So the question section, you got the answer. But the neat thing is underneath all of that, you have objects that you can work with that you can query. So taking a look down here, pass the any, right. So here I say, okay, I've got a result that I queried. This is, I'll move this down just a little more. So I have this result. Give me the header that I got back. And I can actually ask it questions. What was the number of questions that I had in there? What were the number of answers that I had in there? Give me back the question itself. I asked for the question. It gives me back something that can be represented as a string. So that's here on line 285. And at the same time, it's actually a collection of questions. So it's an array I can go through and I can map and say give me all the Q class, Q name, Q type. So, and you can do that with all the answers. So you can do all kinds of advanced, you can basically write Ruby code. They could do deep querying on DNS through either this library or resolve, really. Next one is who is. That's just a simple example of how I can say, okay, give me back a result for Google.com. And then tell me if it's available, if it's registered, when it was created, who the registrant contact is for it. So, but you can see already, the data starts to get messed up, okay. The address is please contact contactedmin at Google.com. So this is it attempting to parse results and you can already see that it still needs work. But it's a starting point. It's a lot better than trying to, maybe not a lot better, but you're gonna end up having to write that yourself if you end up querying who is. So you can also ask when it expires, give me its name servers, things like that. The final thing I wanna show you, and anybody who wants to see this more can come to me afterwards. DNS Simple has its own API that's REST based. I've already written a Ruby library that talks to that library. So you can do things like this. I can check the domain's availability and that line is actually gonna go to our servers and actually ask the registry, is anything available? And it's gonna come back with an available or not available. So that's better than who is because it's more accurate and timely. You can get a list of all of your domains. So for example, I could see various domains, activewarehouse.org, anthonene.com, things like that. I can also look at records too. So I could say, okay, give me all the records for anthonene.com. And this library's fully open source. It's up on GitHub under hron slash dnsimple-ruby. So you could take a look at all the code underneath. It's pretty straightforward. It just sits there and spends most of its time talking HTTP over to the REST servers which do all the hard work. So that's an introduction to the code. So now what I find interesting is that there's a lot that we can do with DNS. We've just, everybody's so used to using DNS for what it's used for in most common cases. But what I like to think about is, how can DNS be used to do things that we're not using it to do yet? So DNS is quite good at basically saying, resolving a name. That's what it's there for. So what if we were to use it for things like, I don't know, dependency resolution of software? All right? So anybody who's ever tried to run an install on with Bundler, if you're doing stuff, knows the bundle install, wait, wait, wait, wait, wait. You know that whole wait cycle where you go off and have a cup of coffee. What that's actually spending a lot of its time doing is there's articles that have been written up on this. Is it's going and it's getting all of the dependency data that's stored in YAML files, all right? Has to go through to one big file first, download that as that file gets larger, it's more and more data has to send over. Then it has to go and look at individual dependencies and figure out which ones those depend on, so on and so forth. So there's actually, I put a gist together and Jeremy, if you went to the data talk last session, actually was a little bit involved working on it too. The idea I think is feasible with simply CNAME records and pointer records, where we could actually, and we've proved that you can do dependency resolution including things like the tilde greater than resolution. Because all it is is I just want a, not the entire name, but a sub part of the name. Because that's essentially what it does. Oh, if I want the latest, I just want the name of the gem itself without the version information in front of it. So if I have a bunch of CNAME records that represent these things, theoretically you could do your dependency resolution entirely through DNS. Speeding up the process because you get the benefits of a lightweight protocol, you get the benefits of caching. You could actually override things locally. So let's say you're inside of a corporate firewall and you have a bunch of things that you can't publish out to the public. You have your own little corporate internal name servers that could just happen to respond for certain dependencies and say, don't use this, use this. So there's all kinds of neat things that you could potentially do with it. We can extend beyond CNAME pointers and go into things like NA pointers to find the best download point. So rather than having to have a whole list of servers that might potentially provide downloads, you could actually have that in DNS. Another interesting example, I think. So HTTP redirect, if you have, I don't know how I'm doing on time, I'm probably running out here five more minutes. So right now if you set up an HTTP redirect from one domain to another, it has two things it has to do. First it has to go have some name server that says the redirecter is at this IP address. Then the request goes to that IP address and that server has to query back into the record to say give me what the URL is that I'm gonna redirect to and has to do an HTTP redirect. So NA pointer records, I talked about those earlier, what they essentially do is they say map this name to some regular expression to translate it. That's what they're designed to do and they can actually be chained together. So theoretically, I could have an NA pointer record that says map the name anthonyedon.org to, and then the regular expression would just be the entire URL, http colon slash slash anthonyedon.com. If your browser understood that that NA pointer record might exist, it could just go ask the name server and it could say here's the NA pointer record and now it doesn't have to do the lookup for the IP address, it just replaces that value in your bar and goes to that instead. So little things like that are I think very interesting and it's gonna get a lot more interesting now that we're able to getting to a point where we can actually sign the entire chain of DNS to say that I actually trust that everything from the root down is the provider for that record, so that's the actual name, because right now you can do things like DNS cache poisoning. If I get in the middle of, if I happen to compromise a cache somewhere in the stream, I can put into that cache a different record than what you're expecting and I can start siphoning off traffic. So there are actually bad things that can start to happen. So to me I think that there's a lot more, there's a lot of opportunity here for some really interesting advancements thanks in part to the signing. We're not there yet, but it's gonna be coming soon. Another example of an interesting one actually just came out the other day. So I don't know how many you know, there's some issues with SSL, Komodo had a few root certs that might have been compromised, it's problematic. So Google was talking, it was one of the people who works for Google who was talking about ways to verify that an SSL cert is probably valid without having to go back to the cert authority. They could say, well, hey, by the way, we at Google have since the beginning of, or since a long time ago, have been cataloging all the SSL certs that we have seen. And we published this data on the SHA-1 key plus certs plus Google.com. And so we show you when we first, the day we first saw it is a number. We show you the days since we last saw it or something like that. How many times, yeah, that's right. Day when we first saw it, day when we last saw it, and the number of times we've seen it in between then. And you can actually use that to sort of determine, hey, okay, I see something which I've never seen before, like let's say I query for that and that SSL cert doesn't exist. That might be a little bit of a warning. Okay, so anyway, I think that there's some, because you're basically using SHA-1 keys as the prefix there, that's an interesting use of it. So when I publish these things up, you can go take a look at that, you also Google it and you'll find it. So anyways, in conclusion, DNS, which is fundamental to everything that we do, really isn't that complicated at its most basic level. It's a bunch of servers that you ask questions that give you back answers. It's a nice protocol, it's been extensible, it's been around for a long time. I think that we still have a lot that we can do with it, that we're not doing with it. So I hope to start to see some new innovation inside of DNS. I think that there are parties that do it, but it's not generally known. I'd like to see it more interesting uses that come out of the developer community that can actually benefit from it. That's essentially it. If we have essentially one minute left, so I could take one burning question for everybody, but you have to use, I can't go too far because I don't have feedback. If you want to ask the question, okay, does anybody have a question?