>>My name is Jim Nitterauer I’m a senior security officer with AppRiver.  My talk is entitled, DNS, Devious Name Services Destroying Your Privacy and Anonymity 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, uh hosted exchange and then secure surf.  Which is where I come into the picture.  Uh my expertise is in building out that DNS infrastructure.  So, before we get, oop it jumped on me there.  Here we go.  Before we get started, um so why am I doing this talk?  In 2014 Glenn Greenwald gave an outstanding Ted Talk about 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 uh, quote from Eric Schmidt in 2009.  And he said if, 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 1 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 uh be a little more careful about what he puts in his own services.  In 2010 there was a TechCrunch interview uh with um Mark Zuckerberg and he essentially told the reporter that privacy is dead and that um, yes in 2013 Mark Zuckerberg bought 4 homes that surround his own home as a buffer zone to prevent people from getting close.  Uh oh, this things gone wonky on me here.  Make sure I’m on the right spot.  Yes that’s.  I’m sorry.  [off-mic comment] Yeah it’s, it’s going crazy here all of a sudden.  [off-mic comment] 
Yeah, alright.  So, I’m going to unplug it and replug it back, see what happens.  Ya 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, point is 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, ok so, more recently the Chinese government made it clear that they were going to crack down VPN users within China and yet 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 in appropriately it would result in further erosion of user privacy and possibly diminish your security.  So, I believe education is key and that’s why I put this talk together.  I first learned about the use of EDNS client’s subnet while I was working to optimized content deliver 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 he, we had a good discussion about why we were doing it and what the impl- implications were.  But it was interesting to me that the Chinese government was implementing this in a way to uh, continue uh, spy on people. 
So companies like Akamai, Google, CISCO which owns OpenDNS 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 of the, comes at expense of our own personal privacy.  With the repeal of the FCC regulations prohibiting the collection and resale of user browser data.  That was senate joint resolution 34 uh, 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 for track 3 yesterday afternoon there was a great talk on how that supposedly anonymized data could be uh, de anonymized and returned to point to specific users.  So it was kind of a scary talk. 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 Daniel in the room or if Suffering Bastard is here, but kind of follow the adventures of him on Twitter.  But I saw this picture.  Jack gave me permission to use it and I appreciate it.  Uh, this picture reminds me of us as the user suffering bastard.  And somebody threw some bread crumbs on the ground. Those bread crumbs to me represent the data that we’re putting out that.  And the pigeons or the providers collecting that data. Trying to uh distribute that information without us really wanting it distributed.  And suffering bastard pretty much 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, should out to Jack Daniel. I don’t know if anybody.  Oop, here we go again.  Yeah I know.  [laughter]  S- S- S- S- S-.  Sorry about this.  That’s just the way it goes sometimes.  So. [off-mic comment]
Maybe the next slide will be better.  We’ll going to keep going.  Because we’re going to run out of time if we keep mucking with this here today.  Alright, s- i- well that doesn’t look good at all, does it? [laughter]
Well I’m going to keep going on with the talk and you’ll have to deal with seeing the slides in uh retro-disco mode here.  So today what we’re going to do is we’re going to review DNS.  Give a quick history of DNS.  Review the introduction of EDNS0 extensions and the option codes that go along with those. We’re going to discuss the rationale for EDNS0 use.  We’re going to examine EDNS client subnet as one of the options that’s in uh use right now as an example of how those option codes are used.  We’re gonna review some DNS servers that support that.  We’re gonna examine some tools and procedures for testing that and we’re gonna discuss the privacy implications that EDNS0 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 DNS world. And you’ll be able to understand how to better protect you 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 and these files were prone to errors as a result of it, it d- it was difficult to share and maintain this information.  Those originally files were called the host master file so that’s why it typically when you’re dealing with somebody that’s registering a domain name they have a host master account.  They uh system grew, it became obvious that a distributed system was necessary and, and in 1983 uh, uh Paul Mockapetris and Jon Postel 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 a level and location in a tree.  The resource records that define that namespace and the resolvers that propagate and manage those records.  Second generation DNS improvements uh came about in uh well the introducing of incremental zone transfers with RFC 1995 in 1996.  Prior to that time changes in a DNS zone required the full transfer of all hosted zones to other interested neighbors.  That now would be possible to transfer only those zone threat changes eh- eh to the interested neighbors.  This is done by comparing serial numbers in the SOA record uh for the interested neighbors. 
The RFC 1996 also introduces the concept of a master and slave records as well as a notify message.  This improved the efficiency of DNS by reducing network traffic. Less than a 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 servicers to transfer only changed resource records within a zone to those zones that are interested neighbors.  This further improves 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 mechanism for DNS or EDNS0.  And we’ll dig into those eh details a little more here coming up.
Fifth generat- or fourth generation DNS enhancements included the edition of standards for RFC 2181 which just redefined some of the standards for DNS and the implementation of standards for NXDOMAIN and responses defined in RFC 2308.  If you wanna look at some more information about um, the fifth-generation DNS improvements came about with the inclusion of DNSSEC in the EDNS0 options and uh then the definition of the option codes that we’re going to be looking at a bit more coming up.  If you want a quick reference on the best places to look to get an overview of DNS here’s a couple quick ones that you can look at.  S
o, 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.  Now 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 a DNS amplification attacks.  DNS data has a hard packet size limit of 512 bytes when EDNS0 options or EDNS0 is not in play.  And the DNS packets contain more than 512 bytes will typically fragment leading to some interesting DNS results.  So option records contain at the very minimum eh, eh the extended datagram size, which is the size of the packet extended return codes and the DNS OK flag.  That tells whether DNSSEC is uh 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 uh record files so they cannot be loaded from zone files.  They can only be set programmatically.  Alright so again this is a type 41 record.  Uh the R code field uh is from 4 to 12 bytes long.  And then EDNS uh um RFC 6891 defines the option record sizes.  And RFC 3225 defines information about DNSSEC. 
Alright this is an example of, uh this this option record is option 41, w- we talk about that and again it shows the information about DNSSEC.  so here we have, this shows the format of one of these option records.  Um.  [off-mic comment]
>>Let’s get this out of your way here. 
>>Sorry for the technical difficulties.  We did test this earlier and everything worked fine so.  Maybe somebody’s figuring out a way to hack HDMI remotely.  Well earlier there were people with macs having the same issue to its, it’s, so it’s a shared, shared problem.  [off-mic comment] [laughter]
Do they know what PowerPoint is? [off-mic comments] [laughter] So we interrupt this talk for a brief comedy routine by the audience.  [laughter]
>>Woo
>>I won’t be able to see.  [applause]  Will I be able to see my notes? [applause]  I can just follow them on the other screen.  That’s fine, I can follow them on the other computer. 
Alright, so now I gotta have, now I gotta have one mic for the mic and one hand for the computer. So here we go now we’ve gotta play catch up.  Let’s get us up to where we are on the other screen.  Alright, that’s where we are, right?  Option resource records.  These option resource records are defined in the RFC and they are uh, showing you that how each packet is defined and inside this the important part that we are going to look at in a few minutes is the R data filed.  And that is where the option codes will be stored for DNS.
This part of the record here is the TTL fields.  So, if we go, try- trying to find the, up.  If we go back up the TTL field is used to store information about DNSSEC information within the EDNS0 uh option record.  or OPT record. And if we look at the RDATA structure, this is attached.  Back up one.  The last row here the RDATA field has a structure that’s a variable for each of the 65,335 different option codes that area available for EDNS0.  And this would be the structure of a typical record.
Alright, what we’re looking at here is a bit of a Wireshark capture that shows uh EDNS0 OPT record.  Starts with the root there, shows you the OPT record.  But if you look down in there you’ll see that his shows the TTL record which has the DO bit.  Which tells you whether DNSSEC is available or not.  And then below that it has 1 option record in there and this one it happens to be option 8 which is EDNS client subnet.  We’re gonna look at that a little bit more in detail here as we go forward.
So all of these EDNS option codes are defined uh via RFC or by drafts.  This is from the IANA website and lists all of the current assignments for EDNS0 option codes.  And tells you, gives you links to the RFCs that pertain to them.  If you wanna look at drafts you have to go to the IFT dot 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 uh list for review. 
So this is a table that shows the option codes, they’re available. Right now um th- this shows the status, the name, the description, and the vendor, Uh who proposed it.  And we’re gonna go through a few of these.  This is the same information.  Uh the last 2 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 algorithm was used to generation the digital signal, signature that’s used to exchange information via DNSSEC.  This specifies a 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 pro- probably most widely used and we’re gonna look into some of the details of this here in a little bit.  A- as we move forward.  This lets resolvers know the IPv4 WAN or IPv6 address of a subnet of the requestor that’s making a DNS request.  It’s developed to enable content delivery via DNS.  And we’ll look at bit more at this here coming up. 
Option code 29, or 26946, this is called DeviceID.  This is issued by CISCO’s umbrella platform, formerly OpenDNS. 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, uh API or via CISCO’s umbrella to their umbrella dashboard.  This is either forwarded from a client that has the umbrella client installed on it, so it could be a laptop, could be tablet, whatever.  Or it’s from a router that may or may not have a umbrella enabled via API pr- uh DNS proxy and API. 
This one here is the ISP draft location. This is another gift from the China Internet Network Information Center.  So it’s gotta be legit.  Right?  So, they’re proposing here their basic gist of this is that uh EDNS client subnet provides IP information. Chinese government wasn’t 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 ClientID this is uh forwarded in DNS queries. This is proposed by Akamai.  It’s currently in draft. It’s being fast tracked for RFC.  And what they wanna do is send the mac address and a hash of some other information from your device through DNS in and EDNS0 option packet to their upstream DNS servers.  The rationale behind this is it allows for uh when a device seems to be making uh calls to compromised domains you can attribute that compromise that a specific device on the network.  So, let’s look at EDNS client subnet with a little more detail.  So we can see how these kinds of things evolve. 
This was an initial draft in 2011. It was uh released by Google, Verisign and Neustar.  Uh the rev- first revision uh of the draft came in 2013.  And if you look here you’ll see, I’m gonna go through these a little bit quickly. This is how quickly the changes were made to this draft once it became uh fast tracked for implementation.  So, within a year it was RFC and now it’s RFC 7871.  There was also 2 patents submitted for this RFC, they’ll never pass but somebody tried.  Uh the Europea-, somebody in the European Union is trying to get a patent on it, uh that will make it impossible for anybody else to implement this without paying them royalties.  And there’s the 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 s- a DNS request to a sub stream cache resolver.  That resolver if it has it in the cache will answer and give you the DNS data back to the uh device.  Now if that resolver supports EDNS client subnet it will pen 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.  Alright, normally the DNS server 1 hop up knows your public IP address.  With E EDNS uh client subnet in play, every server in the chain potentially has the ability to read your uh 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, or, or a geolocation is in play and send you to the correct site.  So, this is a content delivery network load balancing via a geolocation and IP.  If you look at a client subnet record, we looked at this uh, part of this in a larger sec through the EDNS0 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.  Uh the option length in this case is 8 bytes.  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 netmask is 32.  So, this is a misconfiguration by the RFC.  It should be a slash 24 or greater.  And the scope netmask tells the receiving server uh what range of geolocation to provider and 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.  Uh Google, Akamai, NS1, OpenDNS, UltraDNS, PowerDNS, BIND 9.11 greater, Amazon CloudFront they all pass ECS data from any edge through the DNS chain.  Recursive resolvers, Unbound supports it from 1 point 6, 2 and above. It has to be currently compiled with an option to enable that.  Uh if you don’t compile it without and option right now if you just download it and install it through the normal package uh it does not include support for this. But I suspect that will change uh here in the near future.  So OpenDNS and BIND also supports, uh Bind 9 point 11 and greater also support EDNS uh client subnet.
There’s was a move a foot called a faster internet.  This was a consortium of people who got together and decided that we wanted to push uh client 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 provider you any information as to if they do or do not support uh the uh 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 my, our name servers support uh ECS right?  So, we don’t know if it’s an ECS client 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 aside the faster internet is not current. Recursive uh resolvers are now uh that support this are now becoming more prevalent and they’re also same deal, there’s no register listening to give you any insight into whether they’re supported. 
So how can we check to see whether it’s in use?  Well l, 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.  Uh and if we’d sue that domain EDNS dash client dash sub dot net that’s a registered domain that’s hosted by a power DNS.  Thank you to them for putting that out there.  It will return a JSON packet that tells you whether the server 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.  Uh last time I checked the version that’s installed in Cali supports it. Uh the version you would download in from bind and install on Windows also supports it. So you would use this plus sub net option and you could 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 cache server 8, 8, 8, 8 and use Google dot com and you’ll see that the IP addresses that are returned based on the client subnet change as you change the subnet IP.  This is an example here of um, using the first method where we’re actually querying the EDNS dash client dash sub dot net and you see the JSON packet there in the response.  And it gives you the option if you look half way 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 opt pseudosection so the upstream server that I queried in this case did not receive an ED, ECS packet when i- when it was queried.  It only returned one based on the result of the uh query. 
This is an example using dig.  We’re using uh dig against 8 dot 8 dot 8 for Google with that subnet option it gives you those IPs.  If we were to change the IPs that we use in the plus subnet option e would get different IPs back for Google. And you can try this against other uh, cloud type systems to see whether it works. Some other tools that we use for uh testing support would be to install Packetbeat.  Okay so Packetbeat can be installed on many, many different platforms. And one of the um Packet capture uh protocols built into Packetbeat 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 uh we use Graylog which you could easily use Splunk or any other log aggregator that would read the JSON packet that Packetbeat sends to it.  Or you could put it directly into Elasticsearch and read it with Kibana.
And I’ll show you an example here of how that works.  So, what you do then is you create a stream for example in Graylog and you can tag the stream for a particular field. The field that’s returned is that Packetbeat DNS option subnet field.  Right now, uh Packetbeat 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 string.
Here’s an example of what you get.  You get a graph.  Um basically what we have is a small ISP set up for some internal customers that have public facing IPs. They use these DNS resolvers and you can see that i- their IP address is in the second column there under messages.  So we would see if we were 3 hops out, we would still see their um 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 a domain request for any IP address. 
So, other things that we could do to evaluate use is we could run uh captures on local interfaces. PCAP captures uh in Wireshark you would use uh a filter.  Here it has a built in uh 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.  Um, how many of you have looked at Microsoft’s Windows 10 lately?  So it’s uh, they’ve added a multicast DNS cache resolver on port 53, 53 that’s built into uh Windows 2016 and Windows 10.  So if you’re looking at DNS you also have to take into account the fact that multi case DNS could be present on your network and could leak DNS information that you may not capture in your normal Wireshark uh 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 at the bottom.  Nmap also has a script that’s available.  This probably came this came out before um support was built into dig.  So you can if you’re doing engagements and wanna do some automated scripting you can use this nmap script to gather information about ECS uh 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.  Uh not really recommended way for doing it. 
I’m working on a too.  l didn’t get a chance to finish it, uh but what we’re gonna do, what I’m gonna do is look through uh maybe Alexa top 1 million or whatever number of I uh domains we can look at. We’re gonna look at the domain name. We can run dig against each name server in that and we can sort out to see which one’s 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 uh put that in a blog somewhere where somebody can get at it. 
So, the other thing that’s uh, we noticed when uh, when I start looking at uh programming support for uh DNS the libraries that support uh looking at DNS traffic.  AIRSoft Tools supports option 8 manipulation so you can set it you can read it.  Uh 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.  Uh Python also has support in their programming language for being able to read EDNS or ECS option 8.  I think uh pyth- the PHP net DNS 32 has it in there as well, or DNS2 uh Scapy does not have support for it at the moment.  Uh Scapy is a open source packet generation tool so being open source if somebody were interested they could add those options and s- uh parsing for those options into the code repository.  So, it’s just a matter of time until that’s out there.  Uh it’s kind of interesting because once that’s in the ability for Scapy to generate packets, packets with spoofed information could be created and sent upstream resolvers. 
So, what is privacy and security implement- implications of all of this?  Well, this was in 2013 when we found out the NSA was reading all of our data.  Dilbert 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, i- if your WAN has a slash 22 and that’s what you want broadcast so everybody in that same network gets the SME cache 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 uh 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 this insight.  They also don’t advertise whether they support it or not it’s up to us to test to see if they do. And the implementers can track your data without your knowledge. As we saw on 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 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 and DNS packets.  Can add data to the, 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 kinds 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. Right, so if somebody tracks that 3 or 4 hops up stream then that data’s available for sale, the log gives us 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 uh 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, eh just a sub example here.  This is a correct configuration of unbound how it’s set up to send uh E 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 um, 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 subnet.  They built into this the ability to do other options they just have released the ability to do it at this point so eh kind of watch wants’ going on with that.
Alright so how do we, how do we define against this sort of thing? Alright, 1 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 gonna find things that you never expected to see on your network.  Ya know route all n- 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 EDNS0 but my guess is you would break a whole lot of things so I wouldn’t suggest that.  Uh monitor your DNS logs obviously and do for PCAP capture.  Something like security on your [inaudible] on a spam board on your edge network would be nice.  If you start seeing things in your DNS create IPS rules to block it.  You could enforce uh DNSSEC requirement for it. Uh but stuff will break. A lot of people don’t maintain their DNSSEC uh keys correctly.  Uh, particularly the big brother domain the dot 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 um forging information uh 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’re doing based on your IP. But I would suggest that if you’re doing any kind of engagement, you’re doing anything where privacy is in the least bit critical that you use full VPN tunnel and then Tor out past that VPN to a safe end point.
And I’ll give you some insight on a couple of other things 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 version 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 you’re accounting for your IPv6 traffic on your network.  Because some things will leak information that you may not expect.  If you use TorGhost for example on Kali it only supports IPv4. Uh my home router has IPv6 enabled because I have to be careful what I’m doing when I use Kali at home.  I have to disable it completely on uh boxes when I’m doing things that I wanna test.  And you can also test on your local network with Wireshark or TCPDUMP 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 DNSCrypt resolver in the crypt. DNSCrypt is put out as an open source project by OpenDNS, now CISCO.  Uh you can build your own.  You can build it into unbound.  You can pile 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.  [laughter]  Must’ve gotten somebody upset.  So the other thing you can do is uh set that resolver to um not, not push any ECS information out over the network.  I don’t know if I can talk loud enough for this.  So we’re almost done here anyway.  So if you set your resolver using a DNSCrypt proxy on Kali.  Download and install that package and uh point your resolver to the 1, 2, 7, 0, 2, 1 address and then it will route your DNS to a series of DNSCrypt resolvers that are a part of a public list.  You can adjust that list and forward it only to your own DNSCrypt resolver. And that way you know for sure that your DNS is secure or is at least as secure as you can make it. 
So summary, a option data usage has several useful purposes.  It allows CDN by DNS.  It enables DNSSEC.  It gives DNS responses that can be used to mitigate DDoS in um 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 contract that data if they’re enabled to read it.  No standard has been set for developing for opting out of that.  Forwarding ENDS options compromises your privacy and there is 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 uh legal reasons, law enforcement maybe.  There is no way to attribute that data to you accurately because other people can modify that data.  Uh botnet commanding control traffic. I think you’ll start to see that happen over the, 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. [applause]