Please visit the original link: sysin.org/blog/dnssec… To view the latest version. Original works, reproduced please retain the source.

Author: GC (at)sysin.org, homepage: www.sysin.org

1. DNS spoofing and cache contamination

When a client (PC, etc.) initiates a domain name request (e.g. visit: www.baidu.com), if the local cache is not available, it will send a domain name query request (also called localDNS) to the recursive server, which then recurses from. To com. And then to baidu.com. (namely to. Authoritative server –> com. > baidu.com.), finally get to www.baidu.com. The corresponding parse A record is returned to the client. An attacker can impersonate any responder throughout the query: recursive server –>. Www.baidu.com –> baidu.com. (UDP packets are extremely easy to forge), in which the resolution record of the response gives the wrong IP address or some other type of resolution record (such as NXDomain, ServFail, or CName goes to the wrong domain address, etc.). If the client or parsing server accepts the forged reply without verifying the correctness of the data source, the client cannot access the website or other resources properly or the client requests are redirected to the forged website. In addition, due to the existence of cache in DNS, such incorrect records will be cached with the TTL set by the attacker. If the recursive server is deceived by DNS, it will cause itself and a large area of clients to cache incorrect resolution records (which can be solved by clearing the cache).

2. Introduction of DNSSEC

DNSSEC (Domain Name System Security Extensions) is a series of DNS Security authentication mechanisms provided by the IETF (for details, see RFC2535). It provides a mechanism to verify the authenticity and integrity of reply information, using cryptography so that the DNS server can verify that the reply it receives (including non-existent reply) is from a real server or has been tampered with during transmission.

DNSSEC uses digital signatures based on public key encryption to enhance DNS authentication. DNSSEC does not cryptically sign DNS queries and responses themselves, but rather the DNS data itself is signed by the data owner.

Each DNS zone contains a private and private key pair. The DNS zone owner uses the zone’s private key to sign the DNS data in the zone, generating a digital signature for the data. As the name suggests, “private key” means that the DNS zone owner keeps the key material secret. However, the public key of the zone is published in the zone for all users to search. Any recursive parser that looks for data within a zone must also retrieve the zone public key, which can be used to verify the authenticity of DNS data. The parser verifies that the digital signature of the retrieved DNS data is valid. If the DNS data is valid, the DNS data is returned to the user. If the signature is not validated, the parser assumes an attack, discards the data and returns an error to the user.

DNSSEC adds two important new features to the DNS protocol:

  • Data source validation – The parser can use encryption to verify that the received data is indeed from the data transfer area it identifies.
  • Data integrity protection – The parser can be confident that the data has not been modified during transmission since the zone owner first signed the data using the zone private key.

3. The principle of DNSSEC

DNSSEC uses public key cryptography to create password signatures for DNS information and provide authentication and information integrity check for DNS information. Its implementation steps are as follows:

After receiving the DNS query request, the DNS server uses the hash function to hash the content of the DNS reply packet to obtain the summary of the content. The summary is encrypted with a private key and then appended to the DNS reply packet.

After receiving the packet, the DNS query requester decrypts the received “content summary” with the public key, calculates the “content summary” in the DNS query request packet with the hash function, and compares the two.

If they are the same, you can confirm that the RECEIVED DNS information is a correct DNS response. If the authentication fails, the packet may be counterfeit or tampered with during transmission or caching.

4. DNSSEC resource records

To implement the signing and validation of resource records, DNSSEC adds four types of resource records:

  • Resource Record Signature (RRSIG) Records: digital signatures of storage Resource records

  • DNSKEY (DNS Public Key) record: stores Public keys

  • DS (Delegation Signer) record: Stores the hash value of the DNSKEY, which is used to verify the authenticity of the DNSKEY, thus establishing a trust chain

  • NSEC (Next Secure) records: Records used to respond to resources that do not exist

5. Mainstream DNS support

Public DNS

Inspection method: dig + noadditional DS icann.org @ the IP of the DNS | grep DS back if you have the DS records show that the server support DNSSEC

Google DNS: 8.8.8.8, 8.8.4.4

Google DNS IPv6：2001:4860:4860::8888，2001:4860:4860::8844

Cloudflare DNS: 1.1.1.1, 1.0.0.1

OpenDNS: 208.67.222.222, 208.67.220.220

Ali AliDNS: 223.5.5.5, 223.6.6.6

CNNIC SDNS: 1.2.4.8, 210.2.4.8

114 DNS: 114.114.114.114, 114.114.115.115

Baidu DNS: 180.76.76.76

DNSPOD DNS: 119.29.29.29, 182.254.116.116

Shanghai Telecom: 202.96.209.5, 202.96.209.133

Beijing Unicom: 202.106.196.115, 202.106.46.151, 202.106.0.20

The preceding public DNS supports DNSSEC. You can use the preceding method to check whether the DNS of the local carrier supports DNSSEC.

Domain names and domain registrar support DNSSEC

Over 90% of top-level domains (TLD) support DNSSEC. For details, see ICANN TLD DNSSEC Report.

ICANN requires domain name registrars to support the addition of resource records, see the Supplementary Guidelines for Registrar Operations.

There doesn’t seem to be a lot of support or paid support for enabling DNSSEC resolution, which may be the reason for the current low number of DNSSEC deployments.

Here’s how DNSSEC is supported by some well-known domain registrars and service providers:

Ali Cloud (formerly Wanwang) : DNSSEC resolution function needs to be paid, using a third party to support DNSSEC DNS resolution, you can add DNSSEC resource records in Ali Cloud (free).

Tencent Cloud (DNSPOD) : no DNSSEC parsing function found, only support to add resource records (free), see the official website.

Godady: Upgrade the prime VERSION of DNS (for a fee) to enable DNSSEC and add DS records for free.

AWS Route 53: DNSSEC parsing is not supported, only resource logging is supported. See AWS Route 53.

Microsoft Azure DNS: Does Azure DNS support DNSSEC? No. Azure DNS doesn’t currently support the Domain Name System Security Extensions (DNSSEC).

For Google Cloud DNS, see Ctivating DNSSEC for Cloud DNS Domains – Google Cloud.

Cloudflare: One click to enable DNSSEC for free. Of course, Cloudflare is not a domain registrar, so you need to add A DS record to the domain registrar (see here).

6. Configure DNSSEC

In this example, Sysin.org uses Cloudflare DNS, the domain name registered in Aliyun.

Enable DNSSEC at Cloudflare

Log in to Cloudflare, select your domain name, click the “DNS” icon, drop down to see “DNSSEC”, click “Enable DNSSEC”, you can see the prompt to add DS records to the domain registrar:

Digest has been processed 😁.

Add resource records in Aliyun domain name management

Log in ali Cloud console, select “Domain name”, enter “Domain name List”, you can see the domain name “sysin.org”, click “Management” at the end of the operation, enter the “Basic Information/sysin.org” page, click “DNSSEC Setting” on the left, click “Add DS Record”

* Encryption Algorithm: Algorithm, drop down to select 13 * Digest Type: select 2-SHA-256 * Digest Type: select 2-SHA-256 * That is the Digest, copy the content of the Digest and paste it inCopy the code

validation

Use the test tool to test the domain name

If DS is displayed on each level of the test page and no red error box is displayed, DS is enabled and has taken effect.

At Cloudflare, the above page will also display: Success! sysin.org is protected with DNSSEC.

7. Query and verify DNSSEC

Dig command

Check the RRSIG (Resource Record Signature) for a domain name signed by DNSSEC.

Viewing domain names with DNSSEC signatures (sysin.org) requires a DNSSEC-enabled DNS server (8.8.8.8).

%Dig sysin.org + dnssec @ 8.8.8.8; < < > > DiG 9.10.6 < < > > sysin.org + dnssec @ 8.8.8.8;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63155 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ; sysin.org. IN A ;; ANSWER SECTION: 299 IN A 104.27.163.41 sysin.org. 299 IN A 172.67.214.128 sysin.org. 299 IN A 104.27.162.41 sysin.org  RRSIG A 13 2 300 20200829022403 20200827002403 34505 sysin.org. 93sJ5e/HTDsFWOYbgw+kw4snha1Bvq1SPSjxWbto8DYvRdaLgZtVVH/N k81Gw086yUTJTpXLLOLDfCel0r//gA== ;; Query time: 133 msec ;; SERVER: 8.8.8.8 # 53 (8.8.8.8);; WHEN: Fri Aug 28 09:24:03 CST 2020 ;; MSG SIZE rcvd: 191Copy the code

Online detection website

dnsviz.net/

dnssec-analyzer.verisignlabs.com/

Browser Extensions

Firefox:addons.mozilla.org/zh-CN/firef…

Chrome:chrome.google.com/webstore/se…