perfsecurity perfsecurity DNS ../common/cw/assets/lsnMapPerfSecurity.swf toggleNavRMABtn XXX Toggle navigation buttons on off. ToggleRMABtnClicked courseMenuBtn Course Map Course Map MainMenuButtonClicked moduleMapBtn Lesson Map Lesson Map CourseMapButtonClicked glossaryBtn Glossary Glossary GlossaryButtonClicked resourcesBtn Resources Resources ResourcesButtonClicked exitBtn Exit Exit ExitButtonClicked replayBtn Replay Replay current screen ReplayButtonClicked pauseBtn Pause Pause audio PauseButtonClicked resumeBtn Resume Resume audio ResumeButtonClicked previousPgBtn Previous screen. PreviousButtonClicked nextPgBtn 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. Screen 1 of 25. Topic Title: Introduction. Screen Title: Objectives and Overview of Topics. Text appears at the bottom of all lesson screens Unclassified slash for Official Use Only. When you have completed this lesson, you will be able to identify appears, followed by bulleted lesson objectives in support of audio. An image labeled Maintaining D N S Performance and Security appears showing a simple three level hierarchy with one server at the top. Hierarchy and server image are enclosed in a ball. An image of a lightning bolt displays just outside the ball. Each objective is highlighted in synch with audio. In synch with audio, a list of eight topics appears. The list includes Introduction and Objectives, D N S Security Vulnerabilities, About D N S Keys, Transaction Authentication, D N S Sec D N S Seck troubleshooting Tools, Near term changes to D N S within D Oh D, and Summary and Conclusion. A digital clock appears displaying 1 hour. 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. Screen 2 of 25. Topic Title: Introduction. Screen Title: Overview. In support of audio, images appear of two laptops, a server, and another laptop highlighted in red. An animated data dot goes from one laptop to the server. The server turns red. An animated data dot goes from the server image to the red laptop image. In support of audio, the server and red laptop are removed, and replaced by a third laptop, which displays web site w w w dot r f c dot net. In support of audio, the laptop display changes to text Fraudulent web site, and fades back. The two other laptops are highlighted, and an image of a lock appears on both laptops. dnsmtg_03 3 The security of the DNS depends on a number of factors, including the diversity of server operating systems, and network topology. As a Systems Administrator, it's your responsibility to keep up-to-date on the DNS products you use, which may include BIND or products from Microsoft, Nominum, Infoblox, and other vendors. You have to be aware as well of new security features, and interoperability issues that can affect DNS. Screen 3 of 25. Topic Title: D N S Security Vulnerabilities. Screen Title: Diversity in Server and Network Topology. On a world map background, a three level D N S hierarchy appears with images of three servers and cache icons. Two bullets operating system diversity and network topology appear in support of audio. Animation of a news ticker scrolls text Microsoft, Nominum, Infoblox, I S C Bind. dnsmtg_04 4 Unlike TCP, a UDP-based service does not have a way of verifying the source of a DNS packet. As a primarily 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 on which an application or service runs, and prevent the server from responding to requests effectively. Attacks can be carried out over the network using TCP or UDP, or attacks can be conducted locally on the DNS server itself. It is important that DNS servers are maintained in a secure configuration at the operating system level, because many common attacks that compromise or disable parts of the operating system can undermine the DNS infrastructure in this way. Foundation attacksPopup 1 of 4: Popup Title: Foundation Attacks. Faded image of a large lightning bolt passing through a ball appears as background watermark. Image of a D N S hierarchy appears in a ball. Image of server labeled Oh S appears at the top of the hierarchy. Text labeled Method and Impact appears in support of audio. Lightning bolt image animates from outside to inside the ball near the server, and the server turns red. dnsmtg_04_02 Denial-of-service attacks flood DNS servers with requests and responses. As a result, DNS servers or their supporting networds are overloaded, and cannot resolve legitimate requests. This means that users entering legitimate requests do not get replies. Denial-of-service attacksPopup 2 of 4: Popup Title: Denial of Service Attacks. Faded image of a large lightning bolt passing through a ball appears as background watermark. Image of a three level D N S hierarchy appears in a ball. Two server images appear, one at the hierarchy top and one at the second level. Three laptop images appear at the third hierarchy level. Text labeled Method and Impact appears in support of audio. Red data dots animate from a laptop image at the third level of the hierarchy to the server at the hierarchy top, turning the server red. Image of a person appears at the third hierarchy level. 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 propagated throughout the DNS. Users see the impact of cache-poisoning when they enter a URL, but then find themselves connected to an unintended website. Cache-poisoning attacksPopup 3 of 4: Popup Title: Cache Poisoning Attacks. Faded image of a large lightning bolt passing through a ball appears as background watermark. Image of a three level D N S hierarchy appears in a ball. Two server images with cache icons appear, one at the hierarchy top and one at the second level. Three laptop images with cache icons appear at the third hierarchy level. Text labeled Method and Impact appears in support of audio. Animated lightning bolt pass through the ball to the top servers cache icon, and the cache icon is highlighted in red. An animated data dot goes from a laptop to the top server. An animated data dot now red goes from the server back to the laptop. In support of audio, other cache icons are highlighted in red. An image of a person and text Directed to wrong web site appears next to the hierarchy. dnsmtg_04_04 In packet interception, or man-in-the-middle attacks, the attacker tries to intercept queries in DNS packets, between the sender and the destination. Most of these types of attacks are carried out between a resolver and a name server. Remember that a resolver may be a simple DNS client workstation, or a caching recursive server. Packet interception attacks may also occur between master and slave servers during zone transfers. Once the attacker intercepts the DNS packet, it substitutes the DNS packet with a malicious one and sends it on as if it were a response from the authentic server. This attack may be more successful if it is combined with a denial-of-service attack, which makes the authentic name server unable to respond. A packet interception attack may become apparent to users if they notice that the data in the response differs from what was expected. There are four variations of packet interception attacks, depending on where the interception takes place and the nature of the data replacement. In data replacement, or spoofing attacks, the data replacement typically involves replacing a legitimate address with an incorrect one. As a result, when users enter a URL, they are connected with a fraudulent web site or resource. With name chaining, the intercepted packet contains additional data, which the attacker replaces with bad data or other information. When the resolver receives the packet, it mistakenly accepts the bad information, and stores it in its cache. As a result, the bad data can be propagated throughout the DNS whenever the resolver returns its response. Finally, there are intentional crashing attacks. In this attack, a malicious user intercepts a DNS packet en route to a server, and returns a response designed to crash the resolver. This type of attack may be confused with a denial-of-service attack, since both prevent the name server from resolving the request. However, intentional crashing attacks take advantage of bugs to crash resolvers, whereas denial-of-service attacks are generally brute-force attacks that overload the network with requests and responses. packet interception attacksPopup 4 of 4: Popup Title: Packet Interception Attacks. Text labeled Method appears in support of audio. Faded image of a large lightning bolt passing through a ball appears as background watermark. Laptop image labeled client resolver and server image labeled name server appear. An animated data dot goes from the laptop to the server and back several times. A red server image appears. In support of audio, the laptop image is highlighted and then changed into a server image labeled caching recursive server resolver. An animated data dot goes from this server to the red server. A data dot returns as a red data dot. The caching recursive server resolver turns red. Text labeled Impact appears in support of audio with bulleted text. Screen 4 of 25. Topic Title: D N S Security Vulnerabilities. Screen Title: Types of Attacks. Image of a D N S hierarchy appears in a ball, with a lightning bolt just outside the ball. Bulleted text appears in support of audio. Text appears Select each type of attack to see how each is carried out. Bulleted text appears selectable, including Foundation attacks, Denial of service attacks, cache poisoning attacks, and packet interception attacks. 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. Select an attack type, and then select its matching description. Screen 5 of 25. Topic Title: D N S Security Vulnerabilities. Screen Title: Knowledge Check ? Types of Attacks. You will not be able to interact with this screen. This screen reviews the descriptions of types of attacks, including the following: Foundation attack is when the operating system of the D N S server is attacked, Name chaining is when additional data is returned in the malicious packet, Packet interception also called Man in the middle, is an attack between a resolver and name server, Intentional crashing is when a Malicious reply packet causes a resolver process to fail, Cache poisoning is when a D N S response is changed and redirected to an unintended site, Denial of service is when the attack overloads name servers with requests, Data replacement or data spoofing is when incorrect data is substituted in a malicious response, Name denial is when the response falsely indicates that no address exists. 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. Screen 6 of 25. Topic Title: D N S Security Vulnerabilities. Screen Title: Defending D N S. Image of D N S hierarchy appears in a ball. Image of animated lightning bolt going to the edge of the ball but not passing through it appears. Bulleted text appears in support of audio. 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. The most common usage of 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. Popup 1 of 2: Popup Title: Cryptography. Bulleted text appears in support of audio. Image of a mailbox, phone book, and key with random numbers appear in support of audio. Sub bullets appear in support of audio. dnsmtg_07_02 Each key or key pair is valid for a time period, and then is 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. Popup 2 of 2: Popup Title: Key Supersession. An image of a key pair appears with an animated timeline extending in support of audio. Two bars appear without overlap along the timeline in support of audio. Text appears Symmetric key supersession equals no overlap. Bars appear with some overlap in support of audio. Text appears Asymmetric key supersession equals no overlap. Screen 7 of 25. Topic Title: About D N S Keys. Screen Title: Basic Concepts about D N S Keys. Two server images appear, each with a lock and chain, and key. Animation appears of random numbers streaming from one server to the other. Bulleted text appears in support of audio. Instructional text appears Select each concept to learn more. Bulleted text Cryptography and Key supersession appear selectable. 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 used to sign larger amounts of data, 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. Screen 8 of 25. Topic Title: About D N S Keys. Screen Title: Cryptographic Attributes of D N S Keys Image of a key appears. Bulleted text appears in support of audio. Bulleted text appears selectable as six rollovers. Rollover 1: Algorithms. The strength of the algorithm affects how secure the overall system may be, and the choice of algorithms usually affects the minimum and maximum key length. Examples of symmetric algorithms include Data Encryption Standard, or DES, and Advanced Encryption Standard, or AES, while public-private key algorithms include DSA and RSA. Rollover 2: Key Length. The length of the key affects the strength of the key. A key that is one bit longer has twice as many possible values, so a 2048-bit key is billions of times stronger than a 1024-bit key. Rollover 3: Key Usage. How the key is used can affect its level of security. All D N S keys are used to sign and/or authenticate data, but with different roles and at different levels of the D N S hierarchy. For example, a set of D N S keys would require a higher level of security if it was used to sign the keys for the root zone, compared to a second set of keys that is used to sign only a personal domain at a lower level. It is also important that a single key is not used for too many different functions. Rollover 4: Key Effectivity Period. Each cryptographic key has an associated time period during which that key is in use and effective, called an effectivity period. A key that is more exposed, or that uses a weaker algorithm, can be partially protected by setting a shorter effectivity period and performing key supersession more often. Rollover 5: Authorization Requirements. Security can be improved by limiting access to the key to authorized users, and by using it only for its intended purpose. Rollover 6: Key Format. D N S keys are stored in Base-64 encoding to allow storage and transmission as a text file, but the key can easily be read by a user, program, or attacker that can access the file system. Contrast this with other systems that provide for encryption or ?wrapping? of a key with a second key, splitting of a key into components, or storage of the key within a high-assurance cryptographic hardware device. 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. Screen 9 of 25. Topic Title: About D N S Keys. Screen Title: D N S Key Management. Image of key appears with bulleted text in support of audio. Bullets appear as rollovers. Instructions appear Roll your cursor over each key management control to see some examples. Rollover 1: Technical Controls. Technical controls include any hardware and software solutions to help establish and maintain secure keys. Rollover 2: Physical Controls. Physical controls include all the types of physical non-computer protections that are appropriate, sometimes referred to as gates, guards, and guns. Appropriate physical controls for US Communications Security, or U S COM SEC, systems in D oh D may include a safe or alarm systems. D N S keys will normally be protected as controlled unclassified information consult the D N S STIG for details. Rollover 3: Procedural Controls. Procedural controls are controls that require human intervention. 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. Screen 10 of 25. Topic Title: Transaction Authentication. Screen Title: What is T Sig? Text Transaction Authentication appears and fades down to T Sig. In support of audio, two server images appear each with a key image. Animated data dots flow back and forth between the server images. Images and data dots fade. Bulleted text appears in support of audio. Server images with keys and animated data dots ree appears. One key is highlighted. Text appears Life Cycle of a T sig key. Horizontal bars and numbered bullets appear in support of audio. dnsmtg_11 11 To configure TSIG between two servers using the BIND software, 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. Now the key can be enabled for zone transfers, using 'allow-transfer' statements in named.conf on both servers. This can be done globally for all zones, or more commonly on a per-zone basis. 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. Popup 1 of 4: Popup Title: Guidelines. Image of a binder appears labeled Guidelines for T sig keys. Bulleted text appears in support of audio. 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. Popup 2 of 4: Popup Title: d n s sec key jen. Text and sample code appear in support of audio. Instructions appear Roll your cursor over each underlined flag to see its description. Rollover 1: hi fen A algorithm. Selects the cryptographic algorithm. There are a large number of algorithms supported, for different purposes. In BIND 9 point 5 the supported methods for T Sig include several different H Mack types using Secure Hash Algorithm as well as the older M D 5 hash algorithm, including M Mack M D 5, H Mack Shah 1, H mack shah two twenty four, H mack shah two fifty six, H mack shah three eighty four, H mack shah five one two. Although H mack M D 5 is officially obsolete for use in T sig keys, it is the only algorithm supported for BIND 9 r n d c keys up through version 9 dot 6 dot oh. Rollover 2: hi fen B key size. Specifies the number of bits in the key. The choice of key size depends on the algorithm used. R S A keys must be between five hundred twelve and four thousand ninety six bits. D S A keys must be between five hundred twelve and one thousand twenty four bits and an exact multiple of 64. H mack Shah 256 keys must be between 1 and 256 bits. Rollover 3: hi fen N name type. Specifies the owner type of the key. The value of name type must either be ZONE for a D N S seck zone key, HOST or ENTITY for a key associated with a host, or USER for a key associated with a user. These values are not case sensitive. Rollover 4: hi fen C class. Indicates that the D N S record containing the key should have the specified class. If not specified, class I N is used. Rollover 5: hi fen E. If generating an R S A key, use a large exponent. Rollover 6: hi fen H. Prints a short summary of the options and arguments to D N S seck key jen. Rollover 7: hi fen P Protocol. Sets the protocol value for the generated key. The protocol is a number between 0 and two hundred fifty five. The default is 2 email for keys of type USER and 3 D N S seck for all other key types. Other possible values for this argument are listed in R F C 2 5 3 5 and its successors. Rollover 8: hi fen random dev. Specifies the source of randomness. If the operating system does not provide a slash dev slash random or equivalent device, the default source of randomness is keyboard input. Random dev specifies the name of a character device or file containing random data to be used instead of the default. The special value keyboard indicates that keyboard input should be used. Note that on recent Linux systems, particularly servers, use of the dev random device may cause this command to appear to hang or block. In such a case, either use the dev u random device or consider using the keyboard device. Rollover 9: hi fen S Strength. Specifies the strength value of the key. The strength is a number between 0 and 15, and currently has no defined purpose in D N S seck. Rollover 10: hi fen T Type. Indicates that the use of the key. type must be one of AUTH CONF, NO AUTH CONF, NO AUTH, or NO CONF. The default is AUTH CONF. AUTH refers to the ability to authenticate data, and CONF the ability to encrypt data. Rollover 11: hi fen V level. Sets the debugging level. 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. Popup 3 of 4: Include. Displays sample code for Include statement for a master or primary server in support of audio. dnsmtg_11_04 Use the same type of include statement to insert the TSIG key into the slave server's named.conf file. Again, this allows the TSIG key to be protected in a separate file that is only accessible by authorized personnel. Popup 4 of 4: Include. Displays sample code for Include statement for a slave or secondary server in support of audio. Screen 11 of 25. Topic Title: Transaction Authentication. Screen Title: Configuring T Sig. A Two server images appear. One is labeled n s 1 dot example dot mil 1 9 2 dot zero dot 2 dot 1. Master. The other is labeled n s 2 dot example dot mil 1 9 2 dot zero dot 2 dot 2 Slave. Double pointed arrow appears between the two servers. Text appears Step 1 Generate the key using d n s sec key jen. Server labeled Master is highlighted. Text box below the double-pointed arrow displays sample code. Code is replaced and sections highlighted in support of audio. Text appears Step 2 Insert the key on the master server, directly or with an INCLUDE statement. Master server is highlighted again. Same text box displays sample code in support of audio. A key image appears next to the Master server. Code is faded and both servers are highlighted. Text appears Step 3 Securely copy the key to the slave server. Text appears Step 4. Insert the key on the slave server, directly or with an INCLUDE statement. Key image appears next to the slave server. Image of a lock appears between the server images. Animated data dots go back and forth between the server images. In support of audio, the lock is highlighted, and text appears list of secret keys. Text Guidelines appears. Instructions appear Select Guidelines, d n s sec key jen, and both INCLUDE statements for a review. 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. Screen 12 of 25. Topic Title: Transaction Authentication. Screen Title: G S S T sig. Text appears Generic Security Services and T sig. General Security Services is animated down to G S S. Microsoft logo appears. dnsmtg_13 13 Domain Name System Security Extensions, or DNSSEC, is a set of extensions to the current DNS protocol, which is approved by the Internet Engineering Task Force, or IETF, to provide authenticity for DNS transactions, that is, make sure that the data received is coming from the zone's actual authoritative server. DNSSEC also aims to ensure data integrity, that is, verify that the data received is the same as the data published. DNSSEC achieves this through providing additional resource records and standards, as well as by using cryptography and keys, to allow data owners to sign their data, and make that data available on their authoritative servers. DNSSEC also allows consumers of DNS data to validate the data on their recursive servers. Data validation in DNSSEC depends on configuring a set of Secure Entry Points, or SEPs, for a given zone, or for a secure parent of that zone. Until the root zone is signed at some point in the future, setup of secure entry points remains a complicated area. Now that we know what DNSSEC is, it is important to know what DNSSEC is not. DNSSEC is not PKI. RRSIG records applied to signing keys have some similarities with certificates, but do not have Certificate Revocation Lists, or CRLs, or Certification Practice Statements, CPS. Also, RRSIG records do not tightly bind an identity to a key. DNSSEC expects key generation and maintenance to be handled separately at each level of the distributed hierarchy, rather than by a few centralized administrators. DNSSEC is not demand-free. DNSSEC records can cause a significant increase to both the amount of network traffic required to service existing query load, and the amount of CPU cycles required on recursive DNS servers. DNSSEC is not TSIG. While TSIG is a method of providing authentication for DNS transactions such as local query and response traffic, DNSSEC is focused on providing authentication of DNS data that can be carried along and verified back to the originating source of data, regardless of the security of any intermediate transaction. And while TSIG is point to point, DNSSEC is end to end. DNSSEC does provide integrity services for DNS, however, it does not provide confidentiality. DNSSEC is not US Communications Security, or US COMSEC. DNSSEC uses a radically different model than US COMSEC for key distribution, generation, and maintenance. DNSSEC isn't simple. In fact, it adds complexity to the existing protocol, to troubleshooting DNS issues, which is partially due to minimal error codes and status reporting in the existing DNS protocol. Finally DNSSEC requires cryptographic key management and additional communications and coordination. Roll your cursor over the underlined terms to learn more about them. Select DNS Issues and resource records and standards to see additional detail about DNSSEC. dnsmtg_13_01 DNSSEC serves several important purposes. DNSSEC has been under development in various forms since at least 1995, specifically to address certain issues fundamental to the DNS protocol. DNSSEC serves as a primary way to address cache poisoning. Recent work by Dan Kaminsky and others has shown that DNS is less resilient than was thought in 2007. DNSSEC is seen as a primary means for addressing cache poisoning attacks. DNSSEC addresses the Federal Information Security Management Act of 2002, or FISMA, mandate for the US Federal Government, which is one of the controls in NIST SP 800-53A. DNSSEC also addresses an Office of Management and Budget memo from August 2008, which mandates DNSSEC signing for the .gov zone, and second-level domains such as nist.gov, by December 2009. The Department of Defense is working toward DNSSEC signing of the .mil zone and second level domains in the same time frame. Roll your cursor over Kaminsky attack to see an explanation of Dan Kaminsky's research. Popup 1 of 2: Popup Title: D N S Issues. Bulleted text appears in support of audio. Instructions appear Roll your cursor over Kaminsky attack to learn more. Rollover 1: Kaminsky attack. In early two thousand eight, Dan Kaminsky discovered that by taking advantage of C NAME records, which is a way to alias one name to another, a target domain could be poisoned in ways that bypassed existing protections. He also identified several ways in which the attack could be enhanced to bypass any protection provided by caching T T L or transaction I D T X I D. Overall, he reduced the time-to-successfully-poison an arbitrary domain from days or weeks on average, to seconds or minutes. Kaminsky worked with software vendors and network operators to implement the best available quick fix for the problem. Source Port Randomization, or U S P R, where U stands for U D P, causes D N S servers to randomly choose a port when generating queries, which makes it harder for attackers to spoof responses. However, the best long-term fix for this issue remains the deployment of D N S Seck, including both cryptographic signing of authoritative D N S data, and validation of the cryptographic signatures on all recursive servers. 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. Popup 2 of 2: Popup Title: Resource Records and Standards. Bulleted text appears in support of audio. Screen 13 of 25. Topic Title: D N S seck. Screen Title: What is D N S seck?. Text Domain Name System Security Extensions appears and animates down to D N S S E C. Bulleted text appears in support of audio. Instructions appear Select D N S issues, and resource records and standards to learn more about D N SSEC. Instructions appear Roll your cursor over the underlined terms to learn more about them. Rollover 1: Authenticity. Verification that data is published by a zone?s actual authoritative server. Rollover 2: Data Integrity. Verification that data being received is the same as the data that was published. Rollover 3: PKI. The D oh D P K I has a formal Certification Practice Statement, or C P S, that serves as a security policy and a set of requirements that are followed in granting a certificate. D oh D P K I Certificates tightly bind a verified identity to a specific key, and all signing of keys and issuing of certificates is centrally controlled. The D o D P K I also provides for revocation of existing certificates before the signatures expire, using Certificate Revocation Lists C R elz or the Online Certificate Status Protocol O C S P. Rollover 4: Simple. D N S uses asymmetric public/private key cryptography, which reduces key distribution problems since public keys are published. However, the use of public private key cryptography requires more CPU power than symmetric cryptography and does not remove all possible key distribution issues. Some common current D N S practices, such as split D N S with two versions of the same zone containing different content, do not interact well with D N S SECK?s aim of achieving verifiable truth. 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 uses 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 uses 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 service, DNS enables source verification. True False Correct. DNS is a UDP-based service, which does not enable source verification. Incorrect. DNS is a UDP-based service, 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. Screen 14 of 25. Topic Title: D N S Seck. Screen Title: Knowledge Check ? What is D N S seck? This is a true false question. Use your keyboard to cycle through the list of options. 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 one or more ZSKs for a zone. The ZSKs then sign all other data or records in the zone. If the zone has child zones underneath it in the hierarchy, the data will include DS records pointing to child zones. The DS record identifies the KSK for the child zone, by pointing to a hash of its value, which is stored at the parent zone. 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 usually 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 resource 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. Popup 1 of 1: Popup Title: Key Pair. Bulleted text appears in support of audio. Screen 15 of 25. Topic Title: D N S Seck. Screen Title: How D N S Seck Works. Image of a simple D N S Hierarchy appears. A server image appears at the top most level. To represent zones, one oval encloses a second level server image and another oval encloses a third level server. Another third level server appears outside of the hierarchy. In support of audio, a duplicate hierarchy appears superimposed on the first one. A key pair image appears. One key is labeled Public, the other private. The server image outside the hierarchy is labeled recursive server. In support of audio, the public key moves next to the recursive server. Text S E P appears next to the same server. Text appears Key Pairs plus R R Sig and D S records equals Chain of Trust. Locks appear at the nodes of the superimposing hierarchy. Text Two types of public and private key pairs appears with bulleted text in support of audio. The top level server appears with text K S K and D S next to it. Text K S K appears next to the second level server. Text is highlighted in synch with audio. Animated arrow goes from top level server to second level server. Arrow is labeled K S K plush hash. Text Z S K appears next to the top server. Both hierarchies appear faded back in support of audio. Server image labeled Signature generating system appears. The key labeled private moves next to this server. Text is highlighted in support of audio. Rollover: Private. Private keys are used to generate cryptographic signatures for the zone data. Rollover: Public. Public keys are published within zones. Rollover K S kaze. Key Signing Key pairs are used only to sign and authenticate Zone Signing Keys, and normally have a relatively long effectivity period that is several months to a year. The public part of a K S K pair can be configured as a Secure Entry Point to allow validation of keys and signatures in that zone and child zones. Rollover Z S kaze. Zone Signing Keys are used more often than K S Kaze to sign more data, and they are therefore more susceptible to certain cryptographic cracking attacks than K S Kaze. Because of this, Z S Kaze normally have a shorter effectivity period that is weeks or a month. 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, zone signing keys should be rolled over approximately every 30 days, while key signing keys should be rolled over at least once a year. Appropriate signature validity periods should be determined for KSK-generated RRSIGs over ZSKs, as well as for ZSK-generated RRSIGs over zone data. The signature validity period is the time span during which the signature, or RRSIG, corresponding to a particular resource record is valid. The start time and end times are specified in the RRSIG resource record. 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. This practice is the basis for the ZSK life cycle. Use the double-signing rollover method during the KSK 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 Using the pre-publish method, a new ZSK is published prior to the actual rollover from the current ZSK. The pre-publish period allows new keys to be pre-staged, cached, and available when older keys are no longer effective. Pre-publishing the zone signing key involves including the public half of the ZSK key pair in the zone file, while not using the private half to sign the zone. As RRSIGs over the data propagate through caching name servers, the public keys become available for validating data. The zone is signed with the current effective zone-signing key, Both the currently effective and pre-published ZSKs are signed with the current KSK. For example, ZSK 1 is generated and published. About five days prior to ZSK 1’s expiration date, the next ZSK is generated and published. During the 5-day pre-publish period, both keys are then signed with the KSK for the zone, but only ZSK 1 is used to sign the zone data. The five-day period allows the new ZSK to be published for at least one signature validity period of the KSK over the ZSKs. The exact duration of the pre-publish period selected for the zone will vary depending on the Time to Live and signature validity period of existing DNS records. Once ZSK 2 has been generated and published, and allowed to propagate for one pre-publish period, 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. Next, a new signature from the current KSK over the new ZSK 2 is generated, while the existing ZSK 1 continues to use its existing older signature. Popup 1 of 1: Popup Title: Pre Publish method. Two images of keys appear. One with text new Z S K is published and the other with text prior to current Z S K rollover. with text pre publish method. Images and text are removed. A key image with text Pre publish the Z S K appears. Bulleted text appears in support of audio. In support of audio, a horizontal bar labeled Z S K 1 appears. Arrow points to the beginning of the bar, with text 1 Generate and 2 Publish. In synch with audio, one fourth of the end of the bar is highlighted. Another bar labeled Z S K 2 appears below the Z S K 1 bar. Z S K 2 is placed such that it overlaps with the highlighted portion of Z S K 1. An enlarged duplicate of Z S K 2 appears. The overlap portion is highlighted and labeled five days and text 1 generate and 2 publish.. In synch with audio, bulleted text appears. Text Effectivity period starts here appears pointing to the end of the overlap period labeled five days. The larger portion of the Z S K 2 bars is labeled thirty days. In support of audio, a third bar appears labeled Z S K 3. Screen 16 of 25. Topic Title: D N S Seck. Screen Title: D N S Key Generation and Storage. Bullet text appears in support of audio. Instructions appear Select Pre publish method for a detailed description of the process. 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. Normally, mismatched system clocks do not pose major issues. However, under certain circumstances, unsynchronized system clocks become a failure mode. 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. Popup 1 of 8: Popup Title: Signature Expiration. In support of audio, one administrator image, a clock with a null symbol on it, a signature icon with a null symbol on it, and a server appear. Null symbol appears on the clock. Animated data dot goes from the null signature image toward the server, but stopping before it reaches the server. 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. Popup 2 of 8: Popup Title: Trust Anchors. Bulleted text appears in support of audio. 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, then the old trust anchors will not be able to validate signatures generated by the new secure entry point keys. Popup 3 of 8: Popup Title: Secure Entry Point Key Rollovers. Images of a server labeled Resolver, and two keys appear. Text appears Secure Entry Point keys must be updated in resolvers. 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. Popup 4 of 8: Popup Title: Secure Entry Point Deletion. An image of a person labeled zone administrator appears. Bulleted text appears in support of audio. 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 data from 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. Popup 5 of 8: Popup Title: Resolver Misconfiguration. An image of a person labeled D N S administrator appears. In support of audio, bulleted text and a server image labeled Misconfigured resolver appear. 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. Popup 6 of 8: Popup Title: Malicious Modification. Images of two servers appear. Text appears Possible Consequences with two bullets Fails without the private key and May succeed with the private key. Animated data dot goes from one server toward the other. Mid way the data dot turns red and stops. The word Attack appears. Bullet point Fails without the private key is highlighted. The animation continues with the red data dot turning black and reaching the other server which then turns red. The bullet May succeed with the private key is highlighted. 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. Popup 7 of 8: Popup Title: D N S Split Views. Bulleted text appears in support of audio. Image of an Oval appears. Inside the oval two boxes, one labeled D N S split view environment and the other labeled D N S SECK are displayed. In support of audio, text appears inside the oval Caution: Easy to introduce errors in this setup. dnsmtg_17_08 Mismatched system clocks generally are a minor issue, since DNSSEC signatures normally are valid for hours, days, or even weeks. However, it is possible to have one system, for example, System A, with RRSIG recordsthat are very close to expiring; and a System B that has a clock set far enough into the future that System A`s RRSIG records are already expired. In this case, if it is 1600 hours on System A`s clock, and four minutes later System B`s clock, then some RRSIG records generated by System A might still be valid on System A, but will have already expired on System B. As a related problem, misconfigured time zones on different systems can produce a similar but more noticeable effect. Signatures might become invalid hours before they should. For precise and accurate time, the Network Time Protocol, or NTP, is the best method to prevent this issue. Popup 8 of 8: Popup Title: Unsynchronized Clocks. Two server images appear with digital clocks. One server is labeled System A and its clock starts at sixteen hundred hours. The other server is labeled System B and its clock starts at sixteen hundred four hours. Animation appears of clocks advancing by the millisecond. Text appears Example System aze R R Sig expires at 16 oh six. Both clocks appear advancing 1 millisecond at a time until System beez clock reads 16 oh 6, at which time it is 16 oh 2 on System aze clock. With each 1 minute advance the text Valid appears below each serverÂ’s clock. When System aze clock reads 16 oh 2, the text Valid next to the System A clock, but the text Expired appears next to the System B clock. The times and text are cleared from the system clocks. In support of audio, next to System A appears text New York City G M T minus 5. Next to System B appears text loss an jeh les G M T minus 8 appears. System aze clock display time oh six hundred hours. System beez clock display oh 9 hundred hours. In synch with audio, the text Valid appears under the System A clock, but expired under the system B clock. Text Network Time Protocol appears in support of audio. Screen 17 of 25. Topic Title: D N S Seck. Screen Title: D N S Seck Failure Modes. A simple D N S hierarchy with three zone ovals appears enclosed in a ball. The zone balls are labeled Zone A, Zone B, and Zone C. Bulleted text appears in support of audio. Instructions appear to Roll your cursor over Definition to learn more about Trust Anchors, and to Select each failure mode to see how it occurs, including failure modes Signature Expiration, Trust Anchors, Secure Entry Point Key Rollover, Secure Entry Point Deletion, Resolver Misconfiguration, Malicious Modification, D N S Split Views, and Unsynchronized Clocks. Rollover: Definition. Trust anchors are public keys that are configured into the D N S resolvers to validate the signatures of incoming data. Since zones may have multiple keys, a zone administrator designates certain keys to serve as a trust anchor for a resolver. Normally, the public half of a KSK pair is designated as the trust anchor. These trust anchors are called the Secure Entry Point keys. 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. The recursive server administrator has not configured public keys for use in signature validation of all zones. Signature expiration Trust anchors Secure Entry Point key rollover Secure Entry Point deletion Resolver misconfiguration Malicious modification DNS split views Correct. A zone administrator designates certain keys as trust anchors for a resolver. The recursive server administrator must configure trust anchors for any zones that their clients should validate, on each recursive server they operate. Incorrect. A zone administrator designates certain keys as trust anchors for a resolver. The recursive server administrator must configure trust anchors for any zones that their clients should validate, on each recursive server they operate. Now check your knowledge about DNS failure modes. Screen 18 of 25. Topic Title: D N S Seck. Screen Title: Knowledge Check ? D N S seck 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_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. Popup 1 of 5: Popup Title: A Multi Part Process. Bulleted text appears in support of audio. 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. Popup 2 of 5: Popup Title: D N S seck Coordination. Bulleted text appears in support of audio. 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. Popup 3 of 5: Popup Title: Serving a Signed Zone. Bulleted text appears in support of audio. Instructions appear Roll your cursor over Path MTU to see a description. Rollover: Path M T U. For any network path, there is a maximum transfer unit size, or MT U, that is derived from a combination of hardware capabilities, protocol limitations, and local configuration. Any packet larger than this M T U size must be fragmented. Common M T yooz for lanz are on the order of fifteen hundred bytes for conventional Eethernet or nine thousand bytes for jumbo packets. Wanz often have much different constraints on their M T yooz. 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 statically configured secure entry points for 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. Popup 4 of 5: Popup Title: Validating D N S seck Signed Data. Bulleted text appears in support of audio. 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. Popup 5 of 5: Popup Title: Changed and New Processes. Bulleted text appears in support of audio. Screen 19 of 25: D N S Seck Topic Title: Setting Up a Secure Zone. Bulleted text appears in support of audio. Instructions appear Select each topic to see additional detail. Topics include A multi part process, D N S Seck Coordination, Serving a signed zone, Validating D N S Seck signed data, and Changed and new processes. 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. Screen 20 of 25. Topic Title: D N S Seck Troubleshooting Tips. Screen Title: Troubleshooting D N S Seck with dig. This is a multiple choice question. Use your keyboard to cycle through the list of options. Rollover: plus multi line. Structures the output of dig so that it is easily readable. As a bonus the key I d will be printed as a comment behind D N S KEY R arz. Rollover: plus c d. Sets the checking disabled bit on the query. You would typically use this when your validating recursive name server reports a SERVFAIL and you need to establish if this is due to D N S Seck marking this data as bad. Rollover: plus D N S Seck. Forces the server being queried to include the D N S SECK related data. Use in combination with the plus c d to establish if data from a zone is signed at all or if you want to determine if the validity intervals on the signatures are correct. Rollover: plus trace. Traces delegation chain. This option may be helpful if you are trying to determine the delegation points. Rollover: plus sig chase. Traces the signature chain. You will also need to have a trusted keys dot keys or et see slash trusted hi fen keys dot keys available that contains trusted key entries. 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 Popup 1 of 1: Popup Title: Drill Options. Text appears without audio. hi fen D enable D N S SECK Hi fen T trace from root down to name, hi fen S chase signature, hi fen V verbose mode, hi fen Q quest mode, hi fen f file read packet from file and send it, hi fen i file read packet from file and print it, hi fen w file write answer packet to file, hi fen q file write query packet to file, hi fen h show this help, hi fen v show version. Screen 21 of 25. Topic Title: D N S Seck Troubleshooting Tips. Screen Title: Drill. Bulleted text appears in support of audio. Instructions appear to Select Drill options to see a full list of options. 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. Screen 22 of 25. Topic Title: D N S Seck Troubleshooting Tips. Screen Title: Other Troubleshooting Utilities. Bulleted text appears in support of audio. 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 provides defensive capabilities for DoD systems. It will be deployed between NIPRNet and the Internet, and allow better control over inboud DNS queries from the Internet to DoD systems. It will also prevent external attacks from directly reaching the internal DNS hierarchy. 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, .mil proxy, 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. Popup 1 of 4: Popup Title: I P v 6. Text Internet protocol appears. Bulleted text appears in support of audio. Instruction appears to Roll your cursor over each format to see its capacity, including I P v 4 and I P V 6 formats. Rollover I P v 4: The current I P v 4 format 32 bits represents over 4 point 2 billion possible addresses. This amount corresponds to about 21 addresses for each of the almost one hundred ninety seven million square miles on the surface of the Earth. Rollover I P v 6 format: The newer I P v 6 format one hundred twenty eight bits represents over 3 point 4 times 10 to the 38 th power possible addresses. This is a phenomenally large number that allows billions of I P addresses to be assigned for each square foot on the surface of the Earth. dnsmtg_23_04 To protect DoD systems, Joint Task Force Global Network Operations has stated a requirement for defensive capabilities, which will be met by a DNS .mil proxy system. This system will prevent external systems from directly contacting or attacking NIPRNet authoritative name servers. It will do this by intercepting all DNS query traffic that is sent to either the .mil hierarchy, or to the reverse DNS servers operated by the DoD Network Information Center, or NIC. Once queries from the outside world are received, the .mil proxy will answer those queries based on a combination of cached data, pre-configured data for top levels of the hierarchy, and queries to the internal servers, as necessary. By doing this, the .mil proxy will significantly increase the resistance of the DoD DNS infrastructure to Distributed Denial of Service attacks, or DDoS. By centralizing all DNS traffic at a smaller set of locations, the .mil proxy will also allow improved DNS traffic monitoring, and blocking or rate-limiting specific queries in ways that cannot be accomplished today. Finally, the .mil proxy will require all traffic to be legitimate DNS traffic that follows protocol standards. This measure will block some common misuses of the ports assigned to DNS. Popup 4 of 4: Popup title: dot mil proxy. Logo of D oh D appears. Bulleted text appears in support of audio. 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. Popup 2 of 4: Popup Title: U E M System. Logo of Defense Information Systems Agency appears. Bulleted text appears in support of audio. 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. Popup 3 of 4: Popup Title: Enterprise Recursive Servers. Logo of Joint Task Force Global Network Operations appears. Bulleted text appears in support of audio. Instructions to Roll your cursor over each term to see its description appears. Rollover: Black hole. Black ho ling of D N S traffic refers to redirecting D N S query traffic to an unused I P address, in order to prevent malicious use of D N S for command, control, and communications also referred to as bot net. Rollover: Sink hole. Sink holing of D N S traffic implies redirecting the traffic to a system that is configured to act in place of the bot net controller. This requires reverse engineering of the mal ware, but allows computer network defense personnel to use the malware's own tools to track infections. Screen 23 of 25. Topic Title: Near Term Changes to D N S Within D oh D. Screen Title: Near term changes to D N S within D oh D. D oh D logo appears. Bulleted text appears in support of audio. Instructions appear to Select I P v 6, dot mil proxy, D N S U E M, and E R S to learn more about their impact on the D oh D. 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_01 Popup 1 of 6: Popup Title: D N S Security Vulnerabilities. Bulleted text appears in support of audio. Rollovers include Foundation attacks, Denial of service, cache poisoning, packet interception and its sub bullets data replacement or spoofing, name denial, name chaining, intentional crashing, and defend D N S. Foundation attacks. Target the operating system on which an application or service runs, and prevent the server from responding to requests effectively. Denial of service floods D N S server and network with requests and responses. As a result, D N S servers or their supporting networks are overloaded and cannot resolve legitimate requests. Cache poisoning places incorrect data in the cache of a recursive server. Packet interception intercepts queries in D N S packets between the sender and the destination. Name denial intercepts a packet before it reaches the nameserver. A response is sent directly, indicating that there is no answer. Users are then led to believe that the web site or resource does not exist. Name chaining replaces the additional section of an intercepted packet with other information. When the resolver receives the packet, it mistakenly accepts the bad information, and stores it in its cache. As a result, the bad data can be propagated throughout the D N S whenever the resolver returns its response. Intentional crashing intercepts a D N S packet en route to a server and returns a response designed to crash the resolver. This type of attack may be confused with a denial of service attack, since both prevent the name server from resolving the request. However, intentional crashing attacks take advantage of bugs to crash resolvers, whereas denial of service attacks are generally brute force attacks that overload the network with requests and responses. defend D N S: There are two primary mechanisms that protect D N S by providing cryptographic enhancements: Transaction authentication, or TSIG, which enables point to point security usually on a local network, and D N S Seck, which provides end to end security for D N S information in transit or in storage. Together, T SIG and D N S SEC can help ensure the integrity of D N S information, and can reduce the effectiveness of some denial of service attacks. However, foundation attacks or brute force denial of service attacks that affect D N S servers and their supporting networks are still a concern, and must be addressed using other measures, including patch updates and network monitoring. dnsmtg_24_02 Popup 2 of 6: Popup Title: D N S seck. Bulleted text appears. Rollovers include D N S SEC: Domain Name System Security Extensions use signatures generated with a public private key algorithm to verify data authenticity and integrity. Authenticity: Refers to verification that data is published by a zone?s actual authoritative server. Integrity: Refers to verification that data being received is the same as the data that was published. Asymmetric Cryptography: In one frequent example of asymmetric cryptography, User A can encrypt a message with the public key for User B, and only User B can decrypt it. As used in D N S, asymmetric cryptography uses a private key to sign data, and the corresponding public key is used to verify the signature. New R R Types: Four resource records types added by D N S SEC are D N S KEY, which carries the public key; R R SIG, which carries the signature on the D N S information; D S, which carries the signed hash of the key; and N SEC, which signs any gaps to assure that the non existence of a resource or domain name. Key Signing Keys or K S kaze: K S kaze are used to sign keys in the zone and can be configured as Secure Entry Points. K S kaze can also be identified and trusted based on a D S record in the parent zone. In the parent zone, the D S record identifies the K S K for the child zone, by pointing to a hash of the K S K value. Zone Signing Keys, Z S kaze, Z S kaze are used to sign all zone data and are effective for a shorter period than are K S kaze. Key effectivity period: The key effectivity period is the time span during which a particular D N S seck key is in effect. If the effectivity period is too long, the keys are more susceptible to certain cryptographic attacks, because of additional usage and resulting plain text and cipher text examples. Also, administrators may lose proficiency with key supersession and rollovers if the key effectivity period is too long. If the key effectivity period is too short, additional resources are required for generating keys and signing zones more frequently. 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. Signature validity period: The signature validity period is the time span during which the signature or R R SIG corresponding to a particular resource record is valid. A new set of signatures R R SIGz on the zone data or keys must be generated before the existing set of signatures expires, or else the D N S SEC validation will fail. Because D N S SEC keys cannot be revoked, recovery from a key compromise is not complete until all valid signatures on the key expire. Therefore the signature validity period should be no more than a matter of days, and shorter than the key effectivity period. Time to Live T T L: The time to live, or T T L, is the time span during which a resolver is encouraged to cache D N S data. Resolvers are not required to abide by the T T L provided by the authoritative server. Guidelines: Currently RSA-SHA1 is the only D N SKEY algorithm widely used Per N I S T S P eight hundred dash eighty one, ten twenty four bit R S A shah 1 keys acceptable for Z S K use; twenty forty eight bit keys for K S K use. By two thousand ten, twenty forty eight bit R S A SHA two fifty six or D S A SHAh two fifty six keys acceptable for both Z S K and K S K but I E T F specification and software must change first. D N S SEC Keys should be generated offline. The private part of a K S K public private pair should never be brought online. The private part of a Z S K public private pair should only be brought online if specifically required to meet an operational need. K S kaze should be configured as S E peeze. Z S kaze should be rolled over about every 30 days; K S kaze at least annually. Appropriate signature validity period, which is on the order of 3 to 5 days for ZS kaze. The Pre publish method should be used to place next Z S K into the zone file. Reduces zone size, bandwidth, and signing time while maintaining security. Use double signing during overlap period. Basis of the Z S K life cycle. Pre publish Method: 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 Z S K pair to sign the zone. The zone is signed with the current effective Z S K, and both the current Z S K and the pre published Z S Kaze are signed with the current K S K. A multi part process: 1. Ensure zone is up to date. Update D S record information for secured child zones. Make other changes as required. Update the serial number always before signing resigning even if no zone data has changed. 2. Generate new keys as required. 3. Use K S Kaze to generate R R sigs for Z S kaze. 4. Use current effective Z S K to generate R R sigs for all other zone data. 5. Pass new K S K and D S information to parent zone. D N S SECK coordination: Zone signing requires coordination with child and parent D N S administrators for DS records. Given R R SIG validity periods of 2 to 7 days, each zone should be signed once every workday. Serving a signed zone. Authoritative servers require minimal additional configuration. Logging and monitoring on the server and other network devices may require attention. Consider that D N S SEC causes larger U D P packets to run into Path M T U limits. Ensure that D N S traffic over 53 T C P works in addition to 53 U D P. Validating D N S SECK signed data: Ensure recursive server is configured with one or more S E peeze. For near term, use at least dot mil and dot gov with transition to a signed root at some future date. Additional logging may be required. Failure to validate data causes errors during transition. Additional logging on recursive servers is useful for localizing errors and troubleshooting. Initial D oh D focus of D N S SEC deployment is signing of zone data, D N S SEC validation will follow later. Changed and new processes. Changes to business processes and resources: Periodic updates of zones, or re signing. Coordination between D N S parent and child zone administrators. Fragility and more difficult troubleshooting with limited error reporting. Signature expiration: The administrator of a D N S zone specifies an expiration time for a D N S signature. If the administrator does not refresh the signature before the expiration time, the signature becomes invalid. Trust anchors: Trust anchors are public keys that are configured into D N S resolvers to validate the signature of incoming data. Secure entry point key rollover. If a resolver that has been configured with trust anchors is not updated with any rollovers on the keys within a zone, the old trust anchors will not be able to validate signatures generated by the new S E Peeze. Secure entry point deletion. If a zone administrator deletes the secure entry point keys that are configured as trust anchors in resolvers, then no signatures are generated, and the resolver considers the zone invalid. Resolver misconfiguration: Misconfiguration may occur with a typo, or if the zone administrator does not fully enable D N S seck support. Malicious modification: Malicious modification takes place when a D N S packet is intercepted and data is changed or deleted. D N S split views: D N S split views occur when more than one legitimate response is possible for a D N S query, often depending on exactly where the query originates in the network. Unsynchronized clocks: Normally, mismatched system clocks do not pose major issues. However, under certain circumstances, unsynchronized system clocks become a failure mode. dnsmtg_24_03 Popup 3 of 6: Popup Title: Transaction Authentication. Bulleted text appears. Rollovers include the following: message authentication Code: The message authentication code is generated using a shared secret, a time stamp, and a hashed message authentication code, or H mack, algorithm. The message authentication code algorithm currently used is either H mack shah 1 or H mack shah two fifty six, where H mack stands for Hashed Message Authentication Code and sha stands for Secure Hash Algorithm. Step 1: First use the command d n s seck key jen to generate the T SIG key for the pair. This is normally done on the primary server. This will output two files, a dot private file and a dot key file. The format of the files differs slightly, but each contains the base sixty four encoded random number that will be used as the shared secret. Step 2: Insert the key statement on the master or primary server. This can be done directly or with an include statement. Step 3: Securely copy the key to the slave or secondary server. Methods for accomplishing this in a suitably secure way include Secure Shell, or S S H; D o D P K I Encrypted Email; or Secure Fax. See the D N S STIG for details. d n s seck key jen: The syntax for d n s seck key jen appears. d n s seck key jen hi fen a algorithm hi fen b key size hi fen n name type hi fen c class hi fen e hi fen h hi fen p hi fen protocol hi fen r random dev hi fen s strength hi fen t type hi fen v level name. G S S T SIG: Generic Security Services, or G S S T SIG, is an alternate version of the T SIG protocol implemented in Windows. G S S T SIG takes advantage of existing trust authorities in a Windows domain. Consult with your vendor documentation or the D N S STIG for more information. dnsmtg_24_04 Popup 4 of 6: Popup Title: About D N S Keys. Bulleted text appears. Rollovers include the following: Technical Controls: Technical controls include any hardware and software solutions that help establish and maintain secure keys. Physical Controls: Physical controls include facility security and physical access controls, that may be used to protect keys. Procedural Controls: Controls that require human intervention. Cryptography: D N S keys are generated using two types of cryptography: symmetric and asymmetric. Symmetric: 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, as it could not be sent along with the message. Symmetric key cryptography is used in D N S to provide data integrity and does not provide confidentiality. Asymmetric: Asymmetric cryptography, or public key encryption, involves signing data with an originator?s private key, and validating the signature with the originator?s public key. Asymmetric key cryptography is used in D N S to provide data integrity and does not provide confidentiality. Key supersession: In key supersession, each key or key pair is valid for a time period, and is then superseded by a new key or key pair. In symmetric key supersession, there can be no overlap between the effectivity periods of new and previous keys. In asymmetric key supersession, there frequently is an overlap between the effectivity periods of new and previous key pair. Algorithms: The algorithm that accepts the key as input. The strength of the algorithm affects how secure the overall system may be. Key length: 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 D N S keys are used to sign and authenticate data. However, D N S key security may vary based on role and placement in the D N S hierarchy. 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. Authorization requirements: Security can be improved by limiting access to the key to authorized users and by using it only for its intended purpose. Key format: D N S 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. dnsmtg_24_05 Popup 5 of 6: Popup Title: Near Term Changes to D N S within D oh D. Bulleted text appears. Rollovers include the following: I P v 6: The I P v 6 format will consist of 8 hexadecimal blocks, which are separated by colons. Each block contains 16 bits of I P address information. Note that blocks of information that contain only zeros can be replaced in a shortened version of the I P address with two adjacent colons. Current 4 number format: 2 1 3 point 4 point 5 6 point 1 2 3. 4 point 2 times 10 to the 9th power possible values. Upcoming change I P v 6: 3 F 0 0 : 0 0 0 1 : : 6 F 0 1 : 0 0 0 1. 3 point 4 times 10 to the 38th power possible values. D N S User Experience Monitor U E M: U E M will: Collect and monitor D N S performance and status information. Be deployed over both Nipper NET and Sipper NET. Provide central management of information. Enable situational awareness of D N S Information. Be both near time and historical, and include the breadth of D N S service health data, such as connectivity, service availability, response time, errors, as experienced by D N S clients. Dot mil proxy: The D N S dot mil proxy system will be deployed between Nipper net and the Internet. The dit mil proxy will intercept all D N S queries from the Internet for Nipper Net information, and provide appropriate responses. This system will prevent external systems from directly contacting or attacking Nipper Net name servers. Enterprise Recursive Servers E R S: E R S deployment will: Process outbound queries. Simplify port 53 management. Allow redirection of malware related traffic blackhole sinkhole. Provide an easier path to D N S SEC validation. D N S SEC Signing. By the end of the calendar year two thousand nine, D oh D and the U S Government expect to have the dot mil and dot gov top level domains signed, as well as most of the second level domains and other parts of the D N S hierarchy. Validation of the signatures will follow, once the signed data roll out is complete and well tested. In support of this plan, the use of D N S Seck signing tools is allowed and encouraged to help individual administrators adhere to D oh D policies for securing zones. Since official D oh D tools are not yet available, administrators may choose to refer to the web site D N S seck-tools.org for more information about these tools, but bear in mind that data and tools on this website do not reflect D oh D policies. dnsmtg_24_06 Popup 6 of 6: Popup Title: D N S Seck Troubleshooting Tools. Bulleted text appears. Rollovers include the following: plus multi line: Structures the output of dig so that it is easily readable. As a bonus, the key I plus d n s seck. Forces the server being queried to include the DN S seck related data. Use in combination with the plus c d to establish if data from a zone is signed at all or if you want to determine if the validity intervals on the signatures are correct. D will be printed as a comment behind D N S KEY R arz. Plus c d: Sets the checking disabled bit on the query. You would typically use this when your validating recursive name server reports a SERV FAIL, and you need to establish if this is due to D N S SEC marking this data as bad. Plus trace: Traces delegation chain. This option may be helpful if you are trying to figure out where the delegation points are. Plus sig chase. Traces the signature chain. You will also need to have a trusted keys dot keys or et see trusted keys dot keys available that contains trusted key entries. The trusted keys dot keys file, or another file of a similar name, is used to store Secure Entry Point keys that is, trust anchor, which can be used by dig and other D N S SECk aware interactive tools. These files can also be included in the name D don conf file for a recursive D N S SECk aware D N S server resolver. Drill: A command line debugging tool. hi fen D enable D N S SECk. Hi fen T trace from root down to name, hi fen S chase signature, hi fen V verbose mode, hi fen Q quest mode, hi fen f file read packet from file and send it, hi fen i file read packet from file and print it, hi fen w file write answer packet to file, hi fen q file write query packet to file, hi fen h show this help, hi fen v show version. Hi fen 4 stay on I P 4. Hi fen 4 stay on I P 4. Hi fen 6. Stay on I P 6. Hi fen A. Only query the first name server default is to try all. Hi fen b. Buff size. Use buff size as the buffer size. Defaults to 512 b. Additional options are provided. Troubleshooting utilities: l d n s key 2 d s creates a D S record from a D N S KEY record. L d n s key fetcher fetches D N S SECk public keys for zones. L d n s key jen generates private and public key pairs for D N S SECk. L d n s sign zone signs a zone file according to D N S SEC biz. L d n s walk walks a D N S SECk zone. Screen 24 of 25. Topic Title: Summary and Conclusion. Screen Title: Summary. Lightning bolt image appears labeled D N S Security Vulnerabilities. Key image appears labeled About D N S Keys. Image of keys, servers, and locks appears labeled Transaction Authentication. Image of a lock appears labeled D N S seck. Image of a tool box labeled D N S seck troubleshooting tools appears. Image of D oh D logo appears labeled Near term changes to D N S within D oh D. Instructions appear Select a topic to review. The topics include all the labels. 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. Screen 25 of 25: Topic Title: Summary and Conclusion. Screen Title: Conclusion. Bulleted text appears in support of audio. -->