 My name is Jim Nitterhauer. I'm a senior security specialist with AppRiver. My talk is entitled DNS Devious Name Services Destroying Your Privacy and Antinuity Without Your Consent. Before we get started, you can read all this legal stuff here. I don't really care too much about it. AppRiver is a web and email security company. We offer three main services, Secure Surf which is a spam filtering service, Hosted Exchange and then Secure Surf which is where I come into the picture. My expertise is in building out that DNS infrastructure. So before we get started, so why am I doing this talk? In 2014, Glenn Greenwald gave an outstanding TED talk entitled Why Privacy Matters. He discussed the good people, bad people fallacy and the dichotomy between what corporate America says about privacy and what C-level execs personally believe when their own privacy is at risk. Greenwald mentioned a quote from Eric Schmidt in 2009. And he said, if you remember, he said, if you have something that you don't want people to know, maybe you shouldn't be doing it in the first place. Yet in 2005, Google blacklisted CNET reporters from talking to Google employees for one full year until July 2006. This was all because CNET published some information on Schmidt including his political views, hobbies, salaries, neighborhood and all this other information. Guess where they got that data? Google. So maybe he should be a little more careful about what he puts in his own services. In 2010, there was a TechCrunch interview with Mark Zuckerberg and he essentially told the reporter that privacy is dead and that yet in 2013, Mark Zuckerberg bought four homes that surround his own home as a buffer zone to prevent people from getting close. Uh-oh. This thing's going wonky on me here. Make sure I'm in the right spot. Yes, that's, I'm sorry. Yeah, it's going, it's going crazy here now all of a sudden. Yeah. All right. So I'm going to unplug it and re-plug it back into what happens. You know what they say, what can go wrong will go wrong, right? It was working perfectly in the ready room and working perfectly earlier. So we will start this again. I think we're back on track. Maybe. So the point is that privacy should be important to all of us, right? We shouldn't be expecting the corporate leaders in America to have a different standard for how they treat our own privacy. Here we go. See if it goes down. Yay. Okay. So more recently, the Chinese government made it clear that they were going to crack down on VPN users within China when you had another attempt to quash privacy. As I began to understand the details of the DNS protocol as it related to our service offerings, I noticed there were some components of DNS that if it were used inappropriately, it would result in further erosion of user privacy and possibly diminish your security. So I believe that education is key and that's why I put this talk together. I first learned about the use of EDNS client subnet while I was working to optimize content delivery via DNS. In May 2016, I received a call from Matt Calder at Microsoft. He called me and said, you guys are using EDNS client subnet in a caching environment. That's kind of weird because the only other people we see in our passive DNS data doing that is the Chinese government. And we had a good discussion about why we were doing it and what the implications were. But it was interesting to me that the Chinese government was implementing this as a way to continue to spy on people. So companies like Akamai Google, Cisco, which owns Open DNS now and others are making use of DNS in unique ways. Sometimes the rush to offer these new services to improve the security and functionality that comes at expense of our own personal privacy. With the repeal of the FCC regulations prohibiting the collection and resale of user browsing data that was sent at joint resolution 34 in 2017 and 18. The internet and content providers now have the freedom to profit from the sale of your data. If you were here in track three yesterday afternoon, there was a great talk on how that supposedly anonymized data could be de-anonymized and returned to point to specific users. It was kind of a scary talk. So you might want to look that one up. So here on the left you see, I don't know if you know who Suffering Bastard is, some of Jack Daniels in the room or Suffering Bastard is here, but I kind of follow the adventures of him on Twitter and I saw this picture. Jack gave me permission to use it and I appreciate it. This picture reminds me of us as the user, Suffering Bastard. And somebody threw some breadcrumbs on the ground. Those breadcrumbs to me represent the data that we're putting out there. And the pigeons are the providers collecting that data, trying to distribute that information without us really wanting it distributed. And Suffering Bastard pretty well sums up the reason for this talk. Is this the life that we really want? Do we want everybody knowing every move that we have on the internet? I would say not. So shout out to Jack Daniel. I don't know if anybody, here we go again. Yeah, I know. Sorry about this. That's just the way it goes sometimes. So maybe the next slide will be better. We'll keep on going because we're going to run out of time if we keep mucking with this here today. All right. That doesn't look good at all, does it? I'm going to keep going on with the talk and you'll have to deal with seeing the slides in retro disco mode here. So today what we're going to do is review DNS, give a quick history of DNS, review the introduction of EDNS 0 extensions and the option codes that go along with those. We're going to discuss the rationale for EDNS 0 use. We're going to examine EDNS client subnet as one of the options that's in use right now as an example of how those option codes are used. We're going to review some DNS servers that support that. We're going to examine some tools and procedures for testing that. And we're going to discuss the privacy implications that EDNS 0 options could have in your environment and hopefully have some time for questions if we're not staying in disco mode too long. By the end of this talk, you should understand the basics about EDNS option resource records. You should understand the potential that they have to be a threat to your privacy. We should have some direction for testing how those are put in play in the DNS world and you'll be able to understand how to better protect your online privacy. So very quickly we're going to do a quick review of some history of DNS here. So stick with me for a minute. DNS was originally devised to support the growth and communication of email via the ARPANET. Host names were developed as a way to make it easier for humans us to remember and recall addresses. Initially the name number relationships were kept in local files on servers. These files were prone to errors as a result of it was difficult to share and maintain this information. Those original files were called the host master files. So that's why typically when you're dealing with somebody that's registering a domain name they have a host master account. The system grew up became obvious that the distributed system was necessary. And in 1983 Paul Machopitri and John Postal proposed the domain name system and those RFCs that we now use for DNS are RFC 1034 and 1035. DNS was designed to be a distributed database that's hierarchical in nature. The master level is the dot domain. All other domains are directly linked back to this dot domain or the root domain. A fully qualified domain name must be expressed with the trailing dot. Domains consist of a namespace which is the level and location in the tree. The resource records that define that namespace and the resolvers that propagate and manage those records. Second generation DNS improvements came about in the introduction of incremental zone transfers with RFC 1995 in 1996. Part of that time changes in a DNS zone required the full transfer of all hosted zones to other interested neighbors that now it would be possible to transfer only those zones that changed to the interested neighbors. This is done by comparing serial numbers in the SOA record for the interested neighbors. The RFC 1996 also introduces the concept of master and slave records as well as a notify message. This improved the efficiency of DNS by reducing network traffic. Lesson of the year later the third generation of DNS was introduced with RFC 2136 and the concept of dynamic updates. This takes transfer efficiency to the next level by enabling master servers to transfer only changed resource records within a zone to those zones that are interested neighbors. This further improved the traffic flow and introduced the concept of the TTL or the time to live that we're all familiar with right now. In 1999 RFC 2671 and now later 6891 bring about the addition of the extension mechanisms for DNS or EDNS 0 and we'll dig into those details a little bit more here coming up. Fourth generation DNS enhancements included the addition of standards for RFC 2181 which just redefined some of the standards for DNS and the implementation of standards for NX domain responses defined in RFC 2308. If you want to look at some more information about the fifth generation DNS improvements came about with the inclusion of DNS sec in the EDNS 0 options and then the definition of the option codes which we're going to be looking at a bit more here coming up. If you want a quick reference on the best places to look to get an overview of DNS there's a couple quick ones that you can look at. So let's look at RFC 2671 a little bit more. RFC 6891 is the one that's currently in play. RFC 2671 was proposed by Paul Vixie in 1999 and replaced by RFC 6891 in 2013. The standards for following DNS to exchange information about servers and services within a given zone. Remember DNS is a layer 7 protocol that essentially uses UDP to exchange DNS information. TCP is used for zone transfer and more recently as a way to mitigate DNS amplification attacks. DNS data has a hard packet size limit of 512 bytes when EDNS 0 is not in play and the DNS packets containing more than 512 bytes will typically fragment leading to some interesting DNS results. So option records contain at the very minimum the extended datagram size which is the size of the packet, extended return codes and the DNS okay flag that tells whether DNS sec is enabled on the network. This allows for additional space and additional return codes and a DNS message. DNS option records have a record ID of 41. They are not stored in record files so they cannot be loaded from zone files. They can only be set programmatically. All right. So again this is a type 41 record. The R code field is from 4 to 12 bytes long. The EDNS RFC 6891 defines the option record sizes and RFC 3225 defines information about DNS sec. All right. This is an example of this option record is option 41. We talk about that and again it shows the information about DNS sec. So here we have this shows the format of one of these option records. Let's get this out of your way. Sorry for the technical difficulties. We did test this earlier and everything worked fine. So maybe somebody's figured out a way to hack HDMI remotely. Well earlier there were people with max having the same issue so it's a shared problem. Do they know what PowerPoint is? So we interrupt this talk for a brief comedy routine by the audience. I won't be able to see my notes. I can just follow them on the other screen. That's fine. I can follow them on the other computer. All right. So now I got to have one hand for the mic and one hand for each computer. So here we go. Now we got to play catch up. Let's get us up to where we are here on the other screen. All right. That's where we are. Option resource records. These option resource records are defined in the RFC and they are showing you how each packet is defined and inside this the important part that we're going to look at here in a few minutes is the R data field and that is where the option codes will be stored for DNS. This part of the record here is the TTL field. So if we go back up, the TTL field is used to store information about DNS second information within the DNS zero option record or opt record. If we look at the R data structure, this is attached back up one. The last row here, the R data field has a structure that's variable for each of the 65,335 different option codes that are available for EDNS zero. And this would be the structure of a typical record. All right. What we're looking at here is a bit of a wire shark capture that shows the EDNS zero opt record. Starts at the root there, shows the opt record. But if you look down in there, you'll see that this shows the TTL record which has the DO bit, which tells you whether DNS sec is available or not. And then below that, it has one option record in there. And this one, it happens to be option 8, which is EDNS client subnet. And we're going to look at that a little bit more in detail here as we go forward. So all of these EDNS option codes are defined via RFC or by drafts. This is from the IANA website and lists all of the current assignments for EDNS zero option codes and tells you links to the RFCs that pertain to them. If you want to look at drafts, you have to go to the IETF.org website. If you search through the option codes that are available there and use the keyword EDNS, it will give you the options that apply to EDNS as they're released or put in the list for review. So this is a table that shows the option codes that are available. Right now, this shows the status, the name, the description, and the vendor who proposed it. And we're going to go through a few of these. This is the same information. The last two at the bottom show proposed drafts and we'll look at those here in just a second. So option codes 5, 6, and 7 are related to DNSSEC implementation. This lets resolvers know which cryptographic algorithms was used to generate the digital signature that's used to exchange information via DNSSEC. This specifies the way for end users to validate what types of encryption algorithms are in play. They're not required for DNSSEC to work, but it does make it much easier for DNSSEC to work. Option code 8, this is EDNS client subnet. This is the one that is probably most widely used and we're going to look into some of the details of this here a little bit as we move forward. This lets resolvers know the IPv4, WAN, or IPv6 address of a subnet of the requester that's making a DNS request. It's developed to enable content delivery via DNSSEC and we'll look a bit more of this here coming up. Option code 29 or 26946, this is called device ID. This is used by Cisco's umbrella platform, formerly open DNS. It sends the information that's shown there. You have an organization ID, a remote internal IP, and a remote IPv6 address that is forwarded to Cisco's umbrella API or via Cisco's umbrella API to their umbrella dashboard. This is either forwarded from a client that has the umbrella client installed on it, so it could be laptop, it could be tablet, whatever, or it's from a router that may or may not have umbrella enabled via API, DNS proxy and an API. This one here is the ISP draft location. This is another gift from the China Internet Network Information Center, so it's got to be legit, right? So they're proposing here, their basic gist of this is that EDNS client subnet provides IP information, Chinese government wants to know the country, the area, and the ISP that's sending that information as well in a DNS packet. So this isn't sketchy at all, right? This last one is the client ID. This is forwarded in DNS queries. This is proposed by Akamai. It's currently in draft. It's being fast tracked for RFC and what they want to do is send the MAC address and a hash of some other information from your device through DNS in an EDNS zero option packet to their upstream DNS servers. The rationale behind this is it allows for when a device seems to be making calls to compromise domains, you can attribute that compromise to a specific device on the network. So let's look at EDNS client subnet in a little more detail so we can see how these kinds of things evolve. This was an initial draft in 2011. It was released and proposed by Google, Verisyn, and Newstar. The first provision of the draft came in 2013. And if you look here, you'll see, I'm going to go through these a little bit quickly, this is how quickly the changes were made to this draft once it became fast tracked for implementation. So within a year it was an RFC and it's now RFC 7871. There was also two patents submitted for this RFC, they'll never pass, but somebody tried. The European, somebody in the European Union is trying to get a patent on it. That will make it impossible for anybody else to implement this without paying them royalties. And there's a US patent number that's pending. I don't suspect that either of these will ever be issued. So how does EDNS client subnet work? Normally a client makes a DNS request to a substream cache resolver. That resolver, if it has it in the cache, will answer and give you the DNS data back to the device. Now, if that resolver supports EDNS client subnet, it will append the EDNS option packet with the option 8 data and send that to every upstream server involved in the DNS request chain. Think about that for a minute. Right, normally a DNS server, one hop up knows your public IP address. With the EDNS client subnet in play, every server in the chain potentially has the ability to read your WAN IP address. The authoritative server then will do some calculations based on the data that's provided in this ECS packet and return an A record based on whether or not a geolocation is in play and send you to the correct site. So this is a content delivery network load balancing via geolocation and IP. If you look at a client subnet record, we looked at this, part of this in a larger section through the EDNS zero record. But this is an example of what you see if you see it in Wireshark. So the first line just tells you what option it is. The option length in this case is 8 bytes. It gives you the option data. It shows you that it's using IPv4 as the IP address that's being passed up to the upstream provider. In this case, the source net mask is 32, so this is a misconfiguration by the RFC. It should be slash 24 or greater. And the scope net mask tells the receiving server what range of geolocation to provide an answer for. And then you see obviously the IP address of the requesting client in the packet. These are the authoritative servers and caching recursive servers that currently support EDNS client subnet or ECS, Google Akamai, NS1 Open DNS, Ultra DNS, Power DNS, Bind 9.11 greater, Amazon Cloud Front. They all pass ECS data from any edge through the DNS chain. Recursive resolvers, unbound supports it from 1.62 and above. It has to be currently compiled with an option to enable that. If you don't compile it without an option right now, if you just download it and install it through the normal package, it does not include support for this, but I suspect that will change here in the near future. So Open DNS and Bind also supports Bind 9.11 and greater also support EDNS client subnet. There was a move afoot called a faster internet. This was a consortium of people who got together and decided that we wanted to push EDNS client subnet or ECS through to RFC. They are, were very active. They've been kind of dormant lately. And none of these providers really provide you any information as to whether they do or do not support the protocol. So problems with this, we need to be able to evaluate whether this is in use or in play on our network, right? So there's really no registry showing our name server support ECS, right? So we don't know whether it's an ECS compliant resolver. You're relegated to reading the provider's tech material and some of them will put it in their website and tell you that they do use it and the site of faster internet is not current. Recursive resolvers are now, that support this are now becoming more prevalent and they're also same deal. There's no register listing to give you any insight into whether they're supported. So how can we check to see whether it's in use? Well, one of the best tools right now is dig. We can do a dig against anything after the at sign would be the name server we want to hit. And if we do use that domain, the EDNS client subnet, that's a registered domain that's hosted by power DNS. Thank you to them for putting that out there. It will return a JSON packet that tells you whether the server that you queried against supports ECS in the query chain. The second way we can do it is we can use dig and we can use the plus subnet option. Now this is built into the later versions of dig. Last time I checked, the version that's installed in Cali supports it. The version that you would download from bind and install on Windows also supports it. So you would use this plus subnet option and you can change that option, the IP address in that option to any IP that you want and you can see what kind of information is returned from the server based on the domain that you're looking up. So for example you could run this against Google's cash server 8888 and use google.com and you will see that IP addresses that are returned based on the client subnet change as you change that client subnet IP. This is an example here of using the first method where we're actually querying the EDNS client subnet. And you see the JSON packet there in the response and it gives you the option if you look halfway through you'll see ECS colon true. So it tells you that it does support it and you'll also find the source mask and the scope mask in that packet. There's no information in the opsudo section so the upstream server that I queried in this case did not receive any ECS packet when it when it was queried. It only returned one based on the result of the query. This is an example using dig. We're using a dig against 8888 for Google with that subnet option and it gives you those IPs. If we were to change the IPs that we use in the plus subnet option we would get different IPs back for Google and you can try this against other cloud type systems to see whether it works. Some other tools that we use for testing support would be to install packet beat. Okay so packet beat can be installed on many many different platforms and one of the packet capture protocols built into packet beat is to capture all DNS traffic. So it's a parallel capture and it can forward all of that traffic to some sort of log aggregation. In our case we use gray log which you could usually use Splunk or any other log aggregator that would read the JSON packet that packet beat sends to it. Or you could put it directly into Elasticsearch and read it with Kibana. I'll show you an example here of how that works. So what you do then is you create a stream for example in gray log and you can tag the stream for a particular field. The field that's returned is that packet beat DNS option subnet field. Right now packet beat only has the ability to support option 8 which is ECS. But in the future I would imagine that other options would be able to be read from that stream. Here's an example of what you get. You get a graph. Basically what we have is a small ISP setup for some internal customers that have public facing IPs. They use these DNS resolvers and you can see that their IP address is in the second column there under messages. So we would see if we were three hops out we would still see their WAN IP address in those DNS packets and be able to capture that. So this is not anything that's very difficult. Any ISP could do this at any point in their network and gather information about domain requests for any IP address. So other things that we could do to evaluate use is we could run captures on local interfaces, PCAP captures. In Wireshark you would use a filter here. It has a built-in filter for DNS where you can do the DNS opt code filter. If you put a number after the doubles equals that's the option code number. One of those 65,535 codes. So if you put in 8 you'll find all of the ECS data. You can go through and try this with other option codes and you might be interested to see what's in your DNS. Just a side note. How many of you have looked at Microsoft's Windows 10 lately? So they've added a multicast DNS cache resolver on port 53. 53 is built into Windows 2016 and Windows 10. So if you're looking at DNS you also have to take into account the fact that multicast DNS could be present on your network and could leak DNS information that you may not capture in your normal Wireshark data capture. So it's just something to keep in mind. This is a single line Wireshark capture of a query a send and receive and it shows you where the ECS data is highlighted down in the bottom. Nmap also has a script that's available. This probably came out before support was built into dig. So you can if you're doing engagement. So I want to do some automated scripting. You can use this Nmap script to gather information about ECS support upstream. It's a little cumbersome. It returns a lot of data and you kind of have to sort through it and manually compare IP addresses to see if support is there. Not really recommended way for doing it. I'm working on a tool. I didn't get the chance to finish it. But what we're going to do, what I'm going to do is look through maybe the top one million or whatever number of domains we can look at. We're going to look at the domain name. We can run dig against each name server in that and we can sort out to see which ones support ECS or supply ECS data using several different methods that I've already gone over. So once I have that information available and put that out there I will put that in a block somewhere where somebody can get at it. So the other thing is that we noticed when I when I start looking at programming support for DNS, the libraries that support looking at DNS traffic. AR soft tools supports option eight manipulation so you can set it. You can read it. Right now it doesn't support any other options. But once that support is built in then you'll be able to look at some of those other option codes that we looked at. Python also has support in their programming language for being able to read the EDNS or ECS option eight. I think Python the PHP net DNS 32 has it in there as well or DNS 2. Skapey does not have support for it at the moment. Skapey is a open source packet generation tool. So being open source if somebody were interested they could add those options and parsing for those options into the code repository so it's just a matter of time until that's out there. That's kind of interesting because once that's in the ability for Skapey to generate packets with spoofed information could be created and sent upstream resolvers. So what does privacy and security implement implications of all of this? Well this was in 2013 when I found out the NSA was reading all of our data. Delbert kind of sums it up. So ECS leaks your IP information if it's in play to every DNS server in the DNS chain. If those servers are able to read that data or if there's packet B or some other logging mechanism installed on those servers that data can be gathered. So interesting right? The first server in a chain for ECS may not honor the subnet restriction meaning if your WAN has a slash 22 and that's what you want broadcast so everybody in that same network gets the same cash results it may actually send a slash 32 or a slash 128 for an IPv6 so you can attribute the DNS request to a specific endpoint. Now remember there's no such concept as NAT with IPv6 right? So IPv6 is deployed all the way to the endpoint. So if you're sending out a slash 128 through one of these options it's getting back to the actual device that has that IP address bound to it. Many of these options are proprietary with no insight into how to send how the data is sent to them. The data that's sent is not always fully disclosed and the other problem is that they all talk about in the RFCs that there should be privacy mechanisms in place and there should be ways to opt out. How many of you know how you could opt out of some of these options? Probably nobody right? I don't. None of these providers have given us any of that insight. They also don't advertise whether they support it or not. It's up to us to test to see whether they do and the implementers can track your data without your knowledge as we saw in the talk yesterday about web browsing data. Now imagine DNS data right? So every call out to the internet from every device every application not just web browsing uses DNS to get you out to the internet and get results. So basically nothing you do on the internet in any way will be private. So it can also return data to the client. This is kind of the scary part. People haven't figured this out yet how to use it. But once they do and once the programming libraries are in play there's going to be new ways for botnet commanding control traffic to be transmitted right? Remember there's 65,535 of these options. Anybody with a little programming creativity wants some of these programming libraries support the ability to add these options in DNS packets can add data to those packets and send it across the wire. So how many of you monitor your DNS right now? I should see every hand in here up. Every hand right? But how many of you that monitor your DNS monitor DNS for option data that goes out of your network? Right? We can look at DNS traffic and we can find exfiltration by subnets added to A records and text records but how many actually look at these records to see what kind of things are going on in your network? This is going to be a big deal once people understand how this works. The other problem is third party recipients can buy information regarding your DNS habits. So if somebody tracks that through four hops upstream, then that data is available for sale. The law gives these providers the ability to sell it. People can use that for various reasons as we saw yesterday. They could use it for good. They could use it for malicious purposes and unethical people could buy that information and use it as well. So the privacy as it relates to DNS without extra steps in place is pretty much dead. So one of the problems is this is just a sub example here. This is a correct configuration of unbound how it's set up to send ECS data upstream. So for IPv6 it will send a slash 64. That's the smallest amount that should be applied to an interface or for a client a slash 24. But it's just as easy to configure it to send a slash 128 or slash 32. So now we get down to the specific device IP address. So these configurations are not very well controlled. They're not very well explained. And this is just one example. And if you look at one other thing, if you look in the configuration for unbound, for example, it gives you the option code for EDNS client submit. They built into this the ability to do other options. They just haven't released the ability to do it at this point. So kind of watch what's going on with that. All right. So how do we defend against this sort of thing? One is know what's normal. Log your DNS. You can log it through looking at just DNS logs or you can do full packet capture. The point is you need to know what's normal on your network. I would imagine that if you dig into your DNS, no pun intended, if you dig into your DNS traffic a little bit more, you're going to find things that you never expected to see on your network. Route all DNS to known resolvers. Don't let your users change your resolvers, right? Make them force your DNS to resolvers that you know and you trust. Lock out non validated DNS at the edge. You could disable the DNS zero, but my guess is you would break a whole lot of things. So I wouldn't suggest that. Monitor your DNS logs obviously and do full P-CAP capture. Something like security on your NERBRO on a span port on your edge network would be nice. If you start seeing things in your DNS, create IPS rules to block it. You could enforce DNS sec, the requirement for it, but stuff will break. A lot of people don't maintain their DNS sec keys correctly, particularly the big brother domain.gov. We've seen those break several times where they don't rotate their keys and they fix it pretty quickly, but anyway, it breaks DNS. Some offensive options that you could use to prevent people from forging information or for gathering information about you is you could create DNS with forged option data, right? You can create packets that forge that information and basically blur what you are doing based on your IP. But I would suggest that if you're doing any kind of engagements, you're doing anything where privacy is in the least bit critical that you use a full VPN tunnel and then tour out past that VPN to a safe endpoint. And I'll give you some insight on a couple of other things that I would do as well. One of the big things that people don't do is account for IPv6 traffic. So which protocols preferred on almost every network stack? IPv6, right? Windows IPv6 is preferred all versions of Linux that I know of IPv6 is preferred. So if it's on your network and you get an IPv6 address, that's what it's going to use. So you need to make sure that when you're doing engagements, you're doing things where you want to hide yourself that you're only using IPv4 or that you're accounting for your IPv6 traffic on your network because some things will leak information that you may not expect. If you use Torgos, for example, on Kali, it only supports IPv4. My home router has IPv6 enabled, so I have to be careful what I'm doing when I use Kali at home. I have to disable it completely on boxes when I'm doing things that I want to test. And you can also test on your local network with wireshark or TCP dump to make sure your DNS is going where you think it should. And again, check for multicast DNS as well. The other way you can make DNS really secure is you can build yourself a DNS crypt resolver in the cloud. DNS crypt is put out as an open source project by open DNS. Now, Cisco, you can build your own. You can build it into unbound. You can compile unbound with it. But basically what it does is it creates a way to prevent DNS from being spoofed. But the other thing you can do then also is, wow, must have gotten somebody upset. So the other thing you can do is set that resolver to not push any ECS information out over the network. I don't know if I can talk loud enough with this. So we're almost done here anyway. So if you set your resolver using DNS crypt proxy on Cali, you just download and install that package and point your resolver to the 127.021 address and it will route your DNS to a series of DNS crypt resolvers that are part of a public list. You can adjust that list and forward it only to your own DNS crypt resolver. And that way you know for sure that your DNS is secure, or at least as secure as you can make it. So summary, the option data usage has several useful purposes. It allows CDN by DNS. It enables DNS sec. It gives DNS responses that can be used to mitigate DDoS in certain situations. And the signature of compromise can be attributed to a particular device when a device is compromised. Those are all good things. The problem of it is that all DNS servers in a DNS chain can track that data if they're enabled to read it. No standard has been set for developing for opting out of that. Forwarding DNS options compromises your privacy and there's no mechanism to verify the opt out again. The opt data could have potential for abuse because people are mining that data. It could be spoofed, right? So if somebody is using that data for legal reasons, law enforcement maybe, there's no way to attribute that data to you accurately because other people can modify that data. Botnet commanding control traffic, I think you'll start to see that happen over these options and data exfiltration could be done via these DNS option packets. So these are all things to keep in mind and look for. And if you have any questions you can find me afterwards. I'll be here through Sunday but I appreciate your time. Thank you.