From:
https://www.hpe.com/us/en/insights/articles/d...
ml

===
October 8, 2018
Larry Seltzer

DNS security still an issue

DNS security is a decades-old issue that shows no signs of being fully 
resolved. Here's a quick overview of some of the problems with proposed 
solutions and the best way to move forward.
Like almost all of the original and fundamental Internet protocols, DNS 
transactions are designed to be transported in plain text on the wire. Other 
network users can see the domains to which users are resolving by sniffing 
their DNS requests on TCP or UDP port 53. Though it has taken too long to fix, 
as is usually the case, the industry is finally getting around to it. But it 
won't be pretty. We can look forward to a variety of DNS security standards 
that aim to address a variety of problems in a variety of ways.

The current standard for securing DNS
The first proposed standard for DNSSEC (RFC 4033 and many others) is almost 20 
years old, but it solves a different problem: validating the provenance of DNS 
results, by using public and private keys and signatures in the DNS to prove 
that an authorized party actually created the DNS entry. This protects the 
client against certain attacks, such as DNS cache poisoning.

After many years of availability, DNSSEC has yet to attain significant 
adoption, even though any security expert you might ask recognizes its value. 
As with any public key infrastructure, DNSSEC is complicated. You must follow 
a lot of rules carefully, although some network services providers are trying 
to make things easier.

But DNSSEC does not encrypt the communications between the DNS client and 
server. Using the information in your DNS requests, an attacker between you 
and your DNS server could determine which sites you are attempting to 
communicate with just by reading packets on the network.

So despite best efforts of various Internet groups, DNS remains insecure. Too 
many roadblocks exist that prevent the Internet-wide adoption of a DNS 
security solution. But it is time to revisit the concerns.

The next generation of DNS security models has arrived
Enter DNS over TLS (RFC 7858 and RFC 8310), a new standard that uses Transport 
Level Security (the successor standard for SSL) to strongly encrypt DNS 
communications between the client and server. DNS over TLS builds on existing, 
proven Internet technologies to provide strong protection. Will DNS over TLS 
adoption move more quickly than DNSSEC? Perhaps. It uses the existing TLS 
infrastructure rather than creating a whole new one, as with DNSSEC. And it 
solves a problem that everyone agrees is worth solving.

On the other hand, there are at least two big reasons why organizations would 
put off adoption. The first, comparatively minor, issue is the need to obtain 
and maintain certificates for DNS servers. The other, more serious, 
consideration is that existing software probably needs modification to work 
smoothly with TLS over DNS.

This latter problem is probably the main one holding back genuine adoption of 
DNSSEC as well. The world is full of software that uses standard library calls 
like gethostbyname() and getaddrinfo() that query the DNS in ways that make it 
difficult to simply swap in DNSSEC. If your software works at a lower level 
with DNS, there is even more work to do. Conventional DNS queries are simple, 
but working with DNSSEC queries involves validating digital signatures and 
confirming them all the way along the "global chain of trust" to the root of 
the DNS to ensure the results have not been modified from those created by the 
authorized entity.

Even if everyone agrees that using DNSSEC would be good, comparatively few IT 
shops are willing to go to the significant extra effort to make software that 
works correctly with DNSSEC and with plain-old insecure DNS. DNS over TLS has 
the same problem to a lesser degree.

How to handle error reporting
With respect to error reporting, TLS validation errors for a DNS connection 
could probably be hidden, at least initially, behind more general "connection 
error" handlers and messages. The real problem is behind the scenes a bit, as 
described by RFC 7858 (DNS over TLS, section 3.4):

"For DNS clients that use library functions such as "getaddrinfo()" and 
"gethostbyname()", current implementations are known to open and close TCP 
connections for each DNS query. To avoid excess TCP connections, each with a 
single query, clients SHOULD reuse a single TCP connection to the recursive 
resolver. Alternatively, they may prefer to use UDP to a DNS-over-TLS-enabled 
caching resolver on the same machine that then uses a system-wide TCP 
connection to the recursive resolver."

In other words, conventional DNS programming practices used on DNS over TLS 
will probably noticeably impact network performance. Getting around this 
problem could be a lot of work and would add moving parts to the network 
stack.

The suggestion to employ UDP raises another point about DNS over TLS that is 
probably academic in the short term. Because TLS is a TCP-only protocol, so is 
DNS over TLS. This is a problem for the many implementations of DNS that use 
UDP for transport.

Performance problems require workarounds
In general, DNS doesn't have a reputation for high performance. That leads to 
ubiquitous caching and other tricks, such as UDP, for getting any advantage 
possible. For this reason, there is a separate Datagram Transport Layer 
Security (DTLS - RFC 6347) specification and the DNS over TLS spec makes 
references to UDP use. But don't assume that TCP implementations of DNS over 
TLS also support DNS over DTLS; Cloudflare's early implementation does not.

Beyond issues of network performance and proper TLS operations, once the 
secure connection is set up, the workings of the actual DNS transaction are 
the same with DNS over TLS as with conventional DNS. TCP port 53 is the 
standard, "well-known" port for DNS; the IANA has reserved port 853 for DNS 
over TLS.

It helps that DNS over TLS has some support from large, important companies. I 
already mentioned Cloudflare, which is always on the cutting edge of new 
Internet security standards. Several DNS server vendors support DNS over TLS 
-- for example, PowerDNS, Bind, Technitium, and Unbound. Cloudflare, Quad9, 
and Tenta all provide free public DNS resolvers that support both DNS over TLS 
and DNSSEC.

Web browsers lack support for new technologies
It doesn't help that no major web browsers support DNS over TLS yet. (Tenta's 
Private VPN Browser + Ad Blocker (Beta) supports it on Android.) The latest 
version of Android (9, a.k.a. Pie) supports it, but not the Chrome browser. 
And we have no word yet from Mozilla, Microsoft, or Apple about support in 
their browsers for the standard.

DNS over TLS solves the problem of sniffing the wire, but it doesn't solve all 
theoretical problems, most obviously the problems DNSSEC addresses. If the DNS 
response sent by the server over TLS is manipulated or otherwise false, the 
fact that the data is encrypted on the wire won't help.

It's also important to understand that the DNS server itself still has your 
DNS requests -- it has to, in order to service them. Those requests will be in 
a log file, for how long depending on the policy set for the server. 
Administrators, potentially hackers, and with proper authorization, law 
enforcement can still get access to those records. This problem, if you view 
it as a problem, is a more general one that applies to almost all network 
services.

But DNS service providers and browser ISVs are working on this problem, too. 
According to this Mozilla article, a Trusted Recursive Resolver (TRR) appears 
to be a DNS resolver with a rigid privacy policy. The administrators "have 
committed to throwing away all personally identifiable data after 24 hours, 
and to never pass that data along to third parties. And there will be regular 
audits to ensure that data is being cleared as expected."  It's basically a 
trust system and not yet an accepted standard. TRR is the term Mozilla coined 
for its resolvers that meet their privacy criteria and provide encrypted 
transport of DNS answers to the Firefox browser. At the moment, Cloudflare is 
the only one in the world supporting this technology.

D'oh!
If DNS over TLS doesn't catch on, Google, Mozilla, and others are working on 
DNS over HTTPS (DoH--yes, really, they use that acronym), which should 
accomplish the same level of security but present fewer issues with firewalls. 
It allows DNS to be implemented over content delivery networks. In fact, 
Mozilla has already rolled this out in its browser, and Cloudflare supports it 
as a resolver.

DoH also moves DNS programming into the more modern realm of REST APIs and 
JSON, and in fact, this is the way it becomes usable over HTTPS, getting 
security almost for free.

DoH is probably the most straightforward of the proposals, which is how it 
reached actual deployment inside of a year since the formation of the working 
group. The proposed specification is very short, and it uses a programming 
model that is as hot as a vinyl car seat in summer. Rather than try to make 
minimal changes to an insecure architecture in order to make it secure, DoH 
uses new, better, and increasingly familiar ways of programming to take 
advantage of existing, proven security systems. All this makes it better than 
DNS over TLS, but DoH doesn't solve the authenticity problem addressed by 
DNSSEC.

The usual gang of security proliferators--Google, Cloudflare, and Mozilla all 
work hard at this--seem to be throwing every DNS security idea they have at 
the wall to see what sticks. At some point, the proliferation of standards 
could produce more confusion than opportunity. We may already be there.

DNS security: Lessons for leaders
. The current DNS security model is insecure, and earlier attempts to resolve 
that issue have little traction.
. Multiple new solutions are being proposed, but each has some gotchas.
. Whatever the solution is, it will require industrywide adoption to be 
effective.

This article/content was written by the individual writer identified and does 
not necessarily reflect the view of Hewlett Packard Enterprise Company.
===

... A hero is one who knows how to hang on one minute longer. - Norwegian 
proverb
--- GoldED+/LNX 1.1.5-b20170303
 * Origin: Outpost BBS * Limestone, TN, USA (618:618/1)