DNS PSD/FAQ 1.0: About DNS 1.1: DNS Definitions 1.2: Name Service Selection 1.3: How DNS Looks Up Records 2.0: Debugging DNS 2.1: The Map Files 2.2: /var/adm/messages 2.3: nslookup 2.4: Dumping in.named 2.5: DNS Debug Mode 2.6: getent 2.7: named-xfer Debugging 3.0: Common How Tos 3.1: How to Set Up a SunOS DNS Client 3.2: How to Set Up a Solaris DNS Client 3.3: How to Register Domains 3.4: How to Modify Domains 3.5: How to Get a Root Cache File 3.6: How to Set Up a Caching Only DNS Server 3.7: How to Set Up a Primary DNS Server 3.8: How to Set Up a Secondary DNS Server 3.9: How to Add a New Record to DNS Map Files 3.10: How to Set Up Subdomains 3.11: How to Set Up a Self Contained Domain 4.0: Some Frequently Asked Questions 4.1: Miscellaneous Questions 4.2: Common DNS Lookup Problems 4.3: Map Modification Problems 4.4: SunOS Name Service Interaction 4.5: Solaris Name Service Interaction 4.6: nslookup Errors 4.7: DNS Directive Problems 4.8: Common Error Messages 5.0: Patches 5.1: DNS Patches for SunOS 5.2: DNS Patches for Solaris 5.3: YP/DNS Intercompatibility Patches for SunOS 6.0: RFEs 6.1: RFEs 6.2: Bugs 7.0: References 7.1: Important Man Pages 7.2: Sun SRDBs 7.3: Sun Educational Services 7.4: Solaris Documentation 7.5: Third Party Documentation 7.6: RFCs 8.0: Supportability 9.0: Additional Support
1.0: About DNS This Tip Sheet documents a wide variety of information concerning DNS, as implemented in the SunOS and Solaris operating systems. It is intended as both an introduction to DNS, and as a guide to the most common problems. There are many more complete references to DNS, a few of which are noted in section 7.0. 1.1: DNS Definitions The following terms are crucial to the understanding of DNS: A RESOLVER is what runs on a client machine, to initiate DNS lookups. On Sun machines, the /etc/resolv.conf file implements this functionality. It contains a list of nameservers to use. (See Sections 3.1 and 3.2 for information on setting up clients.) A NAMESERVER is the program that actually does the work of looking up names. On Sun machines, the program IN.NAMED acts as the nameserver. There is usually one nameserver for a cluster of machines. There are three main types of NAMESERVERS. A CACHING-ONLY nameserver does lookups of names, but controls no name records itself. A PRIMARY nameserver not only does lookups of names, but also owns the records for a domain. A SECONDARY nameserver does name lookups, and it also backs up a primary nameserver by providing authoritative answers for a certain domain. Many nameservers will combine Primary and Secondary functionality for different domains. (See Sections 3.6, 3.7 and 3.8 for information on setting up servers.) There are numerous types of records in DNS. They are all listed and explained in the in.named man page. The most important records are those which correlate machine names and IP addresses. FORWARD RECORDS, or A RECORDS, are those which translate from machine names to ip addresses. These are the most commonly used records. A typical A record is constructed as follows: dns.test.com. IN A 188.8.131.52 (this example shows an A record which correlates the machine name dns.test.com to the IP address 184.108.40.206) REVERSE RECORDS, or PTR RECORDS, are those which translate from ip address to machine names. They are typically used for security tests, and to convert ugly ip addreses into names, for when humans are examining them. PTR records are constructed in an awkward manner. The IP address of a machine is reversed, and then the suffix in-addr.arpa is appended. A typical PTR record is: 220.127.116.11.in-addr.arpa. IN PTR dns.test.com. (this example shows a PTR record which correlates the IP address 18.104.22.168 to the machine name dns.test.com) CNAME RECORDS are used to provide an alias for a hostname. For example: loghost IN CNAME testhack.test.com MX RECORDS are used to direct mail to specific locations. For example, if you had two hosts that work as mailhosts, you could identify them with MX records. More often, you create an MX record to tell others outside your domain (e.g. on the Internet) how to get mail to you. E.g. test.com IN MX 10 mailgate.test.com This is most often seen when there is no host called test.com. There are two very important files for DNS. The existance of /etc/resolv.conf tells a machine that it should be a DNS client. The resolv file lists a domain name, and name servers. The existance of /etc/named.boot tells a machine that it should be a DNS server. The boot file lists all of the subsidiary files that are used by a DNS servers, and is typically the starting place for DNS debugging. 1.2: Name Service Selection Naming services are selected in a certain order, and it is important to understand this order, to make it easier to debug DNS problems. On SunOS machines, the client first makes naming service requests to NIS. If the NIS server is unable to find a hostname record, the server will then make a request to DNS. There are two important things to note here: first, if NIS is not running, a SunOS machine will not be able to use DNS second, it is actually the SunOS NIS servers that do DNS lookups, not the clients. Thus, you must ensure that all of your NIS servers are set up as DNS clients (see Section 3.1). On Solaris machines, name server selection is done based on the order shown in the /etc/nsswitch.conf (see Section 3.2). It is always the client which actually does the DNS lookup. The nslookup program is a notable exception. It always goes straight to DNS, and never accesses any other naming services. This is of note because it is the only case where a SunOS NIS client will actually do a DNS lookup itself. For this reason, it is usually best to make sure that all SunOS NIS clients are also set up as DNS Clients (see Section 3.1). 1.3: How DNS Looks Up Records Finally, it should be pointed out that DNS looks up records in a method that might not be entirely intuitive. In your /etc/resolv.conf, a domain is listed. Whenever a lookup occurs, DNS will first examine the hostname you requested, with the domain name tacked on. Then, it will examine the hostname with a subdomain tacked on (ie, the first part of the domain is removed). This iterative process proceeds until there is only one label left in the domain name (ie, com, gov, edu). That label is discarded rather than being looked up. Afterwards, just the hostname is looked up. If a lookup succeeds, the further lookups will not be tried. For example, assume that my domain name is corp.sun.com. If I lookup 'psi', the following lookups could be done: psi.corp.sun.com psi.sun.com psi In reality, since psi.corp.sun.com is an actual machine name, I will get a sucess back from 'psi.corp.sun.com' and the other two lookups will not be done. However, if I tried to lookup 'ftp.csua.berkeley.edu', the following lookups could be done: ftp.csua.berkeley.edu.corp.sun.com ftp.csua.berkeley.edu.sun.com ftp.csua.berkeley.edu The last lookup is the correct one, and so all three are done. There is only one way to circumvent this DNS lookup order. By appending a '.' to the end of a lookup request, you fully qualify the name. This tells DNS not to use the searchlist, but just to lookup the name you typed. For example, if you did a lookup of 'ftp.csua.berkeley.edu.', the following lookups could be done: ftp.csua.berkeley.edu Some bugs in DNS setups go away when a '.' is appended to the end of a hostname. This is usually because one of the earlier entries in the searchlist (incorrectly) comes back with an affirmative answer. BIND 4.9.3 note: the "ndots" directive in /etc/resolv.conf can be used to preserve the above documented behavior. 2.0: Debugging DNS A variety of DNS problems, from records simply not being displayed, to nslookup coredumping, can be attributed to errors in your DNS map files. It is extremely easy to make a mistake as simple as leaving off a '.' that can have very undesirable effects on your DNS maps. Following are a few good methods for debugging errors in DNS map files. Please understand that SunService is cannot troubleshoot Internet connectivity problems, and cannot handhold anyone through debugging configuration problems. Most often you need to use this Tip sheet in addition to the information from the O'Reilly book, so solve DNS configuration and Internet connectivity issues. SunService Technical Support can help get you pointed in the right direction and provide explaination to error messages and check for bug reports. 2.1: The Map Files are called Zone Files The simplest method for discovering errors in your zones is simply consulting the map or zone files themselves. Described below are the most common DNS errors, which are all very obvious from a quick perusal of the file. The simplest method for discovering errors in your zones is simply consulting the map or zone files themselves. Described below are the most common DNS errors, which are all very obvious from a quick perusal of the file. 2.1.1: Unqualified Names If you put a machine name in a DNS map file, but do not include a '.' at the end of the machine name, the domain of the map will automatically be appended. For example, if I have the following information in my named.boot: primary test.com named.test And in the named.test file I have the following entry: www IN CNAME dns.test.com I will get undesirable results. in.named will look at the two hostnames, 'www' and 'test.com', and see that neither is fully qualified because of the lack of a trailing '.' Thus, that line will be interpreted as follows: www.test.com is a CNAME record to dns.test.com.test.com The following would be correct: www IN CNAME dns.test.com. In this case, only the www entry would get 'test.com' appended to it. However, the next record is the preferred one, as it is totally consistant and thus more likely to be free of errors: www.test.com. IN CNAME dns.test.com. This is particularly a problem in reverse address files. If, for example, I had the following in my named.boot: primary 0.0.127.in-addr.arpa named.local Any unqualified hostnames in the named.local map would have '0.0.127.in-addr.arpa' domain added on to them. So, the following line: 1 IN PTR localhost Would be interpreted as: 22.214.171.124.in-addr.arpa is a PTR record to localhost.0.0.127.in-addr.arpa The bottom line is: always put in the full host name within your DNS maps, and always put a '.' at the end of each record, to be sure there are no problems. Please note that this is only for the individual DNS map files. Names in the resolv.conf and the named.boot should not have an appended '.' 2.1.2: Incorrect Records in Files If you have a DNS map controlling a domain, that file can only contain entries for machines within that domain. Nameserver records are a distinct exception, since it is necessary that they exist to do lookups for the domain. However, normal records (A, MX, CNAME) should all be within the domain that is listed in your named.boot. For example, if your named.boot lists the following: primary test.com named.test The following record would be correct and expected: www.test.com. IN CNAME dns.test.com. As would the following: very.long.cname.test.com. IN CNAME dns.test.com. The following would be useless though: other-domain.com. IN CNAME dns.test.com. Since our named.boot does not say we control other-domain.com., queries for that domain will never get directed to us. Again, the exception is: many NS records will have A records associated with them, which are from outside the domain of your file. This is necessary, so that the name servers can be found. 2.1.3: Illegal Directives Earlier versions of DNS allowed 'domain' and 'sortlist' directives to be put in the named.boot file. These may still be used, but might cause problems if you list them in your named.boot. The named.boot file should GENERALLY contain the following directives: directory, primary, secondary, cache. There are others, but these are the important ones. 2.2: /var/adm/messages Whenever you restart in.named, the map files will get parsed, and obvious error messages will be reported to /var/adm/messages. You can restart the named by running: # kill -HUP `cat /etc/named.pid` You can then check for the named messages by running: % grep named /var/adm/messages Ignore everything but the messages that have times correlating with your killing of the named. You should see just the following if the named startup detects no errors: Sep 7 12:28:04 psi named: reloading nameserver However, if there are problems, errors will be displayed as well: Sep 7 12:28:04 psi named: named.root: No such file or directory Sep 7 12:28:04 psi named: named.local: No such file or directory If any named messages appear in /var/adm/messages at named startup time, consider whether they are errors, or informational data. 2.3: nslookup nslookup is a very powerful command for debugging DNS problems. When you run it, it will start up doing lookups from the first nameserver in your resolv.conf file: psi% nslookup Default Server: sun-barr.EBay.Sun.COM Address: 126.96.36.199 > By default, nslookup looks for MX records on Solaris, and A (address) records on SunOS. You must tell nslookup to check A records by changing the query type at the prompt: > set q=a -or- > set type=a Then to do the lookup: > psi.corp.sun.com Server: sun-barr.EBay.Sun.COM Address: 188.8.131.52 Name: psi.corp.sun.com Address: 184.108.40.206 > Note that on every lookup, nslookup repeats the server name and address, to remind you what DNS server is answering your requests. You can ask nslookup to verify other types of DNS records as well, using the 'set type=' or 'set q='command. For example, if I wanted to examine MX records, I would enter the following: > set type=mx > sun.com Server: sun-barr.EBay.Sun.COM Address: 220.127.116.11 sun.com preference = 10, mail exchanger = Sun.COM Sun.COM internet address = 18.104.22.168 > Finally, you can ask nslookup to use a different server for lookups, using the 'server' command: > server cs.utexas.edu Default Server: cs.utexas.edu Address: 22.214.171.124 > sun.com Server: cs.utexas.edu Address: 126.96.36.199 sun.com preference = 30, mail exchanger = Sun.COM sun.com preference = 10, mail exchanger = mercury.Sun.COM sun.com preference = 20, mail exchanger = venus.Sun.COM Sun.COM internet address = 188.8.131.52 mercury.Sun.COM internet address = 184.108.40.206 venus.Sun.COM internet address = 220.127.116.11 This is particularly useful if you are trying to check for propagation of DNS records, or if you thinks that DNS records might look different as different sites (as indeed is the case with the mx records that I looked up for sun.com). NOTE: you must be able to connect to those servers to do this (e.g. be on the internet or intranet with the other server). If you get a hang, then use the "lserver" command to get yourself "back" > lserver sun-barr.EBay.Sun.COM Later parts of this document will suggest that nslookup be used to examine certain types of records, sometimes on certain servers. This may be done with the 'set type=' and 'server' commands that are shown above. 2.3.1: nslookup -debug You can get even more information from nslookup by putting it into debug mode. This is done by typing 'set debug' at the nslookup prompt, and then doing a lookup, as normal. nslookup will produce a lot of information when you do this: > set debug > sun.com Server: sun-barr.EBay.Sun.COM Address: 18.104.22.168 res_mkquery(0, sun.com.Corp.Sun.COM, 1, 1) ------------ Got answer: HEADER: opcode = QUERY, id = 5, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion ava questions = 1, answers = 0, authority records = 1, additional = 0 ... ------------ res_mkquery(0, sun.com.Sun.COM, 1, 1) ------------ Got answer: HEADER: opcode = QUERY, id = 6, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion ava questions = 1, answers = 0, authority records = 1, additional = 0 ... ------------ res_mkquery(0, sun.com, 1, 1) ------------ Got answer: HEADER: opcode = QUERY, id = 7, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion ava questions = 1, answers = 1, authority records = 0, additional = 0 QUESTIONS: sun.com, type = A, class = IN ANSWERS: -> sun.com internet address = 22.214.171.124 ttl = 86400 (1 day) This is very useful because it takes you through the entire lookup, going down the whole search list. You'll note that when I look up sun.com, because my domain is corp.sun.com, nslookup looks at sun.com.corp.sun.com, sun.com.sun.com and sun.com, in order. Many DNS problems are due to something in the searchlist giving an incorrect answer (for example, if I got an answer from sun.com.sun.com, I would never get the correct answer). This can be clearly seen if nslookup ends earlier in the search path. You can get MORE detailed nslookup debug info with the "set d2" to set debug level 2. 2.4: Dumping the DNS database - helpful for debugging the server You can force your in.named to dump, to see exactly what is in its "memory". The dump is ASCII data, and looks much like the DNS configuration files. You do dump the database by executing the following: # kill -INT `cat /etc/named.pid` -or- Get the PID on in.named from ps -ef, and # kill -INT pid This will cause all of the information stored by your in.named to be written to /var/tmp/named_dump.db. You'll probably see lots of random entries which your named has learned from other nameservers. You will also see "hints" from your cache file(s) specified in the /etc/named.boot file. By looking carefully through this file, you'll be able to also pick out your own data. Look for the $ORIGIN of your domain(s). Via this method, and a little experience, one can see problems, such as that noted in section 2.1 above. Here is an example database dump: ; Dumped at Thu Feb 13 12:11:55 1997 ;; ++zone table++ ; omnilab.com (type 2, class 1, source /usr/tmp/NsTmp1136.1) ; time=855853545, lastupdate=855853528, serial=15, ; refresh=30, retry=15, expire=90, minimum=86400 ; ftime=855853528, xaddr=[126.96.36.199], state=0241, pid=0 ; z_addr: [188.8.131.52] ;; --zone table-- ; Note: Cr=(auth,answer,addtnl,cache) tag only shown for non-auth RR's ; Note: NT=milliseconds for any A RR which we've used as a nameserver ; --- Cache & Data --- $ORIGIN com. omnilab -1 IN SOA cascades.omnilab.com. root.cascades.omnilab.com. ( 15 30 15 90 86400 ) ;Cl=2 -1 IN NS cascades.omnilab.com. ;Cl=2 -1 IN NS mercedes.omnilab.com. ;Cl=2 $ORIGIN omnilab.com. testalias -1 IN CNAME hack.omnilab.com. ;Cl=2 whitewolf1 -1 IN A 184.108.40.206 ;Cl=2 -1 IN MX 10 whitewolf1.omnilab.com. ;Cl=2 ozone -1 IN A 220.127.116.11 ;Cl=2 -1 IN MX 10 ozone.omnilab.com. ;Cl=2 yoda -1 IN A 18.104.22.168 ;Cl=2 -1 IN MX 10 yoda.omnilab.com. ;Cl=2 localhost -1 IN A 127.0.0.1 ;Cl=2 2.5: DNS Debug Mode for in.named If none of the above methods clarify your DNS map errors, you can turn DNS debugging on. This should be done on the DNS server that your current client is referencing via its /etc/resolv.conf. The following kill commands will turn debugging on DNS up to level two (each time the kill signal is given, the debugging level increments by one): # kill -USR1 `cat /etc/named.pid` # kill -USR1 `cat /etc/named.pid` This will make a debugging file appear in /var/tmp/named.run. Here is an example of a DNS debugging file showing a DNS lookup of "sun.com" which failed: Debug turned ON, Level 1 Debug turned ON, Level 2 datagram from 22.214.171.124 port 33446, fd 6, len 38 req: nlookup(sun.com.Corp.Sun.COM) id 5 type=1 req: missed 'sun.com.Corp.Sun.COM' as '' (cname=0) findns: No root nameservers for class 1? req: answer -> 126.96.36.199 6 (33446) id=5 Local datagram from 188.8.131.52 port 33447, fd 6, len 25 req: nlookup(sun.com) id 6 type=1 req: missed 'sun.com' as '' (cname=0) findns: No root nameservers for class 1? req: answer -> 184.108.40.206 6 (33447) id=6 Local In this case, you can again note the entire searchlist is checked. I can also see from the 'req: missed' line that nothing was returned, and from the next line that I'm getting an error 'No root nameservers for class 1?'. This makes sense, as I'm behind a firewall, and so my DNS can't get out to look up names at the root level Sometimes the DNS debugging information will give this sort of clue as to the real problem, but often it is hard to read and difficult to interpret. Usually, you will be better off using the debug mode in nslookup, as that is a little easier to read. When you want to turn off named logging, you should execute: # kill -USR2 `cat /etc/named.pid` This will return DNS debugging to level 0. Consult the O'Reilly book DNS and BIND for a more thorough treatment of the joys of debug mode. 2.6: getent Surprisingly, some apparent DNS problems really are not the fault of DNS. On Solaris, this can be diagnosed via the getent command. You can run getent with the following arguments: % getent hosts machine-name getent will look at the nsswitch.conf, and look up your machine-name according to the order listed in the hosts: line. So, it might first go to files, then to nis or nisplus before it gets to DNS. If you used nslookup and everything looked fine, you should try getent next. If it fails, or gives bad information, that means that one of the other naming services, before DNS, is misbehaving. 2.7: named-xfer and Debugging a secondary server You may find that when you are acting as a secondary name server, you are getting errors when named-xfer runs, and tries to download your zones. The most common error is: named-xfer: bad response to soa query from <ip address> If the problem is occasional, it is extremely likely that you are having some intermittent connectivity problem, or a performance problem. These issues are beyond the scope of this document, and are generally not issues that SunService can help with. Sections 8.0 and 9.0 explain your other alternatives. If seeing the "bad response to soa query" error, the root causes is usually in the SOA record on the primary. Scrutinize if VERY carefully, errors in the SOA record can be extremely subtle! If the problem is very consistant, you should try and download the map with full debugging turned on. This is done by running named-xfer by hand. SunOS: # /usr/etc/in.named-xfer -z sub.test.com -f /tmp/zonefile -s 0 -d 2 dns.test.c om Solaris: # /usr/sbin/named-xfer -z sub.test.com -f /tmp/zonefile -s 0 -d 2 dns.test.com The above command would download the zone sub.test.com from the machine dns.test.com. When the download occurs, it will be written to /tmp/zonefile. Debugging output will be written to /var/tmp/xfer.ddt.*. After you have executed named-xfer, you should investigate the zonefile that was transferred, and see how much of the file made it to you. More importantly, you should look at the debugging output. Very often, it will list precisely what the problem is. Usually, when connectivity is good, if named-xfer fails it is because there is some error in the zone files on the primary DNS server. 3.0 Common How Tos 3.1: How to Set Up a SunOS DNS Client You must edit the /etc/resolv.conf to make a machine correctly use DNS. There should be between 2 and 4 lines in the resolver file. The first line contains the domain for the machine, while the following lines contain nameservers. If you list more than one nameserver, the additional ones will be used as backups. A typical resolv.conf, for my machine, psi.corp.sun.com, which has one nameserver, would be: domain corp.sun.com nameserver 220.127.116.11 You should always use an IP address for the nameserver directive, not a hostname. On a SunOS machine, you will also have to run NIS for DNS to work correctly. In addition, the NIS server must have a resolv.conf file set up, exactly as is described above. If this is not an option, section 4.4 suggests unsupported alternatives. 3.2: How to Set Up a Solaris DNS Client The resolv.conf setup for a Solaris machine is identical to what is described in section 3.1 for SunOS. On a Solaris machine, you must also add dns to the hosts: line of the /etc/nsswitch.conf. For example, if you are not using NIS or NIS+, the hosts: line of your nsswitch.conf will read: hosts: files You should change it to read: hosts: files dns If the phrase '[NOTFOUND=return]' appears in the hosts line, you should either get rid of it, or put the phrase dns before it, otherwise dns will never get consulted. For example, the standard hosts line if you are running NIS+ reads: hosts: nisplus [NOTFOUND=return] files Change it to read: hosts: nisplus dns [NOTFOUND=return] files 3.3: How to Register Domains Before you can start offering DNS service for your domain, you must register that domain with InterNic, the internet naming authority. To do this, ftp to internic.net, go into the /templates directory and retrieve the file called DOMAIN-TEMPLATE.TXT. This template can be used to register for ORG, COM, EDU or NET domains. You will need another template for other countries, or other domains. They should all be contained in this same directory. After you have filled out DOMAIN-TEMPLATE.TXT, you must return it to HOSTMASTER@internic.net. Complete information on this procedure will be contained in the template file itself. Note that you must have your primary and secondary nameservers up and running before InterNic will register your domain name. You should also be aware that InterNic takes a few weeks to a month to complete domain registration, and so you should put in your application well ahead of time. In most cases, your internet service provider will have already taken care of these details for you. Please note that in the near future, there will be new Internet Naming Authorities in the USA, along with new "root level" domains besides the "traditional" domain names. 3.4: How to Modify Domains The same procedure as is described in section 3.3 should be used if you want to modify domain information that Internic is currently holding. Simply retrieve the DOMAIN-TEMPLATE.TXT file, and send it to HOSTMASTER@internic.net. You can verify the domain level information using nslookup. Domain level information maintained by the NIC includes any NS, MX or A records for your domain. For example: nslookup > set q=ns > sun.com Server: sun-barr.EBay.Sun.COM Address: 18.104.22.168 sun.com nameserver = Sun.COM Sun.COM internet address = 22.214.171.124 > set q=mx > sun.com Server: sun-barr.EBay.Sun.COM Address: 126.96.36.199 sun.com preference = 10, mail exchanger = Sun.COM Sun.COM internet address = 188.8.131.52 > set q=a > sun.com Name: sun.com Address: 184.108.40.206 3.5: How to Get a Root Cache File FTP the file /domain/named.root from rs.internic.net for the most current Root Cache File. Your root cache file should be updated regularly. In the below examples, this cache file will be installed as /var/named/named.ca. 3.6: How to Set Up a Caching Only DNS Server Following is a sample of how to set up a caching only name server. This will be a name server which will cache records it looks up, but will control no records of its own: --start /etc/named.boot-- ; ; named.boot file for a caching only name server ; directory /var/named cache . named.ca primary 0.0.127.in-addr.arpa named.local --end /etc/named.boot-- --start /var/named/named.local-- ; ; Address to host mapping for 127.0.0 net ; ; Note: In this and all other examples, the SOA line contains ; the following args: ; ; @ IN SOA controlling-machine email (serial refresh retry expire ttl) ; ; The '@' indicates that the domain name is the same as the origin, ; as specified in the the named.boot file. ; ; The 'controlling-machine' is the machine which holds the primary ; records for this particular domain. ; ; 'email' is an e-mail address for the DNS administrator, with ; the '@' substituted for a '.' ; ; The parentheses allow the SOA record to span more than one line. ; @ IN SOA dns.test.com. administrator.test.com. ( 1 ; serial number 10800 ; refresh after 3 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS dns.test.com. 1 IN PTR localhost. dns.test.com. IN A 220.127.116.11 --end /var/named/named.local-- There will also need to be a /var/named/named.ca file, which should be retrieved as described in section 3.5. The books listed in sections 7.4 and 7.5 give a much more in-depth description of setting up a caching only name server. 3.7: How to Set Up a Primary DNS Server Following is a sample of how to set up a primary DNS server. This will be a name server which will cache records it looks up, and also controls records of its own. Please note that in this example we control both the domain test.com, and a theoretical set of IP addresses for that domain, 18.104.22.168. All DNS servers should control both their forward and reverse address records. --start /etc/named.boot-- ; ; named.boot file for a primary name server ; directory /var/named cache . named.ca primary 0.0.127.in-addr.arpa named.local primary test.com named.test primary 1.1.192.in-addr.arpa named.rev --end /etc/named.boot-- --start /var/named/named.local-- [Identical to section 3.6 above] --end /var/named/named.local-- --start /var/named/named.test-- ; ; Host to address mapping for test.com ; @ IN SOA dns.test.com. administrator.test.com. ( 1 ; serial number 10800 ; refresh after 3 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS dns.test.com. dns.test.com. IN A 22.214.171.124 num2.test.com. IN A 126.96.36.199 ; there should be one A record as above for each machine in the ; test.com domain --end /var/named/named.test-- --start /var/named/named.rev-- ; ; Address to Host mapping for test.com ; @ IN SOA test.com. administrator.test.com. ( 1 ; serial number 10800 ; refresh after 3 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ;minimum TTL of 1 day IN NS dns.test.com. 1 IN PTR dns.test.com. 2 IN PTR num2.test.com. dns.test.com. IN A 188.8.131.52 --end /var/named/named.rev-- NOTE: there should be one PTR record as above for each machine in the 1.1.192.in-addr.arpa domain, that is every machine whose network number starts with 192.1.1. DON'T FORGET THE TRAILING "."!!! There will also need to be a /var/named/named.ca file, which should be retrieved as described in section 3.5. The books listed in sections 7.4 and 7.5 give a much more in depth description of setting up a caching only name server. 3.8: How to Set Up a Secondary DNS Server Following is a sample of how to set up a secondary DNS server. This will be a name server which will cache records it looks up, and also backs up records for a domain. Please note that we secondary both the domain test.com, and a theoretical set of IP addresses for that domain, 184.108.40.206. --start /etc/named.boot-- ; ; named.boot file for a caching only name server ; directory /var/named cache . named.ca primary 0.0.127.in-addr.arpa named.local secondary test.com 220.127.116.11 named.test secondary 1.1.192.in-addr.arpa 18.104.22.168 named.rev --end /etc/named.boot-- The ip address noted for the secondary lines (22.214.171.124 in this example) should be the IP address of the machine that is primary for the domain. The named.ca file should be retrieved as described in section 3.5. The named.local file should be created as described in section 3.6. The named.test and named.rev files will automatically be created when in.named is started up, by downloading the information from the primary server. Note: although this example only shows secondary lines, machines can actually combine primary and secondary lines in arbitrary ways. For example, a machine could primary test.com, and secondary foo.org, as a favor to a nearby domain. 3.9: How to Add a New Record to DNS Map or Zone Files Given below is an example of how to add a record for a new machine to your DNS files. Steps 1 and 2 will vary if you are adding something else, like MX or CNAME records. Steps 3 and 4 should be done whenever a change is made to a DNS file. This outline assumes the example shown in section 3.7 above. Step 1: Add an A record for your new host to your forward zone file In /var/named/named.test: newmachine.test.com. IN A 126.96.36.199 or newmachine IN A 188.8.131.52 Step 2: Add a PTR record for your new host to your reverse zone file In /var/named/named.rev: 3 IN PTR newmachine.test.com. Step 3: Increment the serial numbers of every file you changed In /var/named/named.test: 2 serial number In /var/named/named.rev: 2 serial number Step 4: Restart the named on your primary server # kill -HUP `cat /etc/named.pid` -------------------------- Advanced DNS Server Setups -------------------------- 3.10: How to Set Up Subdomains If you decide that you wish to create subdomains in your DNS zone, you have a number of options. The easiest method is to just include the subdomain in the same file as your domain. For example, if you control test.com, and wish to create a subdomain called sub.test.com, you could just put entries like the following in the file that is defined as primary for your test.com domain: machine.sub.test.com. IN A 184.108.40.206 If you prefer, you could put the subdomain in a seperate file. In this case, you would modify your named.boot. --start /etc/named.boot-- ; ; named.boot file for a name server with subdomains ; directory /var/named cache . named.ca primary 0.0.127.in-addr.arpa named.local primary test.com named.test primary sub.test.com named.sub primary 1.1.192.in-addr.arpa named.rev --end /etc/named.boot-- Afterwards, all of the machine.sub.test.com entries would go in named.sub. In the most complex setup, or if you are running the Solaris DNS BIND 4.9.3 patches, you MUST configure the subdomain properly. This also allows you to "give the subdomain away" to someone else, and allow them to control it. This is called Parenting (or Delegating) a Subdomain. To do this, you must edit the file that is primary for the domain, and add nameserver and A lines for the subdomain. For example, if I wanted to give control of sub.test.com to remote-machine.sub.test.com, I would put the following two lines in the named.test file: sub.test.com. IN NS remote-machine.sub.test.com. remote-machines.sub.test.com. IN A 220.127.116.11 In general, you must add a NS line for each of the machines that will be a name server for the subdomain. Although it is not necessary, most admins also put in an A record for each of those name servers. In DNS "geek" language, these are called "glue records". Afterwards, the subdomain nameservers must be set up as a primary or secondary nameserver (see Section 3.7), and changes may be made to those files on the primary server for the subdomain. 3.11: How to Set Up a "Self Contained" or Internal Root Nameserver If you are not connected to the internet, but still want to set up DNS, you must implement a Self Contained Domain. This is done by defining one of your internal machines as a root name server. On all nameservers other than your root name server, you will need to set up a special cache file. As usual, all of your non-root name servers will have the following line in their named.boot: cache . named.ca However, rather than retrieving a root file as is described in Section 3.5, you will contruct it yourself. Simply create a file that includes an NS record pointing towards your root name server, and an A record, as follows: --start /var/named/named.ca-- . 99999999 IN NS root.test.com. root.test.com. IN A 18.104.22.168 --end /var/named/named.ca-- You must also edit the files on your newly defined root server. There should NOT be a 'cache' line in the named.boot on the root name server. Rather, you need to insert a primary line for the root domain: --snippet of /etc/named.boot-- primary . named.root --snippet of /etc/named.boot-- The named.root file must contain nameserver records for each of your internal domains, and A records for each of them. If section 3.7 contained my entire internal DNS domain, I would need to create the following named.root file, which assumes just 1 root nameserver: -- named.root file --- ; ; Internal Root db ; @ IN SOA root.test.com. administrator.root.test.com. ( 1 ; serial number 10800 ; refresh after 3 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS root.test.com. root.test.com. IN A 22.214.171.124 ; NS records for test.com. ; We have two nameservers, test.com. and num2.test.com. test.com. IN NS dns.test.com. IN NS num2.test.com. ; NS records for our reverse domain ; We have two nameservers, test.com. and num2.test.com. 1.1.192.in-addr.arpa. IN NS dns.test.com. IN NS num2.test.com. ; A records for all of the nameservers listed above dns.test.com. IN A 126.96.36.199 num2.test.com. IN A 188.8.131.52 root.test.com. IN A 184.108.40.206 A self-contained domain should never be set up if you are directly connected to the internet. If you do become connected to the internet at a later time, you must replace all of your root caches with a correct one from the net. In addition, you must get rid of any 'primary .' lines in your named.boot files. 4.0 Frequently Asked Questions 4.1: Miscellaneous Questions Q1: What version of BIND does Sun's in.named implement? A1: SunOS implements Bind 4.8.1. This means that some newer directives such as 'search' will not be available. Solaris 2.5.1 and earlyer are supplied with Bind 4.8.3. A patch for Solaris 2.5.1 updates bind to 4.9.3. See the Solaris Patch list in Section 5.2. More details on BIND 4.9.3 are supplied in the Patches. Solaris 2.6 is supplied with BIND 4.9.4. BIND 8.1.1 may be supplied with a future release of Solaris, no commitments have been agreed at this time. You may load different versions of BIND onto SunOS or Solaris, however Sun does not support support these configurations. Contact http://www.vix.com/ to get info on download locations on the Web. Q2: What limitations are there on domain names? A2: According to RFC 924, the first character of your domain name may not be a digit (ie, 1sun.com is illegal). Though RFC 1123 does relax this limitation, Sun machines do not support this. Sun's Bind is RFC 924 compliant. Host names should not contain an underscore '_' character either. The BIND 4.9.4 server 'in.named' by default will not permit the use of underscores in primary zone/database files. You may currently override this feature by modifying named.boot with the following entry: check-names primary warn The 4.9.4 defaults are: check-names primary fail check-names secondary warn check-names response ignore Q3: Why do some of my host names appear as 255.255.255.255 or as a different number? A3: The cause of this is use of leading zeros in the DNS database files for the "A" records. If you put in a leading zero, named assumes the number is octal. Because 8 and 9 are illegal numbers in octal, the 255.255.255.255 entry goes in the database. Also an entry such as 192.1.1.032 translates the 032 to 26 decimal. Q4: How do I prevent someone from transfer DNS zone files from a Sun DNS server? A4: You can only to this with BIND 4.9.3. Use the xfrnets directive in the named.boot file. Q5: I have just installed the BIND 4.9.3 patches. What are all those "lame server" messages?? They are filling up my /var/adm/messages! A5: A "lame server" is a DNS server that has been incorrectly configured to be authoritative for information in another domain at the "same" level, or a "level above" it in the DNS name space. For example, if my server was authoritative for test.com, and if I put in information for sun.com in the database, I would see a "lame server" error message. Or, if I put in information for test.com in the database for "sub.test.com", I would also see this messages. Of course, being directly connected to the Internet, your name server will post hundreds of "lame server" messges, until such time that you fix the problem if it is caused by your server, or that the admin for the DNS server fixes it. A workaround is to NOT log infomation to daemon.info, in your /etc/syslog.conf file. Just put in a line daemon.info /dev/null And HUP the syslogd to change this behavior. Please note that you will lose some useful messages from in.named and possibly other daemons. Q6: Where can I find some DNS and BIND tools to help manage and troubleshoot my DNS environment? A6: Pointer to DNS tools, including zone check and h2n http://www.is.co.za/andras/computer/dnsrd/tools.html Q7: Where is there more info on the latest BIND developments? A7: http://www.vix.com/isc/ This is a pointer from Vixie Enterprises home page to the ISC (Internet Software Consortium). http://www.dns.net Misc info, including the tools mentioned above. Q8: If my DNS server is on the (USA) Internet, how big would I expect the in.named process to be? A8: This depends on the activity to and from your site, as well as the size of your database. In early 1997, we saw several University DNS servers running from 16MB to up 34MB in size. Expect this to grow as the Internet grows. 4.2: Common DNS Lookup Problems Q: Why does name resolution immediately fail? A1: An intercompatibility problem may exist with other naming services, such as NIS or NIS+. Run 'nslookup' and see if you can use that to lookup the record that you were trying to access. If 'nslookup' works, DNS is ok, but may not be integrated into your naming services. Consult section 4.4 or 4.5 below. A2: Your resolv.conf may be set up incorrectly. Reference section 3.1 for the correct way to set up your resolver. Verify the spelling of the various directives (domain, nameserver) to make sure that there were no inadvertant typos. A3: On a SunOS system, you may be trying to run DNS without NIS. This is unsupported. Section 4.4 explains your options. A4: On a 5.3 system, you may have a comment in the middle of the hosts line in your /etc/nsswitch.conf, as follows: hosts: file dns # changes made by me On 5.3 machines, comments in the nsswitch.conf must begin at the start of a line if they are in the middle of a line, that line will not be correctly read. Q: Why does name resolution hang for a minute before failing? A: If name resolution is hanging for an extended time before failing, this means that your DNS server is not responding. You should verify that you have a good route to your DNS server with the ping command. If your route seems sound, then either the server is not running in.named, or the server is having an error of its own. Either continue debugging the error on the server, or choose another machine to be your name server, and adjust your resolv.conf appropriately. Q: Why does name resolution hang for half a minute before returning an answer? A: This typically means that you have multiple name servers in you resolv.conf, and the first one or two failed, as in the question above. Your resolver is eventually falling back to a good name server later in your resolv.conf. You should comment out the first nameserver listed in your resolv.conf, and see if that improves the situation. If you have three nameservers listed, you may end up commenting out the first two. Afterwards, you should investigate the server to see what might have been causing the problem. Q: Why can I not look up names outside of my domain? A1: You do not have a named.ca file on your DNS server, or it is out of date, or it contains incorrect information. Section 3.5 shows how to get a new one. A2: Your DNS server is unable to contact the root servers. You can verify this by pinging the root servers listed in your cache file. If this seems to be the case, you should examine your routing, particularly to see if anything is purposefully blocking packets. Q: Why can I only sometimes look up names outside of my domain? A: Your named.ca file is out of date. Section 3.5 explains how to get a new one. 4.2.1: ping/telnet/rlogin Problems Related to Name Lookup Q: Why can I only ping/telnet/rlogin if I put a '.' after the machine name, ie 'ping sun.com.'? A: There is in an error in one of the DNS maps on the nameserver listed in your resolv.conf. Consult section 2.0 for hints on how to track down a map error. Adjusting your resolv.conf to look at a different DNS server will fix your client, but not the basic error which exists in one of your DNS maps. Q: Why does ping/telnet/rlogin core dump on my SunOS system when I try and connect to a system with multiple A records? A: This is a known bug. It is fixed in the libc patch for 4.1.3 and 4.1.3_u1. See section 5.1 below. Q: Why do some sites refuse to let me ftp/rlogin to them, complaining that they can't lookup my server name? A: Your machine is failing a security test because it does not have a PTR record in the reverse map. Consult section 3.9 above, for how to create both an A record and a PTR record for a machine. 4.3: Map or DNS Zone Modification Problems Q: Why don't my modifications to the DNS maps show up after I make them? A1: It could be that you are not following the proper procedure to make changes. First, you always need to increment the serial number of each and every map that you are modifying. All that is required is that the number be increased. Second, you always need to deliver a -HUP signal to the in.named process on your main server. See section 3.9 above for the proper procedure to add entries to DNS maps. A2: DNS changes do take a measurable time to be propagated. Depending on your exact setup, it may be two or more days before all sites on the internet see modifications that you make. The only machine that is guaranteed to have your new records, after you have followed the proper procedure noted in section 3.9 to add entries, is your primary nameserver. You can check that they are there by running nslookup, setting your server to be your primary DNS server, and then looking up the record. See section 2.3 for a brief introduction on running nslookup. If you are able to lookup DNS records on your primary DNS server, wait a few days after you have made the change. It is probable that the changes will get propagated out to the net in due time. NOTE: "HUP" the secondaries after you "HUP" the primary so the secondaries are updated right away instead of later. A3: If you have followed the proper procedure to add entries to your DNS map, but you are unable to look them up on the primary name server, it is likely that you made an error in your entry. Examine your maps carefully. You will also want to check the /var/adm/messages file, as noted in section 2.2. Q: Why do my modifications never appear anywhere outside my domain? A: If you can see modifications on your primary DNS server, but not anywhere else, and several days have passed since the change was made, it is likely that your primary server is not registered with InterNic as such. You can verify this by running nslookup, setting your server to something other than your primary (or secondary) DNS server, and then looking up the NS records for your domain. The best server to use for this lookup is your parent domain. That is, if you control sub.test.com, use the name server for test.com. If you control test.com or some other top level domain, use one of the root name servers listed in your cache file. Section 2.3 gives a brief introduction to running nslookup. 4.4: SunOS Name Server Interaction Q: How do I use DNS without NIS? A: You really can't, at least not in a supported manner. If you are running DNS on a SunOS machine, without NIS, you will find that it will react in a very erratic and unexpected manner. Lookups might not go to DNS at all, or they might go to DNS only in some specific cases. In order to run DNS in a Sun-supported manner, you should setup at least a minimal NIS configuration. If you are unwilling to do this, Sun SRDB #3886 explains how to modify your libc to remove any NIS dependencies. This procedure does work, but SunService is unable to support DNS on sites which use this configuration. Q: Why are my hostname lookups never checking DNS if NIS fails? A1: In order for hostname lookups to get passed on to DNS, if NIS lookups fail, you must build your DNS maps with a special "-b" flag. If you consult your /var/yp/Makefile on your NIS master, near the top, you will see four lines as follows: # Set the following variable to "-b" to have NIS servers use the domain name # resolver for hosts not in the current domain. #B=-b B= In order for DNS to work with NIS, you must change the last two lines: B=-b #B= Afterwards make a new map with the correct flags on it: # touch /etc/hosts # cd /var/yp # make A2: When NIS fails to lookup a host, and the request gets passed on to DNS, it is actually the yp server that does the DNS lookup, not your client. Check what your current ypserver is by executing: % ypwhich Then, log on to that server, and verify that DNS works correctly from that machine with the command: % nslookup See Section 2.3 for a description of the nslookup command. A3: You could be running into a bug where NIS gives up if the first DNS server does not respond. See section 5.1 for a description of the patches that resolve this bug. A4: It appears that ypserv can incorrectly cache information that says that a DNS server is down. When this occurs, NIS decides that DNS is down, and never forwards requests. This seems to occur most often when DNS has just been set up for the first time. After determining which yp server you are bound to, via the ypwhich command, try logging on to that machine, killing the ypserv daemon and restarting it. In many cases, this will cause DNS lookup to start working. Q: Why are my hostname lookups never checking DNS if NIS+, running in YP compatibility mode, fails? A1: If you are running NIS+ in YP compatibility mode, and have SunOS clients, your rpc.nisd must be run with the flags -Y and -B. Change the following line: EMULYP="-Y" in the file /etc/init.d/rpc to read: EMULYP="-Y -B" and then reboot your machine. Alternatively, you can find the rpc.nisd process in the process table, kill it, and restart it with the -Y and -B flags. In this case, you will still need to change the /etc/init.d/rpc file, however, in order to make rpc.nisd come up correctly after the next reboot. A2: When NIS+ fails to lookup a host, and the request gets passed on to DNS, it is actually the NIS+ server that does the DNS lookup, not your client. Go to each of your NIS+ servers, and verify that DNS works correctly from that machine with the command: % nslookup See Section 2.3 for a description of the nslookup command. If DNS is intermittently not getting used, it is quite possible that one of your NIS+ servers is not running DNS, since each NIS+ request gets handled by an arbitrary machine. 4.5: Solaris Name Server Interaction Q: Why isn't DNS being used for name lookups? A: On Solaris machines, the file /etc/nsswitch.conf controls what is used for hostname lookups. You should consult the hosts: line of that file, and verify that it includes dns. See section 3.2 for the correct method for adjusting the /etc/nsswitch.conf.
4.6: ns lookup Problems Q: Why can't nslookup look up an ip address, such as 127.0.0.1? A: Some versions of nslookup will let you type an ip address, such as 127.0.0.1, directly at the prompt, and then automatically do the reversal and lookup for you. This works, for example, under Solaris' nslookup. This is not true of older versions of nslookup on SunOS machines which will give you the following result: > 127.0.0.1 Server: sun-barr.EBay.Sun.COM Address: 220.127.116.11 Name: [127.0.0.1] Address: 127.0.0.1 For SunOS machines, you should request a PTR record, and reverse the address: > set type=ptr > 18.104.22.168.in-addr.arpa Server: sun-barr.EBay.Sun.COM Address: 22.214.171.124 126.96.36.199.in-addr.arpa host name = localhost.Sun.COM Q: Why does nslookup fail with the message "Can't find server name for address XXX.XXX.XXX.XXX"? A1: This typically means that a PTR record does not exist for the nameserver listed first in your resolv.conf. Section 3.9 explains how to correctly set up the reverse address records for a machine. You can check and see if the reverse address records exist for a machine by going to someplace where nslookup works, then telling it to look up the PTR record for that machine, as is described above. A2: This seems to occur in some instances where the server that you are connecting to is running the public domain 4.9.3 BIND and you are running nslookup on a SunOS box. If your server's reverse address records are set up correctly, you should determine if your server is running BIND 4.9.3 or 4.9.4. Contact the admin of that server and have them add the following to the named.boot file on the DNS server: options fake-iquery Q: Why does nslookup core dump when I run it? A: nslookup is very picky, and will coredump if it is given incorrect input. If nslookup core dumps when you start it up, you should check your /etc/resolv.conf, and all of your map files on your server (especially recently modified ones). Section 3.1 explains how a resolv.conf file should look. Section 2.0 gives hints on debugging bad map files.
4.7: DNS Directive Problems Q: Why is my 'search' directive not being used? A: The search directive is not supported under SunOS. If you wish to use the search directive, you must upgrade to Solaris, or use a public-domain version of BIND. Q: Why is my 'sortlist' directive not being used? A: sortlist is not supported on any of the current versions of Sun's DNS on SunOS 4.x, nor on the unpatched DNS on Solaris (4.8.3). 4.8: Common Error Messages The following errors are generated from in.named, usually to the /var/adm/messages file. Q: What does "named-xfer exited with signal 1" mean? A: named-xfer is the program that secondary name servers use to load the zone maps from primary name servers. If you see an error like the above, it usually means that named-xfer failed. You should try and ping the IP address listed as your primary server (this is in the named.boot, as is described in Section 3.8). If you can not ping it, you are having an connectivity problem. Other named-xfer problems may be diagnosed by running named-xfer by hand. This is described in Section 2.7. Q: What does "rt_malloc: memdebug overflow" mean? A: This is an error in the DNS implementation in Solaris 2.4. Apply patch 102479. See Section 5.2. Q: What does "too many zones (MAXZONES=128)" mean? A: Under SunOS, in.named has a limit of 128 zones this means that there may not be more than 128 primary/secondary lines in the named.boot. If you are hitting this limit, you will have to combine several subdomains into one domain file. ie, just list: primary test.com named.test Rather than: primary test.com named.test primary sub.test.com named.sub primary sub2.test.com named.sub2 ... Under Solaris, this limitation does not exist. 5.0 Patches 5.0: Patches The following is the list of all of the DNS related patches for 4.1.3, 4.1.3_u1, 4.1.4, 5.3, 5.4, 5.5 and 5.5.1. If you are having DNS problems, installing the patches is a good place to start, especially if you recognise the general symptoms noted below. In order for a machine to be stable, all of the recommended patches should be installed as well. The list of recommended patches for your operating system is available from sunsolve1.sun.com. 5.1: DNS Patches For SunOS 100390-01 SunOS 4.1, 4.1.x: DNS doesn't work properly with secondary name Resolves a problem where zone transfers were not occuring properly between primary and secondary DNS servers, because the $ORIGIN was getting changed. 100891-13 SunOS 4.1.3: international libc jumbo patch 100890-14 SunOS 4.1.3: domestic libc jumbo patch 101558-09 SunOS 4.1.3_U1: international libc jumbo patch 101759-05 SunOS 4.1.3_U1: domestic libc jumbo patch Correct a problem where ftp, ping and other internet connection programs coredump if they try and connect to a machine with multiple A records. Please be sure to install the domestic version, and not the international version, if you are in the US, because the international version does not include encryption, which is necessary for login to work correctly. 101838-01 SunOS 4.1.3_U1: in.named core dumps in 4.1.x Fixes a number of problems which caused in.named to core dump. 5.2: DNS Patches for Solaris 101739-13 SunOS 5.3: sendmail jumbo patch - security 101359-04 SunOS 5.3: DNS spoofing is possible per Cern ca-96.02 103705-01 SunOS 5.3: rpc.nisd_resolv rebuild for BIND 4.9.3 102167-03 SunOS 5.3: dns fix 102066-15 SunOS 5.4: sendmail jumbo patch - security 102479-04 SunOS 5.4: DNS spoofing is possible per Cern ca-96.02 102165-03 SunOS 5.4: nss_dns.so.1 fixes 103706-01 SunOS 5.4: rpc.nisd_resolv rebuild for BIND 4.9.3 101973-24 SunOS 5.4: fixes for libnsl and ypbind 102064-12 SunOS 5.4_x86: sendmail jumbo patch - security 102480-04 SunOS 5.4_x86: DNS spoofing is possible per Cern ca-96.02 102166-03 SunOS 5.4_x86: nss_dns.so.1 fixes 103707-01 SunOS 5.4_x86: rpc.nisd_resolv rebuild for BIND 4.9.3 101974-24 SunOS 5.4_x86: fixes for libnsl and ypbind 102980-10 SunOS 5.5: sendmail fixes 103667-03 SunOS 5.5: DNS spoofing is possible per Cern ca-96.02 103708-02 SunOS 5.5: rpc.nisd_resolv rebuild for BIND 4.9.3 103746-01 SunOS 5.5: XFN source modifications for BIND 4.9.3 102981-09 SunOS 5.5_x86: sendmail fixes 103668-03 SunOS 5.5_x86: DNS spoofing is possible per Cern ca-96.02 103709-01 SunOS 5.5_x86: rpc.nisd_resolv rebuild for BIND 4.9.3 103747-01 SunOS 5.5_x86: XFN source modifications for BIND 4.9.3 103594-06 SunOS 5.5.1: /usr/lib/sendmail fixes 103663-05 SunOS 5.5.1: DNS spoofing is possible per Cern ca-96.02 103680-01 SunOS 5.5.1: nscd/nscd_nischeck rebuild for BIND 4.9.3 103686-01 SunOS 5.5.1: rpc.nisd_resolv rebuild for BIND 4.9.3 103743-01 SunOS 5.5.1: XFN source modifications for BIND 4.9.3 103595-05 SunOS 5.5.1_x86: /usr/lib/sendmail fixes 103664-05 SunOS 5.5.1_x86: DNS spoofing is possible per Cern ca-96.02 103681-01 SunOS 5.5.1_x86: nscd/nscd_nischeck rebuild for BIND 4.9.3 103687-01 SunOS 5.5.1_x86: rpc.nisd_resolv rebuild for BIND 4.9.3 103744-01 SunOS 5.5.1_x86: XFN source modifications for BIND 4.9.3 103596-05 SunOS 5.5.1_ppc: /usr/lib/sendmail fixes 103665-04 SunOS 5.5.1_ppc: DNS spoofing is possible per Cern ca-96.02 103682-01 SunOS 5.5.1_ppc: nscd/nscd_nischeck rebuild for BIND 4.9.3 103688-01 SunOS 5.5.1_ppc: rpc.nisd_resolv rebuild for BIND 4.9.3 103745-01 SunOS 5.5.1_ppc: XFN source modifications for BIND 4.9.3 5.3: YP/DNS Intercompatibility Patches for SunOS 100482-08 SunOS 4.1 4.1.1 4.1.2 4.1.3: ypserv and ypxfrd Jumbo Patch Fixes a number of incompatibilities between DNS & YP, including the one noted in 101435, below. 101435-03 SunOS 4.1.3_U1: ypserv fix Resolves a problem where DNS would fail if the first name server was down, even if others when up, if YP was also involved. 6.0: Known Bugs & RFES 6.1: RFEs 1178513 Solaris DNS in.named et al. requires upgrade to latest version Requests that in.named be upgraded to the current version of Bind, which is 4.9.3 This is been done for Solaris ONLY. SunOS still uses BIND 4.8.1 6.2: BUGS Use SunSolve to search for bugs with DNS. 7.0: References Although this document tries to give an overview of the most common DNS issues, it is by no means comprehensive. The following resources should be used to supplement the information that is contained herein. 7.1: Important Man Pages in.named nslookup resolver resolv.conf 7.2: Sun SRDBs 3886 Using DNS without NIS 4619 How to set up NIS/YP to use DNS? 5113 How to set up reverse address in server 7.3: Sun Educational Services [pending] 7.4: Solaris Documentation _Name Services Configuration Guide_, Part #801-6635-10 Basic information on how to set up the various DNS files on a Solaris machine. 7.5: Third Party Documentation _DNS and Bind_, by Paul Albitz & Cricket Liu, published by O'Reilly & Associates, Inc., ISBN #1-56592-010-4 The definitive source on administering DNS. Gives in-depth information on DNS setup, administration and debugging. A necessity for anyone controlling a large DNS domain. IMPORTANT: as of 1/97 there is a 2ND edition of this book, which includes valuable additions and information on BIND 4.9.3. 7.6: RFCs RFCs are the internet-written documents that define the specifications of many common networking programs. RFCs can be retrieved from nic.ddn.mil, in the /rfc directory, or through WWW at http://www.cis.ohio-state.edu/hypertext/information/rfc.html 1032 Domain Administrators Guide 1033 Domain Administrators Operations Guide 1034 Domain Names - Concepts and Facilities 1035 Domain Names - Implementation and Specification Together, these four documents form the official specs for the Domain Naming Service that underlies BIND. 8.0: Supportability SunService is not responsible for the initial configuration of your DNS, nor for answering basic questions about how to put such a DNS configuration together. We can help resolve problems where DNS is not behaving correctly, but in such cases the contact must be a system administrator who has a good understanding of the syntax and rules of DNS maps.
9.0: Additional Support For initial configuration, or DNS setup, please contact your local SunService office for possible consulting offerings. Sun's Customer Relations organization can put you in touch with your local SunIntegration or Sales office. You can reach Customer Relations at 800-821-4643. SOLUTION SUMMARY: