- dns-wg - mailman.ripe.net

DNS recommendations - the paper
by Elmar K. Bins 25 Nov '98

25 Nov '98

Content-Description: DNS recommendations RIPE DNS-WG paper DNS recommendations Originally by: Hans Niklasson <hasse(a)swip.net> Amar Andersson <amar(a)telia.net> Reworked by: Elmar K. Bins <ekb(a)ivm.net> (use the dns-wg(a)ripe.net list for discussion :-) ) Remark to dns-wg: Although (or maybe because of) being new to RIPE as an active person, I was very unsatisfied with the status of this paper after having attended Hans' presentation and thought that given experience with DNS getting the paper ready would not take one too long. Rationale: So what this paper should deliver is a structured guide to what a DNS administrator should regard when setting up her zones. Many of us know their parameters by heart whereelse others are new to the business and still have to look up parts of it. Not to mention copying broken zones as I did for a long time (and it was a pain to fix all of them). Scope: This documents act as a recommendation for configuring your DNS. This is NOT a requirement, only a recommendation of things to think about when setting up your DNS. Purpose: To decrease lame delegations and limit unecessary traffic due to resolving problems, among other things. Records: ----------------------------------------------------------------------------- ================================= SOA Start of Authority Record ================================= Synopsis @ IN SOA <originating dns server> <dottified admin email>\ ( <serial number> <refresh> <retry> <expire> <minimum TTL> ) Example @ IN SOA ns.isp.net. netmaster.isp.net. ( 1998100100 86400 3600 604800 345600 ) Semantics The SOA record gives the originating host's name, the email address of the person responsible for the zone, timeout values to be used by secondaries and the TTL preset/default. There is only one SOA record per zone. originating dns server: Canonical hostname of the DNS server authoritatively carrying this zone. In case of hidden primary setup, put the exposed primary. Don't forget to close with a dot. dottified admin email: The administrator's email address in a form where the "@" has been replaced by a dot. To regain the address, replace the first dot by an at sign. serial number: Changed zones are only reloaded if a higher serial number than the already known one is encountered, so be sure to increase this number with every change you want to be seen. refresh: Secondaries check every <refresh> seconds, whether the SOA on the primary has changed. If yes, a zone transfer is done. retry: A secondary having been unable to do a zone transfer because of unreachable of the primary retries every <retry> seconds. expire: The zone's information is considered invalid by the secondary if the primary could not be reached for <expire> seconds. minimum TTL: This is the default value for all records in the zone file which can be overriden by values for the individual records. After <minimum TTL> seconds, the zone information on the caching nameserver becomes invalid and has to be re-fetched from an authoritative server. NOTE: This field was intended to be a minimum value for all records in the zone but is now widely implemented as giving the default. Recommendations and remarks originating dns server: As stated above, insert the name of the originating server that is reachable from the Internet. dottified admin email: The email address here cannot contain dots left of the "@" sign, since it's always the _first_ dot that's being replaced. Remember: This email address must be valid. So it seems to be good practice to use a role account address instead of a personal address - just in case your admin leaves your company. serial number: There's a widely agreed upon form of the serial number that is both easily readable and less errorprone which reads YYYYMMDDnn with YYYY being the 4-digit year (year 2000 is near), MM the 2-digit month, DD the day (again 2 digits) and nn the number of the latest update of the zone on the same day. All of those fields lest the year are left-padded with zeroes. refresh: This timeout determines the "currentness" of the secondaries' information about a zone. Set it to a lower value if changes to the zone are expected in the near future, so your secondary servers stay up to date. 86400 (24 hours) seems a reasonable value to start with. NOTE: If you are running bind 8.x, you may keep this value pretty high and have your DNS server send notification signals to your secondaries. [jh] retry: The retry timeout should be fairly low to have the secondary regain authoritativeness as soon as possible after the primary has become available again. Of course, setting this too low will only mean wasting bandwidth. 3600 (1 hour) seems a reasonable value although most of us are using longer retry timeouts. expire: Old data is, speaking of customers, almost always better than no data at all, so keep this value high enough to be able to buy and install a machine within expiry time if your primary dies. 604800 (7 days) is the value used here. [ekb] minimum TTL: Like with the refresh value, if a quick change to the zone is expected in the near future, temporarily lower the minimum TTL. Don't forget to increase it to a reasonable value after the change is done, because this value is probably the most common source of bandwidth waste in the whole Internet ;-) 345600 (4 days) may already be too short for a stable zone. =========================== NS Name Server Records =========================== Synopsis [<zone>] [<TTL>] IN NS <authoritative server> Examples IN NS ns.isp.net. ; NS for all of the zone's domain bla IN NS ns.cust.com. ; subdelegation for bla.<zone> Semantics As you might have guessed already, this record denotes the supposed-to-be authoritative DNS servers for the current zone (or the zone given). authoritative server: The <authoritative server> given must be the FQDN for the nameserver machine. Check its correctness in advance and don't forget the trailing dot. Recommendations and remarks Have the zone's NS records, the registry's and RIPE's nameserver information consistent, and do not give nameservers with whose administrators you have not coordinated in advance. Remember that most registries require you to have at least two authoritative servers reachable via different routes. ============================== MX Mail Exchanger Records ============================== Synopsis [<host/subdom name>] [<TTL>] IN MX <preference> <mailhost> Examples IN MX 100 relay.isp.net. ; fallback MX for domain <zone> IN MX 10 mail.cust.com. ; final MX bla IN MX 100 relay.isp.net. ; fallback MX for bla.<zone> IN MX 10 blamail ; blamail.<zone> needs an A record Semantics MX records tell a foreign mail server where to deliver mail to addresses in our domain. preference: This field is the numerical preference for mail delivery to the machine mentioned. Lower values are tried first. mailhost: Mentions the name of a machine that accepts mail for our domain. Recommendations and remarks FQDNs are preferred, local (to <zone>) hosts are can be used as well. Verify that A records exist for the MX hosts and don't forget the trailing dot on FQDNs. Have at least two MX records to ensure delivery. It is not a good idea to have MX records point to CNAME'd hosts. This will almost certainly get you into a lot of trouble. Use hosts with proper A records instead. ======================= A Address Records ======================= Synopsis [<hostname>] [<TTL>] IN A <IPV4 address> [<IPV4 address> ...] Examples mail IN A 123.45.67.8 ; our mail host www IN A 123.45.67.10 123.45.67.11 ; multiple hardware IN A 123.45.67.9 ; <zone> as a hostname ;-) Semantics A records contain the data that performs name-to-number translation. Recommendations and remarks Do not use FQDNs in the <host> part. Hosts in subdomains à la "www.internal", which resolve to "www.internal.<zone>" are okay though. Remember that IP addresses do not end in a dot. Do not forget to maintain reverse delegation as well. ============================== CNAME Canonical Name Records ============================== Synopsis <alias> [<TTL>] IN CNAME <hostname> Example news IN CNAME news.isp.net. Semantics CNAME records provide a means to give aliases to machines. This can be used to have entries in one zone have the same data as hosts in a completely different zone. If a hosts IP address changes in the other domain there is no maintenance necessary on our side to change the hosts IP address Recommendations and remarks CNAME records are not being cached by name servers and thus should be used as rarely as possible to avoid unnecessary network traffic. It is not a good idea to have MX records point to CNAME'd hosts. ======================= PTR Reverse Records ======================= Synopsis <ip-fragment> [<TTL>] IN PTR <hostname> [<hostname> ...] Examples 123.45.67.8 IN PTR mail.cust.com. 10 IN PTR www.cust.com. Semantics PTR records provide the reversed functionality of A records, resolving IP addresses to hostnames. Recommendations and remarks Make sure that your PTR and A records match. Having a customer use machines without PTR records will resume in unresponsive FTP servers, which often do reverse lookups for security purposes. ========================= HINFO Host Info Records ========================= Synopsis <host> [<TTL>] IN HINFO <CPU> <OS> Examples play IN HINFO i586 Linux-2.1.107 Semantics HINFO records contain information about the CPU type and the operating system running on a host. Recommendations and remarks Giving away information about CPU and operating system may open security holes. There seem to be a few reasons to be this open to the Internet community, some of which can be found in RfC 1035. I would strongly recommend not using HINFO records for security reasons. The Internet is no more the safe haven it has been. The values here were once required to be standardized CPU and OS names (see RfC 1010 and descendants), but are more or less free strings nowadays. ============================================== WKS Well Known Service Description Records ============================================== Synopsis <host> [<TTL>] IN WKS <address> <protocol> <service> [<service>...] Examples mail IN WKS 123.45.67.8 UDP domain IN WKS 123.45.67.8 TCP smtp domain Semantics The Well Known Services record describes the record provided by a particular protocol on a particular interface. The protocol is usually UDP or TCP, although it can be any of the protocols in /etc/protocols. The services can be any of the /etc/services services that use a port below 256. Recommendations and remarks The WKS record is seldom used. ==================== TXT Text Records ==================== Synopsis <host> [<TTL>] IN TXT <text> Examples news IN TXT Yesterday's news are today's olds. Semantics The values found in TXT records are entirely up to free interpretation. ----------------------------------------------------------------------------- General recommendations, remarks and tips ----------------------------------------------------------------------------- Glue records "Glue records" is a term that describes entering A records into a zone for machines whose hostnames do not lie within <zone>. With these glue records one tries to achieve resolution for foreign machines that are being used e.g. as name servers or mail exchangers. Glue records should almost never be necessary, provided the ISP has set up their nameservers properly. If this is not the case, why would you trust them to have their mail relays functioning? If you use glue records, don´t add unnecessary ones. This can cause resolving problems if the host changes IP address. Trailing dots: Don´t forget to add a dot (".") to the end of the domain/hostname. If this is forgotten, this will have the DNS add <zone> to the domain/hostname again. This will cause resolving problems. Something like IN MX 10 mail.cust.com Will lead to IN MX 10 mail.cust.com.cust.com. when fully resolved. Legal characters: Only A-Z/a-z (case does not matter), 0-9 and - are recommended. In fact, the full range of 8 bit characters is allowed everywhere but in hostnames. Yet to be on the secure side, do not use more than the range mentioned above. Some services may be more restricted than DNS. General Points: Always use the latest version of the DNS software for your platform. If you use bind, you should consider changing to the 8.x versions. 4.x is expected to be obsoleted soon. Check for updates regulary, as new versions provide current security and bug fixes. Additional reading and references: RFC1034 ( Domain Names - Concepts and Facilities ) RFC1035 ( Domain Names - Implementation and Specification ) RFC1537 ( RFC1912 ) ( Common DNS Operational and Configuration Errors ) "DNS & BIND 2nd Edition" by Paul Albitz & Cricket Liu from O´Reilly & Associates Inc. ftp://ftp.ripe.net/internet-drafts/draft-ietf-dnsind-classless- inaddr-04.txt ( For reverse delegation methods for blocks smaller than /24, 256 addresses ) http://www.dns.net/dnsrd/ ( DNS Resources Directory ) === fin === Regards, Elmi. -- | \ / |\/| Gesellschaft fuer Internet, Vernetzung und Mehrwertdienste mbH | \/ | | Zissener Str. 8 - D-53498 Waldorf - +49 2636 9769-0 - Fax -999 The Net People. Elmar K. Bins (ekb(a)ivm.net) http://www.ivm.net/

6 21

Re: DNS recommendations - the paper
by Berislav Todorovic 25 Nov '98

25 Nov '98

>> How far should this paper go into detail? I think it should contain only necessary summary info, with links to RFC's and other documents useful for DNS setup, where necessary. Some additional hints and corrections, I found while reading your document: * In the "Scope:" section add: "This document doesn't replace any DNS related RFC or any other good book dealing with DNS. It is a simple collection of hints for DNS administrators". * In the SOA section: parentheses are placed wrongly - instead of: >> @ IN SOA ns.isp.net. hostmaster.isp.net. >> ( 1998100100 86400 3600 604800 345600 ) you should write (both in the syntax block and the example): >> @ IN SOA ns.isp.net. hostmaster.isp.net. ( >> 1998100100 86400 3600 604800 345600 ) EXPLANATION: parentheses are not a mandatory part of a SOA record - they only serve to tell the DNS that rdata is split over multiple lines. In other words, you can use them in other records too, e.g. www IN CNAME ( server.domain.com. ) ; --- Of course, noone uses this as well as you can write the SOA record in one line: @ IN SOA ns.isp.net. hostmaster.isp.net. 1998100100 86400 3600 604800 345600 * Regarding "minimum TTL" - higher values make problems with zones that change more oftenly, while lower make a lot of unecessary traffic. I think the following text should be added to the section on "minimum TTL": "Minimum TTL should closely correspond to the average time interval between two successive zone contents changes, but not greater than 345600 (4 days). For example, if the zone is changed almost once or twice a day, 86400 (1 day) is a reasonable value. If, however, the zone is changed not more than once a week, there is no need to have such a small value of minimum TTL". * In the NS record section - the phrase: "There should be at least two of them for every zone," should be updated by: "There need not to be more than six servers for a zone". * In the MX section, add the following after " ... a lot of trouble.": "Furthermore, it is forbidden by the current RFC documents". * In the CNAME section add: "Avoid pointing CNAMEs to other CNAMEs". * The PTR section contains a possible mistake - are you sure you can write: >> 123.45.67.8 IN PTR mail.cust.com. Wouldn't say so - I think you'll get: 123.45.67.8.67.45.123.in-addr.arpa. IN PTR mail.cust.com. EXPLANATION: like all other records, PTR's have record name as the first parameter in the record. The server will automatically concatenate the reverse domain name if it doesn't find a trailing dot. Therefore, I would rewrite the whole section in the following manner: Synopsis <ip-fragment> [<TTL>] IN PTR <hostname> [<hostname> ...] Examples 8.67.45.123.in-addr.arpa. IN PTR mail.cust.com. Semantics PTR records provide the reversed functionality of A records, resolving IP addresses to hostnames. <ip-fragment> is the reverse written IP address of the host, appended to "in-addr.arpa'. Recommendations and remarks: Don't write whole names of PTR's (8.67.45.123.in-addr.arpa). If your inverse domain name is 67.45.123.in-addr.arpa, then use: 8 IN PTR mail.cust.com. (copy other recommendations). Add the following: "If you're assigned a network less than /24 (former "C class"), read RFC 2317 and consult your ISP before you set up your reverse zone". * In the "Legal Characters" section add the following: "Comments in the zone file are provided starting with a semicolon ';'. DON'T USE comment delimiters used in programming languages or operating system scripts (some exapmles of WRONG comment delimiters: #, !, C, /* */, //, { } ...). NOTE: this states for the ZONE FILES only! Comment delimiters in the boot file may differ (e.g. ';' is used in bind 4 named.boot file, while "//" is used in bind 8 named.conf file for comments; zone files, however, use ';' in both cases!). Some hints for future document extensions: * Forwarders - pro et contra. * Security - xfer access lists - what to do and what not to do. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI(a)etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3370-106 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' --------------------------------------------------------------------

4 3

Re: DNS recommendations - the paper
by Elmar K. Bins 25 Nov '98

25 Nov '98

BERI(a)etf.bg.ac.yu (Berislav Todorovic) wrote: > * In the "Scope:" section add: "This document doesn't replace any DNS > related RFC or any other good book dealing with DNS. It is a simple > collection of hints for DNS administrators". agreed. > * In the SOA section: parentheses are placed wrongly - instead of: True. Corrected. > EXPLANATION: parentheses are not a mandatory part of a SOA record - they > only serve to tell the DNS that rdata is split over multiple lines. In > other words, you can use them in other records too, e.g. I've added the explanation as well. > "Minimum TTL should closely correspond to the average time interval > between two successive zone contents changes, but not greater than > 345600 (4 days). For example, if the zone is changed almost once or > twice a day, 86400 (1 day) is a reasonable value. If, however, the > zone is changed not more than once a week, there is no need to have > such a small value of minimum TTL". I like this explanation, so I added it. > * In the NS record section - the phrase: "There should be at least two > of them for every zone," should be updated by: "There need not to be > more than six servers for a zone". I cannot second that. People tend more to have fewer NS servers than they are about to add more than six. Maybe both statements should be included here. I see no danger from more than six servers but I do see trouble brewing if you only have one (which, btw, no NIC will accept). I've added the part about "more than six". > * In the MX section, add the following after " ... a lot of trouble.": > "Furthermore, it is forbidden by the current RFC documents". > > * In the CNAME section add: "Avoid pointing CNAMEs to other CNAMEs". Added them and removed the part about "trouble" in the MX section. > * The PTR section contains a possible mistake - are you sure you can write: > > >> 123.45.67.8 IN PTR mail.cust.com. > > Wouldn't say so - I think you'll get: > > 123.45.67.8.67.45.123.in-addr.arpa. IN PTR mail.cust.com. > > EXPLANATION: like all other records, PTR's have record name as the first > parameter in the record. The server will automatically concatenate the > reverse domain name if it doesn't find a trailing dot. Yes, I think this is true. Problem is, this is not a real-life example. My zones only contain something like " 8 IN PTR mail.cust.com." since they are loaded as zones for (e.g.) 67.45.123.in-addr.arpa. Maybe we should really complete the example as shown above (thanks, that was not my own example, so I overlooked it). > "If you're assigned a network less than /24 (former "C class"), > read RFC 2317 and consult your ISP before you set up your reverse > zone". Ah, you're addressing the drive-my-own-server customer here. Ok :-) But I guess we need not go into the details of classless reverse delegation... > * In the "Legal Characters" section add the following: "Comments in the zone added (more briefly though) > Some hints for future document extensions: > > * Forwarders - pro et contra. > * Security - xfer access lists - what to do and what not to do. This concerns bind operation, not zones ;-) If somebody wants to set up recommendations for this I'd be happy to read... Regards, Elmi. -- | \ / |\/| Gesellschaft fuer Internet, Vernetzung und Mehrwertdienste mbH | \/ | | Zissener Str. 8 - D-53498 Waldorf - +49 2636 9769-0 - Fax -999 The Net People. Elmar K. Bins (ekb(a)ivm.net) http://www.ivm.net/

1 0

remove
by Didier Windmeulen 24 Nov '98

24 Nov '98

----- Original Message ----- From: Niels Bakker <niels(a)euro.net> To: <dns-wg(a)ripe.net> Sent: mercredi 25 novembre 1998 0:01 Subject: Re: DNS recommendations - the paper >Quoth Randy Bush: > >>> @ IN SOA ns.isp.net. netmaster.isp.net. >>> ( 1998100100 86400 3600 604800 345600 ) >> s/netmaster/hostmaster/ see RFC 2142 >> >> or, i think it was piet who recommended being conservative, and do not >> relying on aliases, rather use a real mailbox name. > >So that person can safely go on a two-week holiday? > >I'd rather put in a real hostname and not rely on MX records, including >possible breakage. If you're real paranoid, register your domain also as >a host with InterNIC (sort of 'ibm.com'), make its address the address of >your primary mail exchanger; even if InterNIC has a minor screw-up - like >"forgetting" your NS records - there's a chance your A record survives. > >This happened some time ago, unfortunately (for IBM, who were one of the >domains lost this way) the host known at InterNIC as 'ibm.com' didn't run >any SMTP daemon. > >(Remember that sendmail falls back to A records if it can't find any MX > records for a host.) > >Good comments for the rest, I agree wholeheartedly with all of them, also >with those from other people. > >Take care, > >-- >Niels Bakker, * * EuroNet Internet BV >Network Operations * * Herengracht 208-214 > * 1016 BS Amsterdam >NJB9 * +31 (0)20 535 5555 > >

1 0

Re: DNS recommendations - the paper
by Berislav Todorovic 24 Nov '98

24 Nov '98

>> >> yes, but only in the in-addr.arpa. zone does it have useful meaning. >> > OK - I took my "toy" (an old Linux box w/BIND 8.1.2 installed). >> >> 0 - i use rfcs not amateur pseudo-unix wannabe systems BIND works everywhere the same way - Unix implementation is irrelevant. Besides, I've just tested the same on a Sun - same result. >> 1 - i meant THE in-addr.arpa. zone, not the <whatever>.in-addr.arpa. zone. I agree with that remark - sorry for my previous misinterpretation of your message ... ;-) Nevertheless, in the case of in-addr.arpa zone the IP address should be reversed, e.g. 8.67.45.123. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI(a)etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3370-106 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' --------------------------------------------------------------------

2 1

Re: DNS recommendations - the paper
by Randy Bush 24 Nov '98

24 Nov '98

> BIND works everywhere the same way unfortunately true. that's why i use the rfcs. randy

1 0

Re: DNS recommendations - the paper
by Randy Bush 24 Nov '98

24 Nov '98

>> yes, but only in the in-addr.arpa. zone does it have useful meaning. > OK - I took my "toy" (an old Linux box w/BIND 8.1.2 installed). 0 - i use rfcs not amateur pseudo-unix wannabe systems 1 - i meant THE in-addr.arpa. zone, not the <whatever>.in-addr.arpa. zone. randy

1 0

Re: DNS recommendations - the paper
by Berislav Todorovic 24 Nov '98

24 Nov '98

>> * The PTR section contains a possible mistake - are you sure you can write: >> 123.45.67.8 IN PTR mail.cust.com. >> >> yes, but only in the in-addr.arpa. zone does it have useful meaning. OK - I took my "toy" (an old Linux box w/BIND 8.1.2 installed). I created a bogus reverse zone 1.168.192.in-addr.arpa. Here is the zone file: @ IN SOA ns.nic.yu. hostmaster.nic.yu. ( 1997092300 10800 3600 604800 86400 ) IN NS ns.nic.yu. IN NS ns2.nic.yu. 192.168.1.1 IN PTR aaa.yyy.zz. 2 IN PTR bbb.yyy.zz. Remark: the first record is created according to the Elmar's text. The latter is a regular record. Now, watch what host utility gives: ~> host 192.168.1.1 192.168.1.1 has no PTR record (Authoritative answer) ~> host 192.168.1.2 Name: bbb.yyy.zz Address: 192.168.1.2 Conclusion? Let's see what really happened: ~> host -alv 1.168.192.in-addr.arpa 1.168.192.in-addr.arpa. 86400 IN NS ns.nic.yu. 1.168.192.in-addr.arpa. 86400 IN NS ns.nic.yu. 2.1.168.192.in-addr.arpa. 86400 IN PTR bbb.yyy.zz. 192.168.1.1.1.168.192.in-addr.arpa. 86400 IN PTR aaa.yyy.zz. Look at the last PTR record - think it looks ok? ;-) Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI(a)etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3370-106 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' --------------------------------------------------------------------

1 0

Re: DNS recommendations - the paper
by Berislav Todorovic 24 Nov '98

24 Nov '98

>> > serial number: >> > Changed zones are only reloaded if a higher serial number add "on the secondary servers" between "reloaded" and "if a ..." >> > Synopsis >> > [<hostname>] [<TTL>] IN A <IPV4 address> [<IPV4 address> ...] Wrong, of course ... RFC 1035 says clearly: 3.4.1. A RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ADDRESS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ADDRESS A 32 bit Internet address. Hosts that have multiple Internet addresses will have multiple A records. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI(a)etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3370-106 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' --------------------------------------------------------------------

2 1

DNS-help document available?
by Kurt Kayser 24 Nov '98

24 Nov '98

Hi! Last time in Edinburgh we've started a document about basic DNS setup procedures. Did somebody continue on it? Where's the latest version available? Thanks, Kurt -- || Kurt Kayser - Internet Planning Engineer || || Viag Interkom - Riesstr. 25 - 80992 Munich - Germany|| || Tel: +49 89 1480 3827 - Fax: 3878 ||

3 2