 But let's get going. So DNS Sec, solving a decade old vulnerability. Well, first off, I'm Carlos Smith. Carlos, I'm a sysad man. I learned about DNS Sec when I was volunteering for InteropNet. And I didn't realize how big of an issue DNS being insecure was. It was just like, oh, DNS, who cares? But I learned that it's actually a huge issue and DNS Sec offers a pretty cool solution. And I just want to spread awareness and hope to encourage adoption. I'm going to go over the general idea of how DNS Sec works. I will cover some DNS basics to make sure everybody is on the same page. And I will touch on how the possibilities that DNS creates. And go over some software that is already taking advantage of DNS Sec. So what's DNS and DNS Sec? DNS is often compared to as the phone book of the internet. And DNS Sec is trying to be like the unspeakable caller ID. What does that really mean more technically? Well, DNS, the domain name system, is translating user-friendly names to addresses that the computer can't understand. This is essential to the functionality of the internet. And DNS Sec is trying to ensure the accuracy of that information. So the benefits of that would help protect users from forged DNS information, strengthen trust in the internet, now that we can make sure that we're getting the correct information from DNS. And this will, like I said, create new possibilities that we will go over, Andam. And so, strengthening DNS will make other online activities like e-commerce, banking, even software distribution, all these different types of communication will be in turn more secure. So, yes, specifically it's mitigating some risks of specifically man-in-the-middle attacks and cash poisonings, which are often used for cybercrimes. And as a brand, it's going to help protect your business and image, and even possibly help build a reputation that you actually take security seriously, and as well as your customer's information. So, exactly, what's the big deal with DNS? Firstly, like I said, DNS is an old sense from the beginning of the internet, and it wasn't designed with any security in mind, so attackers can force this data. And so, like I said, DNS is telling the computer where to go, it's trying to get the name to an internet address. So if that's insecure, attackers can redirect people to fraudulent sites. Hopefully I can illustrate that a little bit better. So here we have a sign telling you where Piggy Bank is, and that's like DNS telling your computer where to go. Well, someone can just come in and disrupt the data, insert fake data, and right now there's not really much to stop that interference. And then that can result you in being led somewhere you didn't want to go to some fraudulent and malicious site, which has the potential risk of phishing, identity theft, this can circumvent anti-spam measures, misinformation can get disseminated, wiretapping over VoIP can happen. And these are just some examples of the risk that DNS currently poses to us. So, like I said, DNS is trying to ensure the credibility of DNS information to help not lead us astray to where we don't want to go by protecting against spoofing, even corruption of DNS data while it's in transit. And it's aimed to maintain backwards compatibility while being able to add a layer of security. So firstly, let's go over how DNS works. Some quick terminology is IP address, just the numbers for your computer. Up there I've illustrated what an IP address in version 4 looks like and IP address in version 6. The domain name is the human readable version of that using like an alpha numeric name. There's an example of a domain name. FQDN is like a fully qualified domain name like the proper full name for it. And DNS is doing the translation between the alpha numeric name and the internet numbers. So the anatomy of a fully qualified domain name, at the very right we got, it's right from right to left so we got root. And then the next part is known as our top level domain, our dot, in this case a dot org. And from there a second level domain example and that's usually where we've traditionally been able to start purchasing those names. And today we can now start purchasing top level domains but traditionally we were purchasing the dot example from the second level. And then we have the subdomain beyond that where we can start adding like www or we can put mail.example.org from there. In a hierarchical view maybe this may make a little more sense. From the top we have root. And then from there we can go to our top level domains. For example we're using org. Then our second level example and then down to our subdomain to create www.example.org. A little more terminology. There's more components to that structure. There's zones, the subset of this hierarchical structure. And within those zones are resource records with the actual data to map the name to the address. So I will illustrate anything in a second but just to give you some examples of possible records like specifically what I've been talking about with the address is known as an A record. But there's also records to let you know how to find a mail server and other things like that. So yes, okay, so this is within the dotted box is our A record for www. And outside of that is where we have our entire zone which can encompass all our records for us of that zone. The name server is what maintains the responsibility of the zone. This is where the whole phone book metaphor comes from because from the name server is where we can look up this information. So using the phone book. I want to find www.example.com. So my example is changed from .org.com. Ideas the same. But my computer doesn't know where this is to start off with but my computer does know where root is. So my computer goes root. It's like, yo, where's www.example.com? I don't know but I know where the .com name servers are. Go check with them. So they give me the information, the addresses to go find .com. So I go ask .com the exact same question. Yo, where is www.example.com? I don't know but example.com is my neighbor. I can give you his address and I get the name server and the address for example.com. And I ask example.com's name server, where's www.example.com? And it's like, oh, I'm responsible for that zone. And here it's a record. And from there I now have, my computer now has the address it needs in order to communicate with the www.example.com. So that whole chain is susceptible to, every part in that chain is susceptible to being exploited. Exploits are, if you ever research the DNS you'll definitely come across such terms as DNS hijacking, DNS spoofing, cash poisoning. Very famously is the Kaminsky bug, one of the original proof of concept type things to illustrate what is wrong with DNS. This is a very simplified, just to illustrate the example of what can happen with DNS poisoning. Basically we have our rogue name server, DNS server hanging out there, just like flooding the requester with answers hoping that something will get through. And there's definitely ways and techniques to increase the odds of getting the requester to accept an answer. So just some examples of some major breaches, and I wanted to choose different types of breaches. DNS changer was a big one where a piece of malware actually got on your machine and changed where you were requesting information from. And then they were able to provide you with the answers they wanted so that they could monetize their traffic and actually made quite a bit of money. The Brazilian ISP, the entire country fell victim to DNS cash poisoning. They think it was a possible inside job. Turkey actually intercepted routes to Google's public DNS and pretended that their DNS servers were Google's DNS public service. And there was no real way for users to detect it. If they were able to spoof like Twitter or any other Facebook or any other site they're going to or their bank sites, users wouldn't be able to probably notice unless if they did a good job of cloning these sites. But I've also been told that Carlos, we assume DNS is insecure. It doesn't work in this environment. And I'm like, well, TLS isn't addressing this problem. Just to throw in some background, SSL slash TLS, I'll probably use the terms interchangeably. TLS is just the next iteration of SSL. But that's putting the S in HTTP, S. That's where we get our little lock icon when we go to our bank. And this is even what I thought was securing me when I was browsing the Internet. I was like, oh, I got my lock and I got all these little logos that tell me I'm safe. Well, that is encrypting my connection to the server that I'm connected to. And the certificate that SSL provides doesn't match the domain name. But if DNS is compromised, then there's no way for me to really be sure that the endpoint I'm connected to is who I think I'm connecting to. But that connection is secure and encrypted. So that's an issue. Also, the certificates that we use to do SSL and TLS come from a third party certificate authority. There are many problems with this system. First of all, if you look up the EFF Observatory program, they go through and map out a ton of certificates at your certificate authority that your computer is automatically trusting. And any of these guys can issue certificates for anybody on the Internet. There's nobody stopping Verisign and DigiCert or anybody else to issue certificates for Google. So if any of them became compromised, they can start now generating keys for people they really weren't contracted to generate keys for. Also, they are able to delegate trust to other certificate authorities. So because you trust me, I'm going to tell you my friend's cool, so you're now going to trust him to whether he really keeps all his security practices on point or not. So that's a big issue. I have a ton of examples of this, but I thought these were some more notable ones. Here, at one point, Komodo and DigiNotar have been compromised, and it actually resulted in finding fraudulent certificates in the wild. Recently, Symathic had some issues because Google found that there was some unauthorized certificates being issued for their domain. And even most recently, and that was 2015, these are also 2015, Microsoft, Dell, and D-Link all linked private keys that were responsible for generating these keys, which means that now anybody is able to create a certificate that looks like it's from Microsoft, and your computer is like, oh, I trust Microsoft. And so now Securities broken, and a man in the middle can see exactly what's going on. So SSL TLS is not a complete solution. We need to secure DNS for a secure internet. This poor little girl is about to have her identity completely stolen. So, DNS Sec, Tempor-Proofing DNS. So, like I said, DNS Sec is working towards protecting us from forged DNS data, and again, which will have the benefit of strengthening the credibility of DNS information, and won't break the current system we have, so we can move forward with this solution and continue without breaking the internet, basically. So what DNS promises is to authenticate that the DNS data is originating from a legitimate sender, like it's from the proper source. And the data hasn't been modified in transit. And if data has not been published in DNS, we can even verify that that data is not there. It does this all through a chain of trusts, which is basically a series of checks and validations. We'll get more detail exactly how that works in just a second. But what DNS Sec is not, though, it is not encryption. It's not going to provide confidentiality. It's not going to hide your DNS data. There are other options to work in conjunction with DNS Sec, but DNS Sec itself is not solving that problem. It's not going to guarantee availability. It's not going to address denial of service attacks. And if your name server is compromised, it's not going to address it. It's going to just protect the data in transit. It's going to protect that when you request, make the request that it's coming from who has control of the name server. So what a signed zone might look like. This is once we've implemented DNS Sec. So on the left, we have our A record and a couple other common records. You may see in a DNS zone. And to the right, we have what it looks like when signed. Each record set will have a signature which we can validate. And then we have some other records that I'm about to go into on how it makes this all work. So when we do now a DNS Sec lookup, we get a little bit of extra information back from our example.com name server. It comes with, we get our answer with our A record to tell us where the address is for www.example.com. But we also get a signature for that record that we can check. Quickly, so these new records that we'll be going over is the DNS key. This is the public key for those signatures in that zone. The signature itself is known as an RCIC record. And then there's another record of the delegation signer. And the delegation signer is basically a hash that will go into the parent zone. So if you're a second level domain, the delegation signer will be in the first level domain. If you're second level, it will be in the first level domain. And from there, you can check the domain beneath you. And that's where the chain of trust starts to form. I do want to let you know these slides are available. I have a link at the end. And I'll be tweeting them out and everything as well. So definitely want to make sure everybody has all the information they need. So how does all this checking and chain of trust start to happen? Okay, so we got our A record back. And we got the signature for that record. Well, how do we check that? Well, now we need to go back to example.com. So what's the key for this? And it responds with the DNS key resource record. And now we can validate that this record checks out with the key that is inside example.com. But maybe we are being tricked into talking to someone that's not really example.com. So we can ask .com, hey, do you have the hash for example.com's public key? And then it replies with the DS record. And from there, it replies with the DS record and a signature of that record as well. So we can check that the hash we're receiving is in fact the correct hash. And so we hit to ask .com. So what's the key for this record? And it replies to us with its public key. We can check that we have the correct hash. Then use that hash to make sure that example.com's public key is legit. And that moves us up into the chain of trust. And similarly, we do the same thing at root. We ask root for .com's hash. And we ask root for its public key. We check the hash. And we check the record. Then we check the hash. And we've moved all the way creating a chain of trust to root. But whoa, how do we know we're even talking to the right root? Well, that's where a trust anchor comes in. And the trust anchor, it's going to complete the chain of trust because it's basically going to be a seed to allow us to validate the root server. So that seed comes from IANA. IANA is responsible for maintaining and publishing that, which you can get the seed from their sites. So now we have, so the trust anchor is essentially a DS record on local to us that we can now check root against. And we can validate root's key and complete the chain of trust. Now we have an entire circle of trust that we can validate for. And this opens up all sorts of new possibilities. Just for completeness, I did mention doing authenticated denial of existence. Basically making sure that we know when there is, that if we get that there's no data there, we can actually verify definitively that there's no data there. This helps clients distinguish between if there's a DNS sec abilities at the name server or if it's an insecure, just a regular insecure DNS record. Being able to verify that helps prevent a man in the middle of tech. So it does that with another record called an NSEC record, NEC secure record. Basically it's a record to point at the next available domain. It does have the side effect of allowing people to walk and basically copy all your DNS info for some entities that is an issue. DNS is technically a database so there's even some legal issues for some entities. So there was a solution to come up with DNS Sec 3. It's kind of a work around hashing these records to make it a lot more difficult to walk. Not impossible but difficult. But DNS Sec 5 looks like it may be a solution but it hasn't been ratified and standardized quite yet. But we've created a chain of trust with cryptographic signatures. Which means we can verify the origin of our data, we can verify its integrity and we can verify that we're not being man in the middle then told that and make sure that we can use DNS Sec when available. So like I said, DNS is basically a database but now it's a database we can trust. And it's universally a distributed database on the Internet. And this database like I mentioned is basically a directory and so now we have an authenticated directory of information we can use. So currently the other types of information we're putting into DNS we have measures for fighting spam known as DKIM. I think there may have been a talk that maybe happened, I don't know if it's coming up that such on these issues but if DNS wasn't secure these measures can be circumvented. Also we've stuck other information in there just even the location of our mail server base and even we've put information for VoIP and Jabber in there. All this information could have been faked. Did you see that? I'm sorry? Yes. Yes, I would definitely make that edit. There's been other efforts to put keys into DNS before. We have IPsec key which is for VPNs and T6 for even doing updates to our zone and even putting SSH fingerprints into DNS. But these were actually to present a greater security risk since the source of the information wasn't safe. So they came up with a, well now we have DNSX so it's actually okay to put these records in there if you are using DNSX. But they want to take it a step further and create a domain DNS based authentication of name entities. It's kind of a funny acronym but basically a way of standardizing this process of how to put keys and to look up keys in records in DNS. So basically being able to standardize this allows us to do key discovery so applications can just go look at your DNS to see what's available if you can do any sort of encryption and what that key is to do that encryption. So this basically allows applications to automatically establish a secure communication channel. So just a quick review of this is what even with our chain of trust with our certificate authorities and current TLS infrastructure it's still susceptible to a lot of attacks from the CAs itself and other men in the middle type of attacks. So with Dane we are no longer dependent on certificate authorities because we can move this information into DNS which we've already established a trust with. The record for that is known as a TLSA record and that can store a certificate or key information. It doesn't have to replace your certificate authority can actually work in conjunction with your certificate authority by actually putting in a key to lock it down to a particular certificate authority or even to a specific certificate so at least the vector of attack isn't so wide. So only one certificate vendor can issue certificates for you or even you can validate against this specific certificate. So mail uses is capable of using TLSSSL as well but currently the way it works is it has to ask the other end and if it's also capable of doing it because when email started mail servers weren't doing this. So depending on the answer from the other endpoint is whether or not it's going to use a secure communication. If the other endpoint says no I can't do TLS then there's no secure connection. So someone can just sit in the middle, lie to both sides and watch the information pass through. So basically TLS on email is not very effective. But putting that being able to put that into our DNS record our mail server can check the DNS and see whether or not for sure it can support a TLS certificate encrypted channel or not. And we can verify that communication. And we can verify even if it cannot support that communication because we have authenticated denial of existence. So we can make sure that it's not there. So I clicked the wrong way. So SSL and TLSA with unified communications. So there's other services that can also take advantage of certificates in DNS the same way mail could including VoIP services, Java services. And so any service that's capable of taking advantage of certificates are now able to do this through our DNS as well. But there's other things we can start sticking in our DNS. So certificates are just the beginning. These next slides are everything in various degrees of development but these are all the type of things people are working on to leverage DNSSEC. So Dane in the web of trust we can start putting PGP keys into our DNS which again allows the automatic discovery. So before PGP has the issue of I have to do that initial exchange of keys well here we have a secure channel to exchange those keys with our DNSSEC and this can even happen automatically. I don't even need to know in advance if I can talk to you securely because I can just look up at your record and just can start running with that. Same thing with S mine, the mail client can just go ahead and look at the and query for the appropriate signatures for in DNS. And we have IPSEC which is just formalizing the IPSEC key to the Dane standard. There's also cool things like people are working off the record protocol so we can do safe key exchanges in DNS there. This is really cool that people are even working on a payment association identifier in DNS. And there's already a couple of Bitcoin wallets working on exchanging Bitcoin via authenticating identity via DNS. Armory and net key, not sure if I'm exactly pronouncing them right but those are the two that I'm aware of that are already attempting to leverage this technology. So why not DNSSEC? Well it does require mass adoption before you can really take advantage of it. But I feel we are basically there. Root has already been signed. That happened in 2010. And there's been a number of huge advancements. This is the current deployment of country code top level domains like your .us, .nl, and the majority of them are already onboard and fully in production with them. Here's the second level domain growth. So the top graph is the growth of .net and .com. .net's been for some reason a little slow, but .com has a clear trajectory upward of adoption. Below that I got statistics for signed second level domains in the new TLDs like .pizza and everything else. And they over doubled across 2015. So adoption is well underway. Also just the queries for DNSSEC, it's about 25% of queries in the United States are being validated. And company adoption. Many ISPs have jumped on board including Comcast, Time Warner, and other CDNs like Cloudflare, Alchemy have jumped on board. And even some large companies have made sure to support it including like Google's public DNS service, Microsoft's products can support DNSSEC and Cisco just to name a few. So I've also been asked, well, why should I even trust Root? Well, Root has a lot of hands on it. So there's a lot of different stakeholders. No one has any like one master key. It requires a big collusion of people to fake Root. And even if they did, changes would be noticed. It wouldn't be something that would go undetected. And even during the whole signing process, it's public, it's streamed, it's audited, and it's under a lot of control. So changes would be detected. Some have said it's expensive to deploy. Well, there is naturally an increase in overhead. We are going to be checking records so there would be an increase in CPU load, but with modern processors that shouldn't be an issue for most people. And we still, caching is still relevant for DNSSEC. There are some variables. I mean, if you're a top level domain, that may present some more issues that went through signing like millions of zones. Or if you're constantly needing to change and sign zones, there may be a little overhead there, but I feel the benefit far outweighs the cost. In this storage, we have not bigger zones. It's about the number I've seen is about, expect like a three times bigger zone. But in general, storage is relatively inexpensive. And zones are relatively small in general. Again, unless you're doing something like top level domain. Now RAM, so bigger zone files, we have more loaded in RAM. So we need about four times as much RAM. But again, at least commodity RAM tends to be relatively inexpensive. There is bandwidth issues, so we are making all these more queries about five times as much DNS traffic. But remember, DNS traffic is really tiny. So it's going to be insignificant compared to the rest of the traffic going over your network, YouTube, and everything else. Compatibility issues. So there are some hardware that may have problems with it. So this is an extension. DNSSEC is an extension of the DNS standard. But this extension was introduced in 1999. So most hardware should have caught up by now. Some vendors for some reason continue to assume that DNS is over UDP and only 512 bytes. But today, putting more information to DNS, it may work over TCP and be larger. But this has already been taken into account for decades ago. Like I said, there may be some non-compliant DNS implementations. Often, many times I know a lot of network admins have made these assumptions when they create their rules, so ACLs and whatnot may need to be adjusted accordingly. I've also been told, well, DNS is incomplete. There's still a hole in DNS. And there is what's known as the last mile or first hop issue depending on your perspective of how it works. But basically what they're talking about is where the chain actually occurs at is who's making the validation. And that's actually traditionally like your ISPs DNS server that your workstation is looking at to get answers from. So there is a need to secure the connection between the requester and the validating DNS server and to make sure that the validating DNS server is legit. There's several solutions being worked out. Unfortunately, there's no standard solution yet at the moment. But some of the ones in work is GetDNS, they work to create a standard API to help developers make DNS-seq-aware applications so the application can validate it for itself. Fedora's solution is to include a validating resolver with the operating system itself. So the workstation is the one doing the checking. That's changed from when I made this slide. They decided they were going to do that for Fedora 24. They postponed it for more discussion. But that's the solution Fedora is looking at, implementing. Microsoft's solution is to create an IP-seq tunnel from every client to the DNS server. And then there's DNSCrypt which actually looks pretty cool, but it's not gained enough adoption yet. That's actually encrypting the DNS traffic to the DNS server. And what about alternatives? Well, these are the alternatives that I have found. I've actually found there's a very popular article that is against DNS-seq and the author actually proposes to do nothing. I don't like to see that as a good answer. What's actually really awesome is DNS curve. It applies elliptic curve encryption to DNS traffic, but it's not exactly solving the same problem. It does look like a cool technology, but unfortunately it has not gained much traction so it's not really usable. What's out to date is DNS-seq. Brute has been signed, the infrastructure is there. And encrypt all DNS traffic outside a curve whether it's VPN or anything else. So quick notes on DNS curve. Lacking adoption. Open DNS and crypto storm are the only names that I could find that have adopted it. And even open DNS themselves say that DNS curve is not necessarily a competing solution. It doesn't stop them from also adopting DNS-seq. So how do we actually start taking advantage of this today? Well first I'll push out these links, but you can even Google for testing DNS-seq validation. And you can check, a lot of websites will have a little piece of JavaScript that can reach out and tell whether or not you're able to validate against their domain. So once we verify that we can actually use DNS-seq in the network that we're in, there's a really cool plug-in for most web browsers, Firefox, Chrome, I think even. I may be wrong, but I think you can even get this in on IE, but that might be a little crazy. But yeah, so right in your web browser you get a new button to let you know if you've gotten your domain through DNS and that you can know for sure this is the correct answer from the DNS server and is also capable of checking for Dain and PLSA certificates. And to use it on a workstation, so I'm currently using DNS-seq trigger. So on my laptop I move from different environments. I don't know always what's going to be capable of in different environments and if they're maybe filtering DNS traffic at the endpoints I'm stuck using whatever they have and that may not support DNS-seq. This tool comes packaged with a resolver, like a very lightweight DNS server, puts it on my laptop and periodically when it queries it looks to see if it can validate or not. And it can detect when it changes networks. So when it changes to a network that I'm no longer able to use DNS-seq, it will pop up with a dialog box asking me if I want to continue insecurely or do I just want to stop altogether? The reason why this is important is because if I just enable DNS-seq on my machine and I go into an environment where I can't use it, well nothing validates anymore. Basically I break the Internet for myself. So this allows me to work around if I'm willing to, whatever I'm trying to do, I want to get out to the Internet regardless of this solution that allows me to toggle back and forth. I do want to note it's at like 0.12 or 0.13 but I run it on my laptop and have no issue with it. And I'm just running a variant of Ubuntu so I'm not doing anything special here. So also if you just want to have a, being able to reach out, let's still don't want to do all the validation yourself, you can reach out to resolvers that support DNS-seq like Google and I have here listed a few others that are publicly available DNS-seq validating servers. So you don't necessarily have to do this on the workstation if you have some infrastructure, even your home router can do this for you. So there's a, on most machines we have DNS mass that is actually doing the querying for DNS for us. Up here unfortunately it doesn't come, I don't believe in most cases it comes enabled all the way. It's called DNS-seq aware but you can still break it because it's not going to, if it gets an answer that says, oh I don't support DNS, it's going to be DNS-seq, it's going to just take the answer. This forces it to actually check the params zone to see if that answer is true, like no, this guy really doesn't do DNS-seq. That doesn't come on by default because that could potentially break Internet for some people because that don't understand what's going on. Like I said, if I move into a different environment and my computer is forcing this check and someone's like, if scale were so crazy to like stop me from doing DNS-seq, then basically my Internet would be broken, a normal user may have it. So they do it too for simplicity but that's a bit of an issue with adoption. And well DDWRT uses that same tool and from what I've read online putting in the options for DNS-seq should enable it. I haven't verified that myself but you go to its web GUI where it lets you put in the options and you should have the Internet. A router you can have in your house that does work for sure is a PF Sense and it is literally a check box and will get the keys for you and everything it needs and is aware of what it needs to do. Or open Sense, sorry, it's the fork of PF Sense. Okay, so what about if we have some more back-end infrastructure? We are the guys with the mail servers and the other communication servers. Well we do have a couple of communication server software that are ready to take advantage of DNS-seq and I really like that JITSI is on board and that we have a SIP solution. There's also some Java servers and clients that are not only able to take advantage of DNS-seq but Dain as well. So these guys can automatically check for certificates and automatically establish a secure channel for you. A couple of mail servers that are already on board or some of the most popular mail servers also can support Dain to do that automatic check and automatic creation of a secure channel. So well if we are a domain owner none of this works if we haven't implemented this in our domain. So you do got to make sure that your registrar can do this. Diana has mandated that all registrars are capable of this but it does vary in actual adoption of who is doing it. I've just thrown up a few to illustrate a handful of the more popular guys that can do DNS-seq today. Basically that means they can take the DS key and pass that to the parent for you. So how about if we actually run a DNS server? Well, Vine 9 is like the standard reference implementation for DNS. And they can even help if you have to do dynamic signing of your keys because you're constantly making changes to DNS. They have a workflow and stuff ready to go. The DNS server of my choice is definitely NSD. It's simple and lightweight. So that's why. And even Windows 2012 supports DNS-seq. They don't support Dain but at least Windows chugging along. They will support Dain in 2016 if you work in a mixed environment. That may be something to be aware of. So you are managing now keys with your DNS. And there's some tools that have come out to help automate these processes. So Open DNS-seq is one of the nicer streamlined turnkey solutions to automate this process. Take whatever policies you need and apply them accordingly. DNS-seq tools is offered a suite of different tools that help you troubleshoot. They've even pushed out patches to applications. They've forked Firefox and they've made Bloodhounds so they have their own web browser if you want a native DNS-seq support. So there's definitely tools available to help make this task simpler. So conclusion. We're almost over. So I'm here because I wanted to spread awareness and adoption. So I hope that I've encouraged enough that you guys want to spread awareness and adoption, take this information back to your shop and start looking at what it will take to implement this. If that's not you, even at your home, make sure that can your ISP do DNS-seq? And why not start asking your bank? Are you looking at these technologies and start pushing the demand for adoption? And even just put it on your own workstation yourself. DNS-seq trigger is a very easy app-get turnkey kind of solution. Also if you need help with adoption, please don't hesitate to drop me a line and I would be more than willing to send reference information or however I may be able to assist. So DNS is fundamental to the Internet, but it's unsafe. DNS-seq is the next evolutionary step in securing the Internet. And DNS-seq is the foundation to more possibilities of doing secure communications and secure transactions over the Internet. Thank you very much. I do want to send a shout-out to Josh Koo of the Internet Systems Contortion and DeepDive Networking. He's allowed me to continue to pick his brain about some of the finer details as I've learned and make sure things are accurate. And here that QR code will take you to my site, which will have the link to my Google Docs version of the slides. And I'll update it with SlideShare. And as soon as I can get the video link, I will put everything on my website page here. I will also be tweeting it in a little bit at Digital Roots 00 in Roots. And I don't know if I have time for questions, but I've got five minutes. Yes, that is correct. So Dane does provide the enforcement. Oh, yes, I'm sorry. So he's asking about a downgrade attack against SMTP because by default, you have to ask the other side whether or not we're going to do any sort of encrypted connection. And depending on the answer, if the answer no, then it's going to be out in the open. And someone could just be seen in the middle lying through both sides and watching everything. And the question was in regards to making sure and enforcing that that's not happening. And that is what Dane is capable of doing. So we are able to – an endpoint has to be capable of understanding Dane and knowing to take a look at the DNS query before starting that communication or the DNS record. And it can look to see if there is a certificate for the other endpoint. And then it will know for sure. And this is after we've already established that we trust DNS. And if it's not there, and because we have authenticated denial of existence, we can know for sure whether or not they do. So we know like, well, no, they really don't, so like we're stuck. But we can check and we trust DNS. We can see that the record's there, so we will use it. And if for whatever reason something else is breaking our connection, well then it's just not going to make the connection. Yes. So the question was if you're on a network on a land that is not providing you with a DNS server that can support DNS. So can you just point to Google DNS public servers? And the answer is yes. What I was trying to articulate though was like if you're in an environment where they may be filtering and not allowing you to do external DNS, then you're kind of stuck. Yes. Yes, the example was given about like this is common at hotels where they want you going over their Wi-Fi and want to intercept and reroute your DNS information. And I actually have experience with this. Coffee Bean is where I do basically my office. And so as I was getting prepared and learning more about DNS tech, getting deeper into it, I actually got to watch them learn about DNS tech. Because some days it will work, some days it wouldn't, some days I can get traffic out to my own resolvers, some days I couldn't. And I'll send a shout out to them since I use them freely as my office. They got it working and it's been consistent for over a month now. Any other questions? Yes. I am aware that there is many. The question has to do with that many of the most popular sites are not signing their zone, their domain, including Google who has enabled DNS tech on their DNS servers, but yet I go to Google.com and they are not using DNS tech sign zones, which is a bit disappointing from Google. But even regardless, we're still in that adoption phase. Adoption is still growing exponentially. And even for financial institutions that do not want to deal with it, that's fine. They'll go away as the way of the dinosaurs. The new companies will come in that are willing to adopt and that are concerned about their customer data. So while it's true, we need zones to be signed for there to be something to use. Things are definitely moving in that direction. I wouldn't argue not to use it because otherwise that goes back to the argument of like, well then what's the alternative? Do nothing. So I think it's clear that the trend is towards DNS tech and eventually everything else will get caught up. Any other questions? Oh, sorry, we're out of time. Though I would love to continue any discussions. If people are interested, I'll be outside. Reach me at digitalroutes00.com. Thank you.