Hi everybody, sorry to be so late. The following is my poor proposal for the agenda of the DNS-WG. Please: - *contribute* to improve the agenda - come to the meeting having seletected your preferred candidate for the WG chairman position Agenda ------ 1. Scribe 2. WG-agenda bashing 3. Nomination of the DNS Working Group chair 4. Status of discussions about TLDs administration 5. Report of problems experienced 6. AOB ---------- ---------- Antonio-Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 50 593246 Via S. Maria, 36 Fax: +39 50 904052 I-56126 PISA Telex: 500371 CNUCE I Italy Url: http://www.nis.garr.it/nis/staff/bonito.html ---------- ----------
- *contribute* to improve the agenda
Two ideas: Discuss the dynamic DNS Internet-Drafts draft-ietf-dnsind-dynDNS-09.txt draft-ietf-dnsind-ixfr-06.txt draft-ietf-dnsind-notify-07.txt draft-ietf-dnsind-serial-02.txt that are next in line with the IESG for proposed standard. Discuss Bill Mannings Internet-Draft draft-manning-dnssvr-criteria-00.txt with specifications for root and TLD name servers. Maybe even convince someone to give short presentations on the contents of the papers? Cheers, /Liman
Quoting from Lars-Johan Liman's message:
- *contribute* to improve the agenda
Two ideas:
Discuss the dynamic DNS Internet-Drafts draft-ietf-dnsind-dynDNS-09.txt draft-ietf-dnsind-ixfr-06.txt draft-ietf-dnsind-notify-07.txt draft-ietf-dnsind-serial-02.txt that are next in line with the IESG for proposed standard.
OK. Here follows another update to the agenda.
Discuss Bill Mannings Internet-Draft draft-manning-dnssvr-criteria-00.txt with specifications for root and TLD name servers.
Already included.
Maybe even convince someone to give short presentations on the contents of the papers?
Cheers,
Lars-Johan, are you volunteering? Blasco ==================================================== RIPE 24 DNS Working Group Berlin 23 May 1996 Chairman position vacant! Deputy: Antonio-Blasco Bonito Proposed draft agenda --------------------- 1. Administrative stuff - volunteering of the scribe - WG-agenda bashing 2. Nomination of the DNS Working Group chair 3. Status of discussions about TLDs administration 4. DNS and UDP checksumming 5. Dynamic DNS updates 6. Report of problems experienced 7. AOB ==================================================== On item 3 please read the following Internet Drafts: K. Denninger (25 January 1996) TOP LEVEL DOMAIN DELEGATION DRAFT Simon Higgs (April 1996) New TLD Categories Bill Manning (April 1996) Technical Criteria for Root and TLD Servers On item 4 see the message sent by Geert Jan on this list. On item 5 please read the following Internet Drafts: Paul Vixie and others (March 1996) Dynamic Updates in the Domain Name System M. Ohta (February 1996) Incremental Zone Transfer in DNS Paul Vixie (March 1996) A Mechanism for Prompt Notification of Zone Changes Robert Elz (March 1996) Serial Number Arithmetic For your convenience I list here the URLs of the above documents http://www.nis.garr.it/netdoc/drafts/draft-denninger-itld-admin-00.txt http://www.nis.garr.it/netdoc/drafts/draft-higgs-tld-cat-00.txt http://www.nis.garr.it/netdoc/drafts/draft-manning-dnssvr-criteria-00.txt http://www.nis.garr.it/netdoc/drafts/draft-ietf-dnsind-dynDNS-09.txt http://www.nis.garr.it/netdoc/drafts/draft-ietf-dnsind-ixfr-06.txt http://www.nis.garr.it/netdoc/drafts/draft-ietf-dnsind-notify-07.txt http://www.nis.garr.it/netdoc/drafts/draft-ietf-dnsind-serial-02.txt
Discuss Bill Mannings Internet-Draft draft-manning-dnssvr-criteria-00.txt with specifications for root and TLD name servers.
Already included.
By the time you meet there should be a revision out: draft-manning-dnssvr-criteria-01.txt. Since it may not have reached the drafts directories by then, would you like me to send a copy to this list? -- --bill
Quoting from bmanning@ISI.EDU's message:
Discuss Bill Mannings Internet-Draft draft-manning-dnssvr-criteria-00.txt with specifications for root and TLD name servers.
Already included.
By the time you meet there should be a revision out:
draft-manning-dnssvr-criteria-01.txt. Since it may not have reached the drafts directories by then, would you like me to send a copy to this list?
-- --bill
Yes, please Thanks ---------- ---------- Antonio-Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 50 593246 Via S. Maria, 36 Fax: +39 50 904052 I-56126 PISA Telex: 500371 CNUCE I Italy Url: http://www.nis.garr.it/nis/staff/bonito.html ---------- ----------
have reached the drafts directories by then, would you like me to send a copy to this list?
Yes, please
Antonio-Blasco Bonito E-Mail: bonito@nis.garr.it
Otay... --------------------- Internet Draft Bill Manning April 1996 ISI Expires in six months Technical Criteria for Root and TLD Servers draft-manning-dnssvr-criteria-01.txt Abstract This draft proposes criteria for servers and their environments that will support zones for top level and root domains. It is expected that the machines running root service will be different than the machines running TLD service. Although there are differences, the same basic criteria should hold. It is expected that TLD servers may field more queries and the root servers may be more concerened with cache pollution. Although this draft has been discussed in various bodies, it is not final, it should not be regarded as a consensus document, and it is presented for open debate in the Internet community. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Design Goals: Define the basic set of requirements for TLD/Root server hardware. Make them all objectively verifiable. Disclaimer: This document doesn't discuss actual placement of servers. Procedures for dealing with non-compliance are not covered in this memo. Selected Operational Qualifications: 1. Modern BIND or equivalents (if any exist). The upgrade process will be coordinated with the zone-master staff and will occur within 96 hours of inital notification. Zone-master senior staff will specify the software and version(s) that will be run in a particular zone. 2. UDP checksums enabled. Note that this should apply to all machines running DNS. 3. Dedicated host no user accounts, just the operations & admin or root account. no other services except NTP. (remove telnet, SMTP, FTP etc). This requires support to be from the console or other specified secure channel. It is expected that one-time tokens will be used for authentication. 4. Singly homed (only one interface). 5. Protected: In general, each server must be adequately protected against security threats. The system administrator must stay up-to-date on the latest security methods and threats and must implement reasonable security countermeasures. Audits by the zone administrator or authorized agents will be permitted and corrective measures will be taken. A good way to keep current is to follow the CERT recommendations. A reasonable approach is to only run DNS sw, NTP and ICMP support with extensive logging. Recommended packages to assist are tcp_wrappers and ipfilter. Any other package which is an acceptable technology is fine. 6. Servers time is synchronized via NTP. This is useful for supporting functions; e.g. logging. It is expected that future enhancements such as dynamic update and security support will take advantage of accurate clocks. 7. Sufficient resources to support a transaction rate of 1200/sec and mean time to respond of 0.5 seconds per transaction. There should be enough extra resources available to support a 15% growth in the number of transactions per second without affecting the response time. 8. Representative on TLD/Root administrator list is responsive: 8a. e-mail about required changes will be answered within 24 hours; 8b. vacations will cause responsibilities to be delegated, not ignored; 8c. contact numbers on file with zone-master senior staff members; 8d. an escalation/delegation list that has at least three levels of hierarchy. 9. Named.boot file will specify... 9a. "xfrlist" of local nets and maybe other roots; 9b. server will use "secondary" from the zone master, not FTP; 9c. "options no-recursion" and "limit transfers-per-ns 1". 9d. "options no-fetch-glue" (Equivalences for non-bind servers will apply!) 10. Network and name server outages will be reported. 10a. To the root admin and TLD admin lists whether scheduled or unscheduled. 10b. via phone to the zone-master senior staff if the outage unscheduled or if the outage is to occur in less than 24 hours. 10c. Extended outages may result in exceptional handling situations. 11. Name server and its immediate infrastructure are protected against likely force majeure (power failures, ...). 12. Address PTR points (only) to ?.root-servers.net, not a "local" name. (for root servers only! :) Selection Criteria: 1. serves max possible number of low-hopcount endpoints not otherwise served. 2. credibly likely to continuously perform on qualification criteria for the duration of the operations contract. 3. stable organization which is considered likely to survive and prosper. 4. Limited exposure to points of failure that may be shared by other, peer nameservers. Security considerations of this memo None. Acknowledgments Constructive comments have been received from: Jon Postel, Paul Vixie, Michael Patton, Andrew Partan, Michael Dillon, Don Mitchell Steven Doyle, Owen DeLong and other members of the internet community. Authors' Addresses Bill Manning USC/ISI 4676 Admiralty Way Marina del Rey, CA. 90292 +1.310.822.1511 bmanning@isi.edu -- -- --bill
Maybe even convince someone to give short presentations on the contents of the papers?
Lars-Johan, are you volunteering?
I really would like to, but that would probably be the last drop of work that kills me, if I take it on. The week-end is painfully busy as it is ... :-( Cheers, /Liman #------------------------------------------------------------------------- # Lars-Johan Liman ! Internet: liman@sunet.se # Ebone/NORDUnet/SUNET Operations Centre ! BITNET : LIMAN@SEARN # Royal Institute of Technology, Sweden ! HTTP : //www.sunet.se/~liman # ! Voice : Int +46 8 - 790 65 60 #-------------------------------------------------------------------------
On Thu, 18 Apr 96 16:50:34 MET DST Antonio_Blasco Bonito wrote:
- *contribute* to improve the agenda
I'd like to have another topic discussed: DNS and UDP checksumming. I brought this up several weeks ago but got only one response (thanks Francis, though I don't agree with you on this ;-) Rationale: We all encounter an increasing amount of junk data in the various DNS caches, where the data usually just has one bit flipped. Presumably this is caused by spikes on serial lines which run without checksumming on the serial protocol itself. As checksums with UDP are not mandatory, some workstation manufacturers ship operating system code with UDP checksumming disabled. This means that data from/to such server can be corrupted, and this will remain undetected. (for those that don't know, UDP checksums are one-complement checksums; hence there are 2 values for 'zero', one of which is used to flag that no checksum has been calculated. Hence, a receiver can see per-packet if the UDP checksum was calculated and can be verified) Looking though various sources, I found 3 classes of machines. One can usually switch between two of these 3 categories with a kernel flag. 1. Some machines send UDP checksums and check for them as well Fortunately this is the common case, and it is as things should be. 2. Some machines don't send UDP checksums, but will verify if a packet with UDP checksum arrives. 3. Some machines neither generate nor check checksums. This are mostly SUNs running 'classic solaris' (SunOS) and this behaviour can be switched to 1. by a simple patch. I also found that it is usually quite hard for an application to find out if a packet that arrives on a UDP socket did have a checksum or not. There are a couple of approaches: - Leaving things as-is Obviously I don't think this is desirable, otherwise I wouldn't bring it up ;-) - Sending warding messages On the FR-NIC FTP server there is a small program to test if UDP checksumming is enabled on a host. This is done by sending UDP packets with a bad checksum to said host; if it responds, then it doesn't check checksums. I have looked into this approach, but I don't think it scales itself to a large scale warning mechanism. I think this method isn't reliable to test this problem, although it certainly helps - Ignoring UDP packets without checksum. RFC1122 or 1123 (can't tell now - don't have RFC repository on my laptop) has some lines in there that suggest that it is allowable for an application to ignore UDP requests without checksum. This is hard to switch on BSD-derived machines, but a kernel patch to ignore all non-checksum UDP packets is simple. If a number of well-known servers would do this, and this mechanism would be known (hence bringing it up on in the WG), then there would be a good incentive for people to fix their boxes (a little bit like the requirement to have in-addr delegation for access to certain FTP archives). While I realize that the last approach is more disruptive, I think that this is the correct approach. My proposal: - Make a short document describing the problem, with workarounds for common platforms (I can only think of SunOS having a bad default) - Setting a flag date - From that date, allowing people to change their servers to reject packets without UDP checksum. So far, I have had one response on this, suggesting that approach two (testing and warning) should be used instead. I don't think this is feasible now, and it certainly has scaling problems, so I'd rather have the RIPE community reach consensus that the last approach is acceptable and can be implemented.. Geert Jan PS: sorry to be long-winded on this, but as I won't be able to attend the Berlin meeting, I won't be able to give a presentation on this. I hope that this message is enough to discuss the matter..
Quoting from Geert Jan de Groot's message:
On Thu, 18 Apr 96 16:50:34 MET DST Antonio_Blasco Bonito wrote:
- *contribute* to improve the agenda
I'd like to have another topic discussed: DNS and UDP checksumming. I brought this up several weeks ago but got only one response (thanks Francis, though I don't agree with you on this ;-)
OK. Here follows the updated agenda Blasco ==================================================== RIPE 24 DNS Working Group Berlin 23 May 1996 Chairman position vacant! Deputy: Antonio-Blasco Bonito Proposed draft agenda --------------------- 1. Administrative stuff - volunteering of the scribe - WG-agenda bashing 2. Nomination of the DNS Working Group chair 3. Status of discussions about TLDs administration 4. DNS and UDP checksumming 5. Report of problems experienced 6. AOB ==================================================== On item 4 see the message sent by Geert Jan on this list. On item 3 please read the following Internet Drafts: K. Denninger (25 January 1996) TOP LEVEL DOMAIN DELEGATION DRAFT Simon Higgs (April 1996) New TLD Categories Bill Manning (April 1996) Technical Criteria for Root and TLD Servers For your convenience I list here the URLs of the above documents http://www.nis.garr.it/netdoc/drafts/draft-denninger-itld-admin-00.txt http://www.nis.garr.it/netdoc/drafts/draft-higgs-tld-cat-00.txt http://www.nis.garr.it/netdoc/drafts/draft-manning-dnssvr-criteria-00.txt
participants (4)
-
Antonio_Blasco Bonito
-
bmanning@ISI.EDU
-
Geert Jan de Groot
-
Lars-Johan Liman