basicconcepts basicconcepts DNS toggleNavRMABtn XXX Toggle navigation buttons on off. ToggleRMABtnClicked courseMapBtn Course Map Main Menu, Select this button to access the course menu. MainMenuButtonClicked lessonMapBtn Lesson Map Lesson Map, Select this button to access the lesson map. CourseMapButtonClicked glossaryBtn Glossary Glossary, Select this button to open the glossary. GlossaryButtonClicked resourcesBtn Resources Resources, Select this button to access the resources for the course. ResourcesButtonClicked exitBtn Exit Exit, Select this button to exit the course. ExitButtonClicked replayBtn Replay Replay, Select this button to replay the current screen. ReplayButtonClicked pauseBtn Pause Pause, Select this button to pause the course. PauseButtonClicked resumeBtn Resume Resume, Select this button to resume the course. ResumeButtonClicked previousPgBtn Previous. Select this button to go to the previous screen. PreviousButtonClicked nextPgBtn Next. Select this button to go to the next screen. NextButtonClicked DNS201_01 1 Screen 1 of 33. Topic Title: Introduction and Objectives. Screen Title: Objectives and Overview of Topics. A text box appears with an image labeled Basic D N S Concepts for Systems Administration. The image shows a simple two level hierarchy with two servers. An icon of a database appears next to each server. A world map appears in the background. The text box also displays a bulleted list of learning objectives, and highlights each objective in support of audio. Another box appears with a list of topics that comprise Introduction and Objectives, Introduction to D N S, Policy Requirements, D N S Server Administration, Basic Security Mechanisms, and Summary and Conclusion. A digital clock appears counting down to zero from 1 minute. Each topic is highlighted in synch with audio. As a Systems Administrator working with the Domain Name System, or DNS, you have to understand DNS operational and security concepts. In this lesson, you will learn about the functions and components of DNS, DoD policy requirements, basic DNS server administration and basic mechanisms for DNS security. This lesson has four main content topics, and should take approximately 60 minutes to complete, depending on your familiarity with the material and your learning style. Following this lesson introduction, the first content topic briefly describes the domain name system, or DNS. The next topic covers policy requirements, namely the information assurance hierarchy. The next two topics introduce DNS server administration, and basic DNS security mechanisms. At the end of this lesson, there is a brief summary. DNS201_02 2 Screen 2 of 33. Topic Title: Introduction to D N S. Screen Title: The D N S Context. An image of a laptop computer, the text w w w dot dissa dot mil, and an image of a printer appears in support of audio. An image of a phone book opening and text John Smith followed by phone number eight hundred five five five one two three four appear in support of audio. Text D N S appears. Next to w w w dot dissa dot mil, an equal sign appears followed by I P address 1 3 1 dot 8 4 dot 1 dot 1 6 8. Next to the image of the printer appears an equal sign followed by I P address 1 9 2 dot zero dot 2 dot 1. I P addresses are highlighted in support of audio. When you are looking for a web site on the internet or resource on your network, how does your computer locate it ? The same way you use a phone book to look up phone numbers by names, computers use the DNS to convert domain or host names into internet protocol, or IP, addresses. If it were not for the DNS, we would have to enter lengthy strings of numbers to perform searches on the internet or local networks, or maintain our own lists of all the hosts and names that we need to access on the network. DNS201_03 3 Screen 3 of 33. Topic Title: Introduction to D N S. Screen Title: The D N S Database. A database icon and text D N S appear. Bulleted text appears in support of audio. D N S maps F Q D N work station 1 dot any net to I P address 1 9 2 dot zero dot 2 dot 1 zero. D N S maps I P address 1 9 2 dot zero dot 2 dot one one to F Q D N work station 2 dot any net. Additional text appears in support of audio. Images of three servers appear. Part of the data base icon moves to the image of the first server, and then the second and third servers in support of audio. A hierarchy appears against the background of a world map in support of audio. Instructions appear to roll the cursor of F Q D N. Rollover FQDN displays definition: A fully qualified domain name is the unambiguous name for a resource that specifies its exact location in the DNS hierarchy, for example, www dot irs dot gov, or a resource on a local network, for example, workstation1 dot example dot com. The DNS is a database, which maps fully qualified domain names, or FQDN's to IP addresses, and vice-versa, maps IP addresses to FQDN's. The DNS also stores records that facilitate other applications, such as e-mail. Many applications, including databases, web-based applications, and instant messanger, rely on DNS services, including mail delivery agents such as sendmail. The DNS database is distributed among multiple servers, so that no single server contains the entire set of data. The information is stored on machines that are spread logically across the DNS, and geographically across the world. This allows the massive DNS database to be decentralized. Roll your cursor over FQDN to see a definition. DNS201_04 4 Screen 4 of 33. Topic Title: Introduction to D N S. Screen Title: D N S Roles. Images of system administrator, a laptop, and three computers appear. Images are labeled Systems Administrators, Clients, Authoritative Servers, and Recursive Servers, respectively, in support of audio. There are four classes of DNS users, or four major components of the DNS, each with their own unique role to play. Systems administrators, clients who initiate queries, and authoritative and recursive servers that respond to queries from clients. Systems administrators are the people who configure, operate, maintain, and troubleshoot the hardware and software components of the DNS. Clients are the entities on the network that make requests of the DNS to find the location of the desired resources. Authoritative servers contain the DNS mappings, such as mappings of names to IP addresses, for all of the domains under their authoritative control. These servers are identified as the top of the authority chain for the domains they serve. They provide definitive answers to resource queries. Authoritative servers form a hierarchy in DNS, beginning at the root name servers and flowing out to all of the various domains supported within DNS. Root servers are the authoritative DNS servers at the top of the hierarchy, and are authoritative for the "root" zone which contains delegations to the top level domains. Recursive servers are often non-authoritative servers, and are used to relay requests from clients to authoritative servers to fully resolve the request. In addition, recursive servers often keep a copy of, or cache, of the answer from the authoritative server, in case another client makes the same request. A hierarchy of recursive servers can be established in an enterprise. DNS201_05 5 Screen 5 of 33. Topic Title: Introduction to D N S. Screen Title: D N S Structure. Network hierarchy appears overlaid on world map. The top node is labeled unnamed root. In support of audio, three branches extend from the unnamed root. These are labeled dot mill, dot guv, and dot cahm in support of audio. Below the dot mil node appears example dot mil. Below the example dot mil node appears workstation one dot example dot mil. An image of a server and a document appears at each node, except at the unnamed root, where only a server image appears, and at the leaf node workstation one dot example dot mil, where a laptop image appears. Top level domains and sub domains are highlighted and labeled in support of audio. Think of the DNS as a tree-like hierarchical structure that has a single unnamed root at the top, and expands downward and outward into branches and sub-branches. Every branch is a domain, and every sub-branch is a sub-domain. Domains and sub-domains are relative. Any given domain, is a child to the domain above it, and a parent to the sub-domains below it. The section at the end of a branch is referred to as a leaf when its is a named device, such as a printer or computer. There are a certain number of generic top-level domains, such as .com for commercial organizations, .gov for U.S. government sites, .mil for the U.S. military, and so on. In an FQDN, the name of the top-level domain appears at the farthest right. The sub-domain just below it appears next, followed by any other sub-domains further down the hierarchy. At each level of the DNS hierarchy the servers have pointers to the child, or sub-domains, below them. DNS201_06 6 DNS201_06_01 Popup 1 of 1: Popup Title: Highlighted Zone. Inside a zone oval, two servers labeled master and slave appear with database icons. Servers are highlighted in support of audio. Image of document labeled Master Copy of zone file appears next to master server. Animation of a copy of this document going to the slave server appears in support of audio. Document is labeled Backup copy of zone file. Servers are highlighted in support of audio. Animation of data dots traveling back and forth between servers appears in support of audio about load balancing. Every zone must have at least two name servers, a master name server, also referred to as a primary name server, which holds the primary copy of the zone file, and a secondary, or slave, name server which transfers a copy of the zone file from the master. Having two servers provides redundancy so that if one server fails, the other can continue to serve clients, and help balance the load between the master and slave servers. Highlighted Zone Screen 6 of 33. Topic Title: Introduction to D N S. Screen Title: D N S Zone Structure. The same hierarchy that appeared on screen 5 is displayed here. Two ovals represent two zones of the D N S hierarchy. The top domain of one zone is dot mil. The top domain of the other zone is example dot mil. Parts of the hierarchy are highlighted in support of audio. An image of a recursive server appears detached from the hierarchy. In support of audio about how recursive servers perform resolution, an animated data dot goes from the recursive server straight to the unnamed root and back to the recursive server, to dot mil and back, to example dot mil and back, and finally to child dot example dot mil and back. Similar animations appear in support of audio. Instructions appear to select the highlighted zone for more information. The portion of the DNS for which a DNS server is responsible is called a zone. Each zone has delegated servers that respond to requests. DNS zones acquire a hierarchy from the domains that they contain. The zone containing a network's top domain is the top zone. A zone that contains one or more sub-domains is below the top zone in the zone hierarchy. When performing resolution, recursive servers pass queries up to the top server in the tree, its root, and then proceed down the tree querying servers in turn. This process is called recursion. The recursive process can be applied to both forward lookup, when resolving domain names to resources, and reverse lookup, for resolving resources to domain names. For recursion to work, recursive servers are configured to know how to find the root zone. Each zone requires records in its data files that specify how to pass information up to the root, and then down to any zones immediately below it. As an example of forward lookup, suppose a recursive server wants to locate child.example.mil. The recursive server first queries the root server for the address, and the root server responds by returning a referral to .mil. The recursive server then queries .mil, which responds with a referral to try example.mil. When the recursive server queries example.mil, Example.mil returns the address for child.example.mil, and the query is completed. While forward lookup represents the most common type of DNS queries, reverse lookup represents a less common type of query, for resolving resources to domain names. The reverse lookup tree employs a different zone structure. Each zone in the reverse lookup tree is part of a delegated hierarchy, similar to the forward lookup tree. However, the top level domain for the reverse lookup hierarchy is a special domain called dot arpa, which takes its name from the old ARPANET, a predecessor of today's internet. Underneath dot arpa there are two sub-hierarchies: in-addr.arpa for IPv4, and ip6.arpa for the newer IPv6 addresses. When resolving queries for reverse lookup information, servers generate queries that traverse this separate hierarchy, in the same way that more conventional DNS queries traverse the forward lookup hierarchy. Now to learn more about name servers inside DNS zones, select the highlighted zone. DNS201_07 7 Screen 7 of 33. Topic Title: Introduction to D N S. Screen Title: D N S Server Types. The image of a D N S hierarchy appears with dot mil at the top with two servers labeled Master and Slave. A database and cache icon appear next to each server. A zone oval appears around both servers at dot mil. A letter A appears in each server. Text appears A equals Authoritative. A branch below dot mil appears labeled example one dot mil. An image of a server appears at this node with a zone oval around it, along with the letter A and database and cache icons. The branch below displays doc dot example one dot mil with a server and database and cache icons, but no letter A and no zone oval. In support of audio, an image of a document appears next to the dot mil master server and the example one dot mil server images. In support of audio. zone ovals are highlighted, and a branch appears at the top of the hierarchy labeled un named root, with the letter A and database and cache icons. Bulleted text appears in support of audio, including Authoritative Servers: Maintain zone file with most recently updated data. Non Authoritative Servers: Request and cache data, Do not have delegated zone, Are not updated from master. Recursive Servers: Fully resolve recursive queries, Begin queries at root. Non Recursive Servers: Check their own cache, and then refer to another server. Current D O D Policy: Generally configure server as either authoritative or recursive, but not both. Servers at root: maintain zone file. In support of audio, images of clocks appear next to the dot mil master server and the doc dot example one dot mil server. Animations of data dots appear along the hierarchy. An image of a server labeled recursive dot example two dot mil appears detached from the hierarchy with a letter R and database and cache icons. Text R equals recursive appears. Also in support of audio, the Letters NR appear next to the root server, dot mil servers, and example one dot mil server. Text N R equals non recursive appears. Name servers can be either authoritative or non-authoritative, and recursive or non-recursive. Authoritative servers maintain information about the zone or zones for which they are authoritative, including zone files with up-to-date information about their delegated zones, the top or root zone, and the zones below it. Authoritative servers hold requested information in memory when zone files are loaded. Slave, or secondary authoritative servers, are notified by the master, or primary authoritative server when the zone data is changed on the master. After being notified, the slave servers request a copy of the updated zone data from the master. Non-authoritative DNS servers, or Caching Only DNS servers, request information from an authoritative server, in the form of queries, and cache the answers. Non-authoritative servers are typically recursive servers, and do not have zones delegated to them. In addition, non-authoritative servers are not automatically updated from an authoritative server. Instead, non-authoritative servers update their cache by making DNS queries. Each piece of data in cache has a Time to Live, or TTL, period. When the TTL on a piece of data expires, which could be as little as several seconds or as long as several days, the data is removed from cache and the server must request the data again when needed. Recursive servers send out queries for information through the hierarchy, from top to bottom, until the query is resolved, that is, until the requested information, such as an IP address, is found. All recursive DNS servers are configured with the IP addresses of the root servers, as the default place to start all queries. Non-recursive name servers differ from recursive servers in that when responding to queries non-recursive servers check their cache, and if they do not have information in their cache, the server returns an error or the message, does not exist. The non-recursive servers can also be configured to forward requests. When a non-recursive server is configured as a forwarder, a request that cannot be answered from the non-recursive server's cache is forwarded on to another name server for processing. In early days of DNS, many DNS servers were configured to be both authoritative and recursive, for flexibility. Current DoD policy requires that servers be generally configured either as recursive or authoritative but not both, with some specific exceptions. A server that is neither authoritative nor recursive is an incorrect configuration that is not useful, as it has no way to obtain or hand out DNS data. Name servers at the root level of DNS maintain and publish a file to the internet, referred to as the root zone file. This file lists the names and numeric IP addresses of the DNS servers that are authoritative for all the top-level domains. DNS201_08 8 Knowledge Check 1 500 425 Dummy question text? Response 1. Response 2. Response 3. Response 4. Correct feedback. Incorrect feedback. Screen 8 of 33. Topic Title: Introduction to D N S. Screen Title: Knowledge Check. You will not be able to interact with this screen. This check on learning reviews types of servers. Non-recursive servers check their own databases or forward the request to another server. They do not send queries to other servers. Non-recursive servers check their own databases or forward the request to another server. They do not send queries to other servers. Recursive servers respond to queries from clients and other servers, and send queries up and down the hierarchy, starting at the top. Non-authoritative servers, or Caching-Only DNS servers, are not automatically updated with current information from the master server. Check your understanding of types of DNS servers. DNS201_09 9 Screen 9 of 33. Topic Title: Introduction to D N S. Screen Title: Zone Transfer. Text Method of D N S Zone Transfer appears. An image of a server labeled Master appears above images of two servers labeled slave servers. A database icon appears next to each server. The database icon next to the Master server is highlighted, and an animation of duplicate database icons going to each slave server appears in support of audio. Portions of the database are highlighted in support of audio. Animation of data dots going from the Master server to the Slave servers appears in support of audio. Text Multi Master appears in support of audio. An image of a third slave server appears with a database icon. Animation of portions of the Master database going to slave servers appears in support of audio. Bulleted text appears in support of audio, including Full – entire zone file replicated. Incremental – only updated information. Multi master- changes propagate as needed. Text Zone Transfer Occurs When appears, with bulleted text including: A slave server first starts up. The Authoritative server sends D N S Notify Message. Configured to request updates automatically based on zone expiration. A zone transfer is a method of replicating the DNS records from databases of master name servers, across a set of slave DNS servers. Slave servers initiate zone transfers by requesting a copy of the most recent zone data from their configured authoritative master servers. This process is critical, since zone data is available from more than one name server. Zone transfers may be either incremental, or full. Another method that can be used is called multi-master replication. For DNS systems using multi-master replication, changes can be made to any authoritative master server, and the change will propagate to all peer master servers. Because multi-master replication is not a standard part of the DNS protocol, consult your vendor documentation for specifics. A full transfer is usually conducted when an authoritative slave server initially starts up. The zone data for any and all zones, for which the authoritative slave server is configured is transferred. In an incremental transfer, only the changed portions of the zone are transferred. A slave server might initiate a zone transfer from its configured authoritative master: when the authoritative slave server's process starts up; when an authoritative master server sends a DNS Notify message to a configured authoritative slave server or when the authoritative slave server has been configured to automatically request an update based on zone expiration parameter. DNS201_10 10 Knowledge Check 1 415 425 Identify whether each statement is true or false. Make your selections; then select Done. An authoritative slave server initiates a zone transfer by requesting up-to-date information from the configured authoritative master server(s). True False Correct. An authoritative slave server initiates a zone transfer by requesting up-to-date information from the configured authoritative master server(s). Incorrect. An authoritative slave server initiates a zone transfer by requesting up-to-date information from the configured authoritative master server(s). A zone transfer always copies the entire zone file. True False Correct. Servers can initiate a full or incremental zone transfer. In a full transfer, the information about the entire zone is copied to authoritative slave servers. In an incremental transfer, only the changed portions of the zone are copied. Incorrect. Servers can initiate a full or incremental zone transfer. In a full transfer, the information about the entire zone is copied to authoritative slave servers. In an incremental transfer, only the changed portions of the zone are copied. Multi-master replication is another means of DNS data transfer, which is separate from zone transfers and is vendor-specific. True False Correct. One common example of multi-master replication for DNS data is when Microsoft Windows Active Directory is used for DNS replication in certain modes. Each vendor's implementation of multi-master replication may be different. Incorrect. One common example of multi-master replication for DNS data is when Microsoft Windows Active Directory is used for DNS replication in certain modes. Each vendor's implementation of multi-master replication may be different. Screen 10 of 33. Topic Title: Introduction to D N S. Screen Title: Knowledge Check. This is a true false question. Use your keyboard to cycle through the list of options. Now check your knowledge of zone transfers. DNS201_11 11 DNS201_11_01 Popup 1 of 3: Popup Title: Recursive. Bulleted text appears in support of audio. Image of server labeled name server appears. In response to a recursive query, the local name server must either respond with the requested information, which is frequently the IP address for the FQDN or resource, indicate that the information cannot be found, or send an error message saying that the requested address does not exist. Note that the response must be fully resolved, and may not include a referral to another server. DNS name servers are not required to support recursive queries. In any case, local policy, network conditions, and other factors can also affect the response. A server that is configured to be recursive will generally make a best effort to obtain an answer to recursive queries, but it may generate an error if it is unable to fully answer the query. Recursive DNS201_11_02 Popup 2 of 3: Popup Title: Iterative. Bulleted text appears in support of audio. Image of server labeled name server appears. Examples of I P address and corresponding domain address appear under the server image in support of audio. In an iterative query, a DNS server can either respond with the requested information (frequently an IP address), or refer another name server that is likely to have the requested information. The name server returns that information to the requesting name server. The server may also respond with an error. All DNS servers are required to support iterative queries. A server that is configured to be authoritative, and not recursive, generally provides either a non-recursive but complete answer, or a referral to another name server that might better answer the question. Queries for data that may not exist usually receive a response of non-existent domain, or NXDOMAIN. Local policy may also cause a server to generate an error condition such as query refused, rather than giving a response. Iterative DNS201_11_03 Popup 3 of 3: Popup Title: Inverse. Bulleted text appears in support of audio. Image of server labeled local name server appears. Inverse queries are rarely used, and are now obsolete. Inverse queries were designed to provide a search function that could look up an IP address in a normal forward DNS zone and obtain the hostname. Now an equivalent function is the separate reverse lookup tree. In response to inverse queries, name servers may return no domain names, one domain name, or multiple domain names for the specific resource. A server may also return an error message. Inverse Screen 11 of 33. Topic Title: Introduction to D N S. Screen Title: Query Types. Bulleted text appears in support of audio. Images of a laptop computer labeled client and a server labeled name server appear. Animation of data dots traveling between the laptop and server appear in support of audio. Text D N S Query types appears. Bulleted text appears in support of audio. Popups are available for Recursive, Iterative and Inverse queries. Instructions to select a query type to learn more appear. A DNS query is a request for information by a client, such as "what is the IP address for this FQDN?", or "what is the FQDN for this IP address?" A name server responds to DNS queries based on the type of query it receives. There are three types of DNS queries: recursive, which is a type of query where all the work done to find the answer to the request is done on behalf of the requestor, iterative, or non-recursive, which is a type of query that results in the final answer to the request, or a referral to another name server where the answer can be found and inverse query, a rarely used, and now obsolete capability, which was designed to request a domain name for a specific resource record. Select a query type to see a description of its response options. DNS201_12 12 Knowledge Check 1 400 425 For each statement, indicate whether it applies to iterative, recursive, or an inverse query. Then select Done to submit your answers. Now obsolete, and largely replaced by reverse lookups Recursive Iterative Reverse Lookup Correct. Inverse queries have been made obsolete by RFC3425. Incorrect. Inverse queries have been made obsolete by RFC3425. Requests the full address or a referral Recursive Iterative Reverse Lookup Correct. Iterative, or non-recursive queries, request a server to provide either the full address, or a referral to another name server. Incorrect. Iterative, or non-recursive queries, request a server to provide either the full address, or a referral to another name server. Requests only a full address, not referrals Recursive Iterative Reverse Lookup Correct. In a recursive query, a DNS server must return either the full address, or an error message. Incorrect. In a recursive query, a DNS server must return either the full address, or an error message. DNS servers are required to support these queries Recursive Iterative Reverse Lookup Correct. DNS servers are required to support iterative queries. Incorrect. DNS servers are required to support iterative queries. Screen 12 of 33. Topic Title: Introduction to D N S. Screen Title: Knowledge Check. You will not be able to interact with this screen. This check on learning reviews types of queries. Inverse queries have been made obsolete by RFC3425. Iterative, or non-recursive queries, request a server to provide either the full address, or a referral to another name server. In a recursive query, a DNS server must return either the full address, or an error message. DNS servers are required to support iterative queries. Now check your knowledge of types of queries. DNS201_13 13 DNS201_13_01 Popup 1 of 2: Popup Title: Stub Resolver. Image of an open laptop appears labeled Client and Stub Resolver. In support of audio, the screen of the laptop shows text Application. Animation of data dots appears going from the text Application to the text Stub Resolver. Text 1. Stub resolver receives query from an application appears. In support of audio, text is replaced with 2. Stub resolver forwards query to recursive name server. Animation of a data dot appears going from Recursive Server to Stub Resolver. In support of audio, text is replaced with 3. Stub resolver returns a response to the application. Animation of a data dot appears going from Stub Resolver to Application. In support of audio, text is replaced with the text I P equals one nine two dot zero dot two dot three appears. In support of audio, text is replaced with text N X domain – no such host. Text host not found appears on image of laptop screen. Instructions Roll your cursor over stub resolver to learn more appears in support of audio. Rollover Stub Resolver displays text Step 1. Application queries the stub resolver. Step 2. Stub resolver forwards request to a recursive name server and waits for response. Step 3. Stub resolver returns an answer to the Application. The answer is either the requested information or it may be the reason the query could not be answered. A stub resolver is the simplest type of resolver. It is usually installed on a client, and is frequently provided by the operating system rather than being part of a single application. A stub resolver receives a query from an application, and then typically forwards it on as a recursive query to a local name server configured to handle recursive queries, and waits for a response. When it receives the response, the resolver returns the answer to the application that originally requested the information. The returned response may be an actual answer, or it may be the reason the query could not be answered. In this case, the user sees the appropriate error message. In the past, neither stub resolvers nor applications typically did any local caching of data, but instead relied on caching by the local name server. With increases in computer capacity, it is now more common for stub resolvers and even some applications to cache DNS responses locally. Roll your cursor over the stub resolver to see the steps in the process. Stub Resolver DNS201_13_02 Popup 2 of 2: Popup Title: Iterative Resolver. Images of an open laptop labeled client and a server labeled Recursive Server and Iterative Resolver appear. In support of audio, animation of a data dot appears going from Stub Resolver to Iterative Resolver. Text Step 1 Iterative resolver receives query from stub resolver appears. In support of audio, text is replaced with Step 2 Iterative resolver checks cache or begins query at root. An image of a server labeled root level authoritative server appears. Animation of data dot appears going from recursive server to root level authoritative server. In support of audio, text is replaced with Step 3 Root Authoritative server responds with a referral to another server. Animation of data dot appears going from root level authoritative server to recursive server. In support of audio, an image of a server labeled Referred Server appears. Text is replaced with Step 4 Iterative resolver queries the referred server. Animation of a data dot appears going from Iterative resolver to Referred Server. In support of audio, text is replaced with Step 5 The query cycle continues. Animation of a data dot appears going from Referred Server to Iterative Resolver. In support of audio, text is replaced with Step 6 When a complete answer or error message is received, the iterative resolver returns it to the stub resolver. In support of audio, the laptop is highlighted and text is replaced with Step 7 When a complete answer is received, the stub resolver returns it to the application. Instructions appear to roll your cursor over iterative resolver to learn more. Rollover Iterative Resolver displays text Step 1. The application queries the stub resolver. Step 2. The iterative resolver queries its own cash, and then the root authoritative server. The queries may be iterative or recursive. Step 3. The root authoritative server responds with either an answer or a referral to another name server. Step 4. The iterative resolver then queries the referred server, which may also respond with a full answer or a referral to another name server. Step 5. The Query cycle continues, until either a full answer is received by the iterative resolver and returned to the requesting application, or one of the referred servers returns an error message. All resolvers other than stub resolvers, according to the terminology of early DNS specifications, should be capable of generating successive sets of iterative queries and are frequently referred to as iterative resolvers. This does not mean that an iterative resolver may only generate iterative queries. Think of it as an iterative-capable resolver, or just as a resolver. An iterative resolver installed on a locally-configured recursive, caching name server may itself send iterative or recursive queries, and will process responses on behalf of clients. A stub resolver sends a recursive query to the recursive server. The recursive server makes an iterative query, starting at the root level, and works down the hierarchy, delegation by delegation, until it gets to the server with the answer. Without other information, such as cached data, the iterative resolver begins a search at the root of the DNS hierarchy. Typically, the root authoritative server answers the query with a referral to another server which is likely to have the information. The iterative resolver sends the query to the referred server. The referred server either replies with the answer, a referral, or an error message. If the referred server returns a referral to another server, the iterative resolver on the recursive server queries the next referred server for the information, and so on. When the iterative resolver either receives a complete answer or an error message, it returns the response to the stub resolver, which sends the response to the client application that originally requested the information. An iterative resolver that is installed on a recursive, caching server that provides service to stub resolver clients, is also commonly referred to as a caching resolver or recursive, caching resolver. Roll your cursor over the iterative resolver to see the steps in the process. Iterative Resolver Screen 13 of 33. Topic Title: Introduction to D N S. Screen Title: Resolver Types. Text D N S resolvers send and receive queries and responses. Images of two servers appear labeled Stub Resolver and Iterative Resolver. Popups are available for Stub and Iterative Resolvers. Instructions appear to select each type of resolver to learn more. A DNS resolver is an application that sends DNS queries and receives DNS responses. There are two types of DNS resolvers: stub resolvers and iterative resolvers. Select each type of resolver to learn about it. DNS201_14 14 Knowledge Check 1 350 425 For each statement, indicate whether it applies to iterative resolvers, stub resolvers, or both. Then select Done to submit your answers. Sends recursive queries only Iterative Stub Both Correct. Stub resolvers send only recursive queries. Incorrect. Stub resolvers send only recursive queries. May send iterative or recursive queries Iterative Stub Both Correct. Iterative resolvers send queries to authoritative servers, such as root and top-level servers, which are generally non-recursive. However, the queries sent may be iterative or recursive. Incorrect. Iterative resolvers send queries to authoritative servers, such as root and top-level servers, which are generally non-recursive. However, the queries sent may be iterative or recursive. Processes referrals Iterative Stub Both Correct. Only iterative resolvers are capable of processing referrals and generating follow-on iterative queries. Incorrect. Only iterative resolvers are capable of processing referrals and generating follow-on iterative queries. Pre-configured with root server IP addresses Iterative Stub Both Correct. Iterative servers are initially configured with IP addresses of root servers. Incorrect. Only iterative servers are initially configured with IP addresses of root servers. Pre-configured with a set of local DNS server addresses Iterative Stub Both Correct. Stub resolvers are initially configured with IP addresses of specific DNS servers, normally a trusted local set of recursive caching resolvers. Incorrect. Stub resolvers are initially configured with IP addresses of specific DNS servers, normally a trusted local set of recursive caching resolvers. Installed on clients Iterative Stub Both Correct. Stub resolvers are installed on clients. Note that a DNS server which has an iterative resolver installed as an application will likely also have a stub resolver provided as part of the operating system. Incorrect. Stub resolvers are installed on clients. Note that a DNS server which has an iterative resolver installed as an application will likely also have a stub resolver provided as part of the operating system. May cache query responses Iterative Stub Both Correct. Both types of resolvers may cache responses for future reference. Incorrect. Both types of resolvers may cache responses for future reference. Screen 14 of 33: Topic Title: Introduction to D N S. Screen Title: Knowledge Check. Use your keyboard to cycle through the list of options. Check your knowledge about resolvers. DNS201_15 15 Screen 15 of 33: Topic Title: Introduction to D N S. Screen Title: Modes of Operation. Image of network hierarchy appears overlaid on a world map. A vertical line divides the hierarchy into two symmetrical parts in support of audio. The left side of the hierarchy is labeled S I P R N E T or sippernet, and right side labeled N I P R N E T or nippernet. Below sippernet appears text J W I C S or J wix. An image of a server appears at the top of each half. In support of audio, the dividing line appears thickened. Instructions to roll the cursor over sippernet, nippernet, and J wix to learn more appears in support of audio. Rollover sippernet displays text Security requirements prevent a detailed discussion of the classified network, however, the operating principles remain the same. D O D N I C provides authoritative dot smil and dot mil servers and generic root servers only. Rollover nippernet displays text The physical architecture of the unclassified network does not currently provide recursive D N S servers at the D o D backbone level. A related dissa initiative, DNS Enterprise Recursive Servers, is in development. D O D NIC provides authoritative .mil servers and generic root servers only. Authoritative servers for lower levels of the hierarchy, and local recursive servers, are provided by the Combatant Commanders, Services, Agencies, and Field Activities as appropriate. Rollover J wix display text Top Secret level network. In the Department of Defense, the overall DNS hierarchy is divided into an unclassified network, or NIPRNET and a SECRET level network, SIPRNET. A third network, Joint Worldwide Intelligence Communication System, or JWICS, provides connectivity at the TOP SECRET level. DNS functionality and capability exists across all DoD networks, but there is no transparent cross-connectivity. The operating modes, or environments, are at different classification levels and are physically isolated from each other. Roll your cursor over each type of network to learn more about it. DNS201_16 16 Screen 16 of 33: Topic Title: Policy Requirements. Screen Title: Information Assurance or I A. Bulleted text appears in support of audio. An oval labeled People appears with bullets Confidentiality, Integrity, Availability. Two additional ovals labeled Operations and Technology appear intersecting each other around the three bullets in support of audio. Image of ovals shrinks slightly and moves to the side. An image of a systems administrator appears in support of audio. Text appears in support of audio, including Authorized User, Privileged User, I A O, I A M, and D A A. Information assurance, or IA, includes a wide range of activities designed to protect and defend information and information systems by ensuring their confidentiality, integrity and availability. IA integrates the capabilities of people, operations, and technology to provide protection of information and information systems necessary to accomplish DoD missions. As a systems administrator, it is important that you understand the IA roles and responsibilities of different types of users in your environment. Users with access to DoD information are referred to as Authorized Users. Users who play a technical role, but not a supervisory role in IA are considered Privileged Users. As a Systems Administrator, you are considered a Privileged User. The Information Assurance Officer, or IAO; Information Assurance Manager, or IAM; and Designated Accrediting Authority, or DAA; all have supervisory responsibilities within the Information Assurance hierarchy. DNS201_17 17 DNS201_17_01 Popup 1 of 5: Popup Title: D A A. Image labeled D A A appears. Image of document appears with text Accreditation, along with images of a telephone and a stack of documents in support of audio. Bulleted text appears in support of audio. Authorized users have particular IA responsibilities. The first requires them to obtain a U.S. Government security clearance equivalent to the level of access they are granted. They should access only the data, information, software, hardware, and firmware for which they are authorized and have a need-to-know. Authorized Users are required to follow all policies and procedures that have been established to secure DoD information systems, terminals, and workstations. Authorized Users also have a responsibility to report threats to and protect the security of information. Should an Authorized User become aware of any IA-related events, potential threats, or vulnerabilities, they must immediately report them to the appropriate Information Assurance Officer, or IAO. Authorized Users should also protect passwords and other authenticators equal to the classification or sensitivity of the information they access. Any compromise, actual or suspected, should be immediately reported to the IAO. Authorized Users must ensure that all DoD system media and output is properly marked and handled at all times based on its classification and need-to-know. They should never unilaterally bypass, strain or test any IA mechanism. If an IA mechanism must be bypassed, the Authorized User should coordinate with the IAO and receive written approval from the Information Assurance Manager, or IAM, before taking any action. Authorized Users should not relocate or change any equipment or network connectivity without the proper IA authorization. D A A DNS201_17_02 Popup 2 of 5: Popup Title: I A M. Image labeled I A M appears. Bulleted text appears in support of audio. Images a computer, monitor, and keyboard appear in support of audio. Image of a document with text I A O Guidelines, and an image of a spreadsheet, appear in support of audio. In addition to fulfilling the responsibilities of an Authorized User, the Privileged User conducts several key technical functions. Privileged Users should have two accounts, one for their daily business, and a second account to conduct their privileged function. They are responsible for configuring and operating IA and IA-enabled technology. This includes establishing and managing Authorized User accounts and access controls for DoD information systems. Privileged Users must monitor technology changes and report any changes that might impact IA to the IAO. I A M DNS201_17_03 Popup 3 of 5: Popup Title: I A O. Image labeled I A O appears. Image of an I D card appears with example text John Hunter Security Pass Warning appears in support of audio. Bulleted text appears in support of audio. Images of calendar, and three ring binder with text Policy appear in support of audio. In addition to satisfying the responsibilities of an Authorized User, the IAO is responsible for controlling access to the information system. The IAO must confirm that all users have the appropriate security clearance and fully understand their responsibilities before they are given access to a system. The IAO is also responsible for ensuring that all IA and IA-enabled software, hardware, and firmware comply with the proper security requirements. The sole function of IA technology, such as firewalls and antivirus protection, is to protect DoD information systems. IA-enabled technology, for example, a Windows operating system, has built-in security functionality but security is not its primary function. In addition, the IAO manages various day-to-day operational activities for the IAM. This includes tracking and reporting all management review items and initiating any necessary protective or corrective measures for IA vulnerabilities and incidents. The role of the IAO is also to implement and enforce all DoD IA policies and procedures to maintain security of DoD information systems. To support this, the IAO must ensure that all IA related documentation is current and accessible to all Authorized Users. I A O DNS201_17_04 Popup 4 of 5: Popup Title: Authorized User. Image labeled Authorized User appears. Bulleted text appears in support of audio. The IAM supervises the IAO and reports directly to the DAA, serving as the DAA's technical advisor. The role of IAM requires an individual to thoroughly understand the system technology and potential security risks in order to properly advise the DAA. Should any IA changes or incidents occur, the IAM is responsible for reporting these to the DAA and any other appropriate individuals in the IA hierarchy to coordinate the appropriate response. As a supervisor to the IAO, the IAM must ensure candidates are U.S. citizens and meet all identified access requirements before appointing anyone to the IAO position. The IAM is responsible for ensuring all IAOs are appointed, in writing, and that they follow all established IA policies and procedures in their daily routine. They should also ensure that the IAO and Privileged Users receive the necessary training, education, and certification, and are following IA policies and procedures. The IAM is responsible for developing and maintaining a comprehensive IA program plan, also known as the System Security Authorization Agreement, or SSAA, that identifies IA architecture, requirements, objectives, policies, procedures, and personnel. To support this plan, the IAM must ensure ownership responsibilities are established. The IAM is also responsible for ensuring that all required IA certification documentation is developed. Any actions required for certification must be reported to the DAA. To ensure the organization is following the certification guidelines, the IAM must ensure that compliance monitoring is taking place. The IAM is responsible for coordinating inspections, tests, and management reviews, including tracking and reviewing all results. Authorized User DNS201_17_05 Popup 5 of 5: Popup Title: Privileged User. Image labeled Authorized User appears. Bulleted text appears in support of audio. Images of a telephone and computer appear in support of audio As the senior executive responsible for IA within an organization, the DAA must ensure that IA is incorporated into all management processes. The DAA must formally grant DoD information systems accreditation to operate based on the requirements of the IA certification and accreditation process. Should any events occur or configuration changes be made that might impact accreditation, the DAA is responsible for communicating this information to the affected parties. The DAA is required to assign all IA positions in writing and provide all appointees with documentation of the responsibilities and the appropriate training associated with their role. Before appointing anyone to an IAM position, the DAA must ensure the candidate is a U.S. citizen and meets all access requirements. Privileged User Screen 17 of 33: Topic Title: The I A Hierarchy. Screen Title: Information Assurance or I A. Images of three people appear as a vertical hierarchy, labeled from top to bottom as D A A, I A M, and I A O. Below the third image, two images of people appear side by side. A box appears displaying in support of audio. In support of audio, the image labeled D A A is highlighted. Animation of the image duplicating and gradually enlarging appears in support of audio. In support of audio, the enlarged image shrinks back into the image in the hierarchy. The image labeled I A M appears with a similar animation. A dotted line appears between the I A M image and the D A A image, and turns into a flashing arrow pointing upward. The enlarged I A M image shrinks and merges back into the small image in the hierarchy, which remains highlighted. In support of audio, the image labeled I A O is highlighted and a similar animation of an enlarged duplicate appears. A flashing arrow points upward from the image labeled I A O to the image labeled I A M in support of audio. The image of the enlarged I A O shrinks and merges into the image in the hierarchy. In support of audio, both images below I A M are highlighted. One of the images is labeled Authorized user, with a similar animation appearing in support of audio. The image shrinks and merges back with the image in the hierarchy. In support of audio, the second image is labeled Privileged User, and similar animation appears in support of audio. Popups are available for Authorized User, Privileged User, I A O, I A M, and D A A. Instructions appear select a role to learn about their responsibilities. The IA professionals associated with each DoD information system are organized in a hierarchy of responsibility and supervision. Department of Defense Directive, or DoDD, 8500.01E, Information Assurance, dated 24 October 2002, and Department of Defense Instruction, or DoDI 8500.2, Information Assurance Implementation, dated 6 February 2003, describe the IA roles and responsibilities of each of these IA professionals. At the top of the IA hierarchy is the DAA. The DAA is the management official responsible for ensuring that IA is incorporated in the life cycle of each DoD information system or enclave for which he or she is responsible. The DAA must formally authorize information processing by each system or enclave. The DAA's authorization is based on the implementation of system security measures required by the appropriate DoD IA certification and accreditation process. The DAA is also responsible for assigning qualified individuals to other IA positions for information systems or enclaves under the DAA's purview, and for overseeing IA-related functions. The IAM is the primary technical advisor to the DAA. In order to provide advice about the system and potential security risks, the IAM must completely understand the technical aspects of the system. The IAM is responsible for developing an information system-level IA program that identifies IA architecture, IA requirements, IA objectives and policies, IA personnel, and IA processes and procedures. According to DoDI 8500.2, the IAM maintains a repository for all IA certification and accreditation documentation and modifications. The IAM ensures that compliance monitoring occurs and that all users receive the necessary technical and IA training, education, and certification to carry out their IA duties. The title IAM may be used interchangeably with the title Information System Security Manager, or ISSM. The IAO plays a key role in managing the day-to-day operations of a system and providing support to the IAM. The title IAO may be used interchangeably with other titles, such as: Information System Security Officer, or ISSO; Information Systems Security Custodian; Network Security Officer; or Terminal Area Security Officer, or TASO. Users granted access to DoD information systems are referred to as Authorized Users. Authorized Users are required to follow all policies and procedures that have been established to secure DoD information systems, enclaves, terminals, and workstations. Individuals acting as System Administrators, or SAs, Web Administrators, and Database Administrators are referred to as Privileged Users. They are responsible for configuring and operating IA and IA-enabled technology. These Privileged Users play a technical role and do not supervise the IA activities of other Authorized Users. Both Authorized Users and Privileged Users are expected to report all IA-related events and potential threats and vulnerabilities to the appropriate IAO. Select a role to learn more about their responsibilities. DNS201_18 18 Knowledge Check 1 580 425 Select the appropriate IA role for each responsibility. When you are finished, select Done. Configure and operate IA and IA-enabled technology and notify the IAO of any changes that might adversely affect IA. DAA IAM IAO Privileged User Authorized User Correct. Privileged users are responsible for configuring and operating IA and IA-enabled technology and notifying the IAO of any changes that might adversely affect IA. Incorrect. Privileged users are responsible for configuring and operating IA and IA-enabled technology and notifying the IAO of any changes that might adversely affect IA. Grant DoD information systems formal accreditation to operate according to the certification and accreditation process. DAA IAM IAO Privileged User Authorized User Correct. DAAs grant DoD information systems formal accreditation to operate according to the certification and accreditation process. Incorrect. DAAs grant DoD information systems formal accreditation to operate according to the certification and accreditation process. Confirm that IAOs and privileged users receive the necessary technical and IA training, education, and certification. DAA IAM IAO Privileged User Authorized User Correct. IAMs confirm that IAOs and privileged users receive the necessary technical and IA training, education, and certification. Incorrect. IAMs confirm that IAOs and privileged users receive the necessary technical and IA training, education, and certification. Work with the IAM to initiate protective measures for all IA incidents and vulnerabilities. DAA IAM IAO Privileged User Authorized User Correct. IAOs work with the IAM to initiate protective or corrective measures for all IA incidents and vulnerabilities. Incorrect. IAOs work with the IAM to initiate protective or corrective measures for all IA incidents and vulnerabilities. Obtain proper IA authorization to relocate or change equipment or network connectivity. DAA IAM IAO Privileged User Authorized User Correct. Authorized users are responsible for obtaining proper IA authorization to relocate or change equipment or network connectivity. Incorrect. Authorized users are responsible for obtaining proper IA authorization to relocate or change equipment or network connectivity. Screen 18 of 33: Topic Title: Policy Requirements. Screen Title: Knowledge Check. You will not be able to interact with this screen. This check on learning reviews Information Assurance roles and responsibilities. Privileged users are responsible for configuring and operating I A and I A related enabled technology and notifying the IAO of any changes that might adversely affect I A. D A ayz grant D o D information systems formal accreditation to operate according to the certification and accreditation process. I A emz confirm that I A Os and privileged users receive the necessary technical and IA training, education, and certification. I A ohz work with the I A M to initiate protective or corrective measures for all I A incidents and vulnerabilities. Authorized users are responsible for obtaining proper I A authorization to relocate or change equipment or network connectivity. Now check your knowledge of the IA roles. DNS201_19 19 DNS201_19_01 Popup 1 of 1: Popup Title: name D dot conf file. Sample content of a name D dot conf file appears. name d dot conf file Screen 19 of 33: Topic Title: D N S Server Administration. Screen Title: D N S Configuration and Data Files. Images of a server and documents appear labeled D N S Configuration and data files. Text Bind D N S on a name server comprises appears in support of audio. Bulleted text appears in support of audio. Image of document is highlighted in support of audio. Instructions appear Select name D dot conf to see a sample. The two most common implementations of DNS on name servers are Microsoft, and the Berkeley Internet Name Domain, or BIND. With a BIND implementation, DNS on a name server is comprised of a configuration file called named.conf, and, if authoritative and a master server, zone data files. The configuration file named.conf establishes whether the name server is a master (primary) or slave (secondary) for its delegated zone or zones or a cache-only server, defines the zone or zones for which the name server has authority, and specifies which data file or files will provide zone data. Named.conf can contain comments and statements, which control the functionality and security of the server. Zone data files describe zone operations, and contain the resource records that make up the smallest unit of information available through DNS. Select named.conf to see a sample named.conf file. DNS201_20 20 DNS201_20_01 Popup 1 of 7: Popup Title: A C L. Sample code and bulleted text are displayed in support of audio. Portions of the code are highlighted in support of audio The Access Control List, or ACL, statement, defines an address-match-list to allow fine-grain control over which hosts may or may not perform which operations on the name server. The named address-match-list assigns one or more IP addresses or IP network prefixes followed by a slash, and the number of bits in the netmask. An acl statement must define a named address match list, before it can be used anywhere else. No forward references are allowed. A C L DNS201_20_02 Popup 2 of 7: Popup Title: Include. Sample code and bulleted text are displayed in support of audio. Portions of the code are highlighted in support of audio. The include statement inserts files to be included in a named.conf file, at the point where this statement is encountered. Use this statement to break the named.conf file into more easily managed chunks. Include DNS201_20_03 Popup 3 of 7: Popup Title: Key. Sample code and bulleted text are displayed in support of audio. Portions of the code are highlighted in support of audio The key statement specifies a key ID used for authentication and authorization on a particular name server. There are several options that are used with key including algorithm (algorithm-name) which specifies the type of algorithm used. The key statement includes both the algorithm and the actual key itself. According to best practices, the key is usually incorporated using an Include statement that refers to a separate file. Key DNS201_20_04 Popup 4 of 7: Popup Title: Logging. Bulleted text appears in support of audio. The logging statement specifies how the name server will log event information by using pre-defined or user-defined channels and associating categories of event information with those channels. Logging DNS201_20_05 Popup 5 of 7: Popup Title: Options. Sample code and other text are displayed in support of audio. The options statement controls global server configuration options and sets default values for other statements. Options DNS201_20_06 Popup 6 of 7: Popup Title: Server. Sample code and other text are displayed in support of audio. The server statement specifies the behavior this server will use when accessing or responding to the defined remote server, particularly zone transfers. The statement applies options on a server-by-server basis, rather than to all servers. Server DNS201_20_07 Popup 7 of 7: Popup Title: Zone. Sample code and other text are displayed in support of audio. The zone statement defines a zone for which this server will be authoritative and applies options to describe how this zone will function. It may take several configuration statements to adequately describe a single zone, and a separate zone statement is required for each individual zone. Zone Screen 20 of 33: Topic Title: D N S Server Administration. Screen Title: Name D Dot Conf Statements. Text appears Commonly used statements in name D dot conf file are. Sample statements appear. Bulleted text appears in support of audio. Popups are available for A C L, Include, Key, Logging, Options, Server, and Zone. Instructions Select each statement to learn more about its function appear. The named.conf file contains statements and comments. Statements are used to establish the operational functionality of the name server. The named.conf file supports the following commonly used statements: acl, include, key, logging, options, server, and zone. Select each statement to learn more about its function. DNS201_21 21 Screen 21 of 33: Topic Title: D N S Server Administration. Screen Title: D N S Data Files. Table appears with Data file names including name D dot C A, hosts dot D B, hosts dot rev, and name D dot local. In support of audio, descriptions appear for each data file. DNS datafiles play specific roles in DNS. The named.ca file defines the names of root servers and provides their IP addresses. The hosts.db file contains all data about the machines in the local zone that serves the name server. The hosts.rev file specifies a zone in the in-addr.arpa domain, which is a special domain that allows reverse address-to-name mapping. The named.local file provides the address for the local loop-back interface, or local host. DNS201_22 22 DNS201_22_01 Popup 1 of 1: Popup Title: Standard R R Format. Standard R R format: appears followed by a sample format. Format appears including name space T T L space class space record hyfen type space type hyfen specific hyfen data. Fields are highlighted in support of audio. In support of audio, text Special R R characters appears. Bulleted list of special characters appears in support of audio. A resource record contains certain fields, separated by white space. The order of the fields is always the same although the first two are optional fields, and the third one varies according to the record-type field. The first field is the name of the domain that applies to the record. If this field is left blank in a given RR, it defaults to the name of the previous RR. A domain name in a zone file can be either a fully qualified name, terminated with a dot, or a relative name, in which case the current domain is appended to it. The second field is an optional time-to-live field. This specifies how long, in seconds, this data will be cached in the database before it is disregarded and new information is requested from a server. By leaving this field blank, the ttl defaults to the minimum time specified in the Start-Of-Authority, or SOA, resource record. If the ttl value is set too low, the server will incur a lot of repeat requests for data refreshment. If, on the other hand, the ttl value is set too high, changes in the information will not be distributed in a timely manner. Most ttl values should be initially set to between a day, 86,400 seconds, and a week, 604,800 seconds. The third field is the record class. Only one class is currently in use: IN for the TCP/IP protocol family. The fourth field states the resource record type, for example, SOA, NS, or PTR. The contents of the record-specific-data field depend on the type of the particular resource record. Although the case is preserved in names and data fields when loaded into the name server, all comparisons and lookups in the name server database are not case sensitive. Within the RR, special characters may be used. A free-standing dot in the name field refers to the current domain. Most resource records have the current origin appended to names if they are not terminated by a dot. You should use a fully qualified name ending in a period if the name is not in the domain for which you are creating the data file. A free-standing @ in the name field denotes the current origin. Two free-standing dots represent the null domain name of the root when used in the name field. A backslash preceding a character, other than 0 through 9 or a dot, indicates that the character 's special meaning does not apply. A backslash preceding three digits between 0 and 9, where each D is a digit, is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. Use parentheses to group data that crosses a line. In effect, line terminations are not recognized within parentheses. A semicolon starts a comment. The remainder of the line is ignored. An asterisk signifies a wildcard. Roll your cursor over the special characters to see a text description of their function. Standard RR Format Screen 22 of 33: Topic Title: D N S Server Administration. Screen Title: Resource Record Types. Text R arz appears. Bulleted list of types of resource records or R arz appears in support of audio. In support of audio, text Standard R R format: appears followed by a sample format. Format sample includes name T T L class record type type specific data. Instruction Roll your cursor over each acronym to see its name appears. Instruction Select the Standard R R format to see the details of the fields appears. Rollover R R displays Resource Record, rollover S O A displays Start of Authority. Rollover N S displays name server, rollover A displays Address record I P V 4, rollover P T R displays pointer reverse lookup, rollover C name displays canonical name, rollover S R V displays server record, rollover M X displays mail exchanger, rollover T X T displays text information, rollover S P F displays sender policy framework, rollover D kim displays domain key identified mail, and rollover AAA displays I P V 6 address record. Popup for Standard R R is available. Instruction appears to select the popup for more information. A zone file also contains entities called resource records, or RRs. There are many common RR types. The Start of authority, or SOA, RR establishes the name of the zone, an e-mail contact, and time and refresh values that apply to the zone. The Name server, or NS, RR establishes the authoritative name server or servers for the domain (defined by the SOA record), or the sub-domain.The A RR identifies the Internet address for a host, or name-to-address mapping. The Pointer, or PTR, is used in reverse lookup zones to map IP address to name. The canonical name, CNAME, or nickname, RR provides a means for a named resource to have an alias name. The SRV resource record type specifies information on available services. The Mail Exchanger, or MX, RR provides a preference value and the host name for a mail server/exchanger that will service this domain. The purpose of the SPF, or Sender Policy Framework, RR, is to allow a mail server, receiving a mail message, to use DNS queries to check the sending mail server's IP, against the sender's domain in the message to see if the message is valid. If it is not, the message can be rejected. The SPF resource record is a clone of the text information, or TXT, RR. The SPF record is valid as a native RR in BIND 9.4 and above. It replaces the TXT RR for its intended use, but is functionally the same as the TXT record that has been used in previous versions of BIND. The Domain Keys Identified Mail, or DKIM, RR identifies a mechanism for allowing e-mails to be cryptographically signed, permitting a sending domain to sign the e-mail and thereby claim responsibility for the introduction of a message into the mail stream. Receiving domains can then verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was sent by a party in possession of the private key for the sending and signing domain. The regular DNS address (A record) is defined for a 32-bit IPv4 address. To allow a domain name to be associated with a 128-bit IPv6 address, a new resource record type was created. This record type is referred to as the four A's or "Quad-A", which is a mnemonic indicating that the IPv6 address is four times the size of the IPv4 address. The Quad-A record is structured in very much the same way as the A record in both binary and master file formats; however the digits are hexadecimal and colons are used to separate fields in place of periods. Note that the record types are very different for reverse zones, which consist primarily of delegations and the Pointer or PTR record. DNS data files are written in standard format, called resource record format. Select the standard RR format to learn more about RR fields. DNS201_23 23 DNS201_23_01 Popup 1 of 1: Popup Title: Name D dot C A. Text appears in support of audio. Instruction Roll cursor over a resource record to see its full name appears. Rollover T T L displays Time to Live. Rollover N S displays name server. Rollover A displays Address for I P V 4 or quad A for I P V 6. The named.ca file establishes the names and IP addresses of the root servers on the internet. This file is used in every name server that is configured as a recursive server. If the network to which the name server is attached is not connected to the internet, the named.ca file is empty or lists the authoritative name servers for the local network. The named.ca file contains the time to live. Root server names are identified in the NS record and their IP addresses in the A records for IPv4, or quad A records for 128-bit IPv6 addresses. You need to add NS and A records for each root server included in the file. Roll your cursor over an RR to see its full name. Named.ca DNS201_23_02 Popup 2 of 4: Popup Title: Hosts dot D B. Text appears in support of audio. Bulleted list builds in support of audio. In support of audio, box appears with two sample zone names and their suggested file names. Host file names are highlighted in support of audio. Instruction roll your cursor over a resource record to see its full name appears. Rollover T T L displays time to live. Rollover S O A displays start of authority. Rollover N S displays name server. Rollover A displays Address record for I P V 4. Rollover quad A displays Address record for I P V 6. Rollover for C name displays canonical name. Rollover M X displays mail exchanger. The hosts.db file contains all the zone data about machines in the local zone, and is specified on the zone statement in the named.conf configuration file, where zones for this name server are defined. The file name is only important to DNS administrators. It can match the zone name, or follow other locally-specified naming schemes. If a zone spans more than one domain, all the domains covered by the zone are listed. A hosts.db file usually contains: a default TTL for all records in the file that do not have an explicit TTL, an SOA, one or more NS records, an A record for IPv4 addresses, or quad A for IPv6 addresses, for each host in the zone, CNAME records for each host alias in the zone, and one or more MX records. Note that this file should be named something other than simply hosts, to avoid confusion with the etc slash hosts file, which is used as a local supplement to DNS. If a DNS domain is divided into example1.mil and child.example1.mil, the corresponding zone files might be named example1.mil.db and child.example1.mil.db. Roll your cursor over an RR to see its full name. hosts.db DNS201_23_03 Popup 3 of 4: Popup Title: hosts dot rev. Text appears in support of audio. Bulleted list builds in support of audio. Instruction roll cursor over a resource record to see its full name appears. Rollover T T L displays time to live. Rollover S O A displays start of authority. Rollover N S displays name server. Rollover P T R displays Pointer. The hosts.rev file. provides zone information used for reverse lookups. The name of this file is specified on the zone statement in the named.conf configuration file, where zones for this name server are defined. The file contains TTL, SOA, NS and PTR resource records. Roll your cursor over an RR to see its full name. hosts.rev DNS201_23_04 Popup 4 of 4: Popup Title: name d dot local. Text appears in support of audio. Bulleted list builds in support of audio. Instruction roll cursor over a resource record to see its full name appears. Rollover T T L displays time to live. Rollover S O A displays start of authority. Rollover N S displays name server. Rollover P T R displays Pointer. The named.local file specifies the address for the local loop back interface, or local host, with the network address 127.0.0.1. The name of this file is specified on the zone statement in the named.conf configuration file where zone or zones for this name server are defined. Typically, a named.local file contains a default TTL for all records in the file that do not have an explicit TTL, an SOA, one or more NS records with fully qualified server and domain names, and a PTR record for local host. Roll your cursor over an RR to see its full name. Named.local Screen 23 of 33: Topic Title: D N S Server Administration. Screen Title: D N S Data File Configuration. Text Data file names appears. List of data files appears including name D dot C A or root hints, hosts dot D B, Hosts dot rev, and name D dot local. Popups are available for D dot C A or root hints, hosts dot D B, Hosts dot rev, and name D dot local. Instruction Select each data file to learn more appears. In order to function properly, DNS data files must be configured appropriately. Select a data file to see a description of its configuration. DNS201_24 24 Screen 24 of 33: Topic Title: D N S Server Administration. Screen Title: Control Entries. Text appears in support of audio. Bulleted text and sample code appears in support of audio. Portions of the sample code are highlighted in support of audio. Within data files, the control entries $INCLUDE and $ORIGIN, and $GENERATE are the only lines that do not conform to the standard RR format. The $INCLUDE control entry allows zone data for a given zone to be organized into separate files, which are included in the zone during DNS server startup. $INCLUDE statements, and the files that they identify, are optional. The $INCLUDE control entry line begins with $INCLUDE in column 1, and is followed by a filename, known as the $INCLUDE file. The $ORIGIN control entry defines the base value used to turn unqualified names into fully qualified names when processing zone file data, and is useful for changing the base value when putting more than one domain in a zone file. Although the use of the $ORIGIN control entry in a zone file is optional, it is recommended. If no $ORIGIN control entry is present in the zone file, the default origin for this zone is the domain named in the second field of the zone statement in the named.conf file. The $ORIGIN control entry starts in column 1 and is followed by a domain name that ends with a dot. The $GENERATE control entry is used to generate a series of almost identical resource records. This command provides a simpler way of addressing a common system administration challenge: generating suitable DNS names for a set of very similar networked systems. Use of $GENERATE is optional. The $GENERATE control entry starts in column 1 and is followed by two major parameters: first, the range over which to iterate, typically for an IP address, and second a regular RR format line which will have the iterated number substituted wherever $ appears. All three of these control entries can be used in files for both forward lookup and reverse lookup zones. DNS201_25 25 Knowledge Check 1 500 425 Dummy question text? Response 1. Response 2. Response 3. Response 4. Correct feedback. Incorrect feedback. Screen 25 of 33: Topic Title: D N S Server Administration. Screen Title: Knowledge Check. You will not be able to interact with this screen. This check on learning reviews D N S configuration and data files. Which configuration or data file matches each description. Contains all data about machines in local zone. Hosts dot D B data file contains all the data about machines in the local zone. Identifies any external files to be included in the name D dot conf file. The dollar include file identifies any external files to be included in the name D dot conf file. Provides names and I P addresses of root servers. The data file, name d dot c a, defines the names of root servers and provides their I P addresses. Provides address for the local loop-back interface or local host. Name D dot local data file provides the address for the local host or local loop-back interface. Specifies zone in special domain for reverse mapping. Hosts dot rev data file specifies a zone in the in adder dot arpa domain, which is a special domain that supports reverse address to name mapping. Defines initial data files, zones; master, slave, or cash only servers for delegated zone. Name D dot conf configuration file defines the data files, zones, master, slave, and cache-only servers for the delegated zone. Now check your knowledge of DNS configuration and data files. DNS201_26 26 DNS201_26_01 Popup 1 of 2: Popup Title: Same Zone Sub Domains. Text box with bullets builds in support of audio. Data files for multi-domain zones must include records for all machines and servers in each domain covered by the zone. In other words, in the hosts file or other file used to store DNS information about the local zone, when you identify a machine in the server's local domain, you only need to use the machine's name. When you identify a machine in some other domain, you must identify the machine with a fully qualified domain name in the format: machine.domain. Server and machine names in the reverse lookup hosts.rev or the localhost named.local files also need to be fully qualified with domain names. Same Zone Sub-Domains DNS201_26_02 Popup 2 of 2: Popup Title: Different Zone Sub Domains. Text box with bullets builds in support of audio. When setting up sub-domains in different zones, each parent zone must specify the delegation and list the name servers for each child zone. First, there may be a PTR record in each hosts.rev file pointing to the name of one or more primary servers. In each hosts or hosts.rev file, there should be two or more NS records for each child zone. When a parent delegates to a child outside its zone, the A record needs to specify both names and IP addresses for each of the child zones' name servers. This type of NS record requires the name of the zone below as the first field in the NS record. The name of the zone is specified in the SOA record of the zone's host file. Different Zone Sub-Domains Screen 26 of 33: Topic Title: D N S Server Administration. Screen Title: Considerations for Setting Up Sub Domains. Network hierarchy appears overlaid on world map. Left side of hierarchy labeled same zone and it contains one zone. Right side is labeled different zones and it contains two zones. Images of server and document icon appear at four nodes. Images of laptops appear at several nodes. Instruction select same zone or different zones to learn more appear. In setting up your DNS zone structure, you can chose to set up sub-domains in the same zone, or in different zones. The simplest method is to include the sub-domain in the parent domain's zone. This means that one set of DNS servers and data files applies to all the machines regardless of their domain. The same-zone method is simple and easy to administer. A disadvantage is that one set of servers is responsible for all the machines in all of the zone's domains. It is possible for these servers to become over-utilized and cause performance issues. You can also place different domains in different zones. Although this will allow you to assign different sets of servers to different clients and balance your server load, it is more complex to set up, since you must specify how clients in one zone obtain DNS information about hosts in another zone. Select same zone or different zone to learn more about data file requirements for each. DNS201_27 27 Knowledge Check 1 500 425 Identify whether each statement applies to setting up same-zone or different-zone sub-domains? Make your selections; then select Done. You include the sub-domain in the parent domain's zone. Same Zone Different Zone Correct. When you set up a sub-domain in the same zone, you are including it in the parent zone's domain. Incorrect. When you set up a sub-domain in the same zone, you are including it in the parent zone's domain. You must specify how clients in one domain get DNS information about hosts in another domain. Same Zone Different Zone Correct. When you set up sub-domains in different zones, you must specify how clients in one domain get DNS information about hosts in another domain. Incorrect. When you set up sub-domains in different zones, you must specify how clients in one domain get DNS information about hosts in another domain. One set of servers is responsible for all machines in all of the zone's domains. Same Zone Different Zone Correct. One set of servers is responsible for all machines in all of the zone's domains. Incorrect. One set of servers is responsible for all machines in all of the zone's domains. Allows you to avoid overloading servers. Same Zone Different Zone Correct. Setting up sub-domains in different zones allows you to avoid overloading servers. Incorrect. Setting up sub-domains in different zones allows you to avoid overloading servers. Data files for multi-domain zones must include records for all machines and servers in each domain within the zone. Same Zone Different Zone Correct. Data files for multi-domain zones must include records for all machines and servers in each domain within the zone. Incorrect. Data files for multi-domain zones must include records for all machines and servers in each domain within the zone. Screen 27 of 33: Screen Title: Knowledge Check. Use your keyboard to cycle through the list of options. Check your knowledge of the differences between setting up sub-domains in the same zone and in different zones. DNS201_28 28 Screen 28 of 33: Screen Title: Overview of D N S Security Concerns. Five text boxes appear in support of audio. Two text boxes appear in a column at center of screen in support of audio. Name servers exposed to the Internet are subject to a wide variety of attacks. Host take-overs are attacks against the name server software that may allow an intruder to compromise the server and take control of the host. This often leads to further compromise of the network. Denial of service, or DoS attacks, even one directed at a single DNS server, may affect an entire network by preventing users from translating host names into the necessary IP addresses. Spoofing attacks try to induce your name server to cache false resource records, and could lead unsuspecting users to fraudulent sites. Information leakage from a seemingly innocent zone transfer could expose internal network topology information that can be used to plan further attacks. A name server could even be an unwitting participant in attacks on other sites. DNS201_29 29 DNS201_29_01 Popup 1 of 6: Popup Title: Eliminate Single Points of Contact. Text box with bullets appears in support of audio. Eliminate single points of failure in the DNS infrastructure to combat denial of service attacks and prevent accidental service outages. Where possible, place DNS servers in more than one autonomous system. To prevent single points of failure, avoid placing all of your name servers on a single subnet, behind a single router, or behind a single leased line. Eliminate Single Points of Contact DNS201_29_02 Popup 2 of 6: Popup Title: Separate Servers. Line of text appears at top center of screen. Server labeled advertising server with database icon appears on left with text supporting audio. Image of internet cloud appears in the center. Image of server labeled resolving appears on right with database icon appears on right with text supporting audio. Consider using separate name servers, each configured to play a specific role. Frequently, different security polices can be applied to these servers so that even if one server is compromised, the other servers will continue to function normally. Consider creating two kinds of name server, each optimized for a particular function: advertising name servers and resolving name servers. An advertising name server would commonly be used as an external name server that is authoritative for your DNS zones. It would "advertise" this DNS information to the Internet. Since it should not be queried for zones for which it is not authoritative, it should be configured as a non-recursive server. Therefore, the server would only provide resolution for the zones for which it has authoritative information. A resolving name server would commonly be used to provide name resolution services to internal clients. It may or may not be configured as authoritative for internal zones. Since it must find DNS information requested by internal hosts, it should be configured as a recursive server. However, it should only answer queries from trusted sources, not from the Internet. By adopting this strategy, the external advertising name server is configured to provide little service other than answering queries for which it is authoritative. The internal resolving name server must provide recursion, and is therefore somewhat more susceptible to attack since it must accept data from other DNS servers. Additional protection of the resolving name server can be provided via other means such as packet filtering and restricting the server to respond only to known hosts. In this manner, if the resolving server were to be compromised or its cache "poisoned", the advertising server's authoritative zone information would be unaffected, thus limiting the potential damage. Similarly, if the resolving name servers are also configured to be authoritative for internal zones, a compromise of the advertising name servers would not affect the normal operation of the internal clients of the resolving name servers. Separate Servers DNS201_29_03 Popup 3 of 6: Popup Title: Filter Traffic. Line of text appears at top center of screen. Server labeled dedicated host with database icon appears on left with text supporting audio. Text box with text and bullets appears on right in support of audio. Consider filtering out unnecessary traffic. By running name servers on dedicated hosts that don't provide any other services, there is no need for them to respond to non-DNS traffic, therefore reducing the possibility of the name server being compromised by a vulnerability in some other piece of software. For authoritative DNS servers providing public name resolution to the Internet, everything but traffic from the Internet to 53/udp and 53/tcp on the server can be safely filtered. Name servers that only provide name resolution services to internal clients can be filtered to allow only internal clients to access 53/udp and 53/tcp on the name server, while allowing recursive servers to make outbound queries to other name servers. Filter Traffic DNS201_29_04 Popup 4 of 6: Popup Title: Restrict Zone Transfer. Two text boxes appear with bullets built in support of audio. Restricting zone transfers is an important step in securing a name server. It prevents others from taxing your name server's resources, listing the contents of your zones, and identifying new targets on your network, such as routers and network infrastructure equipment, mail servers, other name servers, file servers, and anything else in your DNS records. To secure DNS, ensure that all authoritative name servers, regardless of their status, have restrictions placed on zone transfers. If possible, the most secure configuration is to disable zone transfers altogether and use a cryptographically secure method of transferring zone files to other authoritative servers. The host -L command and dig's axfr option can be useful for testing zone transfer restrictions since those commands are implemented as zone transfers. Restrict Zone Transfer DNS201_29_05 Popup 5 of 6: Popup Title: Authenticate with T sig. Text and bulleted list appear in support of audio. Image of key is displayed in top left of screen. With BIND 8.2 and later name servers, you can use Transaction Signatures, or TSIG, to cryptographically authenticate and verify zone data. TSIG uses a shared-secret cryptographic signature to authenticate authoritative zone data. Use of TSIG requires that you configure a shared key on your authoritative name servers and then instruct them to use the key to sign communication with each other. TSIG requires participating name servers to have their system clocks synchronized. The DNS Security Technical Implementation Guide (STIG) requires the use of TSIG or other equivalent authentication, for example, VPN tunnel, to protect all DNS zone transfers. Authenticate with T sig DNS201_29_06 Popup 6 of 6: Popup Title: Configure cash poisoning protection. Image of server appears on right side of screen, labeled recursive server with database and cache icons next to it appears on right. Name servers that provide recursive resolution services to the Internet at large may be susceptible to cache poisoning. Cache poisoning occurs when a name server caches bogus data for a domain name. This can result in denial-of-service or man-in-the-middle attacks. An attacker making a recursive query to a name server that provides recursion, can cause a name server to look up and cache information contained in zones under their control. Therefore, the victim name server is made to query their malicious name servers, resulting in the victim caching and serving bogus data. To reduce this risk, BIND administrators have four options, depending on the software version in use, at least one of which should be chosen: disable recursion entirely, if possible, on BIND 4.9 and up; restrict the addresses that can make queries of any type, to the name server on BIND 8 and up; restrict the addresses that can make recursive queries to the name server on BIND 8.2.1 and up; and disable the fetching of glue records, if possible only on BIND versions prior to version 9. Administrators using DNS software other than BIND should consult their documentation for specifics of cache poisoning protection made available by their vendor. In all cases, ensure that the DNS server software in use provides UDP Source Port Randomization, to protect against attacks revealed in 2008. Configure cache poisoning protection Screen 29 of 33: Screen Title: Methods for D N S Security. Bulleted list builds in center of screen in support of audio. Popups are available for Eliminate Single poitns of Contact, Separate Servers, Filter traffic, Restric zone transfer, Authenticate with T Sig and Configure cash poisoning protections. Instructions to select each bullet to learn more appears at bottom center of screen. There are various methods for achieving DNS security, including eliminating single points of failure, using separate servers, filtering traffic, restricting zone transfer, authenticating with TSIG, and configuring cache poisoning protection. Select each method to learn how it can be deployed to secure DNS. DNS201_30 30 Knowledge Check 1 500 425 Dummy question text? Response 1. Response 2. Response 3. Response 4. Correct feedback. Incorrect feedback. Screen 30 of 33. Screen Title: Knowledge Check. You will not be able to interact with this screen. This screen reinforces proper use of DNS security methods as follows. Use TSIG to authenticate communications between servers. Configure cache-poisoning protection to prevent recursive name servers from storing bogus data for a domain name, which can lead to denial-of-service attacks or man-in-the-middle attacks. Reduce the exposure of DNS servers to internet traffic by allowing only internal clients access 53/udp and 53/tcp on recursive name servers. Avoid single points of failure to prevent accidental power outages or DoS attacks by not placing all servers on a single sub-net, behind a single router or leased line, or within a single routing Autonomous System where possible. Place restrictions on zone transfers to prevent potential attackers from identifying new network targets, by limiting and controlling the way authoritative servers communicate about DNS records, components, and so on. Use separate servers to exposure to prevent internet traffic, by dedicating servers to provide either advertising or resolving service. Check your knowledge of types of DNS attacks. DNS201_31 31 Knowledge Check 1 700 425 Select the security mechanism that best matches the description; then select Done to submit your answer. Use this method to protect data during zone transfers by requiring authoritative servers to sign communications with each other, using a pre-configured key. Filter traffic Eliminate single points of failure Authenticate with TSIG Restrict zone transfer Configure cache-poisoning protection Separate servers Correct. Use TSIG to authenticate communications between servers. Incorrect. Use TSIG to authenticate communications between servers. Use this method to prevent recursive name servers from storing bogus data for a domain name, which can lead to denial-of-service attacks or man-in-the-middle attacks. Filter traffic Eliminate single points of failure Authenticate with TSIG Restrict zone transfer Configure cache-poisoning protection Separate servers Correct. Configure cache-poisoning protection to prevent recursive name servers from storing bogus data for a domain name, which can lead to denial-of-service attacks or man-in-the-middle attacks. Incorrect. Configure cache-poisoning protection to prevent recursive name servers from storing bogus data for a domain name, which can lead to denial-of-service attacks or man-in-the-middle attacks. Use this method to reduce DNS server exposure to internet traffic, by allowing only internal clients to access 53/udp and 53/tcp on recursive name servers. Filter traffic Eliminate single points of failure Authenticate with TSIG Restrict zone transfer Configure cache-poisoning protection Separate servers Correct. Reduce the exposure of DNS servers to internet traffic by allowing only internal clients access 53/udp and 53/tcp on recursive name servers. Incorrect. Reduce the exposure of DNS servers to internet traffic by allowing only internal clients access 53/udp and 53/tcp on recursive name servers. Use this method to prevent accidental power outages or DoS attacks by not placing all servers on a single sub-net, behind a single router or leased line, or within a single routing Autonomous System where possible. Filter traffic Eliminate single points of failure Authenticate with TSIG Restrict zone transfer Configure cache-poisoning protection Separate servers Correct. Avoid single points of failure to prevent accidental power outages or DoS attacks by not placing all servers on a single sub-net, behind a single router or leased line, or within a single routing Autonomous System where possible. Incorrect. Avoid single points of failure to prevent accidental power outages or DoS attacks by not placing all servers on a single sub-net, behind a single router or leased line, or within a single routing Autonomous System where possible. Use this method to prevent potential attackers from identifying new network targets, by limiting and controlling the way authoritative servers communicate about DNS records, components, and so on. Filter traffic Eliminate single points of failure Authenticate with TSIG Restrict zone transfer Configure cache-poisoning protection Separate servers Correct. Place restrictions on zone transfers to prevent potential attackers from identifying new network targets, by limiting and controlling the way authoritative servers communicate about DNS records, components, and so on. Incorrect. Place restrictions on zone transfers to prevent potential attackers from identifying new network targets, by limiting and controlling the way authoritative servers communicate about DNS records, components, and so on. To prevent DNS servers from exposure to internet traffic, dedicate servers to provide either advertising or resolving service. Filter traffic Eliminate single points of failure Authenticate with TSIG Restrict zone transfer Configure cache-poisoning protection Separate servers Correct. Use separate servers to prevent exposure to internet traffic, by dedicating servers to provide either advertising or resolving service. Incorrect. Use separate servers to prevent exposure to internet traffic, by dedicating servers to provide either advertising or resolving service. Screen 31 of 33: Screen Title: Knowledge Check. Use your keyboard to cycle through the list of options. Now check your knowledge about basic DNS security mechanisms. DNS201_32 32 DNS201_32_01 Popup 1 of 4: Popup Title: Introduction to DNS. Scrollable list of summary bullets appears in support of audio. Rollover text displays further details. Rollover Hierarchical Structure. DNS has a tree like hierarchical structure that has a single unnamed root at the top, and expands downward and outward into branches and sub branches. Every branch is a domain. Every sub branch is a sub domain. Domains and sub domains are relative. Rollover Zones states Portion of the DNS over which a name server is authoritative. Rollover authoritative states Authoritative servers maintain a zone file, and cash with time to live or T T L. rollover non authoritative states Non authoritative name servers are Not updated from primary, not delegated to a zone, do not respond to queries from Authoritative Server, and Request and cache data. Rollover recursive states Recursive name servers are, Fully resolve recursive queries, and Begin queries at root. Rollover non recursive states Non-recursive name servers, Check their own database only, and Respond with I P address or referral. Rollover zone transfers states Zone transfer is a method of DNS Records Transfer, and can be full or incremental. Zone transfers occur when either, A secondary server first starts up, A query requests information, or The Authoritative server sends DNS Notify message. Rollover Recursive Query states Requests a complete I P address for an F Q D N. Rollover iterative query states Requests either the complete I P address for an F Q D N, or a referral to another name server who would know. Rollover Inverse Query states Requests a domain or host name for a specified I P address. Rollover stub resolver states Stub resolvers are the simplest type of resolver. It is usually installed on a client. Follow these steps to resolve queries Step 1. Application queries the stub resolver. Step 2. Stub resolver forwards request to a recursive name server and waits for response Step 3. Stub resolver returns an answer to the Application. The answer is either an I P address, or an error message. Rollover iterative resolver states Iterative resolvers send queries and process responses on behalf of clients. They are installed on recursive servers. Follow these steps to resolve queries: Step 1. Application queries the stub resolver. Step 2. The iterative resolver queries its own cache, and then the root authoritative server. Step 3. The root authoritative server responds with either an answer or a referral to another name server. Step 4. The iterative resolver then queries the referred server, which may also respond with a fully answer or a referral to another name server. Step 5. The Query cycle continues until: Step 6 a. A full answer is received by the iterative resolver and returned to the requesting application, or Step 6 b. One of the referred servers returns an error. Introduction to DNS DNS201_32_02 Popup 2 of 4: Popup Title: Policy Requirements. Images of the people representing the Information Hierarchy appear in support of audio. Images are labeled from top to bottom, D A A, I A M, and I A O. Below I A O images labeled privileged user and authorized user appear on the same level. Rollover text displays further details. Rollover I A states Information Assurance, or I A, includes a wide range of activities designed to protect and defend information and information systems by ensuring their confidentiality, integrity and availability. Rollover D A A states D A A Responsibilities: OVERSEE I A PROGRAM incorporate I A into management processes Grant formal accreditation. COORDINATE I A ACTIVITY, Ensure events and configuration changes are reported to affected parties MANAGE I A STAFFING, Assign all I A positions in writing , Provide appointees with responsibilities and training And Ensure all I A emz are U.S. citizens and meet access requirements. I A integrates the capabilities of people, operations, and technology to provide protection of information and information systems necessary to accomplish D o D missions. Rollover I A M states IAM Responsibilities: ADVISE DAA Act as the DAA's I A technical advisor Report all changes and incidents to DAA and coordinate the appropriate response. SUPERVISE IAO, Certify IAOs are U.S. citizens and meet requirements. Ensure I A ohz are appointed in writing and are following policies and procedures, Confirm I A ohz and Privileged Users receive training, education, and certification. OVERSEE PROGRAM PLAN. Develop and maintain IA program plan, Establish ownership responsibilities, Ensure certification documentation is developed, Certify that compliance monitoring occurs; inspections, tests, and IA management reviews are coordinated and tracked; and results are reviewed. Rollover I A O states IAO Responsibilities: CONTROL ACCESS. Ensure users have appropriate security clearance and are aware of their responsibilities, Ensure software, hardware, and firmware comply with guidelines. ASSIST I A M. Track and report management review items, Initiate protective/corrective measures. ENFORCE POLICY. Implement and enforce all IA policies and procedures. Ensure IA-related documentation is current and accessible. Rollover Privileged User states Privileged User Responsibilities: In addition to Authorized User responsibilities: MANAGE TECHNOLOGY. Configure or operate technology, Establish/manage user accounts and access controls, Notify IAO of any changes impacting IA. Rollover Authorized user states Authorized User Responsibilities: ACCESS. Hold U.S. Government security clearance equal to access level, Access items for which they are authorized and have a need-to-know, Observe policies and procedures for secure use of D O D information systems, terminals, and workstations, REPORT/PROTECT, Inform the IAO of events, potential threats and vulnerabilities, and when access is no longer required, Protect authenticators and report any compromise of authenticators to IAO. Ensure that system media and output are properly marked and handled. OBTAIN AUTHORIZATION. Coordinate with IAO and IAM before taking action with IA mechanisms, Obtain authorization to relocate/change equipment or connectivity. Policy Requirements DNS201_32_03 Popup 3 of 4: Popup Title: D N S Server Administration. List of summary bullets appears in support of audio. Rollover name D dot conf states name D dot conf file Defines server type, Establishes zone authority, Defines data files to be used in the zone. Rollover resolv dot conf states Identifies name servers for client queries. Rollover data files states Describe the data for the zones, and include the name D dot c a, hosts, hosts dot rev and name D dot local files, and any partial zone files identified on dollar INCLUDE control entries. Statements rollover states Statements are used to establish the operational functionality of the zone. name D dot conf supports the following commonly used statements: a c l, include, key, logging, options, server, and zones. A C L rollover states Controls access to the server by defining groups of hosts who may be allowed or denied access to the name server. Include rollover states Inserts files to be included in a name D dot conf file, at the point where this statement is. Key rollover states Specifies a key I D used for authentication and authorization on a particular name server. Logging rollover states Specifies a key I D used for authentication and authorization on a particular name server. Logging rollover states Specifies the information the server logs and the destination of log messages. Options rollover states Controls global server configuration options and sets default values for other statements. Server rollover states Designates configuration options associated with a remote name server, particularly regarding notifications and zone transfers. Zones rollover states Selectively applies options on a per zone basis. Four types rollover states data file names with descriptions, including name d dot c a Defines names of root servers and provides their I P addresses. Hosts dot d b Contains all data about the machines in the local zone that serves the name server. Hosts dot rev Specifies a zone in the in adder dot arpa domain, which is a special domain that allows reverse address to name mapping. Name d dot local Provides the address for the local loop back interface, or local host. Rollover R arz states The Start of authority, or S O A, R R establishes the name of the zone, an e-mail contact, and time and refresh values that apply to the zone. The Name server , or N S, R R establishes the authoritative name server or servers for the domain defined by the S O A record, or the sub domain. The A R R identifies the Internet address for a host, or name to address. The Pointer, or P T R, or address to name, R R is used in reverse lookup zones to support reverse lookup. The canonical name, C NAME, or nickname, R R The Mail Exchanger , or M X R R provides a preference value and the host name for a mail server/exchanger that will service this zone. Finally, there are the The text information, T X T, and Sender Policy Framework, or S P F, R arz. The S P F is a clone of the T X T. It allows a mail server, receiving a mail message, to use D N S queries to check the sending mail server’s I P, against the sender’s domain in the message as one check designed to reduce acceptance of forged e-mail. Services S R V R arz, which documents the services available on the host, and Domain Keys Identified Mail, or D KIM, which identifies a mechanism for allowing e-mails to be cryptographically signed, permitting a sending domain to sign the e-mail and claim responsibility for the introduction of a message into the mail stream. Receiving domains can then verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was sent by a party in possession of the private key for the sending and signing domain. Standard format rollover states The standard RR format is: name space t t l space class space record type space type hyfen specific hyfen data. Special characters rollover states. hyfen A free standing dot in the name field refers to the current domain. At symbol, a free standing at symbol in the name field denotes the current origin. Two free standing dots represent the null domain name of the root when used in the name field. A backslash preceding a character, other than 0 through 9 or a dot, indicates that the character 's special meaning does not apply. A backslash preceding three digits between 0 and 9, where each D is a digit, is the octet corresponding to the decimal number described by D D D. The resulting octet is assumed to be text and is not checked for special meaning. Use parentheses to group data that crosses a line. In effect, line terminations are not recognized within parentheses. A semicolon starts a comment. The remainder of the line is ignored. An asterisk signifies a wildcard. Dollar include rollover states Allows zone data to be organized into separate files, which are included in the zone at startup. Is optional. Dollar origin Changes the origin in a data file, Resets the origin for relative domain names, Places more than one zone in a data file, is optional. Same zone rollover states The simplest method is to include the sub domain in the parent domain's zone. This means that one set of DNS servers and data files applies to all the machines regardless of their domain. The same-zone method is simple and easy to administer Data file requirements: Hosts file Local domain equals machine name. Other domain equals fully qualified name. hosts dot rev and name d dot local Fully qualified server and machine names. Different zones rollover states This will allow you to assign different sets of servers to different clients and balance your server load. It is more complex to set up, since you must specify how clients in one zone obtain D N S information about hosts in another zone. Data file Requirements: hosts dot rev file, P T R pointing to parent zone master servers, hosts file, Zone N S identifying each name server in each zone, A records identify immediate child zones. D N S Server Administration DNS201_32_04 Popup 4 of 4: Popup Title: D N S Security Mechanisms. List of summary bullets appears in support of audio. Rollover text displays further details. Rollover host take overs states Attacks against the name server software that may allow an intruder to compromise the server and take control of the host. This often leads to further compromise of the network. Rollover denial of service states Affect an entire network by preventing users from translating hostnames into the necessary I P addresses. Rollover spoofing states Try to induce your name server to cache false resource records, and could lead unsuspecting users to fraudulent sites. Rollover information leaking states Expose internal network topology information that can be used to plan further attacks. Rollover unwitting participation states Name servers can be forced to participate in attack without the knowledge of their administrators. Rollover single points of failures states Eliminate single points of failure in the DNS infrastructure to combat Denial of service attacks and prevent accidental service outages. Avoid placing all of your name servers, On a single subnet, Behind a single router, Behind a single leased line, Within a single autonomous system. Rollover separate servers states Consider using separate name servers, each configured to play a specific role. An advertising name server would commonly be used as an, external name server that is authoritative for your D N S zones. A resolving name server would commonly be used to provide name resolution services to internal clients. It may or may not be configured as authoritative for internal zones. It should be configured as a recursive server. However, it should only answer queries from trusted sources, not from the Internet. Rollover filter traffic states Consider filtering traffic, Name servers for public name resolution to the internet, Name servers for internal name resolution. Restrict zone transfer rollover states Restricting zone transfers is an important step in securing a name server. Restrict zone transfer on all name servers, regardless of status, Disable zone transfer altogether, Use cryptographically secure transfer methods, host dash el one. A X F R. Rollover T sig states Uses shared secret cryptographic signature to authenticate authoritative zone data. The DNS Security Technical Implementation Guide, stig requires the use of T SIG or other equivalent authentication, for example, V P N tunnel to protect all DNS zone transfers. Configuration Requirements: Configure a shared key, Instruct name servers to use the key to communicate, Synchronize system clocks. Rollover cash poisoning protection states Name servers that provide recursive resolution services to the Internet at large may be susceptible to cache poisoning. To configure, choose at least one of these methods: Disable recursion entirely BIND 4 point 9 and up, Restrict the addresses that can make queries to the server BIND 8 and up, Restrict the addresses that can make recursive queries to the name server BIND 8 point 2 point 1 and up, Disable the fetching of glue records, if possible BIND versions prior to 9 only, If possible, ensure that the D N S server software in use provides U D P Source Port Randomization, to protect against attacks revealed in 2008. D N S Security Mechanisms Screen 32 of 33: Screen Title: Summary. In support of audio, four text boxes appear with selectable headings Introduction to D N S, which displays image of a D N S hierarchy. Policy Requirements, which displays images of five persons. D N S Server Administration, which displays an image of a server and an icon. D N S security mechanisms, which displays two computer networks, with a lock and the word threats. Instructions are displayed to select each topic for review. This lesson introduced the domain name system and policy requirements. It also provided an overview of DNS server administration and DNS security mechanisms. Select a topic to review what you have learned. For a more thorough review, select Lesson Map and select a topic. DNS201_33 33 Screen 33 of 33: Screen Title: Conclusion. The word Congratulations displays in support of audio. Text box appears with list of objectives in support of audio Congratulations! You have completed the Basic DNS Concepts for Systems Administration lesson! You should now be able to identify basic DNS functions and components, DoD policy requirements, server administration, and mechanisms for security.