Domain Name System security: Difference between revisions
imported>Howard C. Berkowitz (General cleanup) |
John Leach (talk | contribs) m (Text replacement - "]]" to "") |
||
(8 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
{{ | {{PropDel}}<br><br>{{subpages}} | ||
{{ | |||
'''''This is a draft for which collaboration would be very, very appreciated. See talk page for some of the problem areas''''' | '''''This is a draft for which collaboration would be very, very appreciated. See talk page for some of the problem areas''''' | ||
DNS, as a critical part of the Internet infrastructure, needs to be protected. There have been, and continue to be, serious attacks against it. DNS is becoming more, not less critical | DNS, as a critical part of the Internet infrastructure, needs to be protected. There have been, and continue to be, serious attacks against it. DNS is becoming more, not less, critical as it becomes involved in more functions than the name-to-address mapping for which it was designed. Internet Protocol version 6 address management demands dynamic DNS update even more than did IPv4 dynamic addressing, but DNS security features are needed to secure the updates. With convergence of communications involving telephone number mapping to Internet names and numbers (e.g., IETF ENUM), DNS is critical in other areas. Another aspect of Internet Protocol version 6 deployment may be increased use of IPsec, which, in turn, needs a secure DNS as a trusted repository for public keys and certificate revocations. | ||
DNS software and operations should follow the overall DNS security architecture (DNSSEC).<ref name=RFC4033>{{citation | DNS software and operations should follow the overall DNS security architecture (DNSSEC).<ref name=RFC4033>{{citation | ||
Line 11: | Line 10: | ||
| date = March 2005 | | date = March 2005 | ||
| url = http://www.ietf.org/rfc/rfc4033.txt}}</ref> | | url = http://www.ietf.org/rfc/rfc4033.txt}}</ref> | ||
Image:Security scope.png|thumb|left|DNS security scope | |||
==Threats to DNS== | ==Threats to DNS== | ||
'''Domain Name System security (DNSSEC)''' is intended to solve, or mitigate, known security threats to the | '''Domain Name System security (DNSSEC)''' is intended to solve, or mitigate, known security threats to the Domain Name System. <ref name=RFC3833>{{citation | ||
| author = D. Atkins, R. Austein | | author = D. Atkins, R. Austein | ||
| id = RFC 3833 | | id = RFC 3833 | ||
Line 21: | Line 21: | ||
In the figure "Conceptual points of vulnerability", you will see that the backgrounds are shaded differently for "Server Security Issues" and "Data Protection Issues". These are one of several ways of breaking out the threat. | In the figure "Conceptual points of vulnerability", you will see that the backgrounds are shaded differently for "Server Security Issues" and "Data Protection Issues". These are one of several ways of breaking out the threat. | ||
Image:Points of DNS Vulnerability.png|thumb|Conceptual points of vulnerability in DNS | |||
Another threat model starts with some basic assumptions.<ref>RFC3303, pp.1-2 </ref> | Another threat model starts with some basic assumptions.<ref>RFC3303, pp.1-2 </ref> | ||
An IETF working group on DNS Security started in 1993. It produced the broad outlines from which DNSSEC would emerge, DNSSEC being a combination of threat analysis and countermeasures to those threats. First, some basic assumptions were made. | An IETF working group on DNS Security started in 1993. It produced the broad outlines from which DNSSEC would emerge, DNSSEC being a combination of threat analysis and countermeasures to those threats. First, some basic assumptions were made. | ||
* "DNS data is "public", and ruled all threats of data disclosure explicitly out of scope for DNSSEC.<ref>RFC3303, pp.1-2 </ref> This does not mean, however, that DNS data inside the namespace of a | * "DNS data is "public", and ruled all threats of data disclosure explicitly out of scope for DNSSEC.<ref>RFC3303, pp.1-2 </ref> This does not mean, however, that DNS data inside the namespace of a virtual private network, "inside the firewall", etc., needs to be available to the public Internet. It means that the data must be available, possibly in read-only format alone, throughout that namespace. | ||
*While some participants in the meeting were interested in authentication of DNS clients and servers as a basis for access control, this work was also ruled out of scope for DNSSEC ''per se.''<ref>RFC3303, pp.1-2 </ref> This does not preclude the additional use of client and server authentication, probably based on some features of | *While some participants in the meeting were interested in authentication of DNS clients and servers as a basis for access control, this work was also ruled out of scope for DNSSEC ''per se.''<ref>RFC3303, pp.1-2 </ref> This does not preclude the additional use of client and server authentication, probably based on some features of IPsec.<ref name=RFC4301>{{citation | ||
| id = RFC4301 | | id = RFC4301 | ||
| title = Security Architecture for the Internet Protocol | | title = Security Architecture for the Internet Protocol | ||
Line 35: | Line 35: | ||
**data integrity, and | **data integrity, and | ||
**data origin authentication. | **data origin authentication. | ||
*The design team noted that a digital signature mechanism would support the desired services.<ref>RFC3303, p.2 </ref> While digital signature mechanisms do not require a full | *The design team noted that a digital signature mechanism would support the desired services.<ref>RFC3303, p.2 </ref> While digital signature mechanisms do not require a full Public Key Infrastructure, such mechanisms do require a certain amount of trusted infrastructure. | ||
DNS data can be spoofed and corrupted between master server and resolver or forwarder | DNS data can be spoofed and corrupted between master server and resolver or forwarder | ||
Line 47: | Line 47: | ||
===Threats to the Zone File=== | ===Threats to the Zone File=== | ||
'''1a''' deals with the problem of a | '''1a''' deals with the problem of a miscreant breaking into the trusted machine, inside the organization, on which the zone file is created, and altering it before it is transferred to the master server. '''1b''' considers both modification to a valid zone file being transferred, as well as a hostile server misrepresenting itself to the primary DNS server as a valid source of zone information. | ||
It is understood that especially in small installations, the DNS zone file creation and primary server are on the same physical computer. This is really undesirable, for reasons beyond security: a primary DNS server is a critical resource, and, for greatest reliability, should run only the minimal DNS and support software. While an administrator is creating a zone file, there are any number of valid reasons why that person might want to access a Web or other public resource, such as the | It is understood that especially in small installations, the DNS zone file creation and primary server are on the same physical computer. This is really undesirable, for reasons beyond security: a primary DNS server is a critical resource, and, for greatest reliability, should run only the minimal DNS and support software. While an administrator is creating a zone file, there are any number of valid reasons why that person might want to access a Web or other public resource, such as the request for comment archive or a root server file. Every time that administrator's machine exposes itself to the public Internet, it opens a potential channel to attack the DNS primary server and all that depends on it. | ||
'''2a''' and '''2b''' deal with zone file attacks at sites external to the domain. | '''2a''' and '''2b''' deal with zone file attacks at sites external to the domain. | ||
Line 58: | Line 58: | ||
===Fake dynamic updates=== | ===Fake dynamic updates=== | ||
'''4''' covers both stateful and stateless sources of updates. When dynamic updates come only from a | '''4''' covers both stateful and stateless sources of updates. When dynamic updates come only from a Dynamic Host Configuration Protocol(DHCP) server, there can be substantial administrative and technical controls on the DHCP server, whether it is DHCP for Internet Protocol version 4 or Internet Protocol version 6. The situation becomes much more complex when IPv6 stateless address autoconfiguration (SLAAC) is deployed, and any host has a legitimate reason to send a dynamic update into DNS. | ||
===Cache attacks=== | ===Cache attacks=== | ||
At '''5''', a caching-only server may masquerade as the real server to the client, and poison the resolver's cache. | At '''5''', a caching-only server may masquerade as the real server to the client, and poison the resolver's cache. | ||
==Security implementation== | ==Security implementation== | ||
DNSSEC specifically refers to the core digital signature mechanisms used to validate secure DNS records. Three of its RRs, DNSKEY, RRSIG and NSEC work together to establish the authenticity and integrity of DNS data. DS is a supplemental feature by which the signing authority can delegate trust to the public keys of third parties. | DNSSEC specifically refers to the core digital signature mechanisms used to validate secure DNS records. Three of its RRs, DNSKEY, RRSIG and NSEC work together to establish the authenticity and integrity of DNS data. DS is a supplemental feature by which the signing authority can delegate trust to the public keys of third parties. | ||
TSIG and TKEY are mechanisms that can be used with, or independently of, DNSSEC | TSIG and TKEY are mechanisms that can be used with, or independently of, DNSSEC; they are intended to be used for the specific function of authenticating TSIG here defines a function of transaction authentication; the original TSIG RR mechanism uses secret keys and is more expensive to implement than its descendant, SIG(0), which uses public keys but a smaller set of functionality than | ||
DNSSEC is limited to providing origin authentication (i.e., the record provided is authentic, or, if DNSSEC returns a null response, the record does not exist). | DNSSEC is limited to providing origin authentication (i.e., the record provided is authentic, or, if DNSSEC returns a null response, the record does not exist). | ||
Line 71: | Line 72: | ||
None of these mechanisms secure the request, as opposed to the response. If that is needed, use IPSec authentication. They do not secure the message headers, or the response in its entirety. | None of these mechanisms secure the request, as opposed to the response. If that is needed, use IPSec authentication. They do not secure the message headers, or the response in its entirety. | ||
===Resource Records for TSIG/SIG(0)=== | ===Resource Records for TSIG/SIG(0)=== | ||
TSIG differs from the new DNSSEC function in being based on symmetric, and presumably preshared, session keys, rather than asymmetric public keys. TKEY sets up the key; SIG(0) authenticates the exchange. | |||
{| class="wikitable" | {| class="wikitable" | ||
Line 84: | Line 85: | ||
| Signature | | Signature | ||
| authenticates an RRset [RFC 2181] of a particular type, class, and name and binds it to a time interval and the signer's domain name | | authenticates an RRset [RFC 2181] of a particular type, class, and name and binds it to a time interval and the signer's domain name | ||
| A | | A digital certificate containing a signature | ||
|- | |- | ||
|} | |} | ||
Line 116: | Line 117: | ||
| Resource Record Signature | | Resource Record Signature | ||
| Carries a digital signature for the Resource Record set (RRset) being transferred | | Carries a digital signature for the Resource Record set (RRset) being transferred | ||
| A | | A digital certificate containing the signature | ||
| SIG, except that SIG is still used for SIG(0) | | SIG, except that SIG is still used for SIG(0) | ||
|- | |- | ||
Line 141: | Line 142: | ||
DNS itself is hierarchical, and DNSSEC follows its hierarchy. This means that a problem at one level of zone propagates to the zones hierarchically below it. | DNS itself is hierarchical, and DNSSEC follows its hierarchy. This means that a problem at one level of zone propagates to the zones hierarchically below it. | ||
DNSSEC implementation will take significant programming skills, and not all error handling is well-defined in the specifications. | DNSSEC implementation will take significant programming skills, and not all error handling is well-defined in the specifications. #Key management issues|Expired keys and slight zone file configuration errors can cause significant problems for a DNSSEC-aware resolver, and the reporting and recover mechanisms may be inadequage. | ||
When DNSSEC is used, it will produce considerably more data than with conventional DNS. It could, therefore, provide even more amplification, so a | When DNSSEC is used, it will produce considerably more data than with conventional DNS. It could, therefore, provide even more amplification, so a denial of service attack aimed at DNS servers than with conventional DNS. | ||
A DNSSEC-aware resolver has to do much more processing, both for basic signature validation and for additional queries that may be required. With non-DNSSEC aware resolvers today, there is already a problem with timeouts and unneeded queries. This was deemed more of a general DNS operations problem than a DNSSEC-specific problem. | A DNSSEC-aware resolver has to do much more processing, both for basic signature validation and for additional queries that may be required. With non-DNSSEC aware resolvers today, there is already a problem with timeouts and unneeded queries. This was deemed more of a general DNS operations problem than a DNSSEC-specific problem. | ||
Line 152: | Line 153: | ||
====Key management issues==== | ====Key management issues==== | ||
Key rollover at the root remains unsolved. There is no agreement even how to configure it. | Key rollover at the root remains unsolved. There is no agreement even how to configure it. | ||
==Mandates== | ==Mandates== | ||
The U.S. government is requiring DNSSEC for all Federal information systems by December 2009.<ref name=OMB-DNSSEC>{{citation | The U.S. government is requiring DNSSEC for all Federal information systems by December 2009.<ref name=OMB-DNSSEC>{{citation | ||
Line 160: | Line 162: | ||
==Implementation guidance== | ==Implementation guidance== | ||
The European | The European address registry, RIPE, has been presenting excellent training on DNSSEC.<ref name=RIPENCC-DNSSEC /> | ||
==References== | ==References== | ||
{{reflist|2}} | {{reflist|2}} |
Revision as of 16:22, 30 March 2024
This article may be deleted soon. | ||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
This is a draft for which collaboration would be very, very appreciated. See talk page for some of the problem areas DNS, as a critical part of the Internet infrastructure, needs to be protected. There have been, and continue to be, serious attacks against it. DNS is becoming more, not less, critical as it becomes involved in more functions than the name-to-address mapping for which it was designed. Internet Protocol version 6 address management demands dynamic DNS update even more than did IPv4 dynamic addressing, but DNS security features are needed to secure the updates. With convergence of communications involving telephone number mapping to Internet names and numbers (e.g., IETF ENUM), DNS is critical in other areas. Another aspect of Internet Protocol version 6 deployment may be increased use of IPsec, which, in turn, needs a secure DNS as a trusted repository for public keys and certificate revocations. DNS software and operations should follow the overall DNS security architecture (DNSSEC).[1] Image:Security scope.png|thumb|left|DNS security scope Threats to DNSDomain Name System security (DNSSEC) is intended to solve, or mitigate, known security threats to the Domain Name System. [2] The image, "Conceptual points of vulnerability in DNS" identifies some of the places where threats exist, and for which defensive methods exist, or are in active research. In the figure "Conceptual points of vulnerability", you will see that the backgrounds are shaded differently for "Server Security Issues" and "Data Protection Issues". These are one of several ways of breaking out the threat. Image:Points of DNS Vulnerability.png|thumb|Conceptual points of vulnerability in DNS Another threat model starts with some basic assumptions.[3] An IETF working group on DNS Security started in 1993. It produced the broad outlines from which DNSSEC would emerge, DNSSEC being a combination of threat analysis and countermeasures to those threats. First, some basic assumptions were made.
DNS data can be spoofed and corrupted between master server and resolver or forwarder The DNS protocol does not allow you to check the validity of DNS data Exploited by bugs in resolver implementation (predictable transaction ID) Polluted caching forwarders can cause harm for quite some time (TTL) Corrupted DNS data might end up in caches and stay there for a long time How does a slave (secondary) knows it is talking to the proper master (primary)? [8] Threats to the Zone File1a deals with the problem of a miscreant breaking into the trusted machine, inside the organization, on which the zone file is created, and altering it before it is transferred to the master server. 1b considers both modification to a valid zone file being transferred, as well as a hostile server misrepresenting itself to the primary DNS server as a valid source of zone information. It is understood that especially in small installations, the DNS zone file creation and primary server are on the same physical computer. This is really undesirable, for reasons beyond security: a primary DNS server is a critical resource, and, for greatest reliability, should run only the minimal DNS and support software. While an administrator is creating a zone file, there are any number of valid reasons why that person might want to access a Web or other public resource, such as the request for comment archive or a root server file. Every time that administrator's machine exposes itself to the public Internet, it opens a potential channel to attack the DNS primary server and all that depends on it. 2a and 2b deal with zone file attacks at sites external to the domain. Masquerade as the Master3 is related to the 2 threats in that it involves as DNS server-to-server zone transfer, but inside the organization. A type 3 attack may come from an internal miscreant, who might not need to penetrate firewalls and strong authentication required for an outside domain. Slave servers also are vulnerable to attacks that corrupt their copy of the zone file. Fake dynamic updates4 covers both stateful and stateless sources of updates. When dynamic updates come only from a Dynamic Host Configuration Protocol(DHCP) server, there can be substantial administrative and technical controls on the DHCP server, whether it is DHCP for Internet Protocol version 4 or Internet Protocol version 6. The situation becomes much more complex when IPv6 stateless address autoconfiguration (SLAAC) is deployed, and any host has a legitimate reason to send a dynamic update into DNS. Cache attacksAt 5, a caching-only server may masquerade as the real server to the client, and poison the resolver's cache. Security implementationDNSSEC specifically refers to the core digital signature mechanisms used to validate secure DNS records. Three of its RRs, DNSKEY, RRSIG and NSEC work together to establish the authenticity and integrity of DNS data. DS is a supplemental feature by which the signing authority can delegate trust to the public keys of third parties. TSIG and TKEY are mechanisms that can be used with, or independently of, DNSSEC; they are intended to be used for the specific function of authenticating TSIG here defines a function of transaction authentication; the original TSIG RR mechanism uses secret keys and is more expensive to implement than its descendant, SIG(0), which uses public keys but a smaller set of functionality than DNSSEC is limited to providing origin authentication (i.e., the record provided is authentic, or, if DNSSEC returns a null response, the record does not exist). None of these mechanisms secure the request, as opposed to the response. If that is needed, use IPSec authentication. They do not secure the message headers, or the response in its entirety. Resource Records for TSIG/SIG(0)TSIG differs from the new DNSSEC function in being based on symmetric, and presumably preshared, session keys, rather than asymmetric public keys. TKEY sets up the key; SIG(0) authenticates the exchange.
Newest Resource Records for DNSSECDNSSEC requires several new Resource Records,[9] as well as some changes to the DNS header flag and a "pseudo-RR", which is a workaround to the standard limitation of DNS datagrams to 512 bytes, so longer keys and other cryptographic information can be passed. An otherwise obsolete RFC makes it clear which old types are replaced or not. [10]
Known issues with DNSSECDNS itself is hierarchical, and DNSSEC follows its hierarchy. This means that a problem at one level of zone propagates to the zones hierarchically below it. DNSSEC implementation will take significant programming skills, and not all error handling is well-defined in the specifications. #Key management issues|Expired keys and slight zone file configuration errors can cause significant problems for a DNSSEC-aware resolver, and the reporting and recover mechanisms may be inadequage. When DNSSEC is used, it will produce considerably more data than with conventional DNS. It could, therefore, provide even more amplification, so a denial of service attack aimed at DNS servers than with conventional DNS. A DNSSEC-aware resolver has to do much more processing, both for basic signature validation and for additional queries that may be required. With non-DNSSEC aware resolvers today, there is already a problem with timeouts and unneeded queries. This was deemed more of a general DNS operations problem than a DNSSEC-specific problem. Authenticated denial becomes considerably more complex due to the existence of DNS wildcards. [11] While not supporting wildcards in DNSSEC was considered, the IETF consensus was that wildcards are operationally necessary. Authenticated denial, therefore, may be fragile. Time synchronization issuesBefore DNSSEC, DNS could operate using "relative" or "elapsed" time. Since DNSSEC signature validity is based on "absolute" time, DNSSEC requires at least loose time synchronization between the resolver and the signing entity. Without it, the resolver may accept expired signatures. If the signer does not have a trusted time reference, a miscreant that can feed inaccurate time to the signer can cause it to sign things valid for a period different than it intended to have valid. Key management issuesKey rollover at the root remains unsolved. There is no agreement even how to configure it. MandatesThe U.S. government is requiring DNSSEC for all Federal information systems by December 2009.[12] The requirement, however, is essentially limited to signing the agency roots. Implementation guidanceThe European address registry, RIPE, has been presenting excellent training on DNSSEC.[8] References
|