Services/DNS: Difference between revisions
(→DNSSEC) |
No edit summary |
||
(15 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{Template:Service |
|||
== NS1 & NS2 == |
|||
| description = Available services: |
|||
* full hosting (NS1) on our servers |
|||
* replication (NS2) on our servers or, at your choice, partner servers (currently via Hivane) |
|||
| prerequisite = You need to buy a domain from a [[wikipedia:Domain_name_registrar|registrar]] and ask an administrator to configure this service. |
|||
| account = global-reg |
|||
| ipv6 = true |
|||
| security_notes = Your zone content can be secured using DNSSEC, and replication can be secured too using TSIG (see below). |
|||
}} |
|||
DC dans provide primary or secondary DNS servers for your zones. |
|||
== Master Zones Administration == |
|||
To have your master zone modified on our servers, you can: |
To have your master zone modified on our servers, you can: |
||
Line 11: | Line 20: | ||
To provide as much security as possible, DC supports the following mechanisms. |
To provide as much security as possible, DC supports the following mechanisms. |
||
=== TSIG === |
=== [[wikipedia:TSIG|TSIG]] === |
||
This protocol allows a secure transfer of zones between primary and secondary servers. |
This protocol allows a secure transfer of zones between primary and secondary servers. |
||
The DC's DNS servers support TSIG and comminication between them are always secured. The following entities are known to support TSIG and can then securely transfer zones to/from DC: |
The DC's DNS servers support TSIG and comminication between them are always secured. The following entities are known to support TSIG and can then securely transfer zones to/from DC: |
||
* [ |
* [https://www.hivane.net/ Hivane] |
||
=== DNSSEC === |
=== [[wikipedia:Domain_Name_System_Security_Extensions|DNSSEC]] === |
||
==== What is DNSSEC |
==== What is DNSSEC? ==== |
||
This protocol aims at establishing a chain of trust, from the root of the DNS, to ensure response to queries on a zone has not been altered on the way. With the root zone public key, it is possible to validate the replies step by step down to your zone, for example: root public key -> ''.'' -> NS for ''org.'' -> NS for ''milkypond.org.'' -> '' |
This protocol aims at establishing a chain of trust, from the root of the DNS, to ensure response to queries on a zone has not been altered on the way. With the root zone public key, it is possible to validate the replies step by step down to your zone, for example: root public key -> ''.'' zone -> NS for ''org.'' -> ''org.'' zone -> NS for ''milkypond.org.'' -> ''milkypond.org.'' zone -> ''irc.milkypond.org.'' entry. |
||
⚫ | |||
In order to help people work on securing their zone, and be ready when their provider is, the [http://www.isc.org/ ISC] created a solution to validating your zone, using another secure path: by publishing security associations in a special zone (''dlv.isc.org'', called the DLV Registry), which itself can be validated the normal way. This is only a stopgap, but as providers seems not to be in a hurry to do their job, DC decided to use it. |
|||
⚫ | DC DNS servers are able to handle the complicated procedure needed to sign a zone for you. You can just modify it the classic way, and have it signed automatically. If your provider gladly support DNSSEC, you just need to ask us to switch the zone to the secure mode. Beware DNS always means propagation delays, so you may have to wait a few days before the switch is completed and your zone fully secured over the whole world. |
||
⚫ | |||
⚫ | |||
⚫ | DC DNS servers are able to handle the complicated procedure needed to sign a zone for you. You can just modify it the classic way, and have it signed automatically |
||
⚫ | |||
⚫ | |||
* [https://nlnetlabs.nl/projects/unbound/about/ Unbound] does this out of the box |
|||
* [https://bind9.net/ Bind] might need some settings if it's an old version: |
|||
⚫ | |||
* |
** the root zone public key is now installed and configured in all major distributions |
||
* add |
** add in your global options (''/etc/bind/named.conf.options''): |
||
include "/etc/bind/root.keys"; |
|||
* add in your global options (''/etc/bind/named.conf.options''): |
|||
dnssec-enable yes; |
dnssec-enable yes; |
||
dnssec-validation yes; |
dnssec-validation yes; |
||
⚫ | |||
dnssec-lookaside auto; |
|||
⚫ | |||
The DLV Registry public key is already provided in the ''bind9'' package. |
|||
Then, you can check it with the ''dig'' tool (available in the ''dnsutils'' Debian package): |
Then, you can check it with the ''dig'' tool (available in the ''dnsutils'' Debian package): |
||
Line 48: | Line 53: | ||
{{warning}} If you check an entry of your zone which is a CNAME, beware the CNAME is resolved and if the destination name cannot be validated, then your entry won't either. |
{{warning}} If you check an entry of your zone which is a CNAME, beware the CNAME is resolved and if the destination name cannot be validated, then your entry won't either. |
||
== Documentation == |
|||
* generic documentation on [[wikipedia:Domain_Name_System|DNS]] |
|||
== Technical Details == |
|||
This service is made using: |
|||
* [https://bind9.net/ Bind9] |
Latest revision as of 18:09, 20 May 2021
Description | Available services:
| |||
---|---|---|---|---|
Prerequisite | You need to buy a domain from a registrar and ask an administrator to configure this service. | |||
Account | Global (registration required) | IPv6 Ready | Yes | |
Security Notes | Your zone content can be secured using DNSSEC, and replication can be secured too using TSIG (see below). |
Master Zones Administration
To have your master zone modified on our servers, you can:
- use our UserMagicalInterface
- ask administrators
DNS Security
To provide as much security as possible, DC supports the following mechanisms.
TSIG
This protocol allows a secure transfer of zones between primary and secondary servers.
The DC's DNS servers support TSIG and comminication between them are always secured. The following entities are known to support TSIG and can then securely transfer zones to/from DC:
DNSSEC
What is DNSSEC?
This protocol aims at establishing a chain of trust, from the root of the DNS, to ensure response to queries on a zone has not been altered on the way. With the root zone public key, it is possible to validate the replies step by step down to your zone, for example: root public key -> . zone -> NS for org. -> org. zone -> NS for milkypond.org. -> milkypond.org. zone -> irc.milkypond.org. entry.
How to use it for my zones?
DC DNS servers are able to handle the complicated procedure needed to sign a zone for you. You can just modify it the classic way, and have it signed automatically. If your provider gladly support DNSSEC, you just need to ask us to switch the zone to the secure mode. Beware DNS always means propagation delays, so you may have to wait a few days before the switch is completed and your zone fully secured over the whole world.
How to test my zone is secured?
First, you need a validating DNS server:
- Unbound does this out of the box
- Bind might need some settings if it's an old version:
- the root zone public key is now installed and configured in all major distributions
- add in your global options (/etc/bind/named.conf.options):
dnssec-enable yes; dnssec-validation yes;
- restart bind
Then, you can check it with the dig tool (available in the dnsutils Debian package):
dig +dnssec <zone>
Look at the flags: it is secured if you find the ad flag. If there is the aa flag instead, then you are interrogating on of the authoritative DNS servers for the zone, it is also secure, but better test it on another server to be sure it is propagated.
If you check an entry of your zone which is a CNAME, beware the CNAME is resolved and if the destination name cannot be validated, then your entry won't either.
Documentation
- generic documentation on DNS
Technical Details
This service is made using: