Every domain holder has the possibility to protect their domain by a DNSSEC signature. The signature enables the user of the website to see if the transferred data actually is identical with the originally entered data.

A domain can be signed either by the Internet service provider or by the domain holder themselves. If the provider assumes responsibility for signing the domain – provided the provider supports DNSSEC – the provider also is responsible for generating the keys, signing the zone data, carrying out re-signing before signature validity expires, and for changing the keys at the required intervals.

If the domain holder carries out the signing because they are operating name servers that meet the obligatory requirements, the provider will obtain the public key of the holder in order to pass it on to the responsible registry (for .de domains this is DENIC). If this variant is used, only the domain holder will know the private key.

In addition to the 2048bit Key Signing Key, a 1024bit Zone Signing Key will be used, which will be rolled over every five weeks by the so-called pre-publish procedure. Both keys generate signatures in accordance with the standardized RSA/SHA256 procedure as specified in RFC5702. Validity of the KSK signatures is three weeks, ZSK signatures, in contrast, are valid for one week only. The .de zone is signed with opt-out, using NSEC3 records according to RFC5155.

quot;nsentry" domains - their records being stored and being authoritative directly in the .de zone - will be recorded automatically by DNSSEC and provided with the corresponding signatures generated by DENIC.

If you operate a validating resolver yourself, you are principally able to validate signatures for DNSSEC domains. The details depend on the resolver.

Alternatively, your ISP operates a validating resolver for you. In that case, this resolver will be able to suppress data it has identified as manipulated and will not transfer such data to you at all. It will however not be possible for you to see whether the data originates from a signed or non-signed domain.

Please contact your domain provider directly to find out if they support DNSSEC.

For Internet users it is essential that they can rely on the integrity of the information they have called on. It must be guaranteed, for instance, that the contents of a website they see on their screen is identical with the data of the website they wanted to access. To achieve this, the path from the query sent to a website up to the response received must be secured. Domain Name Security Extensions (DNSSEC) render a contribution to this security. They authenticate the origin of data for the Domain Name System (DNS), i.e. they secure the path between the DNS servers and the validating DNS clients. The signature applied reveals if the data is authentic, i.e. if it originates from the authoritative zone. At the same time, securing data integrity protects against DNS data that was manipulated on the way.

However, DNSSEC does not warrant the correctness of the initially stored data of a website nor does it prove that the data is harmless. Neither will DNSSEC recognize if a website you call on, and which you have possibly accessed via a link received in an e-mail, is forged (so-called phishing), nor is it able to protect against domain hijacking or manipulations during the registration process.

If a DENIC member stops to administer a domain and places the domain in TRANSIT, DENIC will remove from the registration database any key material possibly existing for the domain. No DENIC member being responsible for the administration of the domain, there is nobody who can transmit domain data changes, including changes to the keys, to DENIC. Thus, the conditions required for key administration are no longer met. To avoid validation errors, the DS record is deleted and thus flagged as unsigned in the zone.

At present, our DENICdirect service does not provide for a possibility to store key material for domains with name server entries. Domains with "nsentry" records - their records being stored and being authoritative directly in the .de zone - will be recorded automatically by DNSSEC and provided with the corresponding signatures generated by DENIC.

Additional information can be found at https://www.denic.de/en/domains/de-domains/registration/nameserver-and-nsentry-data/.

To be able to benefit from DNSSEC you need a validating resolver that is capable to interpret the additional information supplied by DNSSEC.

If you do not operate a validating resolver yourself, you will only benefit if your Internet service provider operates such a resolver for you. When you call a website, for example, the operating system installed on the computer automatically transfers the DNS query to the DNS server defined by the respective Internet service provider. This way, the signed DNS data is verified on the provider's server and manipulations can be identified and forged data be supressed.

Domain Name Security Extensions (DNSSEC) are used to verify data by means of cryptographically secured signatures. These signatures are computed from the data to be protected and are transferred to the client together with the data. Data verification is executed in the client or in the upstream resolver and includes the check against the public keys valid for the respective zone. The easiest solution for these keys, in turn, is to store and call on them in the Domain Name System (DNS). This procedure ensures that the security mechanism cannot be interrupted, since even the key transfer is secured by DNSSEC; only the key required to start the security chain (i.e. the key of the root zone) is permanently stored in the client or incorporated through configuration.

Domain Name Security Extensions (DNSSEC) are extensions of the DNS (Domain Name System) which have the purpose to close security holes in the Internet, such as cache poisoning, DNS redirection and DNS spoofing.

In the conventional DNS an application expects the answer to a DNS query to be intact and to originate from the right source. However, you cannot always be confident about that. In the past, there have been rare cases when non-authentic data were deliberately introduced in DNS caches (the so-called cache poisoning). Already in the nineties this attack was identified as a potential threat and documented later in the RFC 3833. The Internet Engineering Task Force (IETF) reacted to this - initially theoretical - threat and finally published the three RFCs RFC 4033, RFC 4034 and RFC4035 .in March 2005. This RFC trilogy is also known as "DNSSECbis". Later, the so-called NSEC3 (RFC 5155), was added as an important supplement. NSEC3 helps to avoid unwanted listing of the zone content (such as all registered DE domains).