September 1998 - dns-wg - mailman.ripe.net

ISO 3166-based Top Level Domain Survey
by Robert Shaw 07 Nov '00

07 Nov '00

Hi, At http://www.itu.int/net/cctlds/nics.htm is a preliminary survey conducted by ITU of Internet ISO 3166-based top level domains. The material is in in draft form and is made available in order to solicit public comment. Information includes all known URLs for registration. While every attempt has been made to ensure accuracy, the information cannot be considered authoritative as the Internet Assigned Numbers Authority (IANA) is the authoritative source for ISO 3166-based top level domain delegation information. All raw data gathered has been and will continue to be provided to IANA. Comments and/or corrections on these pages should be sent to Ms. Asa Johansson at <asa.johansson(a)itu.int>. Denominations and classifications employed in this publication do not imply any opinion on the part of the ITU concerning the legal or other status of any territory or any endorsement or acceptance of any boundary. Thanks, Robert -- Robert Shaw <robert.shaw(a)itu.int> Advisor, Global Information Infrastructure International Telecommunication Union <http://www.itu.int> Place des Nations, 1211 Geneva, Switzerland

4 3

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

Re: Recommendations for DNS
by Berislav Todorovic 22 Sep '98

22 Sep '98

>> > 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 ! >> >> While this particular hack works, it is a clear violation of the spec. The simplest solution to the problem is to stick with the recommendation, already given in the proposed document: instead of using real addresses, usage of role accounts is preferred. A very good practice is to create the role account <hostmaster@domain>. Besides, it's recommended by the RFC 2142, which has STD status. 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: Recommendations for DNS
by Simon Leinen 22 Sep '98

22 Sep '98

>> Like in wilfried\.woeber.univie.ac.at ! > While this particular hack works, it is a clear violation of the spec. Well, RFC 1035 explicitly uses this in its examples, and RFC 1912 also mentions this in section 2.2 "SOA records". So it may be a hack, but it's an IETF-sanctioned hack :-) -- Simon.

1 0

Re: Recommendations for DNS
by Berislav Todorovic 22 Sep '98

22 Sep '98

>> This is the action point from RIPE-28 thats in the final stage. >> I will be presenting this at RIPE-31 this Thursday. >> So any comments and suggestions will be looked at if they arrive before >> Thursday. In general, the text is ok, though I think a more detailed text covering DNS is really needed. However, that can be left for some next iteration. Minor changes I would suggest here follow: >> To have a document for LIR:s to use for their customers instead of a >> number of RFC:s. I would add: "This document should be taken as a brief DNS reminder. For thorough understanding, reading RFC's and books, listed at the end of this document, is highly recommended". >> 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." >> MX When pointing a domain to a mailserver/hostname, do not forget >> to add a record ( A ) for this. I would add: "only if the hostname is within the zone (see below)". >> Additional reading and references: >> >> ftp://ftp.ripe.net/internet-drafts/draft-ietf-dnsind-classless- >> inaddr-04.txt >> ( For reverse delegation methods for blocks smaller than /24, >> 256 addresses ) This is outdated and has to be changed with the pointer to RFC 2317. 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

Recommendations for DNS
by Hans Niklasson 22 Sep '98

22 Sep '98

Greetings This is the action point from RIPE-28 thats in the final stage. I will be presenting this at RIPE-31 this Thursday. So any comments and suggestions will be looked at if they arrive before Thursday. Otherwise I´ll see you there. :) DNS recommendations. By: Hans Niklasson <hasse(a)swip.net> Amar Andersson <amar(a)telia.net> 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. To have a document for LIR:s to use for their customers instead of a number of RFC:s. Records: ----------------------------------------------------------------------------- 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). Ex: foo.bar.com. IN SOA dns.foo.bar.com admin.foo.bar.com SERIAL Serial number should follow this format: YYYYMMDDXX ( year.year.year.year.month.month.day.day.nr.nr ), where XX is the number of the latest update of the zone in the same day. (Year 2000 is near.) Ex: 1998010101 ; serial TTL A good balance of this will reduce unecessary traffic between nameservers. Ex: 28800 ; refresh (8 hours) 7200 ; retry (2 hour) 1209600 ; expire (14 days) 86400 ) ; minimum (1 day) MX When pointing a domain to a mailserver/hostname, do not forget to add a record ( A ) for this. Ex: foo.bar.com. IN MX 10 mail.foo.bar.com. mail.foo.bar.com. IN A 192.168.0.1 CNAME Use this with caution. It is *not* recommended to use a CNAME for a mailservers hostname, as this can cause resolving problems and mailloops. Also it is not a good thing to use CNAMES on nameservers as this will cause unnecessary traffic on the net. A A record can only point to an IP address. PTR This is used for reverse lookup of the IP address to a hostname within the zone. Make sure that your PTR records and A records match. For each A record there has to be a PTR record, and vice versa. More tips: Unecessary glue data: Do not add unecessary glue data about hosts that is not within the zone. This can cause resolving problems if the host changes IP address. Ex: foo.bar.com. IN MX 10 mail.foo.bar.com. mail.foo.bar.com. IN A 192.168.0.1 Trailing dots: Do not forget to add a "." at the end of the domain/ hostname. If this is forgotten, this will make the DNS to add the domain name to the domain/hostname again. This will cause resolving problems. Ex: 11 PTR foo.test will produce foo.test.7.42.666.in-addr.arpa. Illegal characters: Only a-z , 0-9 and - is valid to use. The domain system allows a label to contain any 8-bit character. Although the domain system has no restrictions, other protocols such as SMTP do have name restrictions. Because of other protocol restrictions, only the above characters are recommended for use in a host name (besides the dot separator). General Points: Use the latest version of the DNS software for your platform. Check for updates regulary, as new versions has the latest solutions and information. Example on a recommended DNS: foo.bar.com IN SOA ns.foo.bar.com. root.foo.bar.com. ( 1998081900 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 1209600 ; expire (14 days) 86400 ) ; minimum (1 day) foo.bar.com. IN NS ns.foo.bar.com. foo.bar.com. IN NS ns2.foo.bar.com. foo.bar.com. IN MX 10 mail.foo.bar.com. www.foo.bar.com. IN CNAME www.webhotel.xx. www2.foo.bar.com. IN A 192.168.0.3 ns.foo.bar.com. IN A 192.168.0.1 ns2.foo.bar.com. IN A 192.168.0.4 mail.foo.bar.com. IN A 192.168.0.2 localhost IN A 127.0.0.1 Additional reading and references: RFC1537 ( RFC1912 ) ( Common DNS Operational and Configuration Errors ) RFC1033-5 RFC2181 "DNS & BIND 3nd Edition" by Paul Albitz & Cricket Liu from OReilly & 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 ) /Hans Niklasson ----------------------------------------------------------------- SWipNet - The Swedish IP Network

3 2