- dns-wg - mailman.ripe.net

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

Re: Recommendations for DNS
by Wilfried Woeber, UniVie/ACOnet 22 Sep '98

22 Sep '98

=>> SOA The address in this field must be a valid e-mail address to the =>> administrator for the DNS. =>> It's also good practise to have role address instead of =>> personal, ie root.. admin.. hostmaster.. =>> (when domain-administrator is leaving your company, you =>> only change the alias for role address). = =I would add: "The 'at' ('@') sign of the email address should be =replaced by a dot, e.g. instead of <hostmaster(a)foo.bar.com>, the =address should be specified as hostmaster.foo.bar.com, as given =in the following example." With regard to the '@' sign hack, I'd rather use 'must' than 'should' :-) On top of that, I suggest to clearly describe the requirement to quote any "leading" dot(s) that are *not* supposed to be converted to an '@' character. Like in wilfried\.woeber.univie.ac.at ! Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

6 5