- dns-wg - mailman.ripe.net

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

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

reverse addressing
by Nader S Kawar 21 Jul '98

21 Jul '98

Hello, We are Global One Jordan and we own the 194.165.128.0 /19 group of class C IP addresses. We need to have the delegation of reverse addressing for these network addresses. What do we need to do in order to get that delegation. Thank you for your help. Awaiting your reply. Best Regards, Nader Kawar IP Technical Manager Global One Communications Jordan (Ltd) phone: ++962 6 562-4777 ext 14 fax : ++962 6 569-7111

3 2

Fwd: Proposal for Discussion
by RB Hunter 02 Jul '98

02 Jul '98

Transitional Framework from a Business and User Perspective Scope: Discuss the U.S. Government's appeal for Internet "consensus" in Internet governance and propose organizational structures for the "new organization". Also, comment on the current IANA activity and international meetings initiated by the Internet community. Overview For the past 10 years or so, the IANA, an unofficial organization, was responsible for many of the duties outlined in the NTIA's White Paper. However, as the Internet has become more commercial, it was realized by the IANA, U.S. government, and many other members of the Internet community, that the time has come for a more formal, official and established organization transition these responsibilities in addition to other responsibilities into an new non-profit organization. The establishment of this new organization will only benefit the Internet community, as long as the transition from the current IANA is smooth and the process for creating this new organization continues to establish the stability needed for the operations of the global Internet. with the Internet from the small academic network to the commercial superhighway that it is today. Whether you think you could of done a better job, who will ever know? The important focus of the present situation is how this old organization will transition to the new one. The old IANA, headed by Jon Postel, has done an admirable job in a very difficult situation. While many strong voices are advocating their own agenda, the old IANA has tried its best to maintain stability of the global Internet without having adequate power and authority from the U.S. government or the Internet community to effectively evolve into the organization we all hoped it would be. Many people claim that Jon Postel has his own agenda, but those are only the ones that don't know him. Jon has done more for the Internet than anyone gives him credit for, whether you want to believe it or not. While I am an advocate in his defense, it is obvious that his role in this new organization should be significantly smaller - a role which he would much rather have, I might add. The people of the old organization need to be intimately involved in this transition. They have just as much stake as anyone else, and quite frankly, including Jon Postel, who has worked extremely hard, in vain, to try to make everyone satisfied with Internet governance. How can we ask Jon to step down from all of his duties when he has given so much of his life to the Internet? It is clear that this new organization will not be someone's single agenda, and it would be wise to have Jon's expertise in certain matters available to the new IANA. While many think they know what is best for the Internet, there are many secret agendas in the participants of this process. The Internet community needs to create an open process where these agendas will be checked and balanced. So many people are concerned with what the Internet can do for them, they miss the fact that this new organization is being created for the good of the Internet as a whole. Domain names are the big issue here. No one cares about protocols or even addresses (for the most part). However, these are currently the main activities of the old IANA. Without these essential parts of the machine, domain names wouldn't matter. One thing about domain names is pretty certain: there will be many more top level domains when this new organization gets a chance to actually work. Sure, there are a few people who don't want any more TLDs, but the vast majority are advocating many more TLDs, including Jon Postel, who initially requested to add 150+ TLDs to the root. All in all, domain names should not be that big of an issue. No matter who is the "CEO" or on a "Board of Directors", they will advocate the creation of many TLDs, maybe an unlimited number of TLDs (which would let the market determine which ones were best). Transition Regardless of this speculation, the process of creating this new organization needs to be WIDE open. From corporations, ISPs, academia and end users from around the world, the new organization needs consensus. We are not going to get anywhere if we leave 1 person out. Understandably, however, not everyone will have their opinion turn into policy. That is not consensus. Consensus is the expression of opinions in an open forum, and the approval of some of them by the majority of the participants. Initially, while the end user might not be thoroughly represented, the stakeholders are the key participants. All stakeholders in the process must work together in order to get the organization running by September 30, 1998. While the International Forums are a good start, I would hope that the result of those forums is to have the old IANA sponsor the proposals that are created in the forums. Sponsoring would entail creating compromise among the proposals, submitting it to the stakeholders of the Internet community (participants of these International Forums) for "consensus", and then working with the final proposal to establish this new organization. There will obviously be many proposals, and it is the role of the Internet community to discuss each proposal and work on finding a few good organizational structures which could elect and Interim Board of Directors for the new organization. Once this Board of Directors is elected, the organization has started, and policies will result, including an official organizational structure, which will have the consensus of the Internet community behind it. Proposal As an informed user, my opinion will probably be disregarded, and that is unfortunate. Simply because I am not an ISP or huge stakeholder in the game shouldn't mean that my business sense and organizational ideas should be discounted. There are many of use who are much more talented organizationally than some of the stakeholders, and in turn, there are many more stakeholders who know a lot more about the process than I do. In any case, because I will not be able to participate in any of the International Forums, my proposal for the new organization will be given here. I have no agenda. I want to see the Internet work. I want the Internet to remain and grow as the commercial machine that it is, and at the same time, I want people involved in the Internet governance game to be sane, effective, aware and adhering to their constituents, and doing what they feel is best for the Internet. Personally, I believe that the election of and Interim Board of Directors to start up the organization should be a bottom-up process, starting with the Internet community [A], which is primarily the stakeholders. These stakeholders, in effect, represent the Internet community and can achieve "consensus". A stakeholder should be representatives attending the International Forums as well as anyone else who feels they have a valuable stake in Internet governance. For the most part, this will not include the end user, who is not all that aware of the situation, and as long as stability of the Internet and day to day operations have integrity, they would rather not be involved (except me, of course). [A] -------------------- |Internet Community| -------------------- >From the bottom up, the Internet community would participate in various commissions [B]. I will propose 5 commissions: Domain, Address, Protocol, User, and Nominating. The commissions will be responsible for nominating Interim "Councils" which would represent their interests. The Domain commission would be responsible, in the interim, for domain name issues (once the Interim Board of Directors is elected). The Address commission would be responsible for Address issues and development. The Protocol commission would be responsible for Protocol issues. The User commission would be responsible to represent the end user and various issues. The Nominating commission would be responsible for nominating interim Board members outside in addition to the elections which take place in the various commissions.Any participant may be involved in each of these commissions, but many not be elected to more than 1 council. ------------ ------------ ------------ ------------ ------------ | Domain | | Address | | Protocol | | User | |Nominating| |Commission| |Commission| |Commission| |Commission| |Commission| ------------ ------------ ------------ ------------ ------------ | | | | | ---------------------------------------------------------- [B] | -------------------- |Internet Community| -------------------- >From these commissions, the councils would be elected. These councils would represent their commission and have a vote on the Interim Board of Directors. Another idea is for each council to be represented on the Board with 2 seats (with the exception of the nominating commission). The nominating commission would independently nominate people for the Board of Directors who are not involved in the other councils. No council for this commission is needed. This results in diagram [C]: ------------ ------------ ------------ ------------ ------------ | Domain | | Address | | Protocol | | User | |Independent| | Council | | Council | | Council | | Council | | Board | | | | | | | | | |Nominations| ------------ ------------ ------------ ------------ ------------ | | | | | ------------ ------------ ------------ ------------ ------------ | Domain | | Address | | Protocol | | User | |Nominating| |Commission| |Commission| |Commission| |Commission| |Commission| ------------ ------------ ------------ ------------ ------------ | | | | | ---------------------------------------------------------- [C] | -------------------- |Internet Community| -------------------- Thus, representatives from each council would be voted in to the interim Board of Directors, and the councils as a whole would vote to approve the Independent Board Nominations, who would serve on the Board with equal status. Diagram [D]: ------------- ------------- |Board Reps | + |Board Reps | | (Councils)| |(Ind. Nom.)| ------------- ------------- | | | | ---------------------------------------------------------- | | | | | ------------ ------------ ------------ ------------ ------------ | Domain | | Address | | Protocol | | User | |Independent| | Council | | Council | | Council | | Council | | Board | | | | | | | | | |Nominations| ------------ ------------ ------------ ------------ ------------ | | | | | ------------ ------------ ------------ ------------ ------------ | Domain | | Address | | Protocol | | User | |Nominating| |Commission| |Commission| |Commission| |Commission| |Commission| ------------ ------------ ------------ ------------ ------------ | | | | | ---------------------------------------------------------- [D] | -------------------- |Internet Community| -------------------- Combined, these elected representatives would constitute the interim Board of Directors. The Council members would remain in their respective positions until the interim Board of Directors establishes the legal organization and framework for the election of the Board of Directors and the participation of the Internet community as a whole. The end result would be diagram [E]: -------------- | Interim | | Board of | | Directors | -------------- | --------------------------- | | ------------- ------------- |Board Reps | + |Board Reps | | (Councils)| |(Ind. Nom.)| ------------- ------------- | | | | ---------------------------------------------------------- | | | | | ------------ ------------ ------------ ------------ ------------ | Domain | | Address | | Protocol | | User | |Independent| | Council | | Council | | Council | | Council | | Board | | | | | | | | | |Nominations| ------------ ------------ ------------ ------------ ------------ | | | | | ------------ ------------ ------------ ------------ ------------ | Domain | | Address | | Protocol | | User | |Nominating| |Commission| |Commission| |Commission| |Commission| |Commission| ------------ ------------ ------------ ------------ ------------ | | | | | ---------------------------------------------------------- [D] | -------------------- |Internet Community| -------------------- Of course, this is only a proposal for discussion. This organization structure was only created as the short-term process for establishing the Interim Board of Directors. While it may contain some ideas as to how the final organizational structure is configured, it was created to start discussion as to how this new non-profit organization should be created. Conclusion While September 30, 1998 may seem like quite a long time away, there is much work needed on this issue. I hope that this proposal can result in some constructive cooperation and criticism for how the new organization should be created. We must all actively participate in this process. Criticism of any proposal should include new ideas and suggestions. Negative reaction without the wisdom to suggest specific reforms will not create cooperation within the community, but will merely divide it. My challenge to all of the stakeholders is to be as agenda-less as possible. It is in your best interest to do so. With competing agendas and self-interest dominating the discussion, no consensus will ever be achieved. If you took the time to read this, thanks for you time and efforts. *********************************** D. Elliott International Consultant & Mediator Concerned Internet User *********************************** ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1