update
This commit is contained in:
13
networking/dns/dns-dnssec.md
Normal file
13
networking/dns/dns-dnssec.md
Normal file
@ -0,0 +1,13 @@
|
||||
# DNSSEC
|
||||
|
||||
DNSSEC (DNS Security Extensions) is a set of security extensions to the [[DNS]] (Domain Name System) protocol that provides authentication and integrity checking for DNS data. DNSSEC uses digital signatures to ensure that DNS responses have not been modified in transit and that they come from an authorized source.
|
||||
|
||||
With DNSSEC, each zone in the DNS hierarchy is signed with a private key, and the corresponding public key is published in the DNS. When a DNS resolver receives a DNS response, it can use the public key to verify the digital signature and ensure that the response has not been tampered with. If the signature is valid, the resolver can be confident that the response is authentic and has not been modified in transit.
|
||||
|
||||
DNSSEC provides several benefits, including:
|
||||
|
||||
- Data integrity: DNSSEC ensures that DNS responses have not been modified in transit, preventing DNS spoofing and other types of attacks that rely on DNS data tampering.
|
||||
- Authentication: DNSSEC allows DNS resolvers to authenticate the source of DNS responses, providing an additional layer of security against DNS cache poisoning and other attacks.
|
||||
- Trust hierarchy: DNSSEC allows for the creation of a trust hierarchy in the DNS, with each zone in the hierarchy being responsible for signing its own data and delegating trust to its child zones.
|
||||
|
||||
DNSSEC is supported by most modern DNS servers and resolvers, and is becoming increasingly important as a tool for securing the Internet's infrastructure.
|
0
networking/dns/dns-doh.md
Normal file
0
networking/dns/dns-doh.md
Normal file
0
networking/dns/dns-dot.md
Normal file
0
networking/dns/dns-dot.md
Normal file
71
networking/dns/dns-record-mailserver.md
Normal file
71
networking/dns/dns-record-mailserver.md
Normal file
@ -0,0 +1,71 @@
|
||||
# Mail Server DNS Records Cheat-Sheet
|
||||
|
||||
If you want to run a mail server on the public internet, you need to set up your [DNS Records](networking/dns-record-types.md) correctly. While some [DNS Records](networking/dns-record-types.md) are necessary to send and receive emails, others are recommended to build a good reputation.
|
||||
|
||||
## Required Mail Server DNS Records
|
||||
### A Record
|
||||
DNS A Record that will resolve to the public IP address of your mail server. This is also needed when your web server has a different IP address than your mail server.
|
||||
|
||||
**Recommended Settings Example:**
|
||||
|
||||
Type | Host | Points to | TTL
|
||||
---|---|---|---
|
||||
`A`|`mail`|`your-mail-servers-ipv4`|`1 hour`
|
||||
|
||||
### MX Record
|
||||
The MX record is important when you want to receive emails. This tells everyone which IP address to contact.
|
||||
|
||||
If you have multiple Mail Servers that need to be load-balanced use the same **priority**. Lower numbers are prioritized. Higher numbers can be used as backup servers.
|
||||
|
||||
**Recommended Settings:**
|
||||
|
||||
Type | Host | Points to | Priority | TTL
|
||||
---|---|---|---|---
|
||||
`MX`|`@`|`mail.your-domain`|`0`|`1 hour`
|
||||
|
||||
### RDNS or PTR Record
|
||||
The reverse DNS record or also called PTR (Pointer Resource Record) is important when you want to send mails. Almost all mail servers check the RDNS record to perform simple anti-spam checks. RDNS is just like a DNS query, just backward.
|
||||
|
||||
>Your RDNS record is not configured on your DNS server, instead, it’s configured on your hosting provider where you got your public IP address from.
|
||||
|
||||
## (Optional but recommended) DNS Records
|
||||
|
||||
### SPF Record
|
||||
The SPF (Sender Policy Framework) is a TXT record on your DNS server that specifies which hosts are allowed to send mails for a given domain. When a mail server receives a mail that seems to come from your domain it can check if it’s a valid message. Some mail servers reject mails if they can’t validate that the message comes from an authorized mail server.
|
||||
|
||||
**Recommended Settings:**
|
||||
|
||||
Type | Host | TXT Value | TTL
|
||||
---|---|---|---
|
||||
`TXT`|`@`|`v=spf1 ip4:your-mail-servers-ipv4 -all`|`1 hour`
|
||||
|
||||
### DKIM Record
|
||||
DKIM (Domain Keys Identified Mail) allows the receiving mail server to check that an email was indeed sent by the owner of that domain. The sending mail server adds a digital signature to every mail that is sent. This signature is added as a header and secured with encryption. These signatures are not visible to the end-user.
|
||||
|
||||
>If you want to add DKIM to your mail server you first need to create a private and a public keypair
|
||||
|
||||
We use the tool [OpenSSL](tools/openssl.md) to generate a DKIM private and public keypair.
|
||||
|
||||
```sh
|
||||
openssl genrsa -out dkim_private.pem 2048
|
||||
openssl rsa -in dkim_private.pem -pubout -outform der 2>/dev/null | openssl base64 -A
|
||||
```
|
||||
|
||||
**Recommended Settings:**
|
||||
|
||||
Type | Host | TXT Value | TTL
|
||||
---|---|---|---
|
||||
`TXT`|`dkim._domainkey`|`v=DKIM1;k=rsa;p=public-dkim-key`|`1 hour`
|
||||
|
||||
### DMARC Record
|
||||
DMARC (Domain-based Message Authentication, Reporting, and Conformance) extends your existing SPF and DKIM records. It makes sure that the sender's emails are protected by SPF and DKIM and tells the receiving mail server what to do if these checks fail.
|
||||
|
||||
**Recommended Settings:**
|
||||
|
||||
Type | Host | TXT Value | TTL
|
||||
---|---|---|---
|
||||
`TXT`|`_dmarc`|`v=DMARC1;p=quarantine`|`1 hour`
|
||||
|
||||
## (Optional) DNS Records
|
||||
### Autoconfiguration DNS Records
|
||||
If you’re using mail clients like Outlook, Thunderbird on your Computer, or Mobile devices they offer the ability to do an “autoconfiguration” also called “Autodiscover”. That means you just need to enter your email address and password and the mail client tries to resolve the mail server IP addresses, used ports, and encryption settings for IMAP and SMTP. You can achieve this by adding SRV DNS records that are defined in the [RFC 6186 standard](https://tools.ietf.org/html/rfc6186) and some specific records that are used in Outlook clients.
|
39
networking/dns/dns-record-types.md
Normal file
39
networking/dns/dns-record-types.md
Normal file
@ -0,0 +1,39 @@
|
||||
# DNS Record Types
|
||||
|
||||
[[DNS]] (Domain Name System) record types are used to store different types of information about a domain name in the DNS database.
|
||||
|
||||
## Most common types of DNS Records
|
||||
|
||||
| Type | Description |
|
||||
| ----- | -------------------------------------------------------------------------------------------------------------- |
|
||||
| A | The record that holds the IP address of a domain. |
|
||||
| AAAA | The record that contains the IPv6 address for a domain (as opposed to A records, which list the IPv4 address). |
|
||||
| CNAME | Forwards one domain or subdomain to another domain, does NOT provide an IP address. |
|
||||
| MX | Directs mail to an email server. |
|
||||
| TXT | Lets an admin store text notes in the record. These records are often used for email security. |
|
||||
| NS | Stores the name server for a DNS entry. |
|
||||
| SOA | Stores admin information about a domain. |
|
||||
| SRV | Specifies a port for specific services. |
|
||||
| PTR | Provides a domain name in reverse-lookups. |
|
||||
|
||||
## Less commonly used DNS Records
|
||||
|
||||
| Type | Description |
|
||||
| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| APL | The ‘address prefix list’ is an experiment record that specifies lists of address ranges. |
|
||||
| AFSDB | This record is used for clients of the Andrew File System (AFS) developed by Carnegie Melon. The AFSDB record functions to find other AFS cells. |
|
||||
| CAA | This is the ‘certification authority authorization’ record, it allows domain owners state which certificate authorities can issue certificates for that domain. If no CAA record exists, then anyone can issue a certificate for the domain. These records are also inherited by subdomains. |
|
||||
| DNSKEY | The ‘DNS Key Record’ contains a public key used to verify Domain Name System Security Extension (DNSSEC) signatures. |
|
||||
| CDNSKEY | This is a child copy of the DNSKEY record, meant to be transferred to a parent. |
|
||||
| CERT | The ‘certificate record’ stores public key certificates. |
|
||||
| DCHID | The ‘DHCP Identifier’ stores info for the Dynamic Host Configuration Protocol (DHCP), a standardized network protocol used on IP networks. |
|
||||
| DNAME | The ‘delegation name’ record creates a domain alias, just like CNAME, but this alias will redirect all subdomains as well. For instance if the owner of ‘example.com’ bought the domain ‘website.net’ and gave it a DNAME record that points to ‘example.com’, then that pointer would also extend to ‘blog.website.net’ and any other subdomains. |
|
||||
| HIP | This record uses ‘Host identity protocol’, a way to separate the roles of an IP address; this record is used most often in mobile computing. |
|
||||
| IPSECKEY | The ‘IPSEC key’ record works with the Internet Protocol Security (IPSEC), an end-to-end security protocol framework and part of the Internet Protocol Suite (TCP/IP). |
|
||||
| LOC | The ‘location’ record contains geographical information for a domain in the form of longitude and latitude coordinates. |
|
||||
| NAPTR | The ‘name authority pointer’ record can be combined with an SRV record to dynamically create URI’s to point to based on a regular expression. |
|
||||
| NSEC | The ‘next secure record’ is part of DNSSEC, and it’s used to prove that a requested DNS resource record does not exist. |
|
||||
| RRSIG | The ‘resource record signature’ is a record to store digital signatures used to authenticate records in accordance with DNSSEC. |
|
||||
| RP | This is the ‘responsible person’ record and it stores the email address of the person responsible for the domain. |
|
||||
| SSHFP | This record stores the ‘SSH public key fingerprints’; SSH stands for Secure Shell and it’s a cryptographic networking protocol for secure communication over an unsecure network. |
|
||||
|
70
networking/dns/dns.md
Normal file
70
networking/dns/dns.md
Normal file
@ -0,0 +1,70 @@
|
||||
# DNS
|
||||
|
||||
DNS (Domain Name System) is a hierarchical distributed naming system used to translate human-readable domain names, such as `www.example.com`, into [[IP]] (Internet Protocol) addresses, such as 192.0.2.1, that computers use to identify each other on the Internet. DNS allows users to access websites and other Internet resources using easy-to-remember domain names instead of having to remember the numerical IP addresses that correspond to them.
|
||||
|
||||
## How DNS works
|
||||
|
||||
DNS operates using a client-server architecture. When a user types a domain name into their web browser, the browser sends a DNS query to a DNS resolver, which is typically provided by the user’s Internet Service Provider (ISP). The resolver then sends a series of recursive queries to other DNS servers, working its way up the DNS hierarchy until it receives a response containing the IP address associated with the requested domain name.
|
||||
|
||||
DNS is organized into a hierarchical structure of domains, with the root domain at the top of the hierarchy. Each domain is divided into subdomains, with each level of the hierarchy separated by a dot (e.g., example.com is a subdomain of the com top-level domain). Each domain is managed by a domain name registrar, which is responsible for assigning domain names and IP addresses to organizations and individuals. DNS also supports advanced features such as [DNSSEC](dns-dnssec.md) (DNS Security Extensions), which provides authentication and integrity checking for DNS queries and responses.
|
||||
|
||||
## DNS Record Types
|
||||
|
||||
DNS records are an essential part of the DNS system, as they contain the information needed to translate domain names into IP addresses and vice versa. Each DNS record contains a specific type of information about a domain name, such as its IP address, mail exchange server, or authoritative name servers.
|
||||
|
||||
There are many different types of DNS records, each with a specific format and purpose. Some of the most commonly used DNS record types include A, AAAA, CNAME, MX, NS, PTR, SOA, SRV, and TXT records. Each record type has a specific format and purpose, and is used to provide different types of information about a domain name.
|
||||
|
||||
Here's a [[dns-record-types|List of all DNS Record Types]].
|
||||
|
||||
## Encryption
|
||||
|
||||
Ever since DNS was created in 1987, it has been largely unencrypted. Everyone between your device and the resolver is able to snoop on or even modify your DNS queries and responses.
|
||||
|
||||
The UDP source port is 53 which is the standard port number for unencrypted **DNS**. The [UDP](../networking/udp.md) payload is therefore likely to be a **DNS** answer.
|
||||
|
||||
Encrypting DNS makes it much harder for snoopers to look into your **DNS** messages, or to corrupt them in transit.
|
||||
|
||||
Two standardized mechanisms exist to secure the **DNS** transport between you and the resolver, [DNS over TLS](dns-dot.md), and [DNS queries over HTTPS](dns-doh.md).
|
||||
|
||||
Both are based on Transport Layer Security ([TLS](../networking/tls.md)) which is also used to secure communication between you and a website using [HTTPS](../networking/https.md).
|
||||
|
||||
As both DoT and DoH are relatively new, they are not universally deployed yet.
|
||||
|
||||
### DNS over HTTPS
|
||||
|
||||
DNS over HTTPS, or DoH, is an alternative to DoT. With DoH, DNS queries and responses are encrypted, but they are sent via the HTTP or HTTP/2 protocols instead of directly over UDP.
|
||||
|
||||
Like DoT, DoH ensures that attackers can't forge or alter DNS traffic. DoH traffic looks like other HTTPS traffic – e.g. normal user-driven interactions with websites and web apps – from a network administrator's perspective.
|
||||
|
||||
```txt
|
||||
┌─────────────────┐ ──┐
|
||||
│ 爵 HTTP Protocol │ │ encrypted
|
||||
├─────────────────┤ ├── traffic
|
||||
│ TLS Protocol │ │ via HTTPS
|
||||
├─────────────────┤ ──┘
|
||||
│ TCP Protocol │
|
||||
│ (Port 443) │
|
||||
├─────────────────┤
|
||||
│ IP Protocol │
|
||||
└─────────────────┘
|
||||
|
||||
GET/POST
|
||||
url/dns-request?dns-...
|
||||
```
|
||||
|
||||
### DNS over TLS
|
||||
|
||||
DNS over TLS, or DoT, is a standard for encrypting DNS queries to keep them secure and private. DoT uses the same security protocol, TLS, that HTTPS websites use to encrypt and authenticate communications. (TLS is also known as "SSL.") DoT adds TLS encryption on top of the user datagram protocol (UDP), which is used for DNS queries.
|
||||
|
||||
```txt
|
||||
┌─────────────────┐ ──┐
|
||||
│ DNS Protocol │ │ encrypted
|
||||
├─────────────────┤ ├── traffic
|
||||
│ TLS Protocol │ │ via TLS
|
||||
├─────────────────┤ ──┘
|
||||
│ UDP Protocol │
|
||||
│ (Port 853) │
|
||||
├─────────────────┤
|
||||
│ IP Protocol │
|
||||
└─────────────────┘
|
||||
```
|
Reference in New Issue
Block a user