1 / 29

Introduction to BIND: A Comprehensive Guide to DNS Server Implementation

Learn about BIND, the most common DNS server implementation, including its history, operation, resource records, and more.

mwestover
Download Presentation

Introduction to BIND: A Comprehensive Guide to DNS Server Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BIND @ Cookie Session - Mohammed M. Ali alimm @ cig .mot .com- Larry P. Schrofschrof@cig.mot.com

  2. WELCOME TO THE BIND @ COOKIE SESSION Cookies!!!

  3. Introduction to BIND The most common implementation of a DNS server is BIND. Berkeley Internet Name Domain (BIND) is an open implementation of the Domain Name System(DNS) protocols which includes : A Domain Name System server (named) A Domain Name System resolver library Tools to verify the proper operation of DNS server.

  4. History of BIND • The birth of BIND was at University of California at Berkeley as a graduate student project under a grant from DARPA. • BIND versions 4.9 and 4.9.1 were released by DEC ( now Compaq) • BIND versions from 4.9.3 onward have been developed and maintained by ISC.

  5. . BIND BIND Operation Guide (BOG) • Understanding of BIND • Zone Vs Domain • Types of Servers • Boot File • Resolver Configuration • Cache Initialization File • Domain Data Files • Standard Resource Record Format

  6. Definitions in BIND • A Zone is part of the namespace • A Domain is also part of the namespace, but it covers several zones.

  7. Name Servers • The DNS server replies to DNS queries sent by resolvers. • Listen at UDP and TCP port 53 • Here UDP for routine queries and TCP for zone transfers. • Primary Name server contains only writeable authoritative copy of the zones. • Secondary Nameserver contains the duplicate copy of the data from the primary name server. • The Caching only name server relies on other name servers for authoritative answers.

  8. Resource Records (RR’s) • Resource Records contain various pieces of information about hosts in the DNS. (RFC 1035 specifies exactly how these records should look.) Some Example Resource Records Owner Class Type Data • cig.mot.com. IN NS motcig.cig.mot.com. • motcig.cig.mot.com. IN A 136.182.15.3 • motcig.cig.mot.com. IN HINFO “Hardware” “Software” • name.cig.mot.com. IN CNAME realname.cig.mot.com. • Name.cig.mot.com. IN TXT “Anything you want” • cig.mot.com. IN MX Priority#mailhost.domain.dom. • 3.15.182.136.IN-ADDR.ARPA. I N PTR motcig.cig.mot.com.

  9. Standard Resource Record Format • {name} {ttl} addr-class Record Type Record Specific data • Column 1 is the name of the domain record, or the “owner”. • Column 2 is the optional time to live field. • Column 3 is the address class; IN indicates the Internet class. • Column 4 is the type of resource record (A, MX, SOA, NS, CNAME, etc...) • Column 5 (and beyond) are the data fields. The types of data in these fields depend on the RR type.

  10. The SOA Record • SOA stands for ‘Start Of Authority’. • The SOA record defines the default parameters that affect the entire zone @ in soa motcig.cig.mot.com. hostmaster.cig.mot.com. ( 1999071913 ; Serial # 3600 ; Refresh 600 ; Retry 259200 ; Expiration 86400 ) ; minimum TTL • Origin Server : Name of the host on which the master zone file resides. • E-mail contact : e-mail address of the administrator. (The @ is changed to a .) • Refresh Rate : How often a secondary name server contacts a primary name server • Retry Rate : How often a secondary contacts a primary if a refresh fails. • Expiration : How long secondaries will consider a zone valid before expiring it. • Cache Interval(Minimum TTL) : The time slot for this data to be cached= 1 day

  11. The MX record • MX stands for ‘Mail Exchange(r)’ • “Why can I send email to schrof@cig.mot.com, if cig.mot.com isn’t an actual machine?” • cig.mot.com has MX records in the DNS: cig.mot.com. in mx 20 relay2.cig.mot.com. in mx 10 ilds01.cig.mot.com. in mx 40 ilms01.cig.mot.com. • Format of an MX record: [owner] [ttl] [class] MX <PREFERENCE> <HOST> • HOSTs with lower PREFERENCES are tried first when transporting email.

  12. The NS record • The NS record is used to specify what hosts act as name servers for a zone. cig.mot.com. in ns motcig.cig.mot.com. in ns koala.cig.mot.com.

  13. The A Record • The A record is probably the most familiar type of RR in DNS. • An A record is used to assign an IP address to a host. • lyric IN A 136.182.7.129

  14. The HINFO Record • The HINFO Record is commonly misused. • It should have EXACTLY two data fields • First field specifies hardware platform • Second field specifies software (OS) version • It’s best to put each field in its own pair of double quotes. • No Other Information Should be Put In An HINFO Record!!! • Other, miscellaneous information, should be put into a TXT record.

  15. The TXT Record • The TXT Record is used to hold miscellaneous information about a host. • TXT records should have only one data field. • Enclose the data field in double quotes. • The data field should not span across lines. • It may take more than one TXT record to hold all the info you want. This is perfectly acceptable. nil in txt “Location: IL27 3121 CR Rack 06 Section 03.” nil in txt “Class: Boot”

  16. The CNAME Record • CNAME Records are a mapping from one DNS hostname to another. • They are commonly called ‘aliases’. xtime in cname trumpet.cig.mot.com. • CNAMEs should never point to IP addresses. • Don’t use a CNAME in other RR’s.

  17. Things To Remember • Domain info. MUST be in the relevant domain file. • Fully-qualified domain names should always end with periods. (This keeps the name server from tacking on an extra copy of the domain name to the data) • All name servers should be listed using NS records. • The owner (name) field in an NS record should be the domain. • CNAME must never have any MX, TXT, HINFO , etc. pointing to it.

  18. zfck is a Perl script written to catch common mistakes in DNS zone files. zfck -f <FILE> [-a] [-w] [-s] [-p #] [-help] -f <FILE> : Specifies zone file to check -a : Advise how to correct errors found -w : Display non-fatal errors -p # : Display progress dots every # lines -s : Short output. -help : Display a usage summary zfck

  19. BIND MAINTENANCE Procedure : Forward domain I. DNS changes necessary when adding/deleting a node. A.Use the selected unique IP hostname and IP address of the node to the DNS database files. 1. Log onto motcig with the login ID 2. Change to the subdirectory containing the DNS database files for the forward domain by issuing the command cd /var/spool/named/primary 3. Edit the cig.mot.com file. 4. Change the serial value in the SOA record. The serial value is in yyyymmddhhh format ( year month day hour). 5. YOU MUST INCREMENT THE SERIAL NUMBER, OR THE NEW DATA WILL NOT BE TRANSFERRED TO THE SECONDARY NAMESERVERS. 6. For adding A RR, put ipname A 160.44.67.11 7. For deleting A RR, put ; A 160.44.67.11 8. Save the file and exit.

  20. BIND MAINTENANCE Procedure : Reverse domain II. DNS changes necessary when adding/deleting node B. Use the selected unique IP hostname and IP address of the node to the DNS database files. 1. Log onto motcig with the login ID 2. Change to the subdirectory containing the DNS database files for the forward domain by issuing the command cd /var/spool/named/primary 3. Edit the rev.domain file for the relevant reverse domain. 4.Change the serial value in the SOA record. The serial value is in yyyymmddhhh format ( year month day hour). 5.YOU MUST INCREMENT THE SERIAL NUMBER, OR THE NEW DATA WILL NOT BE TRANSFERRED TO THE SECONDARY NAMESERVERS. 6. For adding PTR RR, put 11 PTR ipname.cig.mot.com. 7. For deleting PTR RR, put ;11 PTR .cig.mot.com. 7. Save the file and exit. 8. The trailing period after ipname.cig.mot.com. It is intentional and VERY IMPORTANT. Do not omit the trailing period from this entry. Otherwise DNS will automatically append the current origin of the database file to this name, such as ipname.cig.mot.com.cig.mot.com.

  21. (Re)starting DNS • At CIG, you should never have to restart DNS manually. It is done periodically. • Commonly, there are two scripts: named.reload and named.restart • named.restart should only be used when • named is not running OR • The named.boot file has been modified • named.reload should be used after making any changes to the zone files. • These scripts were incorrectly switched for CIG.

  22. Named Configuration Files • Telnet motcig.cig.mot.com • cd /var/spool/named • Boot File : named.boot = named configuration • Root Cache : root.servers = point to dns1.Corp.mot.com and dns2.Corp.mot.com • Forward Mappings : Converts host names to IP addresses. • Reverse Mappings : Converts IP addresses to names.

  23. Named.Boot File • motcig 134 % vi named.boot • ; • ; Named.boot file for cig.mot.com • ; $Id: named.boot,v 1.60 1998/11/24 20:52:23 david2 Exp $ • ; • directory /var/spool/named • ;forwarders 129.188.137.100 129.188.137.101 • sortlist 136.182.0.0 • cache . root.servers • bogusns 193.0.14.129 198.41.0.4 198.32.64.12 198.32.65.12 128.9.0.107 19 • 2.33.4.12 128.8.10.90 192.203.230.10 192.5.5.241 192.112.36.4 128.63.2.53 192.36 • .148.17 198.41.0.10 • include primary.zones • include secondary.zones

  24. Root.Cache : root.servers File • motcig 141 % vi root.servers • ; • ; Data to prime the cache with • ; • ; • ; Motorola ROOT nameservers • ; • . 99999999 in ns dns1.corp.mot.com. • 99999999 in ns dns2.corp.mot.com. • ; • ; Nameservers for .com • ; • com. 99999999 in ns dns1.corp.mot.com. • 99999999 in ns dns2.corp.mot.com. • ; • ; Nameservers for mot.com • ; • mot.com. 99999999 in ns dns1.corp.mot.com. • 99999999 in ns dns2.corp.mot.com.

  25. Cig.mot.com File • motcig 137 % vi cig.mot.com • ; $Id: cig.mot.com,v 1.3969 1999/05/27 19:50:05 alimm Exp corrie $ • ; • @ in soa motcig.cig.mot.com. hostmaster.cig.mot.com. ( • 1999052716 ; Serial = yyyymmddhh • 3600 ; Refresh = 1h • 600 ; Retry = 10m • 259200 ; Expire = 3d • 86400 ) ; Minimum = 1d • in ns motcig.cig.mot.com. • in ns koala.cig.mot.com. • ; ============================================================================= • ; MAIL EXCHANGERS START HERE • ; ============================================================================= • cig.mot.com. in mx 50 po_box.cig.mot.com. • in mx 20 relay1.cig.mot.com. • in mx 20 relay2.cig.mot.com. • in mx 10 ilds01.cig.mot.com. • in mx 40 ilms01.cig.mot.com. • in mx 40 ilms02.cig.mot.com. • mail-relay in a 136.182.15.5

  26. Host.rev : rev.160.44 File • motcig 150 % vi rev.160.44 • ; • ; rev.160.44 (ORIGIN = 44.160.in-addr.arpa. ) • ; $Id: rev.160.44,v 1.86 1999/05/25 17:04:43 alimm Exp $ • ; • @ in soa motcig.cig.mot.com. hostmaster.cig.mot.com. ( • 1999052512 ; Serial ( yyyymmddhh ) • 3600 ; Refresh ( every hour ) • 600 ; Retry ( every 10 minutes ) • 259200 ; Expire ( if !refresh after 3 days ) • 86400 ) ; Minimum ( non-specified ttl - 1 day ) • in ns motcig.cig.mot.com. • in ns koala.cig.mot.com. • $ORIGIN 1.44.160.in-addr.arpa. • 225 in ptr gli_j4840_5_225.cig.mot.com. • 226 in ptr gli_j4840_5_226.cig.mot.com. • 227 in ptr gli_j4840_5_227.cig.mot.com. • 228 in ptr gli_j4840_5_228.cig.mot.com. • 254 in ptr rfd50_1e_2-e1.cig.mot.com. • $ORIGIN 2.44.160.in-addr.arpa. • 254 in ptr rfd50_1e_2-e2.cig.mot.com.

  27. 1) Name server RR: in ns motcig.cig.mot.com. in ns koala.cig.mot.com. 2) A RR rfd3121_penny in a 136.182.0.212 ; f0 in hinfo Cisco-4500 "Cisco 10.2.5" 3) Canonical Name RR : r3121_penny in cname rfd3121_penny.cig.mot.com. 4) PTR RR : 212 in ptr rfd3121_penny-f0.cig.mot.com. 5) Mail Exchanger RR : cig.mot.com. in mx 50 po_box.cig.mot.com.

  28. BIND to QIP 5.0 The current BIND migration is outlined by migration in two phases:- Phase 1 : Import phil.cig.mot.com to QIP format. Phase 2 : Import cig.mot.com to QIP format The highlights of Release 5.0 of QIP are New "Organization" Layer Full Classless DNS/CIDR Support (RFC2317) Ability to Control/Define Reverse Zones for DNS New Administrative Model New Motif User Interface Ability to Define and Manage User Profiles DHCP Feature/Performance Enhancements Support for Microsoft NT 4.0 DHCP Server LDAP Enabled DHCP and DNS Servers New User-Defined Hierarchy Many-to-one DHCP Fail over

  29. Recommendations • To change the layout of domain data files on motcig name server. • Restrict access to motcig name server. • Modify boot file by few people only. • Use Make command (perl script) to maintain BIND. • To modify any forward or reverse file, I recommend to make a copy of the original file to that date, and then edit the files. • To Modify the format of Serial # in the SOA record to yyyymmddrr (The recommended format is valid for up to 99 revisions a day versus the current use of hour format).

More Related