---
type: concept
title: DNSSec
tags: [dns, security, network, authentication, cryptography]
related: [universitatsrechenzentrum-urz, dnssec-validation, systemd-resolved, dnsmasq, sshfp, unbound]
created: 2026-07-01
updated: 2026-07-01
sources: ["output/rz_uni_greifswald_de_support_dokumentation_anleitungen.md", "output/rz_uni_greifswald_de_support_dokumentation_anleitungen_dnssec.md", "output/rz_uni_greifswald_de_support_dokumentation_anleitungen_dnssec_linux.md", "output/rz_uni_greifswald_de_support_dokumentation_anleitungen_dnssec_macos.md"]
---
# DNSSEC

**DNSSEC** (Domain Name System Security Extensions) is a suite of specifications and extensions designed for securing information provided by the Domain Name System (DNS). It adds a layer of security to the DNS protocol by enabling DNS responses to be digitally signed and cryptographically validated. This allows DNS resolvers and clients to authenticate the origin and verify the integrity of the DNS data, ensuring it has not been tampered with.

## Purpose and Mechanism
The primary goal of DNSSEC is to prevent attacks such as DNS spoofing or cache poisoning, where a malicious actor redirects a user to a fraudulent website by providing false DNS records.

DNSSEC works by adding digital signatures to existing DNS records. A DNSSEC-capable resolver can verify these signatures using a chain of trust that leads back to the DNS root zone.

## Role at Universität Greifswald
At the Universität Greifswald, the [[universitatsrechenzentrum-urz]] provides specific instructions on the usage and implementation of DNSSEC to ensure the authenticity and integrity of DNS data.

Within the university's IT infrastructure, DNSSEC is necessary for accessing specific security-based applications. A primary example is the verification of **SSH fingerprints**, which relies on DNSSEC to ensure the authenticity of the host key.

## Implementation and Technical Challenges

### Challenges
- **Default State**: On most client systems, DNSSEC is inactive by default during standard name resolution.
- **Authoritative Server Limitation**: Querying an **Authoritative Nameserver** (the server holding the actual records for a zone) directly does not provide the client with a validated response.

### Resolution and Requirements
To achieve DNSSEC validation on a client device, the use of a **Local DNS Resolver** (a DNSSEC-capable resolver) is required. These resolvers handle the validation process locally, ensuring that the responses provided to the application are verified.

- One example of a DNSSEC-capable resolver is [[unbound]].
- Detailed configuration guides are available for [[macos]] and [[linux]].

## Linux Implementation Details
According to [[sources/6-output--59-rzunigreifswalddesupportdokumentationanleitungendnsseclinux--1hdao70]], DNSSEC can be implemented on Linux systems through various resolvers:

- **[[systemd-resolved]]**: A modern system service that provides network name resolution. DNSSEC can be toggled via the `resolved.conf` configuration.
- **[[dnsmasq]]**: A lightweight DNS forwarder. Implementation requires the definition of `trust-anchor` keys to verify the chain of trust.

### Trust Anchors
A **Trust Anchor** is a starting point for verifying the chain of trust in DNSSEC. It consists of a public key (and its associated metadata) that the resolver trusts implicitly. In a `dnsmasq` configuration, these anchors are explicitly defined in the configuration file to allow the resolver to validate the signatures of the DNS root zone.