DOCSLIB.ORG

BIND 9 Administrator Reference Manual Copyright C 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Internet Systems Consortium, Inc

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
BIND 9 Administrator Reference Manual Copyright C 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Internet Systems Consortium, Inc BIND 9 Administrator Reference Manual Copyright c 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Internet Systems Consortium, Inc. (”ISC”) Copyright c 2000, 2001, 2002, 2003 Internet Software Consortium. Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED ”AS IS” AND ISC DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Internet System Consortium 950 Charter Street Redwood City, California USA http://www.isc.org/ Contents 1 Introduction 1 1.1 Scope of Document . 1 1.2 Organization of This Document . 1 1.3 Conventions Used in This Document . 1 1.4 The Domain Name System (DNS) . 2 1.4.1 DNS Fundamentals . 2 1.4.2 Domains and Domain Names . 2 1.4.3 Zones . 2 1.4.4 Authoritative Name Servers . 3 1.4.4.1 The Primary Master . 3 1.4.4.2 Slave Servers . 3 1.4.4.3 Stealth Servers . 3 1.4.5 Caching Name Servers . 4 1.4.5.1 Forwarding . 4 1.4.6 Name Servers in Multiple Roles . 4 2 BIND Resource Requirements 5 2.1 Hardware requirements . 5 2.2 CPU Requirements . 5 2.3 Memory Requirements . 5 2.4 Name Server Intensive Environment Issues . 5 2.5 Supported Operating Systems . 6 3 Name Server Configuration 7 3.1 Sample Configurations . 7 3.1.1 A Caching-only Name Server . 7 3.1.2 An Authoritative-only Name Server . 7 3.2 Load Balancing . 8 3.3 Name Server Operations . 9 3.3.1 Tools for Use With the Name Server Daemon . 9 3.3.1.1 Diagnostic Tools . 9 3.3.1.2 Administrative Tools . 9 3.3.2 Signals . 13 4 Advanced DNS Features 15 4.1 Notify . 15 4.2 Dynamic Update . 15 4.2.1 The journal file . 16 4.3 Incremental Zone Transfers (IXFR) . 16 4.4 Split DNS . 16 4.4.1 Example split DNS setup . 17 4.5 TSIG . 19 4.5.1 Generate Shared Keys for Each Pair of Hosts . 20 4.5.1.1 Automatic Generation . 20 4.5.1.2 Manual Generation . 20 4.5.2 Copying the Shared Secret to Both Machines . 20 4.5.3 Informing the Servers of the Key’s Existence . 20 4.5.4 Instructing the Server to Use the Key . 21 4.5.5 TSIG Key Based Access Control . 21 4.5.6 Errors . 21 4.6 TKEY . 21 4.7 SIG(0) . 22 4.8 DNSSEC . 22 i CONTENTS 4.8.1 Generating Keys . 22 4.8.2 Signing the Zone . 23 4.8.3 Configuring Servers . 23 4.9 DNSSEC, Dynamic Zones, and Automatic Signing . 25 4.9.1 Converting from insecure to secure . 25 4.9.2 Dynamic DNS update method . 26 4.9.3 Fully automatic zone signing . 26 4.9.4 Private-type records . 26 4.9.5 DNSKEY rollovers . 27 4.9.6 Dynamic DNS update method . 27 4.9.7 Automatic key rollovers . 27 4.9.8 NSEC3PARAM rollovers via UPDATE . 28 4.9.9 Converting from NSEC to NSEC3 . 28 4.9.10 Converting from NSEC3 to NSEC . 28 4.9.11 Converting from secure to insecure . 28 4.9.12 Periodic re-signing . 28 4.9.13 NSEC3 and OPTOUT . 28 4.10 Dynamic Trust Anchor Management . 28 4.10.1 Validating Resolver . 28 4.10.2 Authoritative Server . 29 4.11 PKCS #11 (Cryptoki) support . 29 4.11.1 Prerequisites . 30 4.11.1.1 Building OpenSSL for the AEP Keyper on Linux . 31 4.11.1.2 Building OpenSSL for the SCA 6000 on Solaris . 31 4.11.1.3 Building OpenSSL for SoftHSM . 32 4.11.2 Building BIND 9 with PKCS#11 . 32 4.11.2.1 Configuring BIND 9 for Linux with the AEP Keyper . 32 4.11.2.2 Configuring BIND 9 for Solaris with the SCA 6000 . 33 4.11.2.3 Configuring BIND 9 for SoftHSM . 33 4.11.3 PKCS #11 Tools . 33 4.11.4 Using the HSM . 33 4.11.5 Specifying the engine on the command line . 35 4.11.6 Running named with automatic zone re-signing . 35 4.12 IPv6 Support in BIND 9 . 36 4.12.1 Address Lookups Using AAAA Records . 36 4.12.2 Address to Name Lookups Using Nibble Format . 36 5 The BIND 9 Lightweight Resolver 37 5.1 The Lightweight Resolver Library . 37 5.2 Running a Resolver Daemon . 37 6 BIND 9 Configuration Reference 39 6.1 Configuration File Elements . 39 6.1.1 Address Match Lists . 41 6.1.1.1 Syntax . 41 6.1.1.2 Definition and Usage . 41 6.1.2 Comment Syntax . ..
Load more

Recommended publications
  • Domain Name System 1 Domain Name System
    Domain Name System 1 Domain Name System The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. A Domain Name Service translates queries for domain names (which are easier to understand and utilize when accessing the internet) into IP addresses for the purpose of locating computer services and devices worldwide. An often-used analogy to explain the Domain Name System is that it serves as the phone book for the Internet by translating human-friendly computer hostnames into IP addresses. For example, the domain name www.example.com translates to the addresses 192.0.43.10 (IPv4) and 2620:0:2d0:200::10 (IPv6). The Domain Name System makes it possible to assign domain names to groups of Internet resources and users in a meaningful way, independent of each entity's physical location. Because of this, World Wide Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device. Internet domain names are easier to remember than IP addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). Users take advantage of this when they recite meaningful Uniform Resource Locators (URLs) and e-mail addresses without having to know how the computer actually locates them. The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain.
    [Show full text]
  • Rssac026v2: RSSAC Lexicon
    RSSAC026v2: RSSAC Lexicon An Advisory from the ICANN Root Server System Advisory Committee (RSSAC) 12 March 2020 RSSAC Lexicon Preface This is an Advisory to the Internet Corporation for Assigned Names and Numbers (ICANN) Board of Directors and the Internet community more broadly from the ICANN Root Server System Advisory Committee (RSSAC). In this Advisory, the RSSAC defines terms related to root server operations for the ICANN Community. The RSSAC seeks to advise the ICANN community and Board on matters relating to the operation, administration, security and integrity of the Internet’s Root Server System. This includes communicating on matters relating to the operation of the Root Servers and their multiple instances with the technical and ICANN community, gathering and articulating requirements to offer to those engaged in technical revisions of the protocols and best common practices related to the operational of DNS servers, engaging in ongoing threat assessment and risk analysis of the Root Server System and recommend any necessary audit activity to assess the current status of root servers and root zone. The RSSAC has no authority to regulate, enforce, or adjudicate. Those functions belong to others, and the advice offered here should be evaluated on its merits. The RSSAC has relied on the RSSAC Caucus, a group of DNS experts who have an interest in the Root Server System to perform research and produce this publication. A list of the contributors to this Advisory, references to RSSAC Caucus members’ statement of interest, and RSSAC members’ objections to the findings or recommendations in this Report are at the end of this document.
    [Show full text]
  • DNS) Deployment Guide
    Archived NIST Technical Series Publication The attached publication has been archived (withdrawn), and is provided solely for historical purposes. It may have been superseded by another publication (indicated below). Archived Publication Series/Number: NIST Special Publication 800-81 Revision 1 Title: Secure Domain Name System (DNS) Deployment Guide Publication Date(s): April 2010 Withdrawal Date: September 2013 Withdrawal Note: SP 800-81 Revision 1 is superseded in its entirety by the publication of SP 800-81-2 (September 2013). Superseding Publication(s) The attached publication has been superseded by the following publication(s): Series/Number: NIST Special Publication 800-81-2 Title: Secure Domain Name System (DNS) Deployment Guide Author(s): Ramaswamy Chandramouli, Scott Rose Publication Date(s): September 2013 URL/DOI: http://dx.doi.org/10.6028/NIST.SP.800-81-2 Additional Information (if applicable) Contact: Computer Security Division (Information Technology Lab) Latest revision of the SP 800-81-2 (as of August 7, 2015) attached publication: Related information: http://csrc.nist.gov/ Withdrawal N/A announcement (link): Date updated: ƵŐƵƐƚϳ, 2015 Special Publication 800-81r1 Sponsored by the Department of Homeland Security Secure Domain Name System (DNS) Deployment Guide Recommendations of the National Institute of Standards and Technology Ramaswamy Chandramouli Scott Rose i NIST Special Publication 800-81r1 Secure Domain Name System (DNS) Deployment Guide Sponsored by the Department of Homeland Security Recommendations of the National Institute of Standards and Technology Ramaswamy Chandramouli Scott Rose C O M P U T E R S E C U R I T Y Computer Security Division/Advanced Network Technologies Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899 April 2010 U.S.
    [Show full text]
  • DNS Introduction
    DNS Introduction www.what-is-my-ip-address.com (C) Herbert Haas 2005/03/11 1 “Except for Great Britain. According to ISO 3166 and Internet tradition, Great Britain's top-level domain name should be gb. Instead, most organizations in Great Britain and Northern Ireland (i.e., the United Kingdom) use the top-level domain name uk. They drive on the wrong side of the road, too.” DNS and BIND book Footnote to the ISO 3166 two-letter country code TLDs 2 DNS Tree Growth 162,128,493 by 2002/7 (C) Herbert Haas 2005/03/11 3 The ISC about the new DNS survey method: The new survey works by querying the domain system for the name assigned to every possible IP address. However, this would take too long if we had to send a query for each of the potential 4.3 billion (2^32) IP addresses that can exist. Instead, we start with a list of all network numbers that have been delegated within the IN-ADDR.ARPA domain. The IN-ADDR.ARPA domain is a special part of the domain name space used to convert IP addresses into names. For each IN- ADDR.ARPA network number delegation, we query for further subdelegations at each network octet boundary below that point. This process takes about two days and when it ends we have a list of all 3-octet network number delegations that exist and the names of the authoritative domain servers that handle those queries. This process reduces the number of queries we need to do from 4.3 billion to the number of possible hosts per delegation (254) times the number of delegations found.
    [Show full text]
  • DNS and the DNS Cache Poisoning Attack
    Lecture 17: DNS and the DNS Cache Poisoning Attack Lecture Notes on “Computer and Network Security” by Avi Kak ([email protected]) June 25, 2021 3:21pm ©2021 Avinash Kak, Purdue University Goals: The Domain Name System BIND Configuring BIND Running BIND on your Ubuntu laptop Light-Weight Nameservers (and how to install them) DNS Cache Poisoning Attack Writing Perl and Python code for cache poisoning attacks Dan Kaminsky’s More Virulent DNS Cache Poisoning Attack CONTENTS Section Title Page 17.1 Internet, Harry Potter, and the Magic of DNS 3 17.2 DNS 5 17.3 An Example That Illustrates Extensive DNS 13 Lookups in Even the Simplest Client-Server Interactions 17.4 The Domain Name System and The dig Utility 28 17.5 host, nslookup, and whois Utilities for Name 42 Lookup 17.6 Creating a New Zone and Zone Transfers 45 17.7 DNS Cache 48 17.7.1 The TTL Time Interval 51 17.8 BIND 56 17.8.1 Configuring BIND 58 17.8.2 An Example of the named.conf Configuration File 64 17.8.3 Running BIND on Your Ubuntu Laptop 68 17.9 What Does it Mean to Run a Process in a 70 chroot Jail? 17.10 Phishing versus Pharming 73 17.11 DNS Cache Poisoning 74 17.12 Writing Perl and Python Code for Mounting a 81 DNS Cache Poisoning Attack 17.13 Dan Kaminsky’s More Virulent Exploit for 92 DNS Cache Poisoning 17.14 Homework Problems 99 Computer and Network Security by Avi Kak Lecture 17 Back to TOC 17.1 INTERNET, HARRY POTTER, AND THE MAGIC OF DNS If you have read Harry Potter, you are certainly familiar with the use of owl mail by the wizards and the witches.
    [Show full text]
  • Understanding Implications of DNS Zone Provisioning
    Understanding Implications of DNS Zone Provisioning Andrew J. Kalafut Craig A. Shue Minaxi Gupta [email protected] [email protected] [email protected] Computer Science Department Indiana University Bloomington, IN ABSTRACT a domain need to synchronize with each other in their view DNS is a critical component of the Internet. This paper of the zone. The DNS provides a special query for that, takes a comprehensive look at the provisioning of Internet called the zone transfer query. In this work, we leverage the domains and its impact on the availability of various services. zone transfer query to capture detailed information about To gather data, we sweep 60% of the Internet’s domains DNS zones in the Internet. During a three month period, for zone transfers. 6.6% of them allow us to transfer their we swept 60% of the Internet for zone transfers. In order to complete information. We find that carelessness in handling increase our data beyond those zones allowing zone trans- DNS records can lead to reduced availability of name servers, fer, we walked the zones of the second-level domains known email, and Web servers. It also undermines anti-spam efforts to deploy DNSSEC [2] (DNS Security Extensions). This is and the efforts to shut down phishing sites or to contain a slow process since it involves making a large number of malware infections. queries, but its net effect is the same as a zone transfer. Us- ing the two data sets, we examined the DNS zones in our two data sets. The key findings of our study are the following: Categories and Subject Descriptors C.2.2 [Network protocols]: Applications—DNS 1.
    [Show full text]
  • Secure Domain Name System (DNS) Deployment Guide
    NIST Special Publication 800-81-2 Secure Domain Name System (DNS) Deployment Guide Ramaswamy Chandramouli Scott Rose C O M P U T E R S E C U R I T Y NIST Special Publication 800-81-2 Secure Domain Name System (DNS) Deployment Guide Ramaswamy Chandramouli Computer Security Division Information Technology Laboratory Scott Rose Advanced Network Technology Division Information Technology Laboratory September 2013 U.S. Department of Commerce Penny Pritzker, Secretary National Institute of Standards and Technology Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and Director Authority This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107-347. NIST is responsible for developing information security standards and guidelines, including minimum requirements for Federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate Federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A-130, Appendix III, Security of Federal Automated Information Resources. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.
    [Show full text]
  • BIND 9 Administrator Reference Manual
    BIND 9 Administrator Reference Manual BIND 9 Administrator Reference Manual Copyright © 2000, 2001 by Internet Software Consortium Table of Contents 1. Introduction............................................................................................................................................9 1.1. Scope of Document.....................................................................................................................9 1.2. Organization of This Document..................................................................................................9 1.3. Conventions Used in This Document..........................................................................................9 1.4. The Domain Name System (DNS)............................................................................................10 1.4.1. DNS Fundamentals.......................................................................................................10 1.4.2. Domains and Domain Names.......................................................................................10 1.4.3. Zones ............................................................................................................................11 1.4.4. Authoritative Name Servers .........................................................................................11 1.4.4.1. The Primary Master .........................................................................................12 1.4.4.2. Slave Servers....................................................................................................12
    [Show full text]
  • Domain Name System
    IBM i 7.2 Networking Domain Name System IBM Note Before using this information and the product it supports, read the information in “Notices” on page 49. This edition applies to IBM i 7.2 (product number 5770-SS1) and to all subsequent releases and modifications until otherwise indicated in new editions. This version does not run on all reduced instruction set computer (RISC) models nor does it run on CISC models. This document may contain references to Licensed Internal Code. Licensed Internal Code is Machine Code and is licensed to you under the terms of the IBM License Agreement for Machine Code. © Copyright International Business Machines Corporation 1998, 2013. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Domain Name System............................................................................................1 What's new for IBM i 7.2..............................................................................................................................1 PDF file for Domain Name System...............................................................................................................2 DNS concepts...............................................................................................................................................2 Understanding zones..............................................................................................................................3 Understanding DNS queries..................................................................................................................
    [Show full text]
  • 1537 CWI Category: Informational October 1993
    Network Working Group P. Beertema Request for Comments: 1537 CWI Category: Informational October 1993 Common DNS Data File Configuration Errors Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Abstract This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time. Introduction Due to the lack of extensive documentation and automated tools, DNS zone files have mostly been configured by system administrators, by hand. Some of the rules for writing the data files are rather subtle and a few common mistakes are seen in domains worldwide. This document is an attempt to list "surprises" that administrators might find hidden in their zone files. It describes the symptoms of the malady and prescribes medicine to cure that. It also gives some general recommendations and advice on specific nameserver and zone file issues and on the (proper) use of the Domain Name System. 1. SOA records A problem I've found in quite some nameservers is that the various timers have been set (far) too low. Especially for top level domain nameservers this causes unnecessary traffic over international and intercontinental links. Unfortunately the examples given in the BIND manual, in RFC's and in some expert documents give those very short timer values, and that's most likely what people have modeled their SOA records after. First of all a short explanation of the timers used in the SOA record: Beertema [Page 1] RFC 1537 Common DNS Data File Configuration Errors October 1993 - Refresh: The SOA record of the primary server is checked every "refresh" time by the secondary servers; if it has changed, a zone transfer is done.
    [Show full text]
  • Using Dns to Protect Clients from Malicious Domains
    Institute for Development and Research in Banking Technology A Project Report on USING DNS TO PROTECT CLIENTS FROM MALICIOUS DOMAINS Submitted by M.L.V.L Akhil Vishnu 3rd year B.Tech, Computer Science and Engineering Indian Institute of Technology (ISM) Dhanbad. Guide Dr. V. Radha Assistant professor IDRBT, Hyderabad. 1 | P a g e ACKNOWLEDGEMENT I would like to express my gratitude to the Institute for Development and Research in Banking Technology (IDRBT) under the guidance of Dr. V. Radha, Assistant Professor, IDRBT, Hyderabad. I would not hesitate to add that this short stint in IDRBT has added a different facet to my life as this is a unique organization being a combination of academics, research, technology, communication service, crucial application etc. and at the same time performing roles as an arm of regulation, spread of technology, and facilitator for implementing technology in banking and non-banking system. I am extremely grateful to Dr. V.Radha for her advice, innovative suggestions and supervision. I thank her for introducing me to different aspects of “CYBER SECURITY AND DOMAIN NAME SYSTEMS”. I am thankful for IDRBT for providing such an amazing platform to work on real application oriented research. I would like to give special thanks to Mrs. Varsha Srivastava, Administrative Executive, IDRBT, Hyderabad for providing resource and motivation in carrying out this project. Finally, I thank one and all who made this project successful either directly or indirectly. M.L.V.L Akhil Vishnu 3rd year B.Tech, Computer Science and Engineering, Indian Institute of Technology (ISM) Dhanbad. 2 | P a g e CERTIFICATE This is to certify that Mr.
    [Show full text]
  • The Forgotten Side of DNS: Orphan and Abandoned Records
    The Forgotten Side of DNS: Orphan and Abandoned Records Raffaele Sommese∗, Mattijs Jonker∗, Roland van Rijswijk-Deij∗, Alberto Dainottiy, K.C. Claffyy, Anna Sperotto∗ ∗Design and Analysis of Communication Systems (DACS) yCAIDA University of Twente UC San Diego Enschede, the Netherlands La Jolla, CA, USA fr.sommese, m.jonker, r.m.vanrijswijk, [email protected] falberto, [email protected] Abstract—DNS zone administration is a complex task in- Given the complexity of managing DNS information, volving manual work and several entities and can therefore misconfiguration and errors can occur, with an impact on result in misconfigurations. Orphan records are one of these the overal security and reachability of the DNS. misconfigurations, in which a glue record for a delegation The goal of this paper is to analyze a specific mis- that does not exist anymore is forgotten in the zone file. configuration, defined as the orphan record [2] in a TLD. Orphan records are a security hazard to third-party domains Such orphan records are a leftover of a domain that has that have these records in their delegation, as an attacker expired, and should have been removed, by the registry may easily hijack such domains by registering the domain or by the registrar, together with the expired domain they associated with the orphan. The goal of this paper is to belong to. Orphan records form a security risk as unwit- quantify this misconfiguration, extending previous work by ting third party domains may still point to these orphan Kalafut et al., by identifying a new type of glue record records in their delegation.
    [Show full text]