7

Okay, I'll admit something first-off: I don't really understand some of the practical aspects of how DNSSec protections work very well.(Even after reading resources like this.)

Well, I certainly understand why anti-spoofing protections for DNS name-to-address resolution lookups are very necessary. And I even understand (roughly, at a basic level) how the cryptographic trust chain mechanisms work, from the DNS root servers and top-level domains down to the lowest-level ISP and internal/corporate nameservers to provide a foundation for the DNSSec role of cryptographically attesting that a given domain name really is linked to one or more given IP addresses.

But my understanding gets hazy at the point where an end-user's device actually takes advantage of the DNSSec system's capabilities to verify that the DNS server the client is dealing with is telling the truth when it says that a certain domain name is legitimately supposed to resolve to a certain IP address. That, for eg., www.example.com really is intended by the people who own it to point to 93.184.216.34, and that 93.184.216.34 isn't just some spoofed, malicious substitute server telling, say, my browser to go to an attacker-controlled web page instead of the genuine one.

Anyway, my actual question here isn't quite "I don't fully understand how DNSSec works at a client/DNS server-level. Please explain that." I have a more pragmatic concern: Can one actually configure an end-user client PC or device to force it to accept & use only DNS lookup results that are cryptographically-verified under DNSSec? Configuring a PC to use certain specific DNS servers is easy enough, obviously; how does one configure a PC to use only DNS lookup results that are verified as legitimate by the DNSSec infrastructure? Or can that even be done; is there something I'm missing about how DNSSec works at the client/DNS server level that means my whole question is off-base? Or is something else going on?

( Note: I suppose I'm asking with the picture of a typical Windows client environment in my head, but really I mean to ask in a more general context of "Is there some kind of verification/checking in DNSSec that actually occurs at the client level, or is DNSSec some purely external thing were a client is expected to "just trust" the end-output of some DNS server?" And the latter sounds a lot like it would just have the some of the same issues that make the legacy DNS system problematic.)

Community
  • 1
mostlyinformed
  • 2,715
  • 16
  • 38
  • You technically could tight things up, but in practice, from latest reports (https://www.icann.org/en/system/files/files/presentation-dnssec-cryptographic-habits-gtld-sld-13may17-en.pdf), this means having access to only something like 0.5% of all domain names, so you will surely miss a lot of things... If you take Alexa list, from top, the following are **NOT** DNSSEC enabled: google.com, youtube.com, facebook.com, baidu.com, wikipedia.org, etc. In fact none in the first 50 positions... – Patrick Mevzek Jun 25 '18 at 18:40
  • Have a look at stubby and dnssect-trigger software. You can configure them in lax or strict modes depending if you favor security or accessbility (that is what to do when DNSSEC fails). – Patrick Mevzek Jun 25 '18 at 18:41

2 Answers2

3

Can one actually configure an end-user client PC or device to force it to accept & use only DNS lookup results that are cryptographically-verified under DNSSec?

I don't think it is possible to do directly. What you might could do is to setup a DNS server which throws away any response which is not signed with DNSSec. Then you could setup your local network so that it uses this DNS server. This DNS server could even be run on the same host. I'm not aware of any existing server which can be configured to do this. But it should not be too hard to write such a server for personal use (i.e. no need to scale a lot).

But, since most of the servers on the internet are not using DNSSec yet you will effectively cut yourself this way from most of the internet. Nice for an experiment, but usually not useful in practice.

or is DNSSec some purely external thing were a client is expected to "just trust" the end-output of some DNS server?"

DNSSec is usually not really integrated into the systems. That means applications on current Windows, Mac or Linux systems are usually not aware if the address they got for a host was retrieved using DNSSec or unprotected DNS. Even if the system resolver would know this, the current API's in the libraries and programming languages mostly do not expose this information to the application or it is unclear how much this information from the API can be trusted itself. For some interesting reading about the complexity of the issue see Support for DNSSEC in the GNU C Library.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • "the current API's in the libraries and programming languages mostly do not expose this information to the application" see the newer getdns API for a solution to that. – Patrick Mevzek Jun 25 '18 at 18:42
  • @PatrickMevzek: the availability of getdns as an explicitly to use library for very few programming languages does not change the fact that most OS and programming languages do not expose DNSSec functionality. With most simple socket and higher level API's commonly found in higher level languages one does not have an option to switch to an alternative DNS resolver. Insofar getdns does not provide a solution for the most common cases where the user just needs to rely on the default resolver. – Steffen Ullrich Jun 25 '18 at 20:57
  • The quote was about libraries and programming languages. getdns is new, but solves the problem. Of course, now, to be useful, it needs to be used by software and ported to new languages. As for the user, the problem is far bigger, as they are also UI issues to tackle in order not to repeat the current fiasco in browsers with warning messages people do not read and just click "I accept". See https://getdnsapi.net/documentation/readme/ for a list of OS and languages. – Patrick Mevzek Jun 25 '18 at 23:05
  • "most OS and programming languages do not expose DNSSec functionality." classic chicken and egg problem. Same for IPv6. – Patrick Mevzek Jun 25 '18 at 23:06
  • @PatrickMevzek: *"getdns is new, but solves the problem."* - I think we are talking about different problems here. The problem I see is not the need to have a library which make it possible to make DNS lookups and also get DNSSec information - there are actually several such libraries. The problem instead is not having such functionality integrated into the API's used by default in OS and programming languages, i.e. provide DNSSec related information without the need to bypass the internal resolver and to use an external library. – Steffen Ullrich Jun 26 '18 at 04:28
  • And why couldn't in the future getdns or any other one like it be included in the OS? – Patrick Mevzek Jun 26 '18 at 04:42
  • @PatrickMevzek: If it would be tightly integrated into the system it would solve the problem - but it currently is not integrated this way and thus the problem is not solved. And tight integration does not mean just having it available by default. It means to be actually usable which involves changes to the OS and programming languages interfaces and also to higher level API's in order to provide applications with the DNSSec related information. – Steffen Ullrich Jun 26 '18 at 04:50
1

Can one actually configure an end-user client PC or device to force it to accept & use only DNS lookup results that are cryptographically-verified under DNSSec?

Yes, you can! There are two different ways to do this:

Application Level

The application can validate DNS queries it performs. An example of this is the DNSSEC Validator extension for Chrome/Firefox. However, this only works if the application (or an addon) supports it.

System/Network Level

Users and network administrators can configure their systems to validate DNSSEC themselves, and therefore have validation for all queries, regardless of origin. The current simplest way to implement this is to setup a simple recurseive resolver and proxy all your DNS traffic through it. Hopefully, in the future, operating system developers will add DNSSEC support to the OSs themselves so this is unnecessary.

Community
  • 1
ConnorJC
  • 326
  • 2
  • 6