9

I'm not sure if the RFC's support a IPSec-only implementation of DNS, but if it does, what does that mean for DNSSec?

Is DNSSec an IPv4-only technology?

AviD
  • 72,138
  • 22
  • 136
  • 218
makerofthings7
  • 50,090
  • 54
  • 250
  • 536

2 Answers2

6

DNSSEC provides something rather different than IPSec, and either or both may meet your needs. IPSec can encrypt packets and sign them, providing evidence that they come from something you trust, IF you have a PKI (Public Key Infrastructure) you can trust. But that "IF" is a very tall order, especially given the presence these days in most common "trusted" default certificate stores of root certificates controlled by foreign governments whom I certainly wouldn't trust.

If you just want a private VPN, using only your own certificates and networks and your own DNS servers, IPSec may provide what you want. But if you want to find out from the public network where to send your packets in the first place, i.e. via a secure mapping from domain names to IP addresses, that is what DNSSEC is for.

Note also, coming in the not-so-distant future (we hope) the almost-formed Keys In DNS (kidns) working group of the Internet Engineering Task Force, which will help integrate these and other security protocols in a way which gets around the current morass of "Certificate Authorities": http://www.spinics.net/lists/ietf-ann/msg57258.html

Update: the kidns working group proposal was adopted under the name DANE: DNS-based Authentication of Named Entities. It wrote RFC6698 which was implemented in some tools and libraries and browser extensions, but did not become a mainstream browser feature.

Alternate technologies like certificate pinning (secse) potentially aided by HTTP Strict Transport Security have helped with the underlying issues.

Community
  • 1
nealmcb
  • 20,544
  • 6
  • 69
  • 116
  • @nealmcb, "via a secure mapping from domain names to IP addresses" **requires root trust anchor too**. So why did we choose to use DNSSEC instead of simply relying on IPSEC? Both will need a root trust anchor anyway. – Pacerier Nov 04 '17 at 05:29
  • In fact, wouldn't the best longterm solution to replace all Ethernet nodes in the internet with MacSEC so that "network eavesdropping" would be a relic of the past? With MacSEC running underneath, we can use plain old DNS, IP, FTP, HTTP, and everything else. – Pacerier Nov 04 '17 at 14:48
  • 1
    @Pacerier Each node always needs to establish its own trust somehow. And re: Macsec, that's not at all true. [MacSEC aka 802.1AE](https://en.wikipedia.org/wiki/IEEE_802.1AE) seems like a good low-level tool, but you need Internet protocols to secure interoperable end-to-end traffic beyond a LAN, and it doesn't help you make sure you're trying to connect to the right node: "_Key management and the establishment of secure associations is outside the scope of 802.1AE_". – nealmcb Dec 03 '17 at 15:52
1

The DNS Section of the IPv6 Wikipedia page does not have anything about defending against bogus DNS responses so it appears that DNSSec is still necessary.

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
Zian Choy
  • 1,131
  • 8
  • 8