perfsecurity perfsecurity DNS toggleNavRMABtn XXX Toggle navigation buttons on off. ToggleRMABtnClicked courseMapBtn Course Map Main Menu, Select this button to access the course menu. MainMenuButtonClicked lessonMapBtn Lesson Map Lesson Map, Select this button to access the lesson map. CourseMapButtonClicked glossaryBtn Glossary Glossary, Select this button to open the glossary. GlossaryButtonClicked resourcesBtn Resources Resources, Select this button to access the resources for the course. ResourcesButtonClicked exitBtn Exit Exit, Select this button to exit the course. ExitButtonClicked replayBtn Replay Replay, Select this button to replay the current screen. ReplayButtonClicked pauseBtn Pause Pause, Select this button to pause the course. PauseButtonClicked resumeBtn Resume Resume, Select this button to resume the course. ResumeButtonClicked previousPgBtn Previous. Select this button to go to the previous screen. PreviousButtonClicked nextPgBtn Next. Select this button to go to the next screen. NextButtonClicked dnsmtg_01 1 As a Systems Administrator working with the DNS, you have to understand DNS performance and security concepts and methods. In this lesson, you will identify DNS security vulnerabilities, as well as important DNS key concepts. You will also identify how Transaction Authentication and DNSSEC are used to secure DNS, and be introduced to DNSSEC troubleshooting tools. Finally, you will identify upcoming changes to DNS within the DoD. This lesson has eight topics, and should take approximately 60 minutes to complete. dnsmtg_02 2 Imagine a user is sending an email with important information and attachments to another user. However, the user's email server is misdirected by maliciously inserted DNS information, and the email goes to an attacker instead. Or consider another user, asked by her manager to do job-related research, attempting to reach a known website, only to be mis-directed to a fraudulent, and inappropriate, website. These scenarios highlight some of the security vulnerabilities inherent to DNS. In this lesson, you will explore those vulnerabilities and the options at your disposal for preventing them from occurring. dnsmtg_03 3 dnsmtg_04 4 Unlike TCP, a UDP-based network does not have a way of verifying the source of a DNS packet. So, as a UDP-based service, DNS is vulnerable to several different types of attacks, including foundation, denial-of-service, cache poisoning, and packet interception. Data replacement, or spoofing, is a variation of packet interception. Other variations include: Name denial, Name chaining, and Intentional crashing. Select each type of DNS attack to see how each is carried out. dnsmtg_04_01 Foundation attacks target the operating system of an authoritative server on which the DNS runs, and prevent the server from responding to requests effectively. Attacks can be carried out over the network or locally on the authoritative server itself. dnsmtg_04_02 Denial-of-service attacks flood DNS servers with requests and responses. As a result, network servers are overloaded and cannot resolve legitimate requests. This means that users entering legitimate requests do not get replies. dnsmtg_04_03 Cache-poisoning attacks place incorrect data in the cache of a recursive server. When network resources request data from that server, the server checks its cache and responds with the bad data. The bad data gets cached again by servers and clients. In this way, the bad data is perpetuated throughout the DNS. Users see the impact of cache-poisoning when they enter a URL, but then find themselves connected to an unintended website. dnsmtg_04_04 dnsmtg_05 5 Knowledge Check 1 500 425 Dummy question text? Response 1. Response 2. Response 3. Response 4. Correct feedback. Incorrect feedback. Now check your knowledge of these types of attacks. dnsmtg_06 6 Now that you understand the ways that attacks can be conducted against DNS, consider how DNS can be protected to ensure the integrity and availability of DNS information. There are two primary mechanisms that protect DNS by providing cryptographic enhancements: Transaction authentication, or TSIG, which enables point-to-point security usually on a local network, and DNSSEC, which provides end-to-end security for DNS information in transit or in storage. Together, TSIG and DNSSEC can help ensure the integrity of DNS information, and can reduce the effectiveness of some denial-of-service attacks. However, foundation attacks or brute force denial-of-service attacks that affect DNS servers and their supporting networks are still a concern, and must be addressed using other measures, including patch updates and network monitoring. Next, we will learn about fundamental concepts of DNS cryptographic key management that apply to both TSIG and DNSSEC. dnsmtg_07 7 In order to understand DNS key management in the DoD environment, it is important to discuss basic concepts about DNS keys. These concepts include: Cryptography, and Key supersession. Select each concept to learn about it. dnsmtg_07_01 DNS keys are generated using two types of cryptography: symmetric and asymmetric. Symmetric cryptography, also known as secret key cryptography, involves using the same key for decrypting and encrypting messages. Both the sender and receiver would have to know the secret key beforehand, and it would have to be sent along with the message. Asymmetric cryptography, or public key encryption, involves encrypting a message with a recipient's public key, and decrypting the message with a recipient's private key. You can use the PO Box system as a metaphor for understanding asymmetric cryptography. The receiver has a mailbox with a slot for inserting mail. The address of the mailbox is like a public key. Anyone can look up the receiver's address and send a message to that address. However, to access the message, the receiver must use his or her own private key. Examples of asymmetric algorithms that are used to generate public and private key pairs, are the Rivest Shamir Adelman, or RSA algorithm, and the Digital Signature Algorithm, or DSA. dnsmtg_07_02 Each key or key pair is valid for a time period, and is then superseded by a new key or key pair. This process is referred to as key supersession. In symmetric key supersession, there is no overlap between the effectivity periods of new and previous keys. Symmetric key supersession requires that rollovers are synchronized from one key to the next by all key users. In asymmetric key supersession, there is an overlap between the effectivity periods of new and previous key pairs. More than one key can be valid at any point in time. dnsmtg_08 8 The level of DNS security is set by key attributes including: The algorithm that accepts the key as input. The strength of the algorithm affects how secure the overall system may be. The length of the key. Key length affects the strength of the key since longer bit length improves security. Key usage. How the key is used can affect its level of security. All DNS keys are used to sign and authenticate data. However, DNS key security may vary based on role and placement in the DNS hierarchy. The key effectivity period. Each cryptographic key is associated with a time period, during which that key is in use and effective, called an effectivity period. Generally, a shorter effectivity period increases the level of security provided by a key. For example, a key that is more exposed, or that uses a weaker algorithm, can be partially protected by setting a shorter effectivity period, and superseding keys more often. Authorization requirements. Security can be improved by limiting access to the key to authorized users and by using it only for its intended purpose. Finally, key format. DNS keys are stored in a clear readable format, and can easily be read by a user, program, or attacker that can access the file system. For this reason, it is important to ensure that DNS private keys or shared secret keys are protected in storage and whenever they are transmitted. Roll your cursor over each attribute for a detailed review. dnsmtg_09 9 DNS key management is the process of establishing and maintaining secure keys. DNS key management involves a combination of technical controls, which include hardware and security solutions, physical controls, which include facility security and physical access controls, and procedural controls, which include required human interactions. Roll your cursor over each control to see some examples. dnsmtg_10 10 Transaction authentication, referred to as TSIG, is a method of securing communication between servers using a message authentication code. The name TSIG comes from Transaction Signatures, an older name for the method. The message authentication code is generated using a shared secret key, a time stamp, and a one-way hash algorithm. A one-way hash algorithm produces an output that is unique for a given input, and cannot be turned back into the input. This is why it is referred to as one way. The resulting Hashed Message Authentication Code, or HMAC, gets its name from the hash algorithm in use. Current HMAC methods for DoD are either HMAC-SHA1 or HMAC-SHA256, where SHA stands for Secure Hash Algorithm. By having the same key on different servers, they can communicate securely to the extent that the servers trust each other. The life cycle of a TSIG key begins with generating the key. Then the key is distributed and loaded. When it is time to generate a new key, the current key is expired and deleted at the same time that the new key is loaded. This leaves no overlap period. This process continues. Note that the keys themselves do not contain any information about their effectivity period. The effectivity period must be set and tracked by administrators based on policy. Refer to the DNS STIG for more information about supersession and effectivity. dnsmtg_11 11 To configure TSIG between two servers, you must first use the command dnssec-keygen to generate the TSIG key for the pair. This is normally done on the master server. This will output two files, a .private file and a .key file. The format of the files differs slightly, but each contains the base64-encoded random number that will be used as the shared secret. Second, you must load the key on the master server. For BIND, this should normally be done using an include statement and a separate key file, but can also be done by directly inserting the key statement. Next, securely copy the key to the slave server. Methods for accomplishing this in a suitably secure way include Secure Shell, or SSH; DoD PKI, or Public Key Infrastructure, Encrypted Email; or Secure Fax. See the DNS STIG for details and requirements. Finally, insert the key statement on the slave server. Again, this can be done with an include statement or directly. Transaction Authentication is now in place between the servers, and communications will be verified through the shared secret. For security purposes, it is recommended that you maintain the list of secret keys in a file other than named.conf, such as /etc/bind/shared.keys, and make it readable only by root, or the system account used by the DNS server process, if applicable. There are specific guidelines for generating and storing TSIG keys. Select Guidelines, dnssec-keygen, and both $INCLUDE statements for a detailed review. dnsmtg_11_01 TSIG should use the second generation Secure Hash Algorithms, SHA224 or higher, unless SHA-1 is required for interoperability. Please review the current STIG for guidance. Note that SHA256 is broken on certain BIND9 implementations but both longer and shorter keys will work. TSIG keys are a shared secret that is stored online. Thus, the key can be generated online. TSIG keys do not have an overlap or rollover period. Only one TSIG key is effective at a time for a pair, or a larger set, of communicating systems. The DNS STIG requires one TSIG key per pair of systems, although waivers may be possible for specific situations with larger numbers of peer servers. For effective use of TSIG keys, good time synchronization, or Network Time Protocol, also known as NTP, is also necessary. TSIG key supersession should be done at least once a year, according to the DNS STIG, requirement DNS0445. dnsmtg_11_02 Dnssec-keygen is a key generation tool that can be used to generate keys for TSIG and DNSSEC. Each key, or key pair, will be stored in a file whose name includes a three-digit identifier for the algorithm, and a four or five-digit ID that is specific to that key, to aid system administrators in key management. The syntax of the code includes multiple flags. Roll your cursor over the underlined flags to read a detailed description. dnsmtg_11_03 For BIND 9, use an include statement to insert the TSIG key into the master name server's named.conf file. Specify that the TSIG key should be used when communicating with the slave server, allowing the slave to authenticate NOTIFY messages sent after changes to the master zone. Be sure to include allow-transfer in the statement. The format of the included file, which is named /etc/bind/shared.keys in this example, is exactly the same format as if the key statement was a regular part of the named.conf file. dnsmtg_11_04 dnsmtg_12 12 Generic Security Services or GSS TSIG, is an alternate version of the TSIG protocol implemented in Windows and some third-party software. GSS TSIG takes advantage of existing trust relationships for computers in a Windows domain. Consult your vendor documentation or the DNS STIG for more information. dnsmtg_13 13 dnsmtg_13_01 dnsmtg_13_02 Four resource record types added by DNSSEC are: DNSKEY, which carries the public key; RRSIG, which carries the signature of the DNS information; DS, which carries the signed hash of the key; and NSEC, which signs any gaps to assure the non-existence of a resource or domain name. dnsmtg_14 14 Knowledge Check 1 530 425 Origin authenticity means that the data sent is the same as the data received. True False Correct. Origin authenticity ensures that data is received from a zone's authoritative server. Incorrect. Origin authenticity ensures that data is received from a zone's authoritative server. Data integrity means that data is received from a zone’s actual authoritative server. True False Correct. Data integrity means that data received is the same as data sent. Incorrect. Data integrity means that data received is the same as data sent. Symmetric cryptography uses one key to encrypt and decrypt messages, whereas asymmetric uses one public and one private key. True False Correct. Symmetric cryptography a secret key shared by the sender and receiver. Asymmetric cryptography involves encrypting a message with a sender's public key and decrypting it with the receiver's private key. Incorrect. Symmetric cryptography a secret key shared by the sender and receiver. Asymmetric cryptography involves encrypting a message with a sender's public key and decrypting it with the receiver's private key. As a UDP-based network, DNS enables source verification. True False Correct. DNS is a UDP-based network, which does not enable source verification. Incorrect. DNS is a UDP-based network, which does not enable source verification. Now check your knowledge of DNSSEC. Select True or False for each statement. Select Done when you have answered all four statements. dnsmtg_15 15 DNSSEC works by providing the DNS data hierarchy with a logically consistent security hierarchy. DNSSEC uses public-private key pairs with specific public keys configured on recursive servers to create secure entry points into the hierarchy. The key pairs, combined with data signature records, called RRSigs, and Delegation Signer or DS records, establish a chain of trust down the DNS data hierarchy. DNSSEC key pairs fall into two categories: key signing keys, KSKs, or zone signing keys, or ZSKs. KSKs are used to sign keys pointed to by the DS record in the parent zone. The DS record identifies the KSK for the child zone, by pointing to a hash of its value, which is stored at the parent. The parent zone signs the DS record, providing a secure pointer to the child. This parallels the name server delegation record, in regular DNS. ZSKs are used to sign all zone data. For both types of keys, the private part of the key pair is securely stored on a signature generation system that is separate from the DNS servers. The public part of the key pair is published, and used to verify that signatures created with the corresponding private key are authentic. Roll your cursor over public, private, KSKs, and ZSKs to review their definitions. Select Key Pair to learn more about time-based parameters of DNSSEC keys. dnsmtg_15_01 DNSSEC key pairs have certain time-based parameters, including: Key effectivity period, Signature validity period, and TTL. The key effectivity period is the time span during which a particular DNSSEC key is in effect. The keys themselves, as with TSIG keys, do not contain any information about their effectivity period-the effectivity period must be set and tracked by administrators based on policy. If the effectivity period is too long, the keys are more susceptible to certain cryptographic attacks, because of additional plain text and cipher text examples. Also, administrators may lose proficiency with key supersession and rollovers if the key effectivity period is too long. On the other hand, if the key effectivity period is too short, additional resources (for example, time, manual effort, and CPU power) are required for generating keys more frequently. The signature validity period is the time span during which the signature or RRSIG corresponding to a particular research record is valid. Because DNSSEC keys cannot be revoked, the signature validity period should be no more than a matter of days, and significantly shorter than the key effectivity period. The time to live, or TTL, is the time span during which a resolver is encouraged to cache DNS data. Resolvers are not required to abide by the TTL provided by the authoritative server. dnsmtg_16 16 Like the guidelines for generating and storing TSIG keys, there are also guidelines for DNSSEC keys. For DNSSEC public-private key pairs, the supported algorithms include RSAMD5, RSASHA1, and DSA. RSASHA1 is currently recommended for DoD usage, as it provides the best combination of interoperability and security. Per Special Publication, or SP, 800-81, National Institute of Standards and Technology, or NIST, has deemed 1024-bit RSA-SHA1 keys acceptable for ZSK use, and 2048-bit RSA-SHA1 keys acceptable for KSK use. By 2010, you can expect both KSK and ZSK keys required to be 2048-bit RSA-SHA256, or DSA-SHA256. However, this standard will first require changes to the Internet Engineering Task Force, or IETF, specifications and software. DNSKEYs should be generated offline, in a system separate from the DNS sever. The private key for each key signing key pair should never be brought online, for security reasons. The private key for each zone signing key pair should only be brought online if specifically required for operational reasons, such as to support a signed zone with dynamic update capability. During the generation process for KSKs, each KSK pair should have the flag set so that the public key can be used as a Secure Entry Point, even if the keys will not be used as such. Configuring KSKs as secure entry points helps administrators differentiate between KSKs and ZSKs. However, because key effectivity periods are set only by policy and not by any key properties, the recommended practice is to maintain a separate electronic or paper log to track all KSKs and ZSKs. In line with the standard recommendation, key signing keys should be rolled over approximately every 30 days, while zone signing keys should be rolled over at least once a year. The signature validity period is the time span during which the signature, or RRSIG, corresponding to a particular resource record is valid. Use the pre-publish method for placing the next ZSK into the zone file. This best practice will reduce the zone size, bandwidth, and signing time, while maintaining security. However, do not sign the zone with a pre-published key. Use the double-signing method during the overlap period to sign a zone with both the KSK about to expire and the new KSK. The KSK overlap period should normally be one signature validity period, or slightly longer. Select Pre Publish method for a detailed description of the process. dnsmtg_16_01 Pre-publishing the zone signing key means including the public part of the key pair in the zone file but not using the private half of the ZSK pair to sign the zone. The zone is signed with the current effective ZSK, and both the current ZSK and the pre-published ZSKs are signed with the current KSK. For example, ZSK 1 is generated and published. About five days prior to its expiration date, the next ZSK is generated and published. Once ZSK 2 has been generated and published, ZSK 1 is deleted. The effectivity period for ZSK 2 begins at this point, and lasts for about 30 days. This cycle repeats for subsequent zone signing keys. This method allows the establishment of trust for the new ZSK at the time that it first becomes effective for signing the zone. dnsmtg_17 17 While establishing a chain of trust between zones on the DNS, there are certain problem areas with DNSSEC, which can lead to failure. Public key signatures, which are part of DNSSEC, possess an expiration date. Once they expire, resolvers are unable to validate the zone's data. Problems can also occur around the use of trust anchors, which may be referred to as Secure Entry Point, or SEP, keys. Changing a trust anchor in any way, in the zone that it represents, can affect a resolver's ability to validate incoming data. A key rollover, or supersession, does not normally require changes to DNSSEC-aware recursive resolvers. The new keys are published in the zone and handled dynamically. However, since Secure Entry Point keys are statically configured, the resolvers require action to update. If the Secure Entry Point keys are not updated in resolvers, then signatures cannot be validated, and DNSSEC will produce error conditions. If Secure Entry Point keys are deleted, validation problems may occur. The administrator may misconfigure the resolver, which would lead to problems with signature validation. While a DNS response is in transit on the network, an attacker can modify the response. DNS split views pose a special problem regarding validation of signatures. Select each failure mode to see how it occurs. Roll your cursor over Definition to see a description of Trust Anchors. dnsmtg_17_01 The administrator of a DNS zone specifies an expiration time for a DNS signature. If the administrator does not refresh the signatures before the expiration time, the signatures become invalid, and resolvers will not be able to use the expired signatures to validate the zone data. dnsmtg_17_02 Currently, there are dozens of major domains that are signed with DNSSEC, but most of those domains are not part of a contiguous hierarchy. To enable DNSSEC validation at the enclave level, a public key for each signed zone to be validated must be configured in each recursive server. The process required to use multiple keys for configuring zone validation is time-consuming and error-prone. It requires keeping multiple trust anchors, on multiple recursive servers, in synchronization with the corresponding zones. To avoid having multiple keys to configure for zone validation, a better approach for ensuring a secure hierarchy, is to sign the root zone and all top-level domains. In the much longer term, vendors must update all DNS clients to be DNSSEC-aware, and capable of validation at the desktop level. Administrators must configure the root zone keys at each DNS client. dnsmtg_17_03 If a resolver that has been configured with trust anchors is not updated following rollovers of Secure Entry Point keys within the zone, the old trust anchors will not be able to validate signatures generated by the new secure entry point keys. dnsmtg_17_04 If a zone administrator deletes the secure entry point KSKs that are configured as trust anchors in resolvers, then there would be no new signatures on the ZSKs to validate. Any existing signatures could not be validated, breaking the chain of trust, and the resolver would consider the zone invalid. dnsmtg_17_05 An administrator might misconfigure a resolver. For example, if the administrator makes a typographical error while entering the trust anchor, then the zone will be considered invalid. Or, for example, if the administrator does not fully enable DNSSEC support in the resolver, then the resolver cannot validate the signatures. dnsmtg_17_06 If an attacker attempts to maliciously modify a response while DNS responses are in transit on the network, the modification attack will fail if the attacker does not have the private key that created the signatures on the response. However, an attacker can still create denial-of-service errors if the resolver cannot get good data. If the attacker does have the private key, there are larger security issues and the zone administrator must react to the key compromise. dnsmtg_17_07 DNS split views are situations where multiple legitimate responses are possible for a DNS query, depending on the origination point of the query. Split views can be avoided in many cases through the use of a split name space or zone cut; however, the existence of firewalls and Network Address Translation, or NAT, make DNSSEC split views a fact of life that remains a consideration. In order for DNSSEC to be deployed in split-view environments, the two technologies must co-exist. Split-view DNSSEC can be realized through proper query channeling and trust anchor selection. However, unless the resolver and nameserver configurations are carefully controlled, it is very easy to introduce errors in this setup. dnsmtg_18 18 Knowledge Check 1 650 425 Old trust anchors are not able to validate signatures generated by new Secure Entry Point keys. Signature expiration Trust anchors Secure Entry Point key rollover Secure Entry Point deletion Resolver misconfiguration Malicious modification DNS split views Correct. If a resolver is not updated with Secure Entry Point rollovers, the old trust anchors cannot validate signatures generated by new SEP keys. Incorrect. If a resolver is not updated with Secure Entry Point rollovers, the old trust anchors cannot validate signatures generated by new SEP keys. The zone administrator does not refresh signatures before their expiration time. Signature expiration Trust anchors Secure Entry Point key rollover Secure Entry Point deletion Resolver misconfiguration Malicious modification DNS split views Correct. Signature expiration can be a mode of DNS failure if a zone administrator does not refresh signatures on time. Incorrect. Signature expiration can be a mode of DNS failure if a zone administrator does not refresh signatures on time. More than one legitimate response is possible for a DNS query. Signature expiration Trust anchors Secure Entry Point key rollover Secure Entry Point deletion Resolver misconfiguration Malicious modification DNS split views Correct. DNS split views are situations where more than one correct answer is possible for a query. Incorrect. DNS split views are situations where more than one correct answer is possible for a query. The information received is different from the information sent. Signature expiration Trust anchors Secure Entry Point key rollover Secure Entry Point deletion Resolver misconfiguration Malicious modification DNS split views Correct. Malicious modification occurs when an attacker attempts to modify a DNS response that is in transit on the network. Incorrect. Malicious modification occurs when an attacker attempts to modify a DNS response that is in transit on the network. The zone administrator does not fully enable DNSSEC support, and the resolver cannot validate signatures. Signature expiration Trust anchors Secure Entry Point key rollover Secure Entry Point deletion Resolver misconfiguration Malicious modification DNS split views Correct. Resolver misconfiguration can be a DNS failure mode if a zone administrator does not fully enable DNSSEC support. Incorrect. Resolver misconfiguration can be a DNS failure mode if a zone administrator does not fully enable DNSSEC support. There are no signatures to validate, and the resolver considers the zone invalid. Signature expiration Trust anchors Secure Entry Point key rollover Secure Entry Point deletion Resolver misconfiguration Malicious modification DNS split views Correct. If a zone administrator deletes the secure entry point keys, there would be no signatures to validate, and the resolvers would consider the zone invalid. Incorrect. If a zone administrator deletes the secure entry point keys, there would be no signatures to validate, and the resolvers would consider the zone invalid. Now check your knowledge about DNS failure modes. dnsmtg_19 19 Setting up a secure zone is a multi-part process that requires significant coordination around DNSSEC activities, and specific measures with regard to logging and monitoring on the server and other network devices. Setting up a secure zone also entails validating DNSSEC signed data, and attending to other issues such as the new need for periodic updates of zones even when the ordinary DNS data in the zone has not changed. Select each area of activity to learn more about it. dnsmtg_19_04 Ensure that the security-aware caching resolver, or recursive server, is configured with one or more Secure Entry Points. For the near term, expect to use at least .mil and .gov, with a transition to a signed root at some future date. Additional logging may be required to help troubleshoot the validation of DNSSEC signed data. Currently there is no easy knob-to-twist during this transition period. Any validation failure causes data to be rejected, and clients to receive errors such as no such domain. Additional logging on the recursive servers helps ensure that errors can be localized and details can be obtained for effective troubleshooting. The initial DoD deployment of DNSSEC is focused on getting data signed. DNS system administrators should ensure that they fully understand the implications of DNSSEC validation. Administrators should also ensure the data-signing process is tested and well understood by administrators before enabling it on production networks. dnsmtg_19_02 Before DNSSEC, once a zone was delegated, communication with the child or parent zones typically only occurred when a name server record needed to be changed. With DNSSEC, zone signing requires regular coordination with child and parent DNS administrators to exchange DS records. Given RRSIG validity periods of 2 to 7 days, you can expect zone signing to be done once per workday, where the number of workdays would be 5 to 7 days a week, depending on the local situation. dnsmtg_19_03 Authoritative servers require minimal additional configuration. As long as the servers are DNSSEC-capable, the additional records are simply more records. Logging and monitoring on both the server and other network devices may require additional attention. DNSSEC causes larger UDP packets, which are more likely to cause packet fragmentation or run into Path MTU limits. Ensure that 53/TCP works as well as 53/UDP. TCP is not just for zone transfer. DNSSEC makes it more likely for DNS to fall back to TCP connections. Roll your cursor over Path MTU to review its description. dnsmtg_19_05 DNSSEC brings on new needs, which require changes to business processes and resources. These include: The need for periodic updates, or re-signing, of zones even when the real data has not changed. The new need for frequent coordination between DNS parent and child zone administrators. The changes to the model of DNS trust, that is, while data integrity improves, there are new forms of fragility or breakage, and more difficult troubleshooting with limited reporting of DNSSEC related errors. dnsmtg_19_01 Setting up a secure zone is a multi-part zone-signing process, which begins with ensuring that the zone is up-to-date. You must update the DS record information for secured child zones, make any other changes as required, and always update the serial number before signing and re-signing the zone, even if no zone data has changed. Updating the serial number ensures that the slave will properly load the new signatures. Once you ensure that the zone is up-to-date, you generate new keys, as required, and then use key signing keys to generate RRSIGs for the zone signing keys. Then you use the current effective zone signing key to generate RRSIGs for all other zone data. Finally, you pass the new key signing key and DS information to the parent zone for the next update. dnsmtg_20 20 Dig has a few switches that are useful in troubleshooting DNSSEC setups. + multiline structures the output of dig to be easily readable. Additionally, the keyid will be printed as a comment behind the DNSKEY RRs. +cd sets the checking disabled bit on the query. This is useful if your validating recursive nameserver reports a servfail and you need to discover if this is due to DNSSEC marking the data as bad. +dnssec forces the server being queried to include the DNSSEC related data. You can use this in combination with the +cd switch to determine if data from a zone is signed at all or if you want to determine if the validity intervals on the signatures are correct. +trace traces the delegation chain. This option may be helpful if you are trying to figure out where the delegation points are. +sigchase traces the signature chain. You will also need to have a ./trusted-keys.keys or /etc/trusted-keys.keys available that contains trusted key entries. Roll your cursor over each switch to see a full definition. dnsmtg_21 21 Drill is a command line tool useful for querying and debugging DNSSEC setup. It can be downloaded from the ldns library at www.netlabs.nl/ldns. Drill has several options that can be used to debug DNS. Two in particular, -T and -S are helpful in troubleshooting. The -T switch follows the chain of trust from the root to the leaves and indicates the security status. The -S flag will chase the signatures from the leaf node back to the root, looking for the relevant records. Select Drill options to see a full list of drill options. dnsmtg_21_01 dnsmtg_22 22 In addition to drill, the ldns library offers other tools useful in troubleshooting DNSSEC. ldns-key2ds creates a DS record from a DNSKEY record. ldns-keyfetcher fetches DNSSEC public keys for zones. ldns-keygen generates private and public key pairs for DNSSEC. ldns-signzone signs a zone file according to DNSSECbis, and ldns-walk walks a DNSSEC zone. dnsmtg_23 23 Within the DoD, there are five major changes to the DNS that are already in progress, or will happen in the near future. Internet protocol version 6, or IPv6, will change the internet addressing format, increasing the use of DNS and causing additional record types to be used. The DNS .mil proxy system will be deployed between NIPRNet and the Internet. The .mil proxy will intercept all DNS queries from the Internet for NIPRNet information, and provide appropriate responses. This system will prevent external systems from directly contacting or attacking NIPRNet authoritative name servers. The DNS User Experience Monitor, or UEM, is planned for deployment on both SIPRNET and NIPRNET networks. This initiative aims to provide greater situational awareness of the DNS as a service. The Joint Task Force Global Network Operations has requested the deployment of a set of enterprise recursive servers, or ERS, to handle all internal DNS requests to external (Internet) DNS servers. This will provide useful new capabilities for Computer Network Defense. Finally, DNSSEC signing is being rolled out on the .mil hierarchy using the techniques already discussed, starting with the .mil zone itself and gradually including second-level zones and their children. Note that the use of DNSSEC signing tools is allowed and encouraged to help individual administrators adhere to DoD policies for securing zones. Since official DoD tools are not yet available, administrators may choose to refer to the web site dnssec-tools.org for more information about one set of available tools, but bear in mind that data and tools on this website do not reflect DoD policies. Select IPv6, DNS UEM, and ERS to learn more about their impact on the DoD. dnsmtg_23_01 Currently, the internet addressing protocol consists of a series of four sets of numbers that represent 32 bits of address data. Due to the explosion of internet applications and issues with network routing blocks, in the near future the IPv4 address space will be exhausted and will not be able to provide unique identifiers for each entity connected to the network. To address this, internet addressing is being converted to IPv6, a format that represents 128 bits of address data. An IPv6 address will be shown as 8 hexadecimal blocks, which are separated by colons. Each block contains 16 bits of IP address information. Note that blocks of information that contain only zeros can be replaced in a shortened version of the IP address with two adjacent colons. In order to support IPv6 addresses in newer software while maintaining IPv4 compatibility with existing software, the new quad-A record and ip6.arpa hierarchy have been added to DNS. Both of these are transparently supported by DNS security measures already discussed including TSIG and DNSSEC. Clearly, the change from a network that is almost entirely IPv4 to a network that uses IPv6 extensively will make DNS even more critical than it is today. The new IPv6 addresses will become even harder for individuals to remember, and address lookups will become a necessity. Roll your cursor over each format to see its capacity. dnsmtg_23_02 The DNS User Experience Monitor, or UEM, system is designed to collect and monitor DNS performance information from a set of sensor nodes strategically distributed throughout the network. The system is planned for deployment on both the NIPRNET and SIPRNET networks. Currently, users and administrators of DNS on both networks have few ways to monitor overall DNS performance from the user's perspective, relying instead on information about how many queries a particular server is answering at a point in time. UEM will address this issue by centralizing collection and display of performance and status information. Information will be both near-real-time and historical, and include the breadth of DNS service health data, such as connectivity, service availability, response time, and errors, as experienced by DNS clients. The DNS UEM system will help provide greater situational awareness of the DNS as a service, which would allow more rapid reaction to current problems, as well as enable proactive steps to preempt future ones. dnsmtg_23_03 The request by the Joint Task Force Global Network Operations to deploy a set of enterprise recursive servers, or ERS, is part of a larger effort by the DoD to address DNS security. The enterprise recursive servers will be responsible for processing outbound queries for DoD network clients to all external (Internet) DNS servers. Currently, recursion is allowed from any point inside NIPRNet to any point outside the DoD through port 53, making it nearly impossible to enforce a default-deny firewall policy. Putting a constellation of enterprise recursive servers in place will simplify the management of port 53 traffic through the firewalls. It will provide useful new capabilities for Computer Network Defense personnel to quickly restrict or redirect specific types of undesirable traffic related to malware, and also provide an easier path to DNSSEC validation of external data using the common set of enterprise servers. Roll your cursor over each term for a definition. dnsmtg_24 24 This lesson discussed security vulnerabilities, and techniques for securing DNS, such as DNSSEC and TSIG. It also identified key concepts in DNS Key Management, and upcoming changes to the DoD DNS environment. Select a topic to review what you have learned. For a more thorough review, select Lesson Map and select a topic. dnsmtg_24_03 dnsmtg_24_04 dnsmtg_24_05 dnsmtg_24_06 dnsmtg_24_01 dnsmtg_24_02 dnsmtg_25 25 Congratulations. You have completed the lesson on Maintaining DNS Performance and Security! You should now be able to identify: DNS security vulnerabilities, basic concepts of DNS keys, Transaction authentication strategies, How DNSSEC is used to secure DNS, DNSSEC troubleshooting tools and methods, and upcoming changes to the DoD environment and current DNS infrastructure.