TThhee DDoommaaiinn NNaammee SSeerrvviiccee _L_a_s_t _E_d_i_t _N_o_v_e_m_b_e_r _2_6_, _1_9_9_2 Reg Quinton Computing and Communications Services The University of Western Ontario London, Ontario N6A 5B7 Canada OOuuttlliinnee (1) IInnttrroodduuccttiioonn ---- History, Goals, Where is Documentation? (2) DDNNSS ddeessiiggnn ---- Components (daemon and resolver), Primary & Secondary servers, Boot Files and components, DNS data records (SOA, NS, etc). (3) PPuuttttiinngg iitt aallll ttooggeetthheerr ---- Registration, Responsiblity, Your DNS data, Configur- ing the resolver, implementing a server. (4) HHeellpp ---- the NIC and liaison. 11 UUWWOO//DDNNSS 11.. HHiissttoorryy//GGooaallss The Domain Name Service (or DNS) is the _m_o_s_t _i_m_p_o_r_t_a_n_t ser- vice on the Internet. An essential component to any IP implementation. Paul Mockapetris is the author of the DNS -- the design of the protocol, the overall methodology, etc. This guy is God! But even god gets help (many people have worked on the DNS -- cf. recent fix for nnssllooookkuupp((88))). When you say, eg. ffttpp uuuunneett..uuuu..nneett, you get connected to [192.48.96.2] (or perhaps [137.39.1.2]) because the DNS maps the name to the numbers. [[1111::4400aamm jjuulliiaann]] nnssllooookkuupp uuuunneett..uuuu..nneett NNaammee:: uuuunneett..uuuu..nneett AAddddrreesssseess:: 119922..4488..9966..22,, 113377..3399..11..22 The IPnet works by number, people and programmers work using names (likewise for every other network). UUWWOO//DDNNSS 22 When you say, eg. mmaaiill rroossnneerr@@vvaaxx..ooxxffoorrdd..aacc..uukk, your mail gets to Oxford in Britain because the DNS maps the name vvaaxx..ooxxffoorrdd..aacc..uukk to a gateway on the Internet. [[1111::5522aamm jjuulliiaann]] nnssllooookkuupp >> sseett ttyyppee==mmxx >> vvaaxx..ooxxffoorrdd..aacc..uukk vvaaxx..ooxxffoorrdd..aacc..uukk pprreeffeerreennccee == 1133,, mmaaiill eexxcchhaannggeerr == nnssffnneett--rreellaayy..aacc..uukk AAuutthhoorriittaattiivvee aannsswweerrss ccaann bbee ffoouunndd ffrroomm:: nnssffnneett--rreellaayy..aacc..uukk iinneett aaddddrreessss == 112288..8866..88..66 nnssffnneett--rreellaayy..aacc..uukk iinneett aaddddrreessss == 1144..00..00..66 NNSS11..CCSS..UUCCLL..AACC..UUKK iinneett aaddddrreessss == 112288..1166..55..3322 NNSS22..CCSS..UUCCLL..AACC..UUKK iinneett aaddddrreessss == 112288..1166..88..33 AAOOSS..BBRRLL..MMIILL iinneett aaddddrreessss == 119922..55..2255..8822 AAOOSS..BBRRLL..MMIILL iinneett aaddddrreessss == 112288..2200..11..22 MMCCSSUUNN..EEUU..NNEETT iinneett aaddddrreessss == 119922..1166..220022..11 33 UUWWOO//DDNNSS 11..11.. WWhheerree ttoo ssttaarrtt See RFC's 1032-1035 (for the brave). These are tedious read- ings -- not for the faint of heart (I haven't read them!). These notes are found as jjuulliiaann::~~ffttpp//ddoocc//ccoouurrsseess//ddnnss..ppss. Read the On-line manuals and the chapters in your System Administrator's Guide. [[1111::5599aamm jjuulliiaann]] mmaann 88 nnaammeedd [[1111::5599aamm jjuulliiaann]] mmaann 55 rreessoollvv..ccoonnff See also jjuulliiaann::~~ffttpp//nniicc (lots of good readings there) and especially (1) ~~ffttpp//nniicc//nnaammeedd: sample primary configuration (for mmccuu..oonn..ccaa). (2) ~~ffttpp//nniicc//nnaammeedd..sseeccoonnddaarryy: sample secondary configura- tion (for **..uuwwoo..ccaa). See also the newsgroup comp.protocols.tcp-ip.domains (for the bleeding edge). UUWWOO//DDNNSS 44 11..22.. DDNNSS EEvvoolluuttiioonn The DNS is an _e_v_o_l_v_i_n_g system although pretty stable these days. Evolving to provide more mail support, other networks (eg. AppleTalk), etc. Recently we at CCS/UWO have started using UUNNIIFFOO records to load the DNS with commentary text. The RFC spec says we ought to use TTXXTT records but this isn't implemented by many servers. You may have noticed recent change notices to fix a bug in nnssllooookkuupp((88)) or the report of problems with ggeetthhoossttbbyynnaammee((33)). Both are instances where we've loaded the DNS more informa- tion than the designers assumed -- problems allocating space for answers. On CCS Unix systems we've implemented some nice local tools that interface with nslookup -- bbyynnaammee((11)) and bbyynnuumm((11)). 55 UUWWOO//DDNNSS 11..33.. GGooaallss The goal is to provide a distributed data base that imple- ments the traditional //eettcc//hhoosstt (or hhoossttss..ttxxtt) files of pre- DNS IP implementations. [[22::5577ppmm jjuulliiaann]] ppaaggee //eettcc//hhoossttss ## WWeedd NNoovv 1111 1177::0088::1188 EESSTT 11999922 ## DDaattaa ddeerriivveedd ffrroomm ooffffiicciiaall DDNNSS ddaattaa ## 112299..110000..00..00 uuwwoo--nneett..uuwwoo..ccaa 112299..110000..11..00 ccccsseexxpp..nneett..uuwwoo..ccaa 112299..110000..11..11 rroommuulluuss..ccccss..uuwwoo..ccaa 112299..110000..11..1100 hhaaddrriiaann..ccccss..uuwwoo..ccaa 112299..110000..11..1111 mmyysstt..ccccss..uuwwoo..ccaa 112299..110000..11..1133 ssuuppeerr..ccccss..uuwwoo..ccaa 112299..110000..11..1144 ddeebbbbiiee..ccccss..uuwwoo..ccaa 112299..110000..11..1155 rraajj..ccccss..uuwwoo..ccaa 112299..110000..11..1177 sshhaaddooww..ccccss..uuwwoo..ccaa 112299..110000..11..1188 ccrryyssttaall..ccccss..uuwwoo..ccaa 112299..110000..11..1199 ooppeerrss..ccccss..uuwwoo..ccaa ....etc. There are some 1,500 (700 in 1990) IP numbers listed in the current //eettcc//hhoossttss for Western (available as jjuulliiaann::~~ffttpp//nniicc//hhoossttss). If we were to list all hosts on the Internet we'd need a file of some 1,000,000 or more hosts! UUWWOO//DDNNSS 66 11..44.. HHiissttoorryy Several events motivate the need for a distributed DNS ser- vice. Circa 1984, now, and in the forseeable future. (1) ARPAnet addressing uusseerr@@hhoosstt didn't capture sites not on the ARPAnet. (2) Addressing by network, eg. uusseerr@@hhoosstt..AARRPPAA and uusseerr@@hhoosstt..CCSSNNEETT, isn't necessarily the best route. For example, to get to the machine CCUUNNYYVVMM..BBIINNEETT (aka ccuunnyyvvmm..ccuunnyy..eedduu) routing over the Internet is much faster. (3) SSeennddmmaaiill..ccff files were very difficult to administer -- lots of rules for delivery to UUCP, BITNET, ARPAnet, MILnet, CSNet, Mailnet, etc. (4) ARPAnet grew to a size where distributing //eettcc//hhoosstt (or hhoossttss..ttxxtt) would actually kill the net (cf. 1,500 hosts at Western and 1,000,000 or more on the Inter- net). (5) Linear searches of //eettcc//hhoosstt are tedious when the file is large. 77 UUWWOO//DDNNSS (6) Updates to a central database distributed out to sites meant that changes to the net were not seen for months. (cf. BITNET routing tables, UUCP maps). (7) //eettcc//hhoossttss is managed by a person who may (or may not) make sure the data is in fact up to date. Like- wise for sseennddmmaaiill..ccff files. (8) People on NetNorth, for example, wanted to have an addressing scheme that covered all systems on campus not just those on the particular network. (9) The HOSTMASTER at NNIICC..DDDDNN..MMIILL (the Network Informa- tion Centre for the Internet) was tired of constantly updating the central version of hhoossttss..ttxxtt. NNIICC..DDDDNN..MMIILL stopped supporting //eettcc//hhoossttss (actually hhoossttss..ttxxtt) around 1988 -- if you wanted to participate you had to use the DNS. This was at about the time Western con- nected. If you want to participate, there's only one way. Use the DNS! UUWWOO//DDNNSS 88 11..55.. GGooaallss//NNeeeeddss There was, and is, a clear need for a facility that (1) Provides addressablity to sites not on the ARPAnet (eg. so you can address uusseerr@@ddoo..mmaa..iinn without worry- ing about hhooww mail gets to the user). (2) Didn't require a centralized data base (which would kill the net and the hostmaster). (3) Can be managed in a distributed manner by those who have been given responsiblity for their network and/or domain. (4) That would be backwards compatible with //eettcc//hhoossttss and hhoossttss..ttxxtt (note that hhoossttss..ttxxtt listed name, num- ber, machine type, and services). (5) That would provide timely answers to questions like ggeetthhoossttbbyynnaammee((33)) (linear searches aren't fast!) Without the Domain Name Service the Internet would not have survived! Certainly would not have survived at the current size. 99 UUWWOO//DDNNSS 22.. DDNNSS ddeessiiggnn The problem managed by the DNS is the coordination and map- ping of domain names to and from IP numbers (plus mail rout- ing, machine type, services, owner, and more). The coordination of IP numbers and Domain Names is man- aged by the NNIICC..DDDDNN..MMIILL (actually by hhoossttmmaass-- tteerr@@nniicc..ddddnn..mmiill). They delegate responsiblity and authority to campus NIC's (perhaps through regional contacts, eg. CAnet for Canada). The NIC for Western is CCS (by email as NNIICC@@UUWWOO..CCAA). (1) NNIICC..DDDDNN..MMIILL has assigned the class B IP-network [129.100.0.0] known as UUWWOONNEETT to the University of Western Ontario and responsibilty to CCS. (2) NNIICC..DDDDNN..MMIILL has assigned the domain name CCAA to Canada and delegated responsibility to CCAAnneett; they have assigned the domain name UUWWOO..CCAA to the University of Western Ontario and responsibilty to CCS. UUWWOO//DDNNSS 1100 This is a chain of authority with the top most responsiblity at the Internet NIC, delegated down through Country, Univer- sity, on to departmental NIC's. [[1111::1133aamm ssuunnccoonn]] nnssllooookkuupp >> sseett ttyyppee==ssooaa >> .. oorriiggiinn == nnss..nniicc..ddddnn..mmiill mmaaiill aaddddrr == hhoossttmmaasstteerr..nniicc..ddddnn..mmiill eettcc...... >> ccaa.. oorriiggiinn == rreellaayy..ccddnnnneett..ccaa mmaaiill aaddddrr == hhoossttmmaasstteerr..rreellaayy..ccddnnnneett..ccaa eettcc...... >> uuwwoo..ccaa.. oorriiggiinn == jjuulliiaann..uuwwoo..ccaa mmaaiill aaddddrr == nniicc..jjuulliiaann..uuwwoo..ccaa eettcc...... >> ccssdd..uuwwoo..ccaa oorriiggiinn == ssyybbiill..ccssdd..uuwwoo..ccaa mmaaiill aaddddrr == mmaaggii..ccssdd..uuwwoo..ccaa The mail address in the Start of Authority (SOA) record is the person responsible for the domain. CCS delegates responsiblity to departments through a registration proce- dure. Networking comes with some responsiblities -- at a minimum all hosts must be registered. 1111 UUWWOO//DDNNSS 22..11.. DDNNSS ccoommppoonneennttss There are two parts to the Domain Name Service: (1) The NNaammee DDaaeemmoonn -- this is the program which runs on our campus name servers. Name Daemons answer ques- tions about name to number translations. These are tcp/ip server processes. There are several running at UWO -- jjuulliiaann, hhyyddrraa and rrrrii are the official name servers known to the rest of the internet. (2) The RReessoollvveerr RRoouuttiinneess -- these provide the interface between your application program (eg. tteellnneett((11)), or ffttpp((11))) and the Name Daemon. The ggeetthhoossttbbyynnaammee((33)) call, for example, is implemented by a resolver rou- tine which talks to the appropriate name daemon. Cf. NNTP -- the Network News Transport Protocol. People use programs like rrrrnn (usually installed as rrnn) to read news. These news readers interact with an NNTP daemon (a server program running on some machine on the net) to get informa- tion that in earlier implementations required access to files. Cf. SQL as a protocol for interacting with remote data bases. UUWWOO//DDNNSS 1122 22..11..11.. RReessoollvveerr rroouuttiinneess Programmers use library calls like ggeetthhoossttbbyynnaammee((33)), ggeehhoosstt-- bbyynnuummbbeerr((33)), etc. These are now implemented using low level resolver calls. The DNS did not require people to rewrite their programs -- the library interface is preserved. Note that the manual entry for ggeetthhoossttbbyynnaammee((33)) has not changed. People program using tools that give answers -- how the tool computes the answer is someone else's problem. The Application Programming Interface (API) remains the same (cf. POSIX standards that define an API). 1133 UUWWOO//DDNNSS The resolver routines are hidden in the C library -- not seen by the casual user. The reference point to connect resolver routines with name daemon on Unix systems is the file //eettcc//rreessoollvv..ccoonnff Resolver routines look for this file (if absent they look to //eettcc//hhoossttss). The resolver file details wwhheerree name servers are found. For example, most people have set up an //eettcc//rreessoollvv..ccoonnff that contains these lines (modulo your departmental domain name): nnaammeesseerrvveerr 112299..110000..22..1122 nnaammeesseerrvveerr 112299..110000..22..1133 nnaammeesseerrvveerr 112299..110000..77..110000 ddoommaaiinn ccccss..uuwwoo..ccaa UUWWOO//DDNNSS 1144 The resolver file lists several name servers. The nnaammeesseerrvveerr lines are used to find a name server. Three are given: jjuulliiaann [129.100.2.12], hhyyddrraa [129.100.2.13] and rrrrii [129.100.7.100]. These are the official name servers for uuwwoo..ccaa. There will be a lot of network traffic generated if the name servers you use aren't on the same network (ie. separated by a router). You'd also have real problems if these name servers weren't accessible (say they, or the net, were down). These are the _r_e_a_s_o_n_s for running a local secondary server. Anyone can run a secondary name server (provided that they are able). A kit has been prepared in jjuulliiaann::~~ffttpp//nniicc//nnaammeedd..sseeccoonnddaarryy. PC's and MACs typically rely on some other machine and don't run a name server. Note: a name server will require space for data -- say 200 bytes/entry. For the 1,500 entries at UWO you're well over the free space available on a typical PC or MAC. 1155 UUWWOO//DDNNSS The resolver file lists a default domain. The ddoommaaiinn mentioned in //eettcc//rreessoollvv..ccoonnff is used to qualify hostnames (a name not terminated by a `.' needs to be qualified). When I say, for example ffttpp hhyyddrraa the resolver routines try to find hhyyddrraa..ccccss..uuwwoo..ccaa, if that fails they try hhyyddrraa..uuwwoo..ccaa, if that fails they try hhyyddrraa..ccaa. Some systems (eg. NeXT and A/IX) aren't very bright about the default domain search (ie. they'll try hhyyddrraa..ccccss..uuwwoo..ccaa and that's all). These are early implementations -- defi- nitely not state of the art. UUWWOO//DDNNSS 1166 22..11..22.. RReessoollvveerr oonn VVaaxx//VVMMSS The Multinet implementation of the resolver routines is sim- ilar (it's actually a port of the public domain BSD imple- mentation). Rather than a file //eettcc//rreessoollvv..ccoonnff Multinet uses Vax/VMS logicals $$ sshhooww llooggiiccaall mmuullttiinneett** .... ((LLNNMM$$SSYYSSTTEEMM__TTAABBLLEE)) .... ""MMUULLTTIINNEETT__LLOOCCAALLDDOOMMAAIINN"" == ""UUWWOO..CCAA"" ""MMUULLTTIINNEETT__NNAAMMEESSEERRVVEERRSS"" == ""112277..00..00..11"" == ""112299..110000..22..1122"" ... This corresponds to the //eettcc//rreessoollvv..ccoonnff file: nnaammeesseerrvveerr 112277..00..00..11 nnaammeesseerrvveerr 112299..110000..22..1133 ddoommaaiinn uuwwoo..ccaa So there's nothing strange or mysterious going on here. 1177 UUWWOO//DDNNSS 22..11..33.. RReessoollvveerr oonn CCUUTTCCPP For CUTCP on MS/DOS your ccoonnffiigg..tteell will have similar infor- mation as follows: ddoommaaiinnttiimmee==44 ## llooookkuupp ttiimmeeoouutt ddoommaaiinnrreettrryy==44 ## mmaaxx nnuummbbeerr ooff rreettrriieess ddoommaaiinnsslliisstt==""ccccss..uuwwoo..ccaa,,uuwwoo..ccaa"" ## ddeeffaauulltt ddoommaaiinn aassssuummppttiioonnss ... nnaammee==jjuulliiaann hhoosstt==jjuulliiaann..uuwwoo..ccaa hhoossttiipp==112299..110000..22..1122 nnaammeesseerrvveerr==11 ## ffiirrsstt nnaammee sseerrvveerr ... nnaammee==hhyyddrraa hhoosstt==hhyyddrraa..uuwwoo..ccaa hhoossttiipp==112299..110000..22..1133 nnaammeesseerrvveerr==22 ## sseeccoonndd nnaammee sseerrvveerr ... nnaammee==rrrrii hhoosstt==rrrrii..uuwwoo..ccaa hhoossttiipp==112299..110000..77..110000 nnaammeesseerrvveerr==33 ## tthhiirrdd nnaammee sseerrvveerr This corresponds with //eettcc//rreessoollvv..ccoonnff on Unix so there's nothing strange or mysterious going on here either! UUWWOO//DDNNSS 1188 22..11..44.. MMiinniimmuumm CCoonnffiigguurraattiioonn At a _m_i_n_i_m_u_m you can participate in the DNS by (1) Constructing //eettcc//rreessoollvv..ccoonnff file (for Unix) with appropriate servers and default domain. (2) Defining the appropriate logicals (for Vax/VMS). (3) Configuration values in ccoonnffiigg..tteell (for CUTCP on MS/DOS) This will enable you to say, for example [[22::5577ppmm jjuulliiaann]] ffttpp uuuunneett..uuuu..nneett even if you don't have a tabled entry in //eettcc//hhoossttss (or hhoossttss..ttxxtt). Single user work stations, eg. your desktop Sun 3/50, PC or MAC, are often configured this way. All DNS queries are han- dled by talking with a remote server (eg. the NFS file server for that system). 1199 UUWWOO//DDNNSS Larger systems, which do a lot more IP work, should have more than this minimal configuration -- they should run a Name Daemon. UUWWOO//DDNNSS 2200 22..22.. NNaammee DDaaeemmoonnss The Name Daemon (or name server) is the process which answers queries made by resolver routines. This is an IP service listening on the ddoommaaiinn port (see //eettcc//sseerrvviicceess, also check servers with nneettssttaatt((88))). Most Name Daemons are ports of BIND (the Berkeley Internet Name Daemon). This is a public domain implementation of the DNS (available on uunet and other archives). [[1100::0088aamm jjuulliiaann]] wwhhaatt //eettcc//nnaammeedd //eettcc//nnaammeedd:: nnaammeedd 44..88..33 TTuuee OOcctt 2200 1155::3322::0088 EEDDTT 11999922 ddbb__dduummpp..cc 44..3300 ((BBeerrkkeelleeyy)) 66//11//9900 eettcc...... We're running the most recent version of nnaammeedd on julian -- not the vendor version (why are vendors so slow to keep up?). 2211 UUWWOO//DDNNSS 22..22..11.. PPrriimmaarryy vvss.. SSeeccoonnddaarryy SSeerrvveerrss There are two types of Name Daemon: (1) A pprriimmaarryy name server answers questions using author- itative data on file (and someone is supposed to be maintaining that data file!). (2) A sseeccoonnddaarryy name server answers questions using data retrieved periodically over the net from some primary name server and cached locally in a file. (3) Most name servers are a mix of primary and secondary (eg. primary for the local domain, secondary for some others). The Name Daemon is started at boot time and uses the config- uration file //eettcc//nnaammeedd..bboooott. On Vax/VMS the file is: mmuullttiinneett::ddoommaaiinn--nnaammee--sseerrvviiccee..ccoonnffiigguurraattiioonn UUWWOO//DDNNSS 2222 22..22..22.. NNaammeedd..bboooott NNaammeedd..bboooott is the configuration file read when the name dae- mon starts. For example, in julian's boot sequence iiff [[ --xx //eettcc//nnaammeedd --aa --ff //eettcc//nnaammeedd..bboooott ]];; tthheenn //eettcc//nnaammeedd --bb //eettcc//nnaammeedd..bboooott;; ffii What is required in a configuration file to get a Name Dae- mon up, running, and communicating with other Name Daemons? (1) Where are some other name daemons on the net? In par- ticular, where are the rroooott name servers? (2) What domains do I serve? ie. what do I act as a pri- mary/secondary server for? In theory the ssiimmpplleesstt name server would only need to know where the root name servers are -- everything else can be learned from them. In pprraaccttiiccee one would always have some authoritative data on hand (eg. my name and number). 2233 UUWWOO//DDNNSS The Named.boot file on julian looks like: ;; ...... ;; pprriimmaarryy mmaasstteerr bboooott ffiillee ((mmooddeelllleedd aafftteerr wwaatteerrlloooo''ss)) ;; ddoommaaiinn uuwwoo..ccaa ddiirreeccttoorryy //uussrr//llooccaall//lliibb//nnaammeedd ;; ...... pprriimmaarryy uuwwoo..ccaa ddaattaa//uuwwoo..ddoommaaiinn pprriimmaarryy aappmmaatthhss..uuwwoo..ccaa ddaattaa//aappmmaatthhss..ddoommaaiinn pprriimmaarryy aarrttss..uuwwoo..ccaa ddaattaa//aarrttss..ddoommaaiinn pprriimmaarryy aassttrroo..uuwwoo..ccaa ddaattaa//aassttrroo..ddoommaaiinn pprriimmaarryy bbiioossttaattss..uuwwoo..ccaa ddaattaa//bbiioossttaattss..ddoommaaiinn ;; ........ pprriimmaarryy 110000..112299..iinn--aaddddrr..aarrppaa iinn--aaddddrr..aarrppaa pprriimmaarryy 00..00..112277..iinn--aaddddrr..aarrppaa nnaammeedd..llooccaall ;; ...... ;; SSeeccoonnddaarryy ssttuuffff ffoorr mmccuu..ggoovv..oonn..ccaa ;; sseeccoonnddaarryy mmccuu..ggoovv..oonn..ccaa.. 119922..6688..222299..11 ccaacchhee//mmccuu.... sseeccoonnddaarryy 222299..6688..119922..iinn--aaddddrr..aarrppaa.. 119922..6688..222299..11 ccaacchhee//222299.... ;; ...... ccaacchhee .. rroooott..ccaacchhee The ellipsis indicates deleted data (for these slides only). UUWWOO//DDNNSS 2244 22..22..33.. BBoooott FFiillee CCoommppoonneennttss 22..22..33..11.. CCoommmmeennttss Any line beginning with a `;' is a comment. If you don't comment your work then how can anyone help you? ;; $$AAuutthhoorr:: rreeggggeerrss $$ ;; $$DDaattee:: 11999922//1111//2266 1177::4477::5588 $$ ;; $$IIdd:: nnaammeedd..bboooott,,vv 11..6600 11999922//1111//1122 1155::5577::5522.... ;; $$SSoouurrccee:: //uussrr//llooccaall//lliibb//nnaammeedd//RRCCSS//nnaammeedd..bboo.... ;; ;; pprriimmaarryy mmaasstteerr bboooott ffiillee ((mmooddeelllleedd aafftteerr ww.... 22..22..33..22.. DDoommaaiinn The ddoommaaiinn keyword specifies the default domain. As the pri- mary and secondary data is loaded any domain not terminated with a `.' gets this tacked on. ddoommaaiinn uuwwoo..ccaa But note that the default domain can be changed in any file with an OORRIIGGIINN directive. 2255 UUWWOO//DDNNSS 22..22..33..33.. DDiirreeccttoorryy The ddiirreeccttoorryy line specifies the default directory where files are stored. Current working directory for execution. ddiirreeccttoorryy //uussrr//llooccaall//lliibb//nnaammeedd For example, on julian: [[1100::0099aamm jjuulliiaann]] llcc //uussrr//llooccaall//lliibb//nnaammeedd DDiirreeccttoorriieess:: RRCCSS ccaacchhee ddaattaa rreeggiissttrraattiioonn FFiilleess:: DDiissttffiillee aalliiaasseess iinn--aaddddrr..aarrppaa iinn--eetthheerr..aarrppaa iinn--nnoovveellll..aarrppaa nnaammeedd..bboooott nnaammeedd..llooccaall rroooott..ccaacchhee rroooott..zzoonnee Note that we store everything in a local directory: [[1111::3355aamm jjuulliiaann]] llss //eettcc//nnaammeedd..bboooott //eettcc//nnaammeedd..bboooott -->> //uussrr//llooccaall//lliibb//nnaammeedd//nnaammeedd..bboooott UUWWOO//DDNNSS 2266 22..22..33..44.. PPrriimmaarryy Lines with keyword pprriimmaarryy specify a domain and file where _a_u_t_h_o_r_i_t_a_t_i_v_e data for that domain is stored -- Start of Authority (SOA) data. pprriimmaarryy ccooggssccii..uuwwoo..ccaa.. ddaattaa//ccooggssccii..ddoommaaiinn The file ddaattaa//ccooggssccii..ddoommaaiinn is found in the specified direc- tory //uussrr//llooccaall//lliibb//nnaammeedd and contains SOA data for the men- tioned domain. The file _m_u_s_t have one, and only one, SOA record for the domain. This is the data file that the technical contact maintains and submits to the NIC. 2277 UUWWOO//DDNNSS 22..22..33..55.. SSeeccoonnddaarryy Lines with keyword sseeccoonnddaarryy specify a domain, sites which have authoritative data, and file where _c_a_c_h_e_d data is stored. sseeccoonnddaarryy ccssdd..uuwwoo..ccaa.. 112299..110000..1111..55 ccaacchhee//ccssdd..uuwwoo..ccaa The file ccaacchhee//ccssdd..uuwwoo..ccaa is retrieved from the specified server [129.100.11.5] and cached in the specified directory (if the server is down it can use cached data). The file will contain SOA data for the mentioned domain (the server is the primary server for that domain and ought to have authoritative data on file). The data _m_u_s_t have one, and only one, SOA record for the specified domain. UUWWOO//DDNNSS 2288 22..22..33..66.. CCaacchhee Lines with keyword ccaacchhee specify a file with hot-wired information. Usually the "root" domain servers are stored in the file rroooott..ccaacchhee. ccaacchhee .. rroooott..ccaacchhee You need to have some pointers to the root servers. On julian, the rroooott..ccaacchhee file is: ;; ......lloottss ooff ccoommmmeennttss ;; .. 9999999999999999 IINN NNSS NNSS..NNIICC..DDDDNN..MMIILL.. IINN NNSS AAOOSS..BBRRLL..MMIILL.. IINN NNSS AA..IISSII..EEDDUU.. ;; ...... ;; NNSS..NNIICC..DDDDNN..MMIILL.. 9999999999999999 IINN AA 119922..6677..6677..5533 AAOOSS..BBRRLL..MMIILL.. 9999999999999999 IINN AA 119922..55..2255..8822 AA..IISSII..EEDDUU.. 9999999999999999 IINN AA 2266..33..00..110033 ;; ...... These records specify the nnaammeess of Root Name Servers (IINN NNSS records) and their aaddddrreessss (IINN AA records). These records are effectively permanent (with a 99999999 Time to Live TTL value). 2299 UUWWOO//DDNNSS 22..22..33..77.. FFoorrwwaarrddeerrss Lines with keyword ffoorrwwaarrddeerrss list IP addresses of local Name Servers who know more (eg. everyone on campus uses the three campus servers as forwarders -- to minimize DNS traf- fic on ONet). ;; IIff II ccaann''tt aannsswweerr iitt,, tthheessee gguuyyss ccaann:: ;; ffoorrwwaarrddeerrss 112299..110000..22..1122 \\ 112299..110000..77..110000 \\ 112299..110000..22..1133 We don't want too much traffic on our ONet links and _i_n_s_i_s_t that sites use the official servers (jjuulliiaann, hhyyddrraa, and rrrrii) as forwarders. Those servers, of course, don't have any forwarders specified -- they go out to the net. UUWWOO//DDNNSS 3300 22..33.. DDNNSS rreeccoorrdd ffoorrmmaatt The format of the records in root.cache is _e_x_a_c_t_l_y the same as the format in pprriimmaarryy data files. Each record in the DNS looks like: [[_d_o_m_a_i_n]] [[_T_T_L]] IINN _d_a_t_a Each record gives information about a domain (eg. address, machine type, services, mail routing, etc.). 3311 UUWWOO//DDNNSS 22..33..11.. DDoommaaiinn DNS data records are all tagged by a ddoommaaiinn name. All DNS queries (ie. low level resolver routines) ask for records by domain name. If the domain name is missing on a record, the previous one is assumed. These are the equivalent: hhyyddrraa..uuwwoo..ccaa.. IINN AA 112299..110000..22..1133 IINN WWKKSS 112299..110000..22..1133 TTCCPP tteellnneett ffttpp ssmmttpp IINN MMXX 00 hhyyddrraa..uuwwoo..ccaa.. IINN MMXX 1100 jjuulliiaann..uuwwoo..ccaa.. IINN HHIINNFFOO ""VVAAXX 44550000"" ""VVMMSS"" IINN UUIINNFFOO ""MMaacchhiinnee rroooomm,, CCCCSS,, 22nndd ffllrr..,, NNaatt..SScc.."" IINN UUIINNFFOO ""CCoonnttaacctt:: GGeerraarrdd SSttaafflleeuu <>"" IINN UUIINNFFOO ""PPhhoonnee:: 667799--22111111xx((66004433))"" IINN UUIINNFFOO ""aallssoo kknnoowwnn aass ''uuwwoovvaaxx''"" and hhyyddrraa..uuwwoo..ccaa.. IINN AA 112299..110000..22..1133 hhyyddrraa..uuwwoo..ccaa.. IINN WWKKSS 112299..110000..22..1133 TTCCPP tteellnneett ffttpp ssmmttpp hhyyddrraa..uuwwoo..ccaa.. IINN MMXX 00 hhyyddrraa..uuwwoo..ccaa.. hhyyddrraa..uuwwoo..ccaa.. IINN MMXX 1100 jjuulliiaann..uuwwoo..ccaa.. UUWWOO//DDNNSS 3322 Note the trailing dot convention to distinguish uuwwoo..ccaa.. (Canada) from uuwwoo..ccaa (which might mean California in the US). A fully qualified domain name (ie. no assumptions about the current context) will terminate with a dot. If the domain name iissnn''tt ffuullllyy qquuaalliiffiieedd then the default domain is tacked on (but this is dangerous, be careful). These are the same: hhyyddrraa..uuwwoo..ccaa.. IINN AA 112299..110000..22..1133 and $$OORRIIGGIINN uuwwoo..ccaa.. hhyyddrraa IINN AA 112299..110000..22..1133 The moral here is to always fully qualify all domain names. Everyone who has ever maintained DNS data has, at some time, dropped a trailing `.' and suffered for it. 3333 UUWWOO//DDNNSS 22..33..22.. TTTTLL TTTTLL -- time to live. A permanent record would have a large value (eg. 99999999). You only see these in root.cache files on hot wired addresses. For example, from julian's rroooott..ccaacchhee: NNSS..NNIICC..DDDDNN..MMIILL.. 9999999999999999 IINN AA 119922..6677..6677..5533 All records in the DNS have a TTL value (specified in the SSOOAA record). Name Daemons _c_a_c_h_e answers they've received. This minimizes traffic on the net (the first query for a domain is cached, subsequent queries get the cached answer). UUWWOO//DDNNSS 3344 22..33..33.. IINN IINN is short for Internet. The DNS is designed to support a directory service for arbitrary networks -- there's talk of defining Apple, Decnet, ISO, etc. records. But not much has come of that (can you say X.500?). To date all records in production DNS servers are internet records. 3355 UUWWOO//DDNNSS 22..33..44.. IINN SSOOAA A Start of Authority record lists important information about the primary DNS data for a domain. Each data file listed with a pprriimmaarryy record in the named.boot will have an SOA record. That includes the in-addr.arpa. map. For example, from the primary DNS data file for gp.uwo.ca. $$OORRIIGGIINN ggpp..uuwwoo..ccaa.. ;; SSOOAA mmeeaannss SSttaarrtt ooff AAuutthhoorriittyy,, wwhhoo''ss iinn cchhaarrggee?? @@ IINN SSOOAA jjuulliiaann..uuwwoo..ccaa.. jjoohhnn..sseeiiss..ggpp..uuwwoo..ccaa.. (( 11..22 ;; SSeerriiaall EEDDIITT MMEE TTOOOO!!!! 33660000 ;; RReeffrreesshh 330000 ;; RReettrryy 33660000000000 ;; EExxppiirree 33660000 )) ;; MMiinniimmuumm UUWWOO//DDNNSS 3366 The @@ is just a way of say ggpp..uuwwoo..ccaa. This is a record for the ggpp..uuwwoo..ccaa domain. jjuulliiaann..uuwwoo..ccaa. That's the name of the primary server for this domain. Authoritative data is on file on that system. jjoohhnn..sseeiiss..ggpp..uuwwoo..ccaa. That's the mail address of the person who maintains the primary data. If the data is wrong, it's his problem. Note the addressing style -- no `@' sign. Use the machine address not an alias. The Serial Number -- each change to the primary data had better change the serial number. Secondary servers regularly query the primary and check serial numbers (to see if their cache is out of date). Some of the other numbers tailor querying and expiration times. Time to live (TTL). No promises, but I believe the Minimum number is the TTL applied to all data in this domain. 3377 UUWWOO//DDNNSS 22..33..55.. IINN NNSS A Name Server record, lists a Name Server for the domain. Every domain must have at least two name servers (for the case when one is down). The root name servers (eg. at NNSS..NNIICC..DDDDNN..MMIILL) have NNSS records for CCAA. that look like: ccaa.. IINN NNSS rreellaayy..ccddnnnneett..ccaa.. ccaa.. IINN NNSS nnnnsscc..nnssff..nneett.. ccaa.. IINN NNSS cclloouussoo..ccrriimm..ccaa.. ccaa.. IINN NNSS uuggww..uuttccss..uuttoorroonnttoo..ccaa.. These servers, in turn, have NNSS records for UUWWOO..CCAA. that look like: uuwwoo..ccaa.. IINN NNSS jjuulliiaann..uuwwoo..ccaa.. uuwwoo..ccaa.. IINN NNSS rreellaayy..ccddnnnneett..ccaa.. uuwwoo..ccaa.. IINN NNSS hhyyddrraa..uuwwoo..ccaa.. uuwwoo..ccaa.. IINN NNSS rrrrii..uuwwoo..ccaa.. With only a very few network queries (and redirects to other Name Servers) you get the information you need. Of course none of these records are worth very much if they don't also have Address records cached with a long TTL! UUWWOO//DDNNSS 3388 22..33..55..11.. NNSS cchhaaiinn ooff rreessppoonnbbiilliittyy NNSS records pointing from the root, through CCAA and on down to UUWWOO..CCAA nameservers don't appear in the DNS by magic; _p_e_o_p_l_e put them into primary DNS data files. However Only CCS is the authority for UUWWOO..CCAA, and only CCS can ask for UUWWOO..CCAA NNSS records. This we have done. Likewise only CCAAnneett is the authority for CCAA, and only they can ask for CCAA NNSS records. This they have done. If _y_o_u want to run a primary name server for your domain (so that you don't have to communicate changes to the campus NIC and wait to have them install your data) you _m_u_s_t ask for and obtain a NNSS record from the campus NIC. A name server will never be queried unless it appears in the chain of responsibility. You _c_a_n run a primary name server. But, this comes with some responsiblities -- if you don't know how, or can't, run your DNS responsibly then we won't delegate. 3399 UUWWOO//DDNNSS For example, let's follow the chain of authority from the root down to the server for ccssdd..uuwwoo..ccaa: [[1111::5533aamm ssuunnccoonn]] nnssllooookkuupp >> sseett ttyyppee==nnss >> sseerrvveerr nnss..nniicc..ddddnn..mmiill >> ccaa.. ccaa nnaammeesseerrvveerr == rreellaayy..ccddnnnneett..ccaa ccaa nnaammeesseerrvveerr == nnnnsscc..nnssff..nneett eettcc.... >> sseerrvveerr rreellaayy..ccddnnnneett..ccaa.. >> uuwwoo..ccaa.. uuwwoo..ccaa nnaammeesseerrvveerr == jjuulliiaann..uuwwoo..ccaa uuwwoo..ccaa nnaammeesseerrvveerr == hhyyddrraa..uuwwoo..ccaa eettcc.... >> sseerrvveerr jjuulliiaann..uuwwoo..ccaa.. >> ccssdd..uuwwoo..ccaa.. ccssdd..uuwwoo..ccaa nnaammeesseerrvveerr == ssyybbiill..ccssdd..uuwwoo..ccaa ccssdd..uuwwoo..ccaa nnaammeesseerrvveerr == jjuulliiaann..uuwwoo..ccaa eettcc.... UUWWOO//DDNNSS 4400 22..33..66.. IINN AA An Address record, list the IP number for the domain. For example hhyyddrraa..uuwwoo..ccaa.. IINN AA 112299..110000..22..1133 A machine might have several IP numbers (if it has several network interfaces). rroommuulluuss..ccccss..uuwwoo..ccaa..IINN AA 112299..110000..11..11 IINN AA 112299..110000..22..11 IINN AA 112299..110000..33..11 IINN AA 112299..110000..88..11 IINN AA 112299..110000..3311..11 IINN AA 112299..110000..3322..11 eettcc.... IINN HHIINNFFOO CCIISSCCOO ""DDeecc//IIPP RRoouutteerr"" nnssllooookkuupp((88)) returns address records: [[1122::1133ppmm ssuunnccoonn]] nnssllooookkuupp rroommuulluuss NNaammee:: rroommuulluuss..ccccss..uuwwoo..ccaa AAddddrreesssseess:: 112299..110000..11..11,, 112299..110000..22..11,, 112299..110000..33..11,, 112299..110000..88..11,, 112299..110000..6655..11,, 112299..110000..6677..11,, eettcc.... 4411 UUWWOO//DDNNSS A machine (or IP address) might be known by several names. For example, pphhoonneebbooookk..uuwwoo..ccaa.. IINN AA 112299..110000..22..1133 hhyyddrraa..uuwwoo..ccaa.. IINN AA 112299..110000..22..1133 uuwwoovvaaxx..uuwwoo..ccaa.. IINN AA 112299..110000..22..1133 There's another way of pointing different names at the same IP address (using CCNNAAMMEE records). I've never found CCNNAAMMEE records to be too useful and have run into some problems. So I recommend this strategy for pointing several names at the same machine. We've tried a number of alternatives for making uwovax and hydra name the same machine. Currently we do it as above, in the past we've tried: uuwwoovvaaxx..uuwwoo..ccaa.. IINN CCNNAAMMEE hhyyddrraa..uuwwoo..ccaa.. and uuwwoovvaaxx..uuwwoo..ccaa.. IINN MMXX 00 hhyyddrraa..uuwwoo..ccaa.. Both have their place, but CCNNAAMMEE records sometimes cause problems. UUWWOO//DDNNSS 4422 22..33..77.. IINN WWKKSS Lists Well Known Services, ie. the TCP or UDP services <= 512 (see //eettcc//sseerrvviicceess), supported by the server. For exam- ple, jjuulliiaann..uuwwoo..ccaa.. IINN AA 112299..110000..22..1122.. IINN WWKKSS 112299..110000..22..1122 UUDDPP ((ddoommaaiinn ttffttpp)) IINN WWKKSS 112299..110000..22..1122 TTCCPP ((nnnnttpp ssmmttpp tteellnneett ddoommaaiinn ffiinnggeerr ffttpp)) The idea with WWKKSS records is that client applications (eg. ffttpp) should check first if the server actually supports the service (eg. supports the ffttpp WWKKSS). In _p_r_a_c_t_i_c_e this never happens. Maintaining these records is just documentation. Systems, which provide no services (ie. they're just con- sumers) should have list no WKS. A typical confusion: a PC might implement POP (Post Office Protocol) and SMTP (Simple Mail Transfer) client applica- tions but not the server applicaton. You only list the servers (ie. services offered). 4433 UUWWOO//DDNNSS 22..33..88.. IINN MMXX List a Mail exchanger. Mail for this domain should be sent where? jjuulliiaann..uuwwoo..ccaa.. IINN AA 112299..110000..22..1122 IINN WWKKSS 112299..110000..22..1122 UUDDPP ((ddoommaaiinn ttffttpp)) IINN WWKKSS 112299..110000..22..1122 TTCCPP ((nnnnttpp ssmmttpp tteellnneett ddoommaaiinn ffiinnggeerr ffttpp)) IINN MMXX 00 jjuulliiaann..uuwwoo..ccaa.. IINN MMXX 1100 hhyyddrraa..uuwwoo..ccaa.. Note that this makes it possible to list machines which don't have an IP address (eg. uuwwoocccc11..uuwwoo..ccaa uses hhyyddrraa as an MMXX gateway). The MX record lists a mail gateway. For exam- ple, uuwwoocccc11..uuwwoo..ccaa.. IINN MMXX 00 hhyyddrraa..uuwwoo..ccaa.. IINN MMXX 1100 jjuulliiaann..uuwwoo..ccaa.. We want all machines to have an MMXX record (perhaps pointing to vvooiidd..uuwwoo..ccaa) so mail doesn't sit in mail queues for days. If the machine can't accept mail it should bounce immedi- ately! The is no machine called vvooiidd..uuwwoo..ccaa so mail will bounce if the MX record points at this machine. UUWWOO//DDNNSS 4444 22..33..99.. IINN HHIINNFFOO Describes Host Information -- machine type and operating system (documentation only). jjuulliiaann..uuwwoo..ccaa.. IINN AA 112299..110000..22..1122 IINN WWKKSS 112299..110000..22..1122 UUDDPP ((ddoommaaiinn ttffttpp)) IINN WWKKSS 112299..110000..22..1122 TTCCPP ((nnnnttpp ssmmttpp tteellnneett ddoommaaiinn ffiinnggeerr ffttpp)) IINN MMXX 00 jjuulliiaann..uuwwoo..ccaa.. IINN MMXX 1100 hhyyddrraa..uuwwoo..ccaa.. IINN HHIINNFFOO ""CCDDCC 44668800"" ""EEPP//IIXX"" The HHIINNFFOO record has two arguments -- machine type and oper- ating system. Use quotes if there's white space in either argument. 4455 UUWWOO//DDNNSS 22..33..1100.. IINN UUIINNFFOO Describes User Information (eg. who is the contact for this system). This is documentation only. ccccss..uuwwoo..ccaa.. IINN SSOOAA ....eettcc.. IINN UUIINNFFOO ""CCoommppuuttiinngg && CCoommmmuunniiccaattiioonnss SSeerrvviicceess"" IINN UUIINNFFOO ""NNaattuurraall SScciieenncceess CCeennttrree"" IINN UUIINNFFOO ""CCoonnttaacctt:: PPeetteerr MMaarrsshhaallll <> sseett ttyyppee==nnss >> 110000..112299..iinn--aaddddrr..aarrppaa.. SSeerrvveerr:: nnss..nniicc..ddddnn..mmiill AAddddrreessss:: 119922..6677..6677..5533 110000..112299..iinn--aaddddrr..aarrppaa nnaammeesseerrvveerr == jjuulliiaann..uuwwoo..ccaa 110000..112299..iinn--aaddddrr..aarrppaa nnaammeesseerrvveerr == hhyyddrraa..uuwwoo..ccaa 110000..112299..iinn--aaddddrr..aarrppaa nnaammeesseerrvveerr == rrrrii..uuwwoo..ccaa The in-addr.arpa domain consists of IP numbers written in a reverse notation (domain heirarchies work right to left, IP heirarchies work the other way). UUWWOO//DDNNSS 4488 For example, gp.uwo.ca is a subdomain of uwo.ca while [129.100.10.0] is a subnet of [129.100.0.0]. So the trick is to write network numbers backwards. Records in the file in-addr.arpa on julian look like: 1111..3344..110000..112299..iinn--aaddddrr..aarrppaa.. IINN PPTTRR \\ wwkkssttnn1111..sslliiss..uuwwoo..ccaa.. 1111..3366..110000..112299..iinn--aaddddrr..aarrppaa.. IINN PPTTRR \\ ttyyrrffiinnggrr..aassttrroo..uuwwoo..ccaa.. 1111..3377..110000..112299..iinn--aaddddrr..aarrppaa.. IINN PPTTRR \\ sseeiissppcc11..ggpp..uuwwoo..ccaa.. 1111..3388..110000..112299..iinn--aaddddrr..aarrppaa.. IINN PPTTRR \\ vvaaxxii..ssssccll..uuwwoo..ccaa.. ...etc 4499 UUWWOO//DDNNSS At UWO people who administer DNS data for their site include the iinn--aaddddrr..aarrppaa.. map as a speciallly formatted ccoommmmeenntt in the primary data files for their domain. Those comments are pulled out and used to construct the primary data file for 110000..112299..iinn--aaddddrr..aarrppaa. [[33::1122ppmm jjuulliiaann]] ppaaggee ddaattaa//ccccss..ddoommaaiinn ;; AAuutthhoorriittaattiivvee ddaattaa ffoorr CCoommppuuttiinngg aanndd CCoommmmuunnii.... ;; tthhee UUnniivveerrssiittyy ooff WWeesstteerrnn OOnnttaarriioo ((ccccss..uuwwoo..ccaa)) ;; ...... ;;11..11..110000..112299..iinn--aaddddrr..aarrppaa.. IINN PPTTRR rroommuulluuss..ccccss..uuwwoo..ccaa.. ;;11..6655..110000..112299..iinn--aaddddrr..aarrppaa.. IINN PPTTRR rroommuulluuss..ccccss..uuwwoo..ccaa.. ...etc [[33::1122ppmm jjuulliiaann]] ppaaggee iinn--aaddddrr..aarrppaa ;; AAuutthhoorriittaattiivvee ddaattaa ffoorr tthhee UUnniivveerrssiittyy ooff WWeesstt.... ;; ........ ;; TThhee ffoolllloowwiinngg ffrroomm ooffffiicciiaall ddaattaa pprroovviiddeedd ttoo .... ;; ######## WWeedd NNoovv 1111 1177::0088::0099 EESSTT 11999922 ######## 11..11..110000..112299..iinn--aaddddrr..aarrppaa.. IINN PPTTRR rroommuulluuss..ccccss..uuwwoo..ccaa.. 11..6655..110000..112299..iinn--aaddddrr..aarrppaa.. IINN PPTTRR rroommuulluuss..ccccss..uuwwoo..ccaa.. ...etc The management of the many DNS data files and construction of derivative data (like //eettcc//hhoossttss, iinn--aaddddrr..aarrppaa maps, mailing lists, etc.) is largely automated by a MMaakkeeffiillee. UUWWOO//DDNNSS 5500 We also use PPTTRR records to document ether net addresses and to document novell server numbers: [[1100::4433aamm jjuulliiaann]] ppaaggee nnaammeedd..bboooott ;; ...... ;; MMiisscceellllaanneeoouuss aanndd nnoonn--ssttaannddaarrdd mmaappss ;; pprriimmaarryy iinn--eetthheerr..aarrppaa.. iinn--eetthheerr..aarrppaa pprriimmaarryy iinn--nnoovveellll..aarrppaa.. iinn--nnoovveellll..aarrppaa These maps, like the in-addr.arpa map, are maintained as commentary text in the SOA data managed by the technical contact: [[1100::4444aamm jjuulliiaann]] ppaaggee ddaattaa//ccccss..ddoommaaiinn ;; AAuutthhoorriittaattiivvee ddaattaa ffoorr CCoommppuuttiinngg aanndd CCoommmmuunnii.... ;; tthhee UUnniivveerrssiittyy ooff WWeesstteerrnn OOnnttaarriioo ((ccccss..uuwwoo..ccaa)) ;; ...... ;;8811664400113333..iinn--nnoovveellll..aarrppaa.. IINN PPTTRR ddttpp..ccccss..uuwwoo..ccaa.. ;;0022660088CC997777778866..iinn--eetthheerr..aarrppaa.. IINN PPTTRR ddttpp..ccccss..uuwwoo..ccaa.. ;;3333..6677..110000..112299..iinn--aaddddrr..aarrppaa.. IINN PPTTRR ddttpp..ccccss..uuwwoo..ccaa.. These extra (and non standard) maps make it possible for Network Operations to chase back by Novell Network and/or Ethernet numbers. 5511 UUWWOO//DDNNSS 22..33..1122.. IINN MMiisscceellllaanneeoouuss RReeccoorrddss There are many more internet records (1) MMBB a mailbox domain name (domain) (2) MMGG a mail group member (domain) (3) MMRR a mail rename domain name (domain) (4) NNUULLLL a null resource record (no format or data) (5) MMIINNFFOO mailbox or mail list information (request_domain error_domain) I've not had an occasion to use any of these and I believe most implementations don't handle them. They seem to be for managing mailing lists but I'm not aware of any mailer (eg. sseennddmmaaiill) that uses them. UUWWOO//DDNNSS 5522 33.. PPuuttttiinngg iitt aallll ttooggeetthheerr The _f_i_r_s_t step is to register a Domain Name and Network Num- ber with the campus NIC (by mail to NIC@UWO.CA). Important registration documents (available from the NIC or by anonymous ftp from jjuulliiaann::~~ffttpp//nniicc): REGISTRATION.README Introduction to Registration Document (UWO) REGISTRATION.DOMAIN Domain Registration Document (UWO) REGISTRATION.NETWORK Network Registration Document (UWO) These _c_o_n_t_r_a_c_t_s delegate responsiblity for managing a domain or network to the Administrative and Technical Contacts listed. 5533 UUWWOO//DDNNSS 33..11.. RReessppoonnssiibbiilliittyy In each case the registration documents rreeqquuiirree that the Technical Contact provide the NIC with DNS data. For exam- ple, from the Domain Registration contract: It is the responsiblity of the Technical Contact to provide the NIC with the data required of the Domain Name Service for this domain. Information must be accu- rate and up to date. Adding new machines to the net- work without informing the NIC is forbidden. From the Network Registration contract: It is the responsiblity of the Technical Contact to provide the NIC with the data required of the Domain Name Service for this network. Information must be accurate and up to date. Adding new machines to the network without informing the NIC is forbidden. These are important obligations that mmuusstt be met. UUWWOO//DDNNSS 5544 33..22.. PPrroovviiddee IInnffoorrmmaattiioonn From reggers Mon Nov 26 12:27:05 1990 To: psyhma@uwocc1.uwo.ca Subject: Psych network/domain Cc: les@vaxr.sscl.uwo.ca Heather, thanks for filling out those registration docu- ments. You've been assigned the IPnet 129.100.47.0. I'll return copies of those documents under separate cover. Please keep copies on file at your site. One of your responsiblities is to provide me (the NIC) with an accurate and up to date list of machines on your network. This is required information for the Domain Name Service and is an ongoing job -- you have to keep the NIC informed of changes to your network (eg. when machines come or go). You should start on this right away (ps. there's a course on this very topic on Thurs 29th 1:30-3:30 in Kresege bldg room 7 you might want to attend). Here's what I need for each machine on your network. (1) Name, eg. bert.psych.uwo.ca (you can pick any names you like so long as they end in psych.uwo.ca). You likely want to name your vax "psych.uwo.ca" and use it as your mail-drop for your PCSA clients. (2) IP number, eg. [129.100.47.10] (your network regis- tration document details the numbers you can use and briefly describes configuring your systems. You can use numbers 10-254 on net 47). (3) Machine type and operating System, eg. IBM PS/2 run- ning MS/DOS (4) Machine location, eg. Room 7002 SSC (5) Contact point (ie. who is running this system and how do I find them?) eg. Heather Acton ; xt. 4729 If you can provide me with this information for all the machines on your network then I'll construct the data file required for the Domain Name Service and I'll then turn the file over to you to maintain. 5555 UUWWOO//DDNNSS For more information about the net (eg. what are good names to use?) you should look at the anonymous ftp area on our Unix system jjuulliiaann::~~ffttpp//nniicc. There's a ton of good reading material there and I'd encourage you to look at them (eg. there's good Intro to IP, Intro to Sysadmin, and other documents). Finally, I gather Les has volunteered to help you install multinet on your vax/vms system. If you need any help from us, please let us know. For information about NCSA/Telnet and other IP tools for your PCs you should talk with Eva Placko ; xt. 6027 At any time, if you need network help send a note to UUWWOO//DDNNSS 5566 33..33.. YYoouurr DDNNSS ddaattaa From the information provided the NIC will construct the DNS data file for your site: ;; AAuutthhoorriittaattiivvee ddaattaa ffoorr NNAAMMEE DDAAEEMMOONN MMaappppiinnggss ;; ;; aaddmmiinniisstteerreedd bbyy:: ;; JJoohhnn BBrruunneett <>;; xxtt 33114444 ;; aanndd ccoommmmuunniiccaatteedd ttoo:: ;; NNeettwwoorrkk IInnffoorrmmaattiioonn CCeennttrree <>;; xxtt 22115511 ;; $$OORRIIGGIINN ggpp..uuwwoo..ccaa.. ;; SSOOAA mmeeaannss SSttaarrtt ooff AAuutthhoorriittyy,, wwhhoo''ss iinn cchhaarrggee?? @@ IINN SSOOAA jjuulliiaann..uuwwoo..ccaa.. jjoohhnn..sseeiiss..ggpp..uuwwoo..ccaa.. (( 11..000088 ;; SSeerriiaall EEDDIITT MMEE TTOOOO!!!! 33660000 ;; RReeffrreesshh 330000 ;; RReettrryy 33660000000000 ;; EExxppiirree 33660000 )) ;; MMiinniimmuumm IINN NNSS jjuulliiaann..uuwwoo..ccaa.. ;; pprriimmaarryy IINN NNSS hhyyddrraa..uuwwoo..ccaa.. ;; sseeccoonnddaarryy IINN NNSS rrrrii..uuwwoo..ccaa.. ;; sseeccoonnddaarryy ;; IINN NNSS ssoommee--oonnee..ggpp..uuwwoo..ccaa.. 5577 UUWWOO//DDNNSS ;; TThhiiss **mmaayy** bbeeccoommee aauutthhoorriittaattiivvee ddaattaa mmaannaaggeedd ;; llooccaallllyy wwiitthhiinn GGeeoopphhyyssiiccss ffoorr tthhee mmoommeenntt iitt iiss ;; eeddiitttteedd llooccaallllyy aanndd ccoommmmuunniiccaatteedd ttoo tthhee NNIICC wwhheenn ;; aanndd aass tthhee eennvviirroonnmmeenntt cchhaannggeess.. ;; ;; RREEAADDMMEE..NNOOWW:: ;; ;; EEvveerryytthhiinngg oonn tthhee IIPPnneett sshhoouulldd bbee rreeggiisstteerreedd iinn aa ;; ddoommaaiinn sseerrvveerr.. TThhiiss eevveenn iinncclluuddeess dduummbb cclluunnkkyy ;; tthhiinnggss lliikkee rroouutteerrss,, tteerrmmiinnaall sseerrvveerrss,, aanndd cclliieenntt ;; oonnllyy PPCC''ss.. iitt''ss iimmppoorrttaanntt tthhaatt yyoouu hhaavvee yyoouurr ;; mmaacchhiinneess rreeggiisstteerreedd bbeeccaauussee wwhheenn wwee sseeee pprroobblleemmss ;; wwiitthh tthhee nneett wwee nneeeedd ttoo cchhaassee iitt bbaacckk ttoo aa ;; bbuuiillddiinngg,, rroooomm,, mmaacchhiinnee,, pphhoonnee nnoo.. aanndd ;; rreessppoonnssiibbllee ppeerrssoonn.. AAddddiinngg nneeww ssyysstteemmss ttoo tthhee nneett,, ;; eevveenn iiff tthheeyy ddoonn''tt sseenndd//rreecceeiivvee mmaaiill,, wwiitthhoouutt ;; hhaavviinngg tthheemm pprrooppeerrllyy rreeggiisstteerreedd iiss ccoonnssiiddeerr VVEERRYY ;; BBAADD FFOORRMM.. EEvveerryy mmaacchhiinnee sshhoouulldd hhaavvee aann MMXX ;; ffoorrwwaarrddeerr eevveenn iiff iitt iissnn''tt aa vvaalliidd mmaaiill aaddddrreessss ;; ((tthhee MMXX ffoorrwwaarrddeerr iinn tthhaatt ccaassee wwiillll ssiimmppllyy rreeffuussee ;; tthhee mmaaiill)).. ;; ......eettcc.... ;;1100..3377..110000..112299..iinn--aaddddrr..aarrppaa.. IINN PPTTRR sseeiiss..ggpp..uuwwoo..ccaa.. sseeiiss..ggpp..uuwwoo..ccaa.. IINN AA 112299..110000..3377..1100 IINN WWKKSS 112299..110000..3377..1100 TTCCPP tteellnneett ffttpp IINN MMXX 00 sseeiiss..ggpp..uuwwoo..ccaa.. IINN MMXX 1100 jjuulliiaann..uuwwoo..ccaa.. IINN HHIINNFFOO SSuunn44//8800 ""UUNNIIXX ((SSuunnOOSS 44..00))"" UUWWOO//DDNNSS 5588 33..44.. CCoonnffiigguurree RReessoollvveerr Configure your site to _u_s_e the resolver routines. Recall that for Unix machines you need to construct the file //eettcc//rreessoollvv..ccoonnff; for Vax/VMS you set the logicals when you install Multinet. For Sun machines integrating YP (or NIS these days) with the DNS will work. Two strategies: (1) Don't use the hosts map in YP, use the DNS. Instruc- tions for doing this are found as jjuulliiaann::~~ffttpp//ppuubb//rreessoollvveerr. (2) Use the DNS as a back end to YP, follow the Sun instructions in the YP Makefile. [[11::4499ppmm ssuunnccoonn]] ppaaggee //eettcc//rreessoollvv..ccoonnff nnaammeesseerrvveerr 112299..110000..22..1122 nnaammeesseerrvveerr 112299..110000..77..110000 nnaammeesseerrvveerr 112299..110000..22..1133 ddoommaaiinn ccccss..uuwwoo..ccaa [[11::5511ppmm ssuunnccoonn]] ffttpp nniicc..ddddnn..mmiill CCoonnnneecctteedd ttoo nniicc..ddddnn..mmiill.. eettcc...... 5599 UUWWOO//DDNNSS 33..55.. SSeeccoonnddaarryy SSeerrvveerr For those who wish to run a secondary name server (and I recommend that large sites do) there is a kit provided. [[1111::4488aamm sshhaaddooww]] ffttpp jjuulliiaann CCoonnnneecctteedd ttoo jjuulliiaann..uuwwoo..ccaa.. 222200 jjuulliiaann..uuwwoo..ccaa FFTTPP sseerrvveerr ((ffrroomm 44..33BBSSDD TTaahhooee)) NNaammee ((jjuulliiaann::rreeggggeerrss)):: aannoonnyymmoouuss 333311 GGuueesstt llooggiinn ookk,, sseenndd iiddeenntt aass ppaasssswwoorrdd.. PPaasssswwoorrdd:: 223300 GGuueesstt llooggiinn ookk,, aacccceessss rreessttrriiccttiioonnss aappppllyy.. ffttpp>> ccdd nniicc//nnaammee..sseeccoonnddaarryy 225500 CCWWDD ccoommmmaanndd ssuucccceessssffuull.. ffttpp>> mmggeett ** .... ffttpp>> qquuiitt [[1111::4488aamm sshhaaddooww]] ppaaggee RREEAADDMMEE Following the instructions should be a painless exercise, others have done it: [[11::5533ppmm cchhaarrlliiee]] ppaaggee //eettcc//rreessoollvv..ccoonnff nnaammeesseerrvveerr 112299..110000..1111..55 nnaammeesseerrvveerr 112299..110000..1111..225511 nnaammeesseerrvveerr 112299..110000..22..1122 nnaammeesseerrvveerr 112299..110000..77..110000 ddoommaaiinn ccssdd..uuwwoo..ccaa UUWWOO//DDNNSS 6600 33..66.. PPrriimmaarryy SSeerrvveerr For those who wish to run a primary name server (and I rec- ommend this for some of the larger sites). (1) Demonstrate that you can keep your DNS data up to date. (2) Demonstrate that you can run a Secondary Server. (3) Coordinate with the NIC to set up a Primary Server. An example for running a Primary Name Server is found as jjuulliiaann::~~ffttpp//nniicc//nnaammeedd (configuration for mmccuu..oonn..ccaa). 6611 UUWWOO//DDNNSS 44.. HHEELLPP!! The campus NIC is there to help and will help. CCS will pro- vide a liaison to those who need one. The NIC at CCS/UWO has the experience. Trust their judge- ment. The campus NIC has accumulated lots of good reading material -- but you have to read it. Start by getting the README file from jjuulliiaann::~~ffttpp//nniicc You have to take on some responbility. Departmental Networks are not managed by the NIC at CCS, they're managed by Admin- istrative and Technical contacts within the department. The Internet will work if everyone does their job, please make sure you do yours. UUWWOO//DDNNSS 6622