DNSSEC, DNS over HTTPS & DNS Flag Day – What’s the Difference?

BY Dana Iskoldski

A few smart folks recently had a conversation about the intersection of networking, cloud, storage, and virtualization. Along the way, the topics of DNSSEC, DNS over HTTPS, and DNS Flag Day came up. They’re all very different things, but easily confused.

Watch below, listen, or read along below as Ned Bellavance, Noel Reynolds, Amarbir Sidhu, and Kevin Wilson break down:

  • The difference between DNSSEC and DNS over HTTPS (DoH)
  • Why DNSSEC adoption is so slow
  • Whether IPv6 impacts DNSSEC
  • How DNS Flag Day and extensions to DNS (eDNS) are relevant to the conversation
  • The value in encrypting DNS
  • Why enterprises may not want to encrypt DNS

Short on time? Enjoy the Cliff’s Notes. Or check out the transcript here.

What’s the difference between DNSSEC and DNS over HTTPS (DoH)?

[00:55:22] - DNS over HTTPS is DNS, but encrypted over the HTTPS protocol. That means queries and responses sent between endpoints and DNS servers are no longer plain text. 

DNSSEC is a protocol extension to a DNS server that allows you to establish a chain of trust, so that the endpoint receiving a response from a DNS server can be confident that the response can be trusted.

Recommended reading: the ISC recommends this blog as an introduction to DNS over HTTPS and its impacts on the internet. To learn more about DNSSEC, you might find this blog post exceptionally valuable.

 

Why is DNSSEC adoption so slow?

[00:57:50] - Configuring DNSSEC from scratch is really hard. Typically, even if a vendor takes care of it for you, you have to deal with a regular rotation of keys. Most organizations still update their DNS servers manually, so this represents a lot of work.

 

Does IPv6 impact DNSSEC?

[1:01:25] - Not really, no. A DNS server works the same on Ipv6 as it would on Ipv4. DNSSEC is just a function of DNS and does not behave any differently.

 

How are DNS Flag Day and extensions to DNS (EDNS) relevant to this conversation?

[01:03:23] - DNS Flag Day was essentially a wake-up call to DNS providers to remove older, or broken, non-compliant systems. In its first year, Flag Day centered around the Extensions to DNS (EDNS) protocol. EDNS was developed in the decades after DNS to enable more of the functionality and efficiency we expect DNS to provide today. Flag Day was the deadline past which many of the big DNS software and service providers said they’d no longer support non-compliant DNS. 

Recommended reading: Noel recommends PacketPushers’ episode on DNS Flag Day for a full lowdown.

 

Why encrypt DNS through DNS over HTTPS?

[01:06:37] - Encrypting the information contained in a DNS query, which would otherwise be readable in plaintext, makes it harder for ‘prying eyes’ to interpret the intent of the endpoint making a query. This approach has widely reported benefits to consumer privacy, yet there are cybersecurity tradeoffs which should be considered as well. Many reasonable people, for example, disagree on whether the tradeoffs involved in DoH implementation are worth the effort.

Recommended reading: again, this ISC-recommended blog should explain it all for you.

 

Why would enterprises oppose encryption of DNS? 

[1:08:25] - For many reasons. Many organizations and cybersecurity solutions analyze the DNS information to optimize network performance, route traffic, and protection.

Recommended reading: no, really, this ISC-recommended blog should explain it all for you.

WARNING: The transcription was generated by a transcription service. Sometimes they confuse words – especially technical terms – and speakers. Read at your own risk. Oh, and use common sense to interpret where a mistake may have been made.

 

Ned: Well, I think we're good. In the lead up to this, the preparation, I did start picking Noel's brain a little bit about the world of DNSSEC. So do you want me to get into that a little bit? But kind of what's going on with DNSSEC, what's going on with DOH and DOT? What's the intersection there? I'm just curious about other people's reactions and opinions because I don't think I have enough information to make an informed opinion about any of those things.
Noel Reynolds: Sure. So why don't we tackle DOH and DOT first. Again, I'm going to stay reasonably high level. You can go online and find a video of me saying that I think DOH and DOT or DOH specifically is a bad idea. DOH seems like it might win the war between DOH and DOT in terms of what's going. So DOH is DNS over HTTPS. DOT is DNS over TLS. They work differently, but they do something similar, which is they encrypt the DNS quarries and query responses from endpoints to DNS servers. DNSSEC is a little bit different in that DNSSEC is a protocol that allows you, so it's an extension to a DNS server that allows you to establish a chain of trust so that the end point when it makes a DNS query can ensure that the response that it's given is, and it does it, DNS, a fully qualified domain name is made up of if we look at www.TechfieldDay.com, the dot-com is the top level domain.
Noel Reynolds: Then you have the Techfield Day, which is the domain. And then WWW is either normally an alias or it could be a host name, but it's kind of a chain of records there. If you are working in an environment where you don't have that record cached somewhere, you have to go through the chain. You have to go through the root server, which is the invisible dot at the very end of that and ask him, "Hey, where do I go to find the dot com server?" Then you have to find the dot com server. DNSSEC allows you to trust that at every point along the way, a server that is responding to you and giving you an answer back is a trusted server and is authoritative for those records and is the real server for those records. Not someone who's a man in the middle who's pretending to be there.
Noel Reynolds: The two technologies are a little bit different and DNSSEC is one that's been around for 25 years. I want to say, something like that. If you were to go and grab DNS, and bind, and crack it open, and figure out how to, how to configure DNSSEC, I think it can be very complicated. It seems complicated depending on what server platform you're using, what vendor you might be using to do DNS. I had that experience where I actually went to configure it by scratch, from scratch. It was really, really difficult. I think that that put a lot of people off from using it for the most part.
Amar: So I concur.
Noel Reynolds: Throw them off of that.
Amar: I think with DNSSEC and configuration wise and what all you need, I think people find it is often complicated because they have to manage DNSSEC data. But if you are one of those DNS service providers that don't host any of the data yourself and the whole function of your servers is to go and fetch it from somewhere else, the contribution wise you strip down landing and percent of what's needed from that bind book to turn on the DNSSEC. It will do the same thing that Noel just talked about. They start from the DOT, go to dot com, go to Techfield Day.
Amar: It keeps on validating all the way down and until find the response and sends back. But like Noel said, the thing that puts people off is hosting being a sec sign data on the external server side, which is often complicated. Then there's a lot of vendors in space, in the space that can simplify things for you. But even after that, you have to then own the yearly, the monthly rotations of keys and things of that sort, which is still a manual work that's required by the system admins.
Noel Reynolds: There's a lot of I would say nomenclature and components, right? I'm not going to explain what all these are, but when you start, KSK, RRC, signed zones, like signed records, what happens when you add a new record to a zone. All of that stuff is taken care of. But honestly, if you go watch a video on YouTube, it seems significantly more complicated than it has to be from a configuration perspective.
Ned: It was that just built into the spec that way or is that the sort of thing that it could have been made easier and more simple, and still just as secure? It just never really reached the adoption point where it would become simple?
Amar: I think adoption wise, at some point, the US government mandated that everything, every agency that falls into the US government umbrella has to have the external DNS data signed by DNSSEC, there's no other way. But DNSSEC, if you go and read history on it, it's primarily made to solve two-use cases. One which was the bigger one is it needs to be backward compatible. Hence why there's a lot of stuff that they have to do around DNS to make it not break DNS because a lot of the legacy systems don't understand the DNSSEC today.
Amar: So when you introduce DNSSEC, it adds additional headers, adds additional records. We tried to make it simple for the systems, but we made it complicated for assisted names. I think at that time, when DNSSEC came out, the intention was never doing encrypt the path between the servers and the clients. It was more so they can validate the data itself. I don't think cybersecurity was at its prime when this came out. So it was never a thought I would say that that data encryption is a thing that it needs to be done on DNS as well.
Ned: Yeah. That seems to have plagued many internet thing in its time. It was never designed with security in mind back in the day. That all had to kind of be bolted on later.
Amar: Yeah.
Ned: Is there anything different about, and I don't know if anybody knows this, but I know when they were designing IPV6 that was much more, okay, security was in mind because it's a little more modern and so there's some security mechanisms just built into IPV6 that IPV4 never had is there anything similar with IPV6 for DNSSEC or is DNSSEC just doesn't care about which of the two is being used?
Amar: DNSSEC generally doesn't care, but what DNSSEC does is it will sign the like type records with one hashing of signature that all your A records, all your quality of records will use as key. So DNS works above the IP stack, so it doesn't care if it's IP before initiative IPV6 initiated. It does work the same on IPV4 as IPV6.
Ned: Okay, cool. Yeah, so I guess that probably answers most of my questions about DNSSEC, which means I probably won't have to learn a whole lot more about it unless for some reason, it gains mass adoption out of nowhere.
Noel Reynolds: I would say, you know one other thing about DNSSEC and Amar spoke to kind of the backward compatibility aspect of it. You're unlikely to have a problem with it. It's unlikely to cause you a problem. I think the biggest problem is when you want to do what's called DNSSEC validation. You want to make sure that DNSSEC is happening to a record that you're querying and it's not.
Noel Reynolds: That's where you can ... If you're a user of DNS, that's where you can have a problem. If you're an administrator of DNS, it's a different story. Then you have to do some troubleshooting and figure out where the trust chain is broken or something like that. But that's the other kind of reason why DNSSEC is not maybe as thought about because you don't really necessarily have to worry about it unless you really care that you're validating those records.
Ned: Right. That kind of reminded me of something else that I think happened maybe this year or last year. I remember just reading a Blurb about it, DNS day where the day when DNS might break or something.
Noel Reynolds: DNS flag day.
Ned: Flag day, that's what it was. What was that all about? Because you mentioned backwards compatibility. I feel like that had something to do with like forcing everybody to a newer or a slightly newer standard of DNS.
Noel Reynolds: So that covered that really well on one of the Packet Pusher's episodes. I would have to find it for you. But yes, flag day. So DNS is a 35-year-old protocol. I think it's 35. I'd have to go look, but I think it was 1984, 1985 was when DNS was first kind of put into play and different models of DNS had existed before that as well, primarily host files or distributed host files, things like that.
Noel Reynolds: But because of the age of the protocol, it necessarily has had layers and layers and layers of additional things put on it including something called extensions to DNS or EDNS0. There are many, many servers out on the internet that don't support all of the latest functionality from a DNS perspective. So what DNS flag day was a day to say, I can't remember if it was to specifically test or to test and say that, yes, your DNS server support all of the latest extensions that can respond to queries in the appropriate way for a modern client. Then I think Amar is like dying to speak. I'm going to shut up for a second.
Amar: So I think this ties back to DNSSEC a little bit, that since the DNSSEC was introduced into DNS, I think we spoke at the last, the briefing. That it causes more stress on the network, that now your network devices that now that DNS is 512 bytes, DNS is not 512 bytes anymore, it's much bigger than that. One of the reasons why this is important is that with introduction of DNSSEC, EDNS which is extensions to DNS mechanism, allowed for DNS to still operate on a UDP, which is TCP because that would have cost much more problems on not just now the networking but also on the servers themselves that are now operating on PCP versus UDP. Imagine if your DNS server is a 50,000, 20 per second server, now you're causing, looking at trouble.
Amar: So they introduced EDNS to allow for DNSSEC, and the flags to propagate easily. So I think the flag day was there to talk about the EDNS has helped us get this far, but we now need to make it more stricter to allow for better compliance. So that's when they introduced the version for EDNS1. Most of the software providers were now releasing patches to comply with EDSN1. But it was also going to break EDNS0, which is what's in use in legacy and current systems today.
Ned: Okay. Yeah. So breaking can be bad.
Amar: Yeah.
Ned: Yeah. So I've got to imagine like this push for, well, DOH seems to be the thing that's going to probably win out longterm is that's going to force another upgrade if ISP use and these different providers want to support that protocol.
Noel Reynolds: Absolutely. That's probably sort of my biggest concern with DOH right now and why it's ... So DOH, and I'm going to call it that, but DNS over HTTPS is, the idea is that your DNS queries will now be encrypted like all the other traffic that you have. If you've ever been at a coffee shop or something like that, I think we're all aware that when I'm going to my bank's website, I'm using HTTPS so it's encrypted. So it's not that big of a deal if I'm not using a VPN or something like that which encrypts sort of all my traffic off of my end point. But the DNS queries are in clear text. If you were to look at any person's DNS queries over the course of a full day, let's say for all their devices, you could learn a lot about that individual, right?
Noel Reynolds: When you start to, if you're an ISP or you're someone who's hosting DNS servers on the internet and you're looking at an individual's queries in aggregate, you're seeing a whole bunch of data that can be useful to advertisers. It can be useful to lots, lots of people. It can be useful to some kind of a foreign actor who's trying to do some kind of espionage. I mean there's just lots of uses for it. The challenge is is that DNS has always been kind of playing text. Individual DNS query, you probably don't care about, it's not a big deal. But again, in aggregate, it's a challenge. And so the idea is, "Hey, let's encrypt this traffic." Everything else is encrypted now. Again, that's a good idea. I like that idea. That's fine. The problem that I have is right now, the number of DOH servers that are available on the internet.
Noel Reynolds: So when I have an endpoint that and I say, "I'm going to use DNS over HTTPS on this endpoint," first of all, almost definitely none of my internal servers are going to be DOH enabled. So there's going to have to be some configuration done there. Microsoft just recently announced that they're going to make all of their endpoints use DNS over HTTPS in the future. Yet their DNS server doesn't support DOH. ISC's bind does not support DOH right now. So as a consumer, as an end user, right? Because again, it's not going to work in an internal corporate environment today or in the next five years based on the way that some organizations upgrade. So I only have a handful of choices about who I want to point DNS to.
Noel Reynolds: In addition to that, specifically DNS over HTTPS, I only have a handful of choices. I can use CloudFlare, I can use Google, whatever. So if the advertisement to me as a consumer is, "Hey, this is going to help your privacy" yeah, I'm not going to point to my ISP who maybe I trust, maybe I don't, whatever. But I'm going to point to Google or I'm going to point the CloudFlare or I'm going to point to some of the organization. So the problem that I have with it is I do think this is what's going to happen. It's for sure DNS is going to be encrypted like every other protocol. There's no question. But what's frustrating for me right now is they're selling it as a privacy solution. Yet there just aren't enough choices for me to feel like I really have privacy.
Noel Reynolds: I would almost rather, and I actually I would rather just get a VPN client, encrypt all of my traffic and point to again, so I want to do something. I'm going to point to one of my VPN points of presence. Then I'm going to disconnect point to a different one and do something different. I mean if I'm really concerned about my privacy, I'm going to do something like that rather than continue. Again, that's only assuming that I've done some research and trust my VPN provider, right? Because that's a whole other discussion. But that's my frustration right now is I just feel like it's sold as privacy and yet you have a very, very limited choice.. It's not like you can host your own DNS over HTTPS server at your house today.
Amar: To me, I take it on that same kind of thought process, but I take it a little bit even higher than that. Right? So again, Noel, going back to your point about what you can see in, in what information over the course of the day, your DNS records can divulge, right? The way this is being introduced is a user-based privacy thing, right? It's based off of our browser, right?
Amar: What about the 70 other applications running on my device that are all making DNS queries that now are not encrypted, right? I'm all for encrypting the traffic. To your point, VPN, let's go, right? That's the way to kind of look at this because now I'm getting whole box type encryption for lack of a better term, right? All the applications, everything running on my device is now under the same level of protection versus just my browser. Tat browser, I bet if you go back and look at my DNS queries throughout the day, very few of them, I would say a very small percentage of them are actually coming from my browser.
Amar: I'm not making a ton of DNS requests through a browser only. If you look at say the thousand that come through in an hour from my one MacBook, a fraction of them are from my browser. The rest of them are from all the other applications and system things that are making DNS calls. So that's where I kind of look at it like I'm good with the idea like you said of encrypting everything, right? Everything else is already encrypted. Why not? But it's just the approach seems to be very consumer-centric right now based on user browser type usage versus just the true security aspect of it.
Noel Reynolds: And the other way where it's consumer centric and maybe a little bit concerning for enterprises is the idea, and again, this is one of the things that's going to get worked out in the detail. But for right now, Ned, I was listening to, I forget which one of your podcasts. But you had a gentleman on who was talking about using DNS in the cloud environment to get actual data on what the endpoints are doing because everything else was encrypted. But DNS was something that they could see so they could track what was going on.
Ned: Mm-hmm (affirmative).
Noel Reynolds: We see corporate organizations mining DNS data because it's in plain text. I mean they're going to have some, need to have necessarily some other view into the DNS data because they're using that DNS data to understand what the endpoints are doing, to understand whether there's a potential security issue to understand.
Noel Reynolds: I mean Cisco's purchased open DNS based on the fact that they could use the DNS intelligence to block malware and lock threats and things like that. The concern that I have is if everything is an HTTPS, if you're looking at an endpoint and you'd have no way to decrypt it or to know which HTTPS traffic is browser based to a website versus DNS-based to a DNS server. I mean, I think as employees, sometimes you hear concern about the fact that the organization has put a proxy server in place that does a man in the middle before data is going out to the internet because now you don't have any privacy in your corporate environment. Look, in a lot of environments, that makes a lot of sense. But now you're going to have to have bigger proxy servers or bigger devices that can decrypt, reencrypt, right? Which is going to add latency to what you're doing just so that you can look at that traffic.
Noel Reynolds: So I think that there are some challenges that we need to solve and maybe. Again, I can think of a lot of ways we could solve those problems. Maybe internally it's plain text DNS until you get to your internal DOH server that then those DOH resolution out to the internet or something like that, so you're encrypting only one time, and it's a little bit safer. I mean, again, that's to be determined, right? There are different organizations that are working to push these standards forward. But I just think right now, there's this massive push for privacy, by the way, from a bunch of people who are still using Instagram, and Facebook, and Twitter, and whatever. But there's this massive push for privacy. But at the same time, there are implications to doing this that I don't think have been completely resolved. So ...
Ned: It reminds me a lot of what happened when iPhone started moving from the personal into the corporate, right? The corporate world was not ready to deal with iPhones, and mobile devices, and being able to properly administrate them, lock them down. A whole bunch of solutions came out to handle mobile device management and mobile application management because there was nothing in place. Just people unaware but when your CEO walked in with his brand new iPhone and iPad and was like, "These need to work on the corporate network." You're like, "Okay, I guess that's what I'm doing." So this is kind of a similar thing. It's being pushed by Google, by adding that in Chrome by default. I don't know if it's enabled by default but it's definitely there by default. Then a Firefox has it there and enabled by default, I think with the latest version.
Ned: So it's definitely being pushed from the consumer space into the corporate space and now once again, somebody is going to have to figure out how to deal with that. It's going to be a company that's somewhat nimble or maybe a brand new company that sees an opportunity in the gap there. So a startup idea. Anybody? Anybody want to start stuff?
Joep : The funny thing that you reminded me, Ned, about the iPhone working in the DNS space currently, I know how many CIS admins that manage DNS KPI forms. Every single one of them, they come with the same names, Iphone.org and you end up with the iPhone record, the links are now 60 IPs. You cannot tell who's who.
Ned: Yeah, that is something up to the, if you have at least have it under MDM, you can like force a rename over the phone I think.
Noel Reynolds: Right. Yeah, I was just going to say that that's that Mac dream that that has never been realized I think. Right? Because that would solve that problem.
Ned: I've seen like one organization actually successfully get knack set up and working, but it was very fragile, like don't sneeze at it because ...
Noel Reynolds: Yeah, right. It's very much like DLP. Very, very much like DLP, right? Once you get it set up, then the company can't culture, the stomach's just not there for it. So it quickly gets, the tabage.
Ned: Well, yeah. People would just find ways around it. If you make any security control to onerous, people will be like, "Well, why can't you go around this way?" What can you do?
Amar: One of the things, I think you all touched on the DOF and the different implications of putting it out now. We're not ready for it. The other one that I was reading upon just a couple of days ago was a lot of the malware detection today by the cyber security teams that are inside a corporate network, they do a lot of their work through DNS. The moment you turn encryption on on DNS, you can save by view, finding out who, which machine is playing which malware because everything is unencrypted. It's hard to decode and put back. Now, there you need to respond with the minutes. Somehow RASOLA that are way more stricter than the others. Now you're avoiding all those RASOLA because you need to ... Your system was slowing you down now versus making you faster.
Dana: I think there's this other additional point of like centralization of the internet if only certain actors are able to encrypt those queries, and one point of failure if one of them goes down.
Noel Reynolds: Right, right, right. That's where its kind of funny. CloudFlare's is known as an organization that values privacy, that deletes records, that doesn't keep records, things like that. It reminds me of a conversation I was having with one of my good friends about my iOS device, right? I love my iPhone. You'll take it from my cold, dead hands. ButI trust Apple necessarily, right? Everything that I have is in iCloud from like all my email, et cetera, et cetera. Right now, Apple, when they have like a security blip where they're recording conversations, whatever, I don't worry so much because I don't think that they care.
Noel Reynolds: I actually had conversations with folks at Apple. I know they don't care about my personal data or about selling my data or whatever. That's fine right now. But what happens when Tim Cook is no longer the CEO and they get a different board? The board wants to do more mining of customer data or something like that. So it's like all of these organizations that we're dealing with are publicly traded for profit companies. At some point in time, if CloudFlare, and again, I'm not saying anything bad about CloudFlare, I like what they do, but maybe they change in the future. As a consumer, where if all my data of some kind is going toward one organization, what's the impact of that on me if their ethics change?
Ned: That's true. I mean, I guess to a certain point, a lot of us are just kind of married to the device we have. It's hard to get away from it, for better or for worse. But yeah, I guess the solution is if the stance of Apple changes and you're an Apple consumer, you could go somewhere else. But do you necessarily trust Android anymore or a well or Android, well, or Android or wait. It's just the two of them.
Noel Reynolds: Right. Exactly. Exactly. Yeah. And The other thing too is what's the ... I mean, for you and I, that's not hard, right? For you and I, that would be easy. I mean and when I say easy, relatively I wouldn't want to move all my digital life out of the services that I get from Apple, right? I've got photos there and whatever or my mom or for your mom or for grandma or your friend who works in marketing, right? Hi Dana.
Noel Reynolds: It might be a lot more difficult because they don't have that kind of technical knowledge, that technical background. So our digital privacy is something that really concerns me. Our kids are growing up in an environment where their photos and images have been shared since day one. I know that a lot of the, I'm not going to use names, but I know that social media companies, regardless of whether you have an account or whether you don't or whatever, they are tracking you as an individual with a serial number the first time that your photo appears on one of their services. They do that so that when you finally register an account, because you get a certain age, you immediately have all your friends that are there. You can be friends with them. So it is something that I get concerned about. Sorry. I know it's not like necessarily core to what we were talking about, but it's related for sure.
Ned: Yeah. No, I agree.
Dana: These are almost the costs that we accept as part of living life where we do, and the way that we like to, and the way that the people we love do.
Ned: Yep.
Ned: Well, I think we're good. In the lead up to this, the preparation, I did start picking Noel's brain a little bit about the world of DNSSEC. So do you want me to get into that a little bit? But kind of what's going on with DNSSEC, what's going on with DOH and DOT? What's the intersection there? I'm just curious about other people's reactions and opinions because I don't think I have enough information to make an informed opinion about any of those things.
Noel Reynolds: Sure. So why don't we tackle DOH and DOT first. Again, I'm going to stay reasonably high level. You can go online and find a video of me saying that I think DOH and DOT or DOH specifically is a bad idea. DOH seems like it might win the war between DOH and DOT in terms of what's going. So DOH is DNS over HTTPS. DOT is DNS over TLS. They work differently, but they do something similar, which is they encrypt the DNS quarries and query responses from endpoints to DNS servers. DNSSEC is a little bit different in that DNSSEC is a protocol that allows you, so it's an extension to a DNS server that allows you to establish a chain of trust so that the end point when it makes a DNS query can ensure that the response that it's given is, and it does it, DNS, a fully qualified domain name is made up of if we look at www.TechfieldDay.com, the dot-com is the top level domain.
Noel Reynolds: Then you have the Techfield Day, which is the domain. And then WWW is either normally an alias or it could be a host name, but it's kind of a chain of records there. If you are working in an environment where you don't have that record cached somewhere, you have to go through the chain. You have to go through the root server, which is the invisible dot at the very end of that and ask him, "Hey, where do I go to find the dot com server?" Then you have to find the dot com server. DNSSEC allows you to trust that at every point along the way, a server that is responding to you and giving you an answer back is a trusted server and is authoritative for those records and is the real server for those records. Not someone who's a man in the middle who's pretending to be there.
Noel Reynolds: The two technologies are a little bit different and DNSSEC is one that's been around for 25 years. I want to say, something like that. If you were to go and grab DNS, and bind, and crack it open, and figure out how to, how to configure DNSSEC, I think it can be very complicated. It seems complicated depending on what server platform you're using, what vendor you might be using to do DNS. I had that experience where I actually went to configure it by scratch, from scratch. It was really, really difficult. I think that that put a lot of people off from using it for the most part.
Amar: So I concur.
Noel Reynolds: Throw them off of that.
Amar: I think with DNSSEC and configuration wise and what all you need, I think people find it is often complicated because they have to manage DNSSEC data. But if you are one of those DNS service providers that don't host any of the data yourself and the whole function of your servers is to go and fetch it from somewhere else, the contribution wise you strip down landing and percent of what's needed from that bind book to turn on the DNSSEC. It will do the same thing that Noel just talked about. They start from the DOT, go to dot com, go to Techfield Day.
Amar: It keeps on validating all the way down and until find the response and sends back. But like Noel said, the thing that puts people off is hosting being a sec sign data on the external server side, which is often complicated. Then there's a lot of vendors in space, in the space that can simplify things for you. But even after that, you have to then own the yearly, the monthly rotations of keys and things of that sort, which is still a manual work that's required by the system admins.
Noel Reynolds: There's a lot of I would say nomenclature and components, right? I'm not going to explain what all these are, but when you start, KSK, RRC, signed zones, like signed records, what happens when you add a new record to a zone. All of that stuff is taken care of. But honestly, if you go watch a video on YouTube, it seems significantly more complicated than it has to be from a configuration perspective.
Ned: It was that just built into the spec that way or is that the sort of thing that it could have been made easier and more simple, and still just as secure? It just never really reached the adoption point where it would become simple?
Amar: I think adoption wise, at some point, the US government mandated that everything, every agency that falls into the US government umbrella has to have the external DNS data signed by DNSSEC, there's no other way. But DNSSEC, if you go and read history on it, it's primarily made to solve two-use cases. One which was the bigger one is it needs to be backward compatible. Hence why there's a lot of stuff that they have to do around DNS to make it not break DNS because a lot of the legacy systems don't understand the DNSSEC today.
Amar: So when you introduce DNSSEC, it adds additional headers, adds additional records. We tried to make it simple for the systems, but we made it complicated for assisted names. I think at that time, when DNSSEC came out, the intention was never doing encrypt the path between the servers and the clients. It was more so they can validate the data itself. I don't think cybersecurity was at its prime when this came out. So it was never a thought I would say that that data encryption is a thing that it needs to be done on DNS as well.
Ned: Yeah. That seems to have plagued many internet thing in its time. It was never designed with security in mind back in the day. That all had to kind of be bolted on later.
Amar: Yeah.
Ned: Is there anything different about, and I don't know if anybody knows this, but I know when they were designing IPV6 that was much more, okay, security was in mind because it's a little more modern and so there's some security mechanisms just built into IPV6 that IPV4 never had is there anything similar with IPV6 for DNSSEC or is DNSSEC just doesn't care about which of the two is being used?
Amar: DNSSEC generally doesn't care, but what DNSSEC does is it will sign the like type records with one hashing of signature that all your A records, all your quality of records will use as key. So DNS works above the IP stack, so it doesn't care if it's IP before initiative IPV6 initiated. It does work the same on IPV4 as IPV6.
Ned: Okay, cool. Yeah, so I guess that probably answers most of my questions about DNSSEC, which means I probably won't have to learn a whole lot more about it unless for some reason, it gains mass adoption out of nowhere.
Noel Reynolds: I would say, you know one other thing about DNSSEC and Amar spoke to kind of the backward compatibility aspect of it. You're unlikely to have a problem with it. It's unlikely to cause you a problem. I think the biggest problem is when you want to do what's called DNSSEC validation. You want to make sure that DNSSEC is happening to a record that you're querying and it's not.
Noel Reynolds: That's where you can ... If you're a user of DNS, that's where you can have a problem. If you're an administrator of DNS, it's a different story. Then you have to do some troubleshooting and figure out where the trust chain is broken or something like that. But that's the other kind of reason why DNSSEC is not maybe as thought about because you don't really necessarily have to worry about it unless you really care that you're validating those records.
Ned: Right. That kind of reminded me of something else that I think happened maybe this year or last year. I remember just reading a Blurb about it, DNS day where the day when DNS might break or something.
Noel Reynolds: DNS flag day.
Ned: Flag day, that's what it was. What was that all about? Because you mentioned backwards compatibility. I feel like that had something to do with like forcing everybody to a newer or a slightly newer standard of DNS.
Noel Reynolds: So that covered that really well on one of the Packet Pusher's episodes. I would have to find it for you. But yes, flag day. So DNS is a 35-year-old protocol. I think it's 35. I'd have to go look, but I think it was 1984, 1985 was when DNS was first kind of put into play and different models of DNS had existed before that as well, primarily host files or distributed host files, things like that.
Noel Reynolds: But because of the age of the protocol, it necessarily has had layers and layers and layers of additional things put on it including something called extensions to DNS or EDNS0. There are many, many servers out on the internet that don't support all of the latest functionality from a DNS perspective. So what DNS flag day was a day to say, I can't remember if it was to specifically test or to test and say that, yes, your DNS server support all of the latest extensions that can respond to queries in the appropriate way for a modern client. Then I think Amar is like dying to speak. I'm going to shut up for a second.
Amar: So I think this ties back to DNSSEC a little bit, that since the DNSSEC was introduced into DNS, I think we spoke at the last, the briefing. That it causes more stress on the network, that now your network devices that now that DNS is 512 bytes, DNS is not 512 bytes anymore, it's much bigger than that. One of the reasons why this is important is that with introduction of DNSSEC, EDNS which is extensions to DNS mechanism, allowed for DNS to still operate on a UDP, which is TCP because that would have cost much more problems on not just now the networking but also on the servers themselves that are now operating on PCP versus UDP. Imagine if your DNS server is a 50,000, 20 per second server, now you're causing, looking at trouble.
Amar: So they introduced EDNS to allow for DNSSEC, and the flags to propagate easily. So I think the flag day was there to talk about the EDNS has helped us get this far, but we now need to make it more stricter to allow for better compliance. So that's when they introduced the version for EDNS1. Most of the software providers were now releasing patches to comply with EDSN1. But it was also going to break EDNS0, which is what's in use in legacy and current systems today.
Ned: Okay. Yeah. So breaking can be bad.
Amar: Yeah.
Ned: Yeah. So I've got to imagine like this push for, well, DOH seems to be the thing that's going to probably win out longterm is that's going to force another upgrade if ISP use and these different providers want to support that protocol.
Noel Reynolds: Absolutely. That's probably sort of my biggest concern with DOH right now and why it's ... So DOH, and I'm going to call it that, but DNS over HTTPS is, the idea is that your DNS queries will now be encrypted like all the other traffic that you have. If you've ever been at a coffee shop or something like that, I think we're all aware that when I'm going to my bank's website, I'm using HTTPS so it's encrypted. So it's not that big of a deal if I'm not using a VPN or something like that which encrypts sort of all my traffic off of my end point. But the DNS queries are in clear text. If you were to look at any person's DNS queries over the course of a full day, let's say for all their devices, you could learn a lot about that individual, right?
Noel Reynolds: When you start to, if you're an ISP or you're someone who's hosting DNS servers on the internet and you're looking at an individual's queries in aggregate, you're seeing a whole bunch of data that can be useful to advertisers. It can be useful to lots, lots of people. It can be useful to some kind of a foreign actor who's trying to do some kind of espionage. I mean there's just lots of uses for it. The challenge is is that DNS has always been kind of playing text. Individual DNS query, you probably don't care about, it's not a big deal. But again, in aggregate, it's a challenge. And so the idea is, "Hey, let's encrypt this traffic." Everything else is encrypted now. Again, that's a good idea. I like that idea. That's fine. The problem that I have is right now, the number of DOH servers that are available on the internet.
Noel Reynolds: So when I have an endpoint that and I say, "I'm going to use DNS over HTTPS on this endpoint," first of all, almost definitely none of my internal servers are going to be DOH enabled. So there's going to have to be some configuration done there. Microsoft just recently announced that they're going to make all of their endpoints use DNS over HTTPS in the future. Yet their DNS server doesn't support DOH. ISC's bind does not support DOH right now. So as a consumer, as an end user, right? Because again, it's not going to work in an internal corporate environment today or in the next five years based on the way that some organizations upgrade. So I only have a handful of choices about who I want to point DNS to.
Noel Reynolds: In addition to that, specifically DNS over HTTPS, I only have a handful of choices. I can use CloudFlare, I can use Google, whatever. So if the advertisement to me as a consumer is, "Hey, this is going to help your privacy" yeah, I'm not going to point to my ISP who maybe I trust, maybe I don't, whatever. But I'm going to point to Google or I'm going to point the CloudFlare or I'm going to point to some of the organization. So the problem that I have with it is I do think this is what's going to happen. It's for sure DNS is going to be encrypted like every other protocol. There's no question. But what's frustrating for me right now is they're selling it as a privacy solution. Yet there just aren't enough choices for me to feel like I really have privacy.
Noel Reynolds: I would almost rather, and I actually I would rather just get a VPN client, encrypt all of my traffic and point to again, so I want to do something. I'm going to point to one of my VPN points of presence. Then I'm going to disconnect point to a different one and do something different. I mean if I'm really concerned about my privacy, I'm going to do something like that rather than continue. Again, that's only assuming that I've done some research and trust my VPN provider, right? Because that's a whole other discussion. But that's my frustration right now is I just feel like it's sold as privacy and yet you have a very, very limited choice.. It's not like you can host your own DNS over HTTPS server at your house today.
Amar: To me, I take it on that same kind of thought process, but I take it a little bit even higher than that. Right? So again, Noel, going back to your point about what you can see in, in what information over the course of the day, your DNS records can divulge, right? The way this is being introduced is a user-based privacy thing, right? It's based off of our browser, right?
Amar: What about the 70 other applications running on my device that are all making DNS queries that now are not encrypted, right? I'm all for encrypting the traffic. To your point, VPN, let's go, right? That's the way to kind of look at this because now I'm getting whole box type encryption for lack of a better term, right? All the applications, everything running on my device is now under the same level of protection versus just my browser. Tat browser, I bet if you go back and look at my DNS queries throughout the day, very few of them, I would say a very small percentage of them are actually coming from my browser.
Amar: I'm not making a ton of DNS requests through a browser only. If you look at say the thousand that come through in an hour from my one MacBook, a fraction of them are from my browser. The rest of them are from all the other applications and system things that are making DNS calls. So that's where I kind of look at it like I'm good with the idea like you said of encrypting everything, right? Everything else is already encrypted. Why not? But it's just the approach seems to be very consumer-centric right now based on user browser type usage versus just the true security aspect of it.
Noel Reynolds: And the other way where it's consumer centric and maybe a little bit concerning for enterprises is the idea, and again, this is one of the things that's going to get worked out in the detail. But for right now, Ned, I was listening to, I forget which one of your podcasts. But you had a gentleman on who was talking about using DNS in the cloud environment to get actual data on what the endpoints are doing because everything else was encrypted. But DNS was something that they could see so they could track what was going on.
Ned: Mm-hmm (affirmative).
Noel Reynolds: We see corporate organizations mining DNS data because it's in plain text. I mean they're going to have some, need to have necessarily some other view into the DNS data because they're using that DNS data to understand what the endpoints are doing, to understand whether there's a potential security issue to understand.
Noel Reynolds: I mean Cisco's purchased open DNS based on the fact that they could use the DNS intelligence to block malware and lock threats and things like that. The concern that I have is if everything is an HTTPS, if you're looking at an endpoint and you'd have no way to decrypt it or to know which HTTPS traffic is browser based to a website versus DNS-based to a DNS server. I mean, I think as employees, sometimes you hear concern about the fact that the organization has put a proxy server in place that does a man in the middle before data is going out to the internet because now you don't have any privacy in your corporate environment. Look, in a lot of environments, that makes a lot of sense. But now you're going to have to have bigger proxy servers or bigger devices that can decrypt, reencrypt, right? Which is going to add latency to what you're doing just so that you can look at that traffic.
Noel Reynolds: So I think that there are some challenges that we need to solve and maybe. Again, I can think of a lot of ways we could solve those problems. Maybe internally it's plain text DNS until you get to your internal DOH server that then those DOH resolution out to the internet or something like that, so you're encrypting only one time, and it's a little bit safer. I mean, again, that's to be determined, right? There are different organizations that are working to push these standards forward. But I just think right now, there's this massive push for privacy, by the way, from a bunch of people who are still using Instagram, and Facebook, and Twitter, and whatever. But there's this massive push for privacy. But at the same time, there are implications to doing this that I don't think have been completely resolved. So ...
Ned: It reminds me a lot of what happened when iPhone started moving from the personal into the corporate, right? The corporate world was not ready to deal with iPhones, and mobile devices, and being able to properly administrate them, lock them down. A whole bunch of solutions came out to handle mobile device management and mobile application management because there was nothing in place. Just people unaware but when your CEO walked in with his brand new iPhone and iPad and was like, "These need to work on the corporate network." You're like, "Okay, I guess that's what I'm doing." So this is kind of a similar thing. It's being pushed by Google, by adding that in Chrome by default. I don't know if it's enabled by default but it's definitely there by default. Then a Firefox has it there and enabled by default, I think with the latest version.
Ned: So it's definitely being pushed from the consumer space into the corporate space and now once again, somebody is going to have to figure out how to deal with that. It's going to be a company that's somewhat nimble or maybe a brand new company that sees an opportunity in the gap there. So a startup idea. Anybody? Anybody want to start stuff?
Joep : The funny thing that you reminded me, Ned, about the iPhone working in the DNS space currently, I know how many CIS admins that manage DNS KPI forms. Every single one of them, they come with the same names, Iphone.org and you end up with the iPhone record, the links are now 60 IPs. You cannot tell who's who.
Ned: Yeah, that is something up to the, if you have at least have it under MDM, you can like force a rename over the phone I think.
Noel Reynolds: Right. Yeah, I was just going to say that that's that Mac dream that that has never been realized I think. Right? Because that would solve that problem.
Ned: I've seen like one organization actually successfully get knack set up and working, but it was very fragile, like don't sneeze at it because ...
Noel Reynolds: Yeah, right. It's very much like DLP. Very, very much like DLP, right? Once you get it set up, then the company can't culture, the stomach's just not there for it. So it quickly gets, the tabage.
Ned: Well, yeah. People would just find ways around it. If you make any security control to onerous, people will be like, "Well, why can't you go around this way?" What can you do?
Amar: One of the things, I think you all touched on the DOF and the different implications of putting it out now. We're not ready for it. The other one that I was reading upon just a couple of days ago was a lot of the malware detection today by the cyber security teams that are inside a corporate network, they do a lot of their work through DNS. The moment you turn encryption on on DNS, you can save by view, finding out who, which machine is playing which malware because everything is unencrypted. It's hard to decode and put back. Now, there you need to respond with the minutes. Somehow RASOLA that are way more stricter than the others. Now you're avoiding all those RASOLA because you need to ... Your system was slowing you down now versus making you faster.
Dana: I think there's this other additional point of like centralization of the internet if only certain actors are able to encrypt those queries, and one point of failure if one of them goes down.
Noel Reynolds: Right, right, right. That's where its kind of funny. CloudFlare's is known as an organization that values privacy, that deletes records, that doesn't keep records, things like that. It reminds me of a conversation I was having with one of my good friends about my iOS device, right? I love my iPhone. You'll take it from my cold, dead hands. ButI trust Apple necessarily, right? Everything that I have is in iCloud from like all my email, et cetera, et cetera. Right now, Apple, when they have like a security blip where they're recording conversations, whatever, I don't worry so much because I don't think that they care.
Noel Reynolds: I actually had conversations with folks at Apple. I know they don't care about my personal data or about selling my data or whatever. That's fine right now. But what happens when Tim Cook is no longer the CEO and they get a different board? The board wants to do more mining of customer data or something like that. So it's like all of these organizations that we're dealing with are publicly traded for profit companies. At some point in time, if CloudFlare, and again, I'm not saying anything bad about CloudFlare, I like what they do, but maybe they change in the future. As a consumer, where if all my data of some kind is going toward one organization, what's the impact of that on me if their ethics change?
Ned: That's true. I mean, I guess to a certain point, a lot of us are just kind of married to the device we have. It's hard to get away from it, for better or for worse. But yeah, I guess the solution is if the stance of Apple changes and you're an Apple consumer, you could go somewhere else. But do you necessarily trust Android anymore or a well or Android, well, or Android or wait. It's just the two of them.
Noel Reynolds: Right. Exactly. Exactly. Yeah. And The other thing too is what's the ... I mean, for you and I, that's not hard, right? For you and I, that would be easy. I mean and when I say easy, relatively I wouldn't want to move all my digital life out of the services that I get from Apple, right? I've got photos there and whatever or my mom or for your mom or for grandma or your friend who works in marketing, right? Hi Dana.
Noel Reynolds: It might be a lot more difficult because they don't have that kind of technical knowledge, that technical background. So our digital privacy is something that really concerns me. Our kids are growing up in an environment where their photos and images have been shared since day one. I know that a lot of the, I'm not going to use names, but I know that social media companies, regardless of whether you have an account or whether you don't or whatever, they are tracking you as an individual with a serial number the first time that your photo appears on one of their services. They do that so that when you finally register an account, because you get a certain age, you immediately have all your friends that are there. You can be friends with them. So it is something that I get concerned about. Sorry. I know it's not like necessarily core to what we were talking about, but it's related for sure.
Ned: Yeah. No, I agree.
Dana: These are almost the costs that we accept as part of living life where we do, and the way that we like to, and the way that the people we love do.
Ned: Yep.