From artur at morgaine.fct.unl.pt Tue May 10 21:32:57 1994 From: artur at morgaine.fct.unl.pt (Artur Romao) Date: Tue, 10 May 94 19:32:57 GMT Subject: DNS debugging Message-ID: <9405101932.AA13980@morgaine.fct.unl.pt> Dear All, I recently wrote a paper on the issue of DNS debugging, as a result of some experience managing the PT domain. By doing that we (the group of PT managers) have seen a lot of errors made by DNS-admins and the consequences of them. So, we became interested in debugging DNS, and this document is the result of playing around with the tools we used for that. It also express some feelings about the way people see and use DNS... Following a sugestion from Francis Dupont, I'm sending this to the list, so that all of you can take a look and comment on it. Francis suggested also that this could provide some input for the next RIPE DNS-WG meeting, so I leave it here for your consideration. Any comments are most welcome. .artur ----------------------------------------------------------------------------- Taking Care of Your Domain Artur Romao Faculdade de Ciencias e Tecnologia Universidade Nova de Lisboa May 1994 1 INTRODUCTION Today more than 2,200,000 computers are inter-connected in a global Internet, comprising several millions of end-users, able to reach any of those hosts just by naming it. This facility is possible thanks to the world widest distributed database, the Domain Name System, used to provide distributed applications various services, the most notable one being translating names into IP addresses and vice-versa. This happens when you do an ftp or telnet, when your gopher client follows a link to some remote server, when you click on a hypertext item and have to reach a server as defined by the URL, when you talk to someuser at some.host, when your mail has to be routed through a set of gateways before it reaches the final recipient, when you post an article to Usenet and want it propagated all over the world. While these may be the most visible uses of DNS, a lot more applications rely on this system to operate, e.g. network security, monitoring and accounting tools, just to mention a few. DNS owes much of its success to its distributed administration. Each component (called a zone, the same as a domain in most cases), is seen as an independent entity, being responsible for what happens inside its domain of authority, how and what information changes and for letting the tree grow downwards, creating new components. On the other side, many inconsistencies arise from this distributed nature: many administrators make mistakes in the way they configure their domains and when they delegate authority to sub-domains; many of them don't even know how to do these properly, letting problems last and propagate. Also, many problems occur due to bad implementations of both DNS clients and servers, especially very old ones, either by not following the standards or by being error prone, creating or allowing many of the above problems to happen. All these anomalies make DNS less efficient than it could be, causing trouble to network operations, thus affecting the overall Internet. This document tries to show how important it is to have DNS properly managed, including what is already in place to help administrators taking better care of their domains. 2 DNS DEBUGGING To help finding problems in DNS configurations and/or implementations there is a set of tools developed specifically for this purpose. There is probably a lot of people in charge of domain administration having no idea of these tools (and, worse, not aware of the anomalies that may exist in their configurations). What follows is a description of some of these programs, their scope, motivations and availability, and is hoped to serve as an introduction to the subject of DNS debugging, as well as a guide to those who are looking for something to help them finding out how healthy their domains and servers are. Some prior knowledge from the reader is assumed, both on DNS basics and some other tools (e.g. dig and nslookup), wich are not analyzed in detail here; hopefully they are well-known enough from daily usage. 2.1 HOST Host is a program used to retrieve DNS information from nameservers. This information may be used simply to get simple things like address-to-name mapping, or some more advanced purposes, e.g. performing sanity checks on the data. It was created at Rutgers University, but then Eric Wassenaar from Nikhef did a major rewrite and still seems to be actively working on it. The program is available from ftp.nikhef.nl:/pub/network/host.tar.Z. By default, host just maps host names to Internet addresses, querying the default servers (as defined in /etc/resolv.conf) or some specific one. It is possible, though, to get any kind of data (resource records) by specifying different query types and classes and asking for verbose or debugging output, from any nameserver. You can also control several parameters like recursion, retry times, timeouts, use of virtual circuits vs. datagrams, etc., when talking to nameservers. This way you can simulate a resolver's behavior, in order to find any problems associated with resolver operations (which is to say, any application using the resolver library). As a query program it may not be as powerful as others like nslookup or dig, but you can live with it perfectly well. As a debugger, host analyzes some set of the DNS space (e.g. an entire zone) and produces reports with the results of its operation. To do this, host first performs a zone transfer, which may be recursive, getting information from a zone and all its sub-zones. This data is then analyzed as requested by the arguments given on the command line. Note that zone transfers are done by contacting authoritative nameservers for that zone, so it must be possible to make this kind of request from such servers: some of them refuse zone transfers (except from secondaries) to avoid congestion. With host you may look for anomalies like those concerning authority (e.g. lame delegations, described below) or some more exotic errors like extrazone hosts (a host of the form host.some.dom.ain, where some.dom.ain is not a delegated zone of dom.ain). These errors are produced upon explicit request on the command line, but you get dozens of other errors as a result of host's operations, something like secondary effects. These may be mere warnings (which may be supressed) or serious errors (in fact, warning messages are not that simple, most of them are due to misconfigured zones, so it might not be a good idea to just ignore them). Error messages have to do with serious anomalies, either with the packets exchanged with the queried servers (size errors, invalid ancounts, nscounts and the like), or others related to the DNS information itself (also called "status messages" in the program's man page): inconsistencies between SOA records as shown by different servers for a domain, unexpected address-to-name mappings, nameservers not responding, not reachable, not running or not existing at all, and so on. Host performs all its querying on-line, i.e., it only works with data received from nameservers, which means you have to query a nameserver more than once if you want to get different kinds of reports on some particular piece of data. You can always arrange arguments in such a way that you get all information you want by running it once, but if you forget something or for any reason have to run it again, this means extra zone transfers, extra load on nameservers, extra DNS traffic. Host is an excellent tool, if used carefully. Like most other querying programs it may generate lots of traffic, just by issuing a simple command. Apart from that, its resolver simulation and debug capabilities make it useful to find many common and some not so common DNS configuration errors, as well as generate useful reports and statistics about the DNS tree. As an example, RIPE (Reseaux IP Europeens) NCC uses it to generate a monthly european hostcount, giving an overview of the Internet usage evolution in Europe. Along with these counts, error reports are generated, one per country, and the whole information is made available in the RIPE archive. 2.2 DNSWALK Dnswalk is a DNS debugger written in Perl by David Barr, from Pennsylvania State University. You'll find the latest version at ftp.pop.psu.edu, in directory /pub/src/dnswalk. With the software comes a small document where the author points some useful advices so it may be worth reading it. The program checks domain configurations stored locally. Data is arranged hierarchically in directories, resembling the DNS tree organization of domains. To set up this information dnswalk may first perform zone transfers from authoritative nameservers. You can have a recursive transfer of a domain and its sub-domains, though you should take care when doing this, as it may generate a great amount of traffic. If the data is already present, dnswalk may skip these transfers, provided that it is up to date. Dnswalk looks for inconsistencies in RRs, such as MX and aliases pointing to aliases or to unknwon hosts, incoherent PTR, A and CNAME records, invalid characters in names, missing trailing dots, unnecessary glue information, and so on. It also does some checking on authority information, namely lame delegations and domains with only one nameserver. It is easy to use, you only have to specify the domain to analyze and some optional parameters and the program does the rest. Only one domain (and its sub-domains, if that's the case) can be checked at a time, though. While in the process of checking data, dnswalk uses dig and resolver routines (gethostbyXXXX from the Perl library) a lot, to get such data as authority information from the servers of the analyzed domains, names from IP addresses so as to verify the existence of PTR records, aliases and so on. So, besides the zone transfers you may count on some more extra traffic (maybe not negligible if you are debugging a relatively large amount of data and care about query retries and timeouts), just by running the program. As of this writing, the program's operation is somewhat constrained by dig's behavior and the author is working hard on "un-dig'ing" it, using just Perl routines. It may be worthwhile upgrading your version if the new, dig-free dnswalk is available. 2.3 LAMERS A lame delegation is a serious error in DNS configurations, yet a (too) common one. It happens when a nameserver is listed in the NS records for some domain, and in fact it is not a server for that domain. Queries are thus sent to the wrong servers, who don't know nothing (at least not as expected) about the queried domain. Furthermore, sometimes the hosts in question (if they exist!) don't even run nameservers. As a result, queries are timed out and resent, only to fail, thus creating (more) unnecessary traffic on the Internet. It's easy to create a lame delegation: the most common case happens when an administrator changes the NS list for his domain, dropping one or more servers from that list, without informing his parent domain administration, who delegate him authority over his domain. From now on the parent nameserver announces one or more servers for the domain, which will receive queries for something they don't know about. On the other hand, servers may be added to the list without the parent's servers knowing, thus hiding valuable information from them (this is not a lame delegation, but is also an error). Other examples are the inclusion of a name in an NS list without telling the administrator of that host that it's being announced as a nameserver for a domain it doesn't know about, or when a server suddenly stops providing name service for the domain. To detect and warn DNS administrators all over the world about this problem, Bryan Beecher from University of Michigan wrote lamers, a program to analyze named's logging information [BEE92]. To produce useful logs, named was applied a patch to detect (and log) lame delegations (this patch was originally written by Don Lewis from Silicon Systems and is now part of the latest, experimental, release of BIND thanks to Bryan Beecher, so it is expected to be widely available in the near future). Lamers is a small shell script that simply scans these logs and reports on the lame delegations found. This reporting is done by sending mail to the hostmasters of affected domains, as stated in the SOA record for each of them. If this is not possible, the message is sent to the affected nameservers postmasters instead. Manual processing is needed in case of bounces, caused by careless setup of those records or invalid postmaster addresses. A report of the errors found by the UM servers is also posted twice a month on the USENET newsgroup comp.protocols.tcp-ip.domains. If you ever receive such a report, you should study it carefully in order to find and correct problems in your domain, or see if your hosts are being affected by the spreading of erroneous information. Better yet, lamers could be run on your servers to detect more lame delegations (UM can't see them all!). Also if you receive a mail reporting a lame delegation affecting your domain or some of your hosts, don't just ignore it or flame the senders. They're really trying to help! You can get lamers from terminator.cc.umich.edu:/dns/lamers.sh. 2.4 DOC Authority information is one of the most significant part of the DNS data, as the whole mechanism depends on it to correctly traverse the domain tree. Incorrect authority information leads to problems such as lame delegations or even, in extreme cases, the inaccessibility of a domain. Take the case where the information given about all its nameservers is incorrect. Being unable to contact the real servers you will end up being unable to reach anything inside that domain. This may be exagerated, but if you're on the DNS business long enough you've probably have seen some lightened examples of this scenario. To look for this kind of problems Paul Mockapetris and Steve Hotz, from the Information Sciences Institute, University of Southern California, wrote a C-shell script named DOC (Domain Obscenity Control), an automated domain testing tool that uses dig to query the appropriate nameservers and analyzes the responses. DOC limits its analisys to authority data since the authors antecipated that people would complain about such things as invasions of privacy. Also, at the time it was written most domains were so messy that they thought there wouldn't be much point in checking anything deeper until the basic problems weren't fixed. Only one domain is analyzed each time: the program checks if all the servers for the parent domain agree about the delegation information for the domain in question. DOC then picks a list of nameservers for the domain (obtained from one of the parent's servers) and starts the checking on its information, querying each of them: looks for the SOA record, checks if the response is authoritative, compares the various records retrieved, gets each one's list of NS, compares the lists (both among these servers and the parent's servers), and for those servers inside the domain the program looks for PTR records for them. Due to several factors, DOC seems to have freezed since its first public release, back in 1990. Within the distribution there is an RFC draft about automated domain testing, which was never published. Nevertheless, it may provide useful reading. The software can be fetched from ftp.uu.net:/networking/ip/dns/doc.2.0.tar.Z. 2.5 DDT DDT (Domain Debug Tools) is a package of programs to scan DNS information for error detection, developed originally by Jorge Frazao from PUUG - Portuguese UNIX Users Group and later rewritten by the author, at the time at the Faculty of Sciences of University of Lisbon. Each program is specialized in a given set of anomalies: you have a checker for authority information, another for glue data, mail exchangers, reverse-mappings and miscellaneous errors found in all kinds of resource records. As a whole, they do a rather extensive checking on DNS configurations. These tools work on cached DNS data, i.e., data stored locally after performing zone transfers (done by a slightly modified version of BIND's named-xfer, called ddt-xfer, which allows recursive transfers) from the appropriate servers, rather than querying nameservers on-line each time they run. This option was taken for several reasons [FRA92]: (1) efficiency, since it reads data from disk, avoiding network transit delays, (2) reduced network traffic, data has to be fetched only once and then run the programs over it as many times as you wish and (3) accessibility - in countries with limited Internet access, as was the case in Portugal by the time DDT was in its first stages, this may be the only practical way to use the tools. Point (2) above deserves some special considerations: first, it is not entirely true that there aren't additional queries while processing the information, one of the tools, the authority checker, queries (via dig) each domain's purported nameservers in order to test the consistency of the authority information they provide about the domain. Second, it may be argued that when the actual tests are done the information used may be out of date. While this is true, you should note that this is the DNS nature, if you obtain some piece of information you can't be sure that one second later it is still valid. Furthermore, if your source was not the primary for the domain then you can't even be sure of the validity in the exact moment you got it in the first place. But experience shows that if you see an error it is likely to be there in the next version of the domain information (and if it isn't, nothing was lost by having detected it in the past). On the other side, of course there's little point in checking one month old data... When building a cache to analyze, you should be careful in getting all the relevant data, which includes both normal domain and reverse-mapping information, or else you get lots of "no PTR record found" messages. This means that using DDT requires some prior planning, so that all the necessary data is available, since the tools don't go out looking for more information, with the exception of authority one (see above). Once again, care should be taken when doing recursive transfers in order not to generate unnecessary traffic. If a host performs nameservice for some domains DDT can use the zone files already stored locally. DDT tries to look for all kinds of errors, as known by the authors at the time of writing it. The list includes lame delegations, version number mismatches between servers (this may be a transient problem), non-existing servers, domains with only one server, unnecessary glue information, MX records pointing to hosts not in the analyzed domain (may not be an error, it's just to point possibly strange or expensive mail-routing policies), MX records pointing to aliases, A records without the respective PTR and vice-versa (may not be an error, see the paragraph above), missing trailing dots in configuration files, hostnames with no data (A or CNAME records) associated, aliases pointing to aliases, and some more. Given the specialized nature of each tool, it is possible to look for a well defined set of errors, instead of having the data analyzed in all possible ways. Within the package comes a set of small programs that perform several kinds of statistics on the cached data. Among these you have hosts per domain, nets per domain, aliases in a domain, most popular names, etc. Except for ddt-xfer, all the programs are written in Perl. A new release may come into existence in a near future, after a thorough review of the methods used, the set of errors checked for and some bug fixing, of course. In the mean time, the latest version is available from ns.dns.pt:/pub/dns/ddt-2.0.tar.gz. 2.6 THE CHECKER PROJECT The problem of the huge amount of DNS traffic over the Internet is getting researchers close attention for quite some time, mainly because most of it is unnecessary. Observations have shown that DNS consumes something like twenty times more bandwith than it should [DAN92a]. Some causes for this undoubtedly catastrophic scenario lie on deficient resolver and nameserver implementations spread all over the world, from personal to super-computers, running all sorts of operating systems. While the panacea is yet to be found (claims are made that the latest official version - 4.9.2 as of this writing - of BIND is a great step forward [KUM93]), work has been done in order to identify sources of anomalies, as a first approach in the search for a solution. The Checker Project is one such effort, developed at the University of Southern California [MIL94]. It consists of a set of C code patched into BIND's nameserver named, which monitors server activity, building a database with the history of that operation (queries and responses). It is then possible to generate reports from the database summarizing activity and identifying behavioral patterns from client requests, looking for anomalies. The named code alteration is small and simple unless you want do have PEC checking enabled (see below). You may find sources and documentation at caldera.usc.edu, in directory /pub/checker. Checker only does this kind of collection and reporting, it does not try to enforce any rules on the administrators of the defective sites by any means whatsoever. Authors hope that the simple exhibition of the evidences is a reason strong enough for those administrators to have their problems corrected. An interesting feature is PEC (proactive error checking): the server pretends to be unresponsive for some queries by randomly choosing some name and start refusing replies for queries on that name during a pre-determined period. Those queries are recorded, though, to try to reason about the retry and timeout schemes used by nameservers and resolvers. It is expected that properly implemented clients will choose another nameserver to query, while defective ones will keep on trying with the same server. This feature is still being tested as it is not completely clear yet how to interpret the results. Presently Checker has been running on a secondary for the US domain for more than a year with little trouble. Authors feel confident it should run on any BSD platform (at least SunOS) without problems, and is planned to be included as part of the BIND nameserver. Checker is part of a research project lead by Peter Danzig from USC, aimed to implement probabilistic error checking mechanisms like PEC on distributed systems [DAN92b]. DNS is one such system and it was chosen as the platform for testing the validity of these techniques over the NSFnet. It is hoped to achieve enough knowledge to provide means to improve performance and reliability of distributed systems. Anomalies like undetected server failures, query loops, bad retransmission backoff algorithms, misconfigurations and ressubmission of requests after negative replies are some of the targets for these checkers to detect. 2.7 OTHERS All the tools described above are the result of sistematic work on the issue of DNS debugging, some of them included in research projects. For the sake of completeness we mention here several other programs that, though just as serious, seem to have been developed in a somewhat ad-hoc fashion, without an implicit intention of being used outside the environments where they were born. This impression is, of course, arguable, nevertheless we didn't feel the necessity of dedicating an entire section to any of them. This doesn't mean they are not valuable contributions, in some cases they may be just what you are looking for, without having to install a complete package to do some testings on your domain. We took as a reference the contrib directory in the latest BIND distribution. There you will find tools for creating your DNS configuration files and NIS maps from /etc/hosts and vice-versa or generate PTR from A records (these things may be important as a means of avoiding common typing errors and inconsistencies between those tables), syntax checkers for zone files, programs for querying and monitoring nameservers, all the short programs presented in [ALB93], and more. It is worth spending some time looking at them, maybe you'll find that program you were planning to write yourself. BIND can be found at gatekeeper.dec.com, in the directory /pub/misc/vixie (the file 4.9.2-940221.tar.gz has the latest public version). You may also want to consider using a version control system (e.g. SCCS or RCS) to maitain your configuration files consistent through updates, or use tools like M4 macros to generate those files. As stated above, it's important to avoid human-generated errors, creating problems that are difficult to track down, since they're often hidden behind some mistyped name. Errors like this may end up in many queries for a non-existing name, just to mention the less serious kind. See [BEE93] for a description of the most common errors made while configuring domains. 3 WHY LOOK AFTER DNS? We have presented several pieces of software to help people administer and debug their name services. They exhibit many differences in their way of doing things, scope and requirements and it may be difficult just to choose one of them to work with. For one thing, pleople's expectations from these tools vary according to their kind of envolvement with DNS. If you are responsible for a big domain, e.g. a top-level one or a big institution's with many hosts and sub-domains, you probably want to see how well is the tree below your node organized, since the consequences of errors tend to propagate upwards, thus affecting your own domain. For that you need some program that recursively descends the domain tree and analizes each domain per se and the interdependencies between them all. You will have to consider how deep you want your analysis to be, the effects it will have on the network infrastructure, i.e. will it generate traffic only inside a campus network, no matter how big it is, or will it be spread over, say, a whole country (of course, your kind of connectivity plays an important role here). You may simply want to perform some sanity checks on your own domain, without any further concerns. Or you may want to participate in some kind of global effort to monitor name server traffic, either for research purposes or just to point out the "trouble-queries" that flow around. Whatever your interest may be, you can almost surely find a tool to suit it. Eliminating problems like those described in this document is a major contribution for the efficiency of an important piece of the Internet mechanism. Just to have an idea of this importance, think of all the applications that depend on it, not just to get addresses out of names. Many systems rely on DNS to store, retrieve and spread the information they need: Internet electronic mail was already mentioned (see [PAR86] for details) and work is in progress to integrate, for example, X.400 operations with DNS; others include "remote printing" services [MAL93], distributed file systems [BIR93] and network routing purposes, among others. These features may be accomplished by some standard, well-known resource records [ROS93], or by new, experimental ones [EVE90], [MAN93]. Even if some of them won't succeed, one may well expect some more load on the DNS burden. The ubiquitous DNS thus deserves a great deal of attention, perhaps much more than it generally has. One may say that it is a victim of its own success: if a user triggers an excessive amount of queries only to have one request satisfied, he won't worry about it (in fact, he won't notice it), won't complain to his system administrator, and things will just go on like this. Of course, DNS was designed to resist and provide its services despite all these anomalies. But, by doing so it is frequently forgotten, as long as people can telnet or ftp. As DNS will be given new responsabilities, as pointed in the above paragraph, the problems described in this text will grow more serious and new ones may appear (notably security ones [GAV93]), if nothing is done to purge them. We hope to have gain people's attention to this subject, so that the Net can benefit from a healthy, properly administered and used Domain Name System. REFERENCES [ALB92] Albitz, P. and C. Liu. DNS and BIND. O'Reilly and Associates Inc., Oct. 1992 [BEE92] Beecher, B. Dealing With Lame Delegations. Univ. Michigan, LISA VI, Oct. 1992 [BEE93] Beertema, P. Common DNS Data File Configuration Errors. CWI, RFC 1537, Oct. 1993 [BIR93] Birrel, A. D., A. Hisgen, C. Jerian, T. Mann and G. Swart. The Echo Distributed File System. SRC Research Report 111, Digital Equipment Corporation, Sep. 1993 [DAN92a] Danzig, P. Probabilistic Error Checkers: Fixing DNS. Univ. Southern California, Technical Report, Feb. 1992 [DAN92b] Danzig, P., K. Obraczka and A. Kumar. An Analisys of Wide-Area Name Server Traffic. Univ. Southern California, TR 92-504, 1992 [EVE90] Everhart, C., L. Mamakos, R. Ullmann and P. Mockapetris (Ed.). New DNS RR Definitions. Transarc, Univ. Maryland, Prime Computer, Information Sciences Institute, RFC 1183, Oct. 1990 [FRA92] Frazao, J. and J. L. Martins. Ddt - Domain Debug Tools, A Package to Debug the DNS Tree. Dept. Informatica da Fac. Ciencias Univ. Lisboa, DI-FCUL-1992-04, Jan. 1992 [GAV93] Gavron, E. A Security Problem and Proposed Correction With Widely Deployed DNS Software. ACES Research Inc., RFC 1535, Oct 1993 [KUM93] Kumar, A., J. Postel, C. Neuman, P. Danzig and S. Miller. Common DNS Implementation Errors and Suggested Fixes. Information Sciences Institute, Univ. Southern California, RFC 1536, Oct 1993 [MAL93] Malamud, C., M. Rose. Principles of Operation for the TPC.INT Subdomain: General Principles and Policy. Internet Multicasting Service, Dover Beach Consulting Inc., RFC 1530, Oct. 1993 [MAN92] Manning, B. DNS NSAP RRs. Rice University, RFC 1348, Jul. 1992 [MIL94] Miller, S. and P. Danzig. The Checker Project, Installation and Operator's Manual. Univ. Southern California, TR CS94-560, 1994 [PAR86] Partridge, C. Mail Routing and the Domain System. CSNET CIC BBN Laboratories Inc, RFC 974, Jan. 1986 [ROS93] Rosenbaum, R. Using the Domain Name System to Store Arbitrary String Attributes. Digital Equipment Corporation, RFC 1464, May 1993 From Francis.Dupont at inria.fr Wed May 11 14:55:17 1994 From: Francis.Dupont at inria.fr (Francis Dupont) Date: Wed, 11 May 1994 14:55:17 +0200 Subject: DNS WG at the 18th RIPE meeting Message-ID: <199405111255.OAA04566@givry.inria.fr> Here is the final draft agenda for the DNS WG meeting : First we have open actions: - prepare workplan and charter for the group - review the Domain object for RIPE DB and some "follow-up" items: - BIND software news - DNS security last I propose to discuss the "Taking Care of Your Domain" document from Arthur Romao. I believe we need 1.5 hour Thanks Francis.Dupont at inria.fr PS: I'll send domain object proposal and BIND news to the dns-wg list. PS (to NCC staff): can you prepare paper copies of Arthur Romao's paper ? From Francis.Dupont at inria.fr Fri May 13 16:27:50 1994 From: Francis.Dupont at inria.fr (Francis Dupont) Date: Fri, 13 May 1994 16:27:50 +0200 Subject: BIND status Message-ID: <199405131427.QAA06409@givry.inria.fr> Here is the current BIND software status with IPng support. Francis.Dupont at inria.fr The last experimental release is BIND 4.9.3 alpha4 (join the mailing list bind-workers at vix.com if you want to use/debug it). The last official release is BIND 4.9.2 and final distrib can be found in gatekeeper.dec.com:[~ftp/]pub/misc/vixie/4.9.2-940221.tar.{Z,gz} and on several anonymous FTP servers. Known problems are negative caching and validating then switch OFF the options NCACHE and VALIDATE. Another problem is resolver library security with SunOS, use the SUNSECURITY switch. SIPP support has been done by Susan Thomson and can be found in thumper.bellcore.com:[~ftp/]pub/pip/code/dns/feb94.tar.Z NSAP support has been done by Paul Traina and can be found in ftp.cisco.com:[~ftp/]bind/4.9.2-beta5-nsap-diffs NSAP support for nslookup (i.e. easy way to find PTR for NSAP addresses) has been done by Richard Colella and is in osi.ncsl.nist.gov:[~ftp/]pub/ncsa_tuba/nslook_rev_nsap.tar (note: the reverse map root is nsap.int) From Francis.Dupont at inria.fr Fri May 13 16:43:35 1994 From: Francis.Dupont at inria.fr (Francis Dupont) Date: Fri, 13 May 1994 16:43:35 +0200 Subject: RIPE DB domain object Message-ID: <199405131443.QAA06435@givry.inria.fr> Here are proposals about the RIPE DB domain object definition Francis.Dupont at inria.fr Some mandatory entries should become optional (i.e. can be missing): - zone-c (zone contact(s)) when the domain is not a zone (technically: it has no SOA RR), for instance MX only domains have no zone contacts. - nserver (name servers) is in the same case - sub-dom (sub domain(s)) when there is no sub domains Some important entries should be redefined: - nserver (name servers): the new syntax should be: (*) name [ (address)+ ] with a star for unpublished (secondary) name servers, fully qualified domain name of the name server and the list of the IP addresses of the name server. We have to write a detailed description of this, for instance what are the mandatory fields, what are unpublished ns, ... - sub-dom (sub domains): this entry should be either not present or not empty. Domain names should be fully qualified (change). New entries like the "notify" entry must be added (it is in the scope of of RIPE DB WG but we have to produce an up to date document about domain object) From Piet.Beertema at cwi.nl Mon May 16 12:02:49 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Mon, 16 May 1994 12:02:49 +0200 Subject: RIPE DB domain object In-Reply-To: "Your message of Fri, 13 May 1994 16:43:35 +0200 " <199405131443.QAA06435@givry.inria.fr> Message-ID: <9405161002.AA28439=piet@zeus.cwi.nl> Some mandatory entries should become optional (i.e. can be missing): - zone-c (zone contact(s)) when the domain is not a zone (technically: it has no SOA RR), for instance MX only domains have no zone contacts. At last... Good! Some important entries should be redefined: - nserver (name servers): the new syntax should be: (*) name [ (address)+ ] with a star for unpublished (secondary) name servers, What's the use of that??? Do you really see a domain registrar chasing each and every subdomain in search for unpublished nameservers? The term "unpublished" is already a clear indication that it shouldn't be listed.... fully qualified domain name of the name server and the list of the IP addresses of the name server. Either one should do, so it should be name|address Piet From pk at TechFak.Uni-Bielefeld.DE Mon May 16 21:12:00 1994 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Mon, 16 May 1994 21:12:00 +0200 Subject: RIPE DB domain object In-Reply-To: Your message of "Fri, 13 May 1994 16:43:35 +0200." <199405131443.QAA06435@givry.inria.fr> Message-ID: <9405161912.AA09070@lupine.techfak.uni-bielefeld.de> > Some important entries should be redefined: > - nserver (name servers): the new syntax should be: > (*) name [ (address)+ ] > with a star for unpublished (secondary) name servers, Why restrict this to secondary servers ? While it might really become a problem to hold this list up-to-date, it is more important to have information about a probably hidden (or "unpublished") primary server in the database. > fully qualified domain name of the name server and > the list of the IP addresses of the name server. To avoid any duplication of information inside the db, this should probably be done with DNS glue logic in mind: Specify the IP address(es) iff the server resides inside the described domain. Having just the addresses does not seem very readable to me, so the server name should be mandatory. Further it might improve readability if we allow just one item per *nserver: field. Any changes here imply changes to the *rev-srv: field in the network object. > - sub-dom (sub domains): this entry should be either not present > or not empty. Domain names should be fully qualified (change). How can I then interpret the list of "domains" shown by the sub-dom fields ? Does it have to be a complete list of subdomains, if not empty ? How is completeness determined in this case ? To become concrete: If I have a DNS object (2nd level domain in this case), e.g. for Uni-Bielefeld.DE, which "subdomains" are to be listed in the sub-dom field ? We have two delegated zones (==subdomains), some not-leaf subdomains (department domains administered within the Uni-Bielefeld.DE zone) and their subdomains (in fact, these are mostly the hosts) and even some leaf domains (mostly hostnames, but also departmental "mail catchers") directly under Uni-Bielefeld.DE . Hostnames are surely not all candidates for the sub-dom (?), whereas the delegated subzones are. What about the rest ? I suggest to list a domain in the sub-dom field iff there is another domain object describing this domain. -Peter From Piet.Beertema at cwi.nl Tue May 17 10:14:44 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Tue, 17 May 1994 10:14:44 +0200 Subject: RIPE DB domain object In-Reply-To: "Your message of Mon, 16 May 1994 21:12:00 +0200 " <9405161912.AA09070@lupine.techfak.uni-bielefeld.de> Message-ID: <9405170814.AA27886=piet@charon.cwi.nl> Having just the addresses does not seem very readable to me, so the server name should be mandatory. Pray tell, why should "foo.bar" be more `readable' 1.2.3.4??? I would even go further: nameserver information in the domain object is utterly useless and only clogging the database; the nameserver information belongs in the nameserver, not in the database: then it's only duplication of information that's not serving any real purpose. So drop the n-server entries! Piet From pk at TechFak.Uni-Bielefeld.DE Tue May 17 19:46:31 1994 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Tue, 17 May 1994 19:46:31 +0200 Subject: RIPE DB domain object In-Reply-To: Your message of "Tue, 17 May 1994 10:14:44 +0200." <9405170814.AA27886=piet@charon.cwi.nl> Message-ID: <9405171746.AA10634@lupine.techfak.uni-bielefeld.de> > Pray tell, why should "foo.bar" be more `readable' 1.2.3.4??? With a human reader in mind I preferred domain names over IP addresses. This is also a nearer to DNS (I know, I know), you do specify hosts there as servers, not (sets of) IP# . > I would even go further: nameserver information in the domain > object is utterly useless and only clogging the database; the ~~~~~~~ We have not yet heard about the idea of publishing unpublished secondaries this way and as I pointed out already it is useful to be able to announce "hidden" primaries. It is also useful to be able to find out the primary server (it is the first in the list), even if it is not "hidden". With proper DNS setup this information should be coded into the SOA RR, but experience shows that this is done wrong often. (OK, I wonder how and why the correct information shall find its way into the DB.) > nameserver information belongs in the nameserver, not in the > database: then it's only duplication of information that's not > serving any real purpose. So drop the n-server entries! This should hold for more fields - the dom-net is available in the DNS by RFC1101 style coding, zone-c is coded into the SOA and admin-c and tech-c can then be announced via RP records. Anything left for the domain object ? -Peter From nipper at xlink.net Thu May 19 14:33:04 1994 From: nipper at xlink.net (Arnold Nipper) Date: Thu, 19 May 1994 14:33:04 +0200 (MET DST) Subject: Root Nameserver Message-ID: <"xlink100.x.144:19.04.94.12.33.07"@xlink.net> Does anybody know the correct set of . NS? Since kava.... disappeared a new one (ns1.isi.edu) popped up. Regards, Arnold ; <<>> DiG 2.0 <<>> . ns @c.nyser.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd ra; Ques: 1, Ans: 8, Auth: 0, Addit: 10 ;; QUESTIONS: ;; ., type = NS, class = IN ;; ANSWERS: . 518400 NS NS.INTERNIC.NET. . 518400 NS AOS.ARL.ARMY.MIL. . 518400 NS NS1.ISI.EDU. . 518400 NS C.NYSER.NET. . 518400 NS TERP.UMD.EDU. . 518400 NS NS.NASA.GOV. . 518400 NS NIC.NORDU.NET. . 518400 NS NS.NIC.DDN.MIL. ;; ADDITIONAL RECORDS: NS.INTERNIC.NET. 518400 A 198.41.0.4 AOS.ARL.ARMY.MIL. 518400 A 128.63.4.82 AOS.ARL.ARMY.MIL. 518400 A 192.5.25.82 NS1.ISI.EDU. 518400 A 128.9.0.107 C.NYSER.NET. 518400 A 192.33.4.12 TERP.UMD.EDU. 518400 A 128.8.10.90 NS.NASA.GOV. 518400 A 128.102.16.10 NS.NASA.GOV. 518400 A 192.52.195.10 NIC.NORDU.NET. 518400 A 192.36.148.17 NS.NIC.DDN.MIL. 518400 A 192.112.36.4 ;; Total query time: 3072 msec ;; FROM: xlink103 to SERVER: c.nyser.net 192.33.4.12 ;; WHEN: Thu May 19 14:28:43 1994 ;; MSG SIZE sent: 17 rcvd: 393 From Piet.Beertema at cwi.nl Thu May 19 14:37:41 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Thu, 19 May 1994 14:37:41 +0200 Subject: Root Nameserver In-Reply-To: "Your message of Thu, 19 May 1994 14:33:04 +0200 (MET DST) " <"xlink100.x.144:19.04.94.12.33.07"@xlink.net> Message-ID: <9405191237.AA06569=piet@kraai.cwi.nl> Does anybody know the correct set of . NS? Since kava.... disappeared a new one (ns1.isi.edu) popped up. Included in the announcement of the disappearance of kava was a note that ISI would provide another root server. So I would expect some formal announcement of which machine is that new root server instead of Networking Land having to discover it by looking at log files... Piet From Marten.Terpstra at ripe.net Thu May 19 14:39:05 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 19 May 1994 14:39:05 +0200 Subject: Root Nameserver In-Reply-To: Your message of Thu, 19 May 1994 14:33:04 MDT. <"xlink100.x.144:19.04.94.12.33.07"@xlink.net> Message-ID: <9405191239.AA02976@rijp.ripe.net> Arnold Nipper writes * Does anybody know the correct set of . NS? Since kava.... disappeared a new * one (ns1.isi.edu) popped up. * * Regards, Arnold rs.internic.net:domain/named.root says: ; ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . " ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher at RS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; file named.root ; ; last update: May 11, 1994 ; related version of root zone: 940516 ; . 99999999 IN NS NS.INTERNIC.NET. NS.INTERNIC.NET. 99999999 A 198.41.0.4 . 99999999 NS NS1.ISI.EDU. NS1.ISI.EDU. 99999999 A 128.9.0.107 . 99999999 NS C.NYSER.NET. C.NYSER.NET. 99999999 A 192.33.4.12 . 99999999 NS TERP.UMD.EDU. TERP.UMD.EDU. 99999999 A 128.8.10.90 . 99999999 NS NS.NASA.GOV. NS.NASA.GOV. 99999999 A 128.102.16.10 99999999 A 192.52.195.10 . 99999999 NS NS.NIC.DDN.MIL. NS.NIC.DDN.MIL. 99999999 A 192.112.36.4 . 99999999 NS AOS.ARL.ARMY.MIL. AOS.ARL.ARMY.MIL. 99999999 A 128.63.4.82 99999999 A 192.5.25.82 . 99999999 NS NIC.NORDU.NET. NIC.NORDU.NET. 99999999 A 192.36.148.17 ; End of File -Marten From erik-jan.bos at SURFnet.nl Thu May 19 15:09:19 1994 From: erik-jan.bos at SURFnet.nl (Erik-Jan Bos) Date: Thu, 19 May 1994 15:09:19 +0200 Subject: Root Nameserver In-Reply-To: Your message of Thu, 19 May 1994 14:39:05 +0200. Message-ID: <"survis.sur.935:19.04.94.13.09.37"@surfnet.nl> Marten, > rs.internic.net:domain/named.root says: > > ; > ; This file holds the information on root name servers needed to > ; initialize cache of Internet domain name servers > ; (e.g. reference this file in the "cache . " > ; configuration file of BIND domain name servers). > ; > ; This file is made available by InterNIC registration services > ; under anonymous FTP as > ; file /domain/named.root > ; on server FTP.RS.INTERNIC.NET > ; -OR- under Gopher at RS.INTERNIC.NET > ; under menu InterNIC Registration Services (NSI) > ; submenu InterNIC Registration Archives > ; file named.root > ; > ; last update: May 11, 1994 > ; related version of root zone: 940516 > ; > . 99999999 IN NS NS.INTERNIC.NET. > NS.INTERNIC.NET. 99999999 A 198.41.0.4 > . 99999999 NS NS1.ISI.EDU. > NS1.ISI.EDU. 99999999 A 128.9.0.107 > . 99999999 NS C.NYSER.NET. > C.NYSER.NET. 99999999 A 192.33.4.12 > . 99999999 NS TERP.UMD.EDU. > TERP.UMD.EDU. 99999999 A 128.8.10.90 > . 99999999 NS NS.NASA.GOV. > NS.NASA.GOV. 99999999 A 128.102.16.10 > 99999999 A 192.52.195.10 > . 99999999 NS NS.NIC.DDN.MIL. > NS.NIC.DDN.MIL. 99999999 A 192.112.36.4 > . 99999999 NS AOS.ARL.ARMY.MIL. > AOS.ARL.ARMY.MIL. 99999999 A 128.63.4.82 > 99999999 A 192.5.25.82 > . 99999999 NS NIC.NORDU.NET. > NIC.NORDU.NET. 99999999 A 192.36.148.17 > ; End of File Most true, and since I am mirroring this file and have a notifier running the appearance of this new file was sent to me. I, however, never saw a announcement of this. I do not expect that the whole world needs to mirror this file... __ Erik-Jan. From Marten.Terpstra at ripe.net Thu May 19 15:11:48 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 19 May 1994 15:11:48 +0200 Subject: Root Nameserver In-Reply-To: Your message of Thu, 19 May 1994 15:09:19 MDT. <"survis.sur.935:19.04.94.13.09.37"@surfnet.nl> Message-ID: <9405191311.AA03025@rijp.ripe.net> Erik-Jan Bos writes * Marten, * Most true, and since I am mirroring this file and have a notifier running * the appearance of this new file was sent to me. I, however, never saw a * announcement of this. I do not expect that the whole world needs to * mirror this file... Would it be useful if the NCC mirrored this file in dns/tools ? -Marten From Piet.Beertema at cwi.nl Thu May 19 15:17:35 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Thu, 19 May 1994 15:17:35 +0200 Subject: Root Nameserver In-Reply-To: "Your message of Thu, 19 May 1994 15:09:19 +0200 " <"survis.sur.935:19.04.94.13.09.37"@surfnet.nl> Message-ID: <9405191317.AA06770=piet@kraai.cwi.nl> I do not expect that the whole world needs to mirror this file... I would hope so... ;-) Piet From Piet.Beertema at cwi.nl Thu May 19 15:19:49 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Thu, 19 May 1994 15:19:49 +0200 Subject: Root Nameserver In-Reply-To: "Your message of Thu, 19 May 1994 15:11:48 +0200 " <9405191311.AA03025@rijp.ripe.net> Message-ID: <9405191319.AA06794=piet@kraai.cwi.nl> Would it be useful if the NCC mirrored this file in dns/tools ? It might be useful. But that's not the point: if a formal announcement of the withdrawal of a root nameserver can be sent widely, then I would expect a formal announcement of an addition/replacement to be sent equally widely. Piet From Marten.Terpstra at ripe.net Thu May 19 15:23:49 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 19 May 1994 15:23:49 +0200 Subject: Root Nameserver In-Reply-To: Your message of Thu, 19 May 1994 15:19:49 MDT. <9405191319.AA06794=piet@kraai.cwi.nl> Message-ID: <9405191323.AA03107@rijp.ripe.net> Piet Beertema writes * Would it be useful if the NCC mirrored this file in dns/tools ? * It might be useful. But that's not the point: if a formal * announcement of the withdrawal of a root nameserver can * be sent widely, then I would expect a formal announcement * of an addition/replacement to be sent equally widely. Some people at InterNIC are on this mailing list, so I hope they have understood your concern and will respond accordingly. -Marten From markk at internic.net Thu May 19 17:06:20 1994 From: markk at internic.net (Mark Kosters) Date: Thu, 19 May 1994 11:06:20 -0400 (EDT) Subject: Root Nameserver In-Reply-To: <9405191323.AA03107@rijp.ripe.net> from "Marten Terpstra" at May 19, 94 03:23:49 pm Message-ID: <199405191506.LAA11067@slam.internic.net> Understand your concern. Although it was inplied in the message that ISI would be replacing KAVA. A message will be sent from the domreg registrar shortly on the change to namedroppers. Mark > > > Piet Beertema writes > * Would it be useful if the NCC mirrored this file in dns/tools ? > * It might be useful. But that's not the point: if a formal > * announcement of the withdrawal of a root nameserver can > * be sent widely, then I would expect a formal announcement > * of an addition/replacement to be sent equally widely. > > Some people at InterNIC are on this mailing list, so I hope they have > understood your concern and will respond accordingly. > > -Marten > > From huber at chx400.switch.ch Fri May 20 10:05:11 1994 From: huber at chx400.switch.ch (Willi Huber) Date: Fri, 20 May 1994 10:05:11 +0200 (MET DST) Subject: register esa.ch ? Message-ID: <9405200805.AA05542@ncc.ripe.net> Dear colleagues, I have got a request from the company "Einkaufsgenossenschaft des Schweizer- ischen Autogewerbeverbands" to register the domain esa.ch. ESA is the registered name of this company that appears also on their letters. I have called their attention to the fact, that esa stands for European Space Agency in different European countries (e.g. esa.de, esa.es, esa.nl ) and that therfore it is not wise to register esa.ch for something completely different. But they insist on this name. Would you register it? Regards, Willi Huber From Daniel.Karrenberg at ripe.net Fri May 20 10:10:41 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 20 May 1994 10:10:41 +0200 Subject: register esa.ch ? In-Reply-To: Your message of Fri, 20 May 1994 10:05:11 MDT. <9405200805.AA05542@ncc.ripe.net> Message-ID: <9405200810.AA02346@reif.ripe.net> > Willi Huber writes: > > But they insist on this name. Would you register it? If it is indeed their "local name" and they have been warned about the conflict I see no reason why not. Daniel From nipper at xlink.net Fri May 20 10:17:36 1994 From: nipper at xlink.net (Arnold Nipper) Date: Fri, 20 May 1994 10:17:36 +0200 (MET DST) Subject: register esa.ch ? In-Reply-To: <9405200805.AA05542@ncc.ripe.net> from "Willi Huber" at May 20, 94 10:05:11 am Message-ID: <"xlink100.x.605:20.04.94.08.17.38"@xlink.net> Willi Huber wrote: > > Dear colleagues, > > I have got a request from the company "Einkaufsgenossenschaft des Schweizer- > ischen Autogewerbeverbands" to register the domain esa.ch. ESA is the registered > name of this company that appears also on their letters. > > I have called their attention to the fact, that esa stands for European Space > Agency in different European countries (e.g. esa.de, esa.es, esa.nl ) and that > therfore it is not wise to register esa.ch for something completely different. > > But they insist on this name. Would you register it? > First come, first serve, if they do not violate any trademarks, ... > Regards, > > Willi Huber -- Arnold Nipper / email: nipper at xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich XLINK /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany From Piet.Beertema at cwi.nl Fri May 20 10:27:57 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 20 May 1994 10:27:57 +0200 Subject: register esa.ch ? In-Reply-To: "Your message of Fri, 20 May 1994 10:05:11 +0200 (MET DST) " <9405200805.AA05542@ncc.ripe.net> Message-ID: <9405200827.AA08556=piet@kraai.cwi.nl> I have got a request from the company "Einkaufsgenossenschaft des Schweizerischen Autogewerbeverbands" to register the domain esa.ch. ESA is the registered name of this company that appears also on their letters. I have called their attention to the fact, that esa stands for European Space Agency in different European countries (e.g. esa.de, esa.es, esa.nl) and that therfore it is not wise to register esa.ch for something completely different. But they insist on this name. Would you register it? In cases like this I would give international context precedence over national context. I would first contact the European Space Agency to see if they have any plans to register esa.ch in the (near) future. If they do, I would give them the "first option" on that domain, but at the same time I would ask them to register it immediately. Piet From Dave.Morton at ecrc.de Fri May 20 10:59:03 1994 From: Dave.Morton at ecrc.de (Dave Morton) Date: Fri, 20 May 94 10:59:03 +0200 Subject: register esa.ch ? Message-ID: <9405200859.AA10358@acrab25.ecrc> > > Willi Huber writes: > > > > But they insist on this name. Would you register it? > >If it is indeed their "local name" and they have been warned about the >conflict I see no reason why not. Daniel - under that argument you wouldn't object either to someone registering RIPE.DE or NL or whatever ? >Daniel I think Piet's approch is the best. Dave From Daniel.Karrenberg at ripe.net Fri May 20 11:02:01 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 20 May 1994 11:02:01 +0200 Subject: register esa.ch ? In-Reply-To: Your message of Fri, 20 May 1994 10:27:57 MDT. <9405200827.AA08556=piet@kraai.cwi.nl> Message-ID: <9405200902.AA02436@reif.ripe.net> > Piet Beertema writes: > In cases like this I would give international context precedence > over national context. > I would first contact the European Space Agency to see if they > have any plans to register esa.ch in the (near) future. If they > do, I would give them the "first option" on that domain, but at > the same time I would ask them to register it immediately. Piet, this is a significant departure from FCFS which should not be done lightly. It establishes a precedent to poll all multi-nationals before registering locally. Daniel From Daniel.Karrenberg at ripe.net Fri May 20 11:06:06 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 20 May 1994 11:06:06 +0200 Subject: register esa.ch ? In-Reply-To: Your message of Fri, 20 May 1994 10:59:03 MDT. <9405200859.AA10358@acrab25.ecrc> Message-ID: <9405200906.AA02449@reif.ripe.net> > Dave Morton writes: > > Daniel - under that argument you wouldn't object either to someone > registering RIPE.DE or NL or whatever ? I would not object to that given that they have been warned strongly about all the requests for address space and what-have-you they will receive and will have to forward. Or shall we register ripe.? Some TLD registrars would ask us for proof that we are a legal entity in the country concerned. Daniel From Piet.Beertema at cwi.nl Fri May 20 11:20:58 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 20 May 1994 11:20:58 +0200 Subject: register esa.ch ? In-Reply-To: "Your message of Fri, 20 May 1994 11:02:01 +0200 " <9405200902.AA02436@reif.ripe.net> Message-ID: <9405200920.AA13451=piet@kwek.cwi.nl> > Piet Beertema writes: > In cases like this I would give international context precedence > over national context. > I would first contact the European Space Agency to see if they > have any plans to register esa.ch in the (near) future. If they > do, I would give them the "first option" on that domain, but at > the same time I would ask them to register it immediately. Piet, this is a significant departure from FCFS which should not be done lightly. It establishes a precedent to poll all multi-nationals before registering locally. Daniel Act locally, think globally! Piet From erik-jan.bos at SURFnet.nl Fri May 20 11:31:11 1994 From: erik-jan.bos at SURFnet.nl (Erik-Jan Bos) Date: Fri, 20 May 1994 11:31:11 +0200 Subject: register esa.ch ? In-Reply-To: Your message of Fri, 20 May 1994 10:27:57 +0200. Message-ID: <"survis.sur.414:20.04.94.09.31.14"@surfnet.nl> Piet, > I have got a request from the company "Einkaufsgenossenschaft > des Schweizerischen Autogewerbeverbands" to register the domain > esa.ch. ESA is the registered name of this company that appears > also on their letters. > I have called their attention to the fact, that esa stands for > European Space Agency in different European countries (e.g. esa.de, > esa.es, esa.nl) and that therfore it is not wise to register esa.ch > for something completely different. > But they insist on this name. Would you register it? > In cases like this I would give international context precedence > over national context. > I would first contact the European Space Agency to see if they > have any plans to register esa.ch in the (near) future. If they > do, I would give them the "first option" on that domain, but at > the same time I would ask them to register it immediately. This will remain a can of worms, always. Some time ago the "Instituut voor Nederlandse Geschiedenis" (Institute for Dutch History) registered "ing.nl". However, two Dutch banks merged (aroud the same) and became "Internationale Nederlanden Groep"... If you ask somebody in The Netherlands where ING stands for, 99 to 100 he'll say "Internationale Nederlanden Groep". __ Erik-Jan. From Piet.Beertema at cwi.nl Fri May 20 11:36:34 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 20 May 1994 11:36:34 +0200 Subject: register esa.ch ? Message-ID: <9405200936.AA08847=piet@kraai.cwi.nl> this is a significant departure from FCFS which should not be done lightly. It establishes a precedent to poll all multi-nationals before registering locally. Please note that I'm *not* saying nor implying that this should be done lightly. And I think such cases will hardly show up: lots of commercial multi-nationals are registered in the various countries, so chances are minimal that some other company will be "entitled" to "their" domain name. For other organisations the situation is different; ESA is a clear example of this. And what if somebody would want to register cern.nl? I probably would think twice and contact CERN about it. Also note that these "name clashes" don't occur only on an international scale: on a national scale they occur as well. Under .NL I've had at least one such case. But that doesn't mean I'm going to "poll" or search for all organisations that I might suspect to have a "right" on a name. In other words: it's the exceptions that confirm the rule; in the case of esa.ch I see such an exception. Piet From Piet.Beertema at cwi.nl Fri May 20 11:43:46 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 20 May 1994 11:43:46 +0200 Subject: register esa.ch ? In-Reply-To: "Your message of Fri, 20 May 1994 11:31:11 +0200 " <"survis.sur.414:20.04.94.09.31.14"@surfnet.nl> Message-ID: <9405200943.AA08872=piet@kraai.cwi.nl> This will remain a can of worms, always. True. Some time ago the "Instituut voor Nederlandse Geschiedenis" (Institute for Dutch History) registered "ing.nl". However, two Dutch banks merged (aroud the same) and became "Internationale Nederlanden Groep"... If you ask somebody in The Netherlands where ING stands for, 99 to 100 he'll say "Internationale Nederlanden Groep". To stay closer to "home": in Amsterdam there is an institute "Centrum voor Wiskunde en Informatica" (Centre for Mathematics and Computer Science), where I happen to work. ;-) It's name is abbreviated to and commonly known as CWI. But there is also an institute "Clara Wichmann Institute", which "in its circles" is known as CWI. They haven't tried to register cwi.nl yet. ;-) But if you ask just somebody in The Netherlands what CWI stands for, there's a fair chance (s)he won't know... :-) Piet From WDILLEN%ESOC.BITNET at vm.gmd.de Fri May 20 19:22:17 1994 From: WDILLEN%ESOC.BITNET at vm.gmd.de (Walter Dillen - ESAnet Services Section (ECNOD/COM/ES)) Date: Fri, 20 May 94 12:22:17 EST Subject: register esa.ch Message-ID: <9405201022.AA06731@ncc.ripe.net> - To all you gentlemen who have contributed to the discussion so far - As ESA-internal coordinator of domains and naming structure, I am obviously not too pleased to see another organisation use the same acronym, but I don't believe that this necessarily causes major problems. This is because of the following. In addition to adopting the registration policy recommended to us by RIPE, namely to register in each country esa., we have established a further convention. Underneath the esa., the name of the ESA establishment is added as a further subdomain in all cases, e.g. estec.esa.nl esoc.esa.de esrin.esa.it, etc. This implies that chances of a clash in domain names are *very* small. Furthermore, ESA has currently no establishments in CH and therefore no intention to register esa.ch. For the hypothetical case where this would happen, the question remains for me if and how the responsibility for a 2nd-level subdomain can be shared and coordinated between two organisations? Btw, I also know about another potential conflict coming up - I've heard of plans within Germany to align 2nd-level domain names with the regional abbreviations known to all from German car plates - e.g. K for Cologne, DA for Darmstadt, etc. Assuming that we as international organisation could stay out of this scheme and retain esa.de, this would cause a clash with the region of Eisenach (also ESA), and the same considerations as above would apply. Comments/Suggestions welcome! Regards, Walter ------------------------------------------------------------------ European Space Agency/Operations Centre Tel: +49-6151-90-2213 Robert Bosch Strasse 5 Fax: +49-6151-90-4213 D-64293 Darmstadt, Germany email: wdillen at esoc.bitnet From root at estec.esa.nl Fri May 20 14:08:57 1994 From: root at estec.esa.nl (root at estec.esa.nl) Date: Fri, 20 May 1994 13:08:57 +0100 Subject: register esa.ch ? Message-ID: <9405201208.AA12089@bcserver.estec.esa.nl> I will reply to you in 10 minutes, sorry for the delay in reading the mail, regards ... Robert Williams - European Space Agency (ESA) Keplerlaan 1, 2200 AG Noordwijk - The Netherlands Phone: +31-1719-85403 Fax: +31-1719-85095 E-Mail: INTERNET: postmaster at bcserver.estec.esa.nl From Piet.Beertema at cwi.nl Fri May 20 13:23:51 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 20 May 1994 13:23:51 +0200 Subject: register esa.ch In-Reply-To: "Your message of Fri, 20 May 94 12:22:17 EST " <9405201022.AA06731@ncc.ripe.net> Message-ID: <9405201123.AA09181=piet@kraai.cwi.nl> Underneath the esa., the name of the ESA establishment is added as a further subdomain in all cases, e.g. estec.esa.nl esoc.esa.de esrin.esa.it, etc. This implies that chances of a clash in domain names are *very* small. Whatever you do under the esa.XX domain, postmaster at esa.XX *must* be a valid address. Furthermore, ESA has currently no establishments in CH and therefore no intention to register esa.ch. That already solves the key problem in this case. For the hypothetical case where this would happen, the question remains for me if and how the responsibility for a 2nd-level subdomain can be shared and coordinated between two organisations? A domain "belongs" to one specific organisation; subdomains under it cannot "belong" to or be shared with a completely different organisation. Btw, I also know about another potential conflict coming up - I've heard of plans within Germany to align 2nd-level domain names with the regional abbreviations known to all from German car plates - e.g. K for Cologne, DA for Darmstadt, etc. Crazy idea: if company X moves from Cologne to Darmstadt, its domain name would change, they would have to reprint their letter heads, business cards, etc., and someone would have to cope with all the bounces of mails sent to the old domain name... Assuming that we as international organisation could stay out of this scheme and retain esa.de, this would cause a clash with the region of Eisenach (also ESA), and the same considerations as above would apply. Which makes it unlikely that you could stay out of such a "reorganisation" (I'd rather call it a mess-up). Comments/Suggestions welcome! Contrary to what I've suggested to you long ago, I'd now recommend that you put ESA under the .INT domain; chances are zero that there will ever be a .EU domain for Europe, unless someone can convince the Powers That Be that there is a very clear need for such a "pseudo top level domain", quite analogous to the current 3-letter TLD's; or maybe the analogy could be carried even further by creating a domain .EUR; but then, who is going to manage it? Piet From root at estec.esa.nl Fri May 20 14:36:44 1994 From: root at estec.esa.nl (root at estec.esa.nl) Date: Fri, 20 May 1994 13:36:44 +0100 Subject: register esa.ch ? Message-ID: <9405201236.AA16253@bcserver.estec.esa.nl> Hi Piet, we are discussing this at the moment with the other ESA sites, will reply soon Rob. From pk at TechFak.Uni-Bielefeld.DE Fri May 20 13:47:05 1994 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Fri, 20 May 1994 13:47:05 +0200 Subject: register esa.ch In-Reply-To: Your message of "Fri, 20 May 1994 13:23:51 +0200." <9405201123.AA09181=piet@kraai.cwi.nl> Message-ID: <9405201147.AA14735@lupine.techfak.uni-bielefeld.de> > Whatever you do under the esa.XX domain, postmaster at esa.XX > *must* be a valid address. Who tells ? Just because it's a domain name it need not be a valid (domain part of a) mail address - unless there is an MX. Have you ever tried postmaster at ac.uk ? > For the hypothetical case where this would happen, the question remains > for me if and how the responsibility for a 2nd-level subdomain can be > shared and coordinated between two organisations? > A domain "belongs" to one specific organisation; subdomains > under it cannot "belong" to or be shared with a completely > different organisation. Again, who "owns" ac.uk ? ESA.XX could be the common 2nd level domain for all organisations with acronym ESA. It's a local decision to associate 2nd level domains with organizations. > Crazy idea: if company X moves from Cologne to Darmstadt, > its domain name would change, they would have to reprint > their letter heads, business cards, etc., and someone would > have to cope with all the bounces of mails sent to the old > domain name... Totally correct. If the company moves, they will have to change their business cards, letter heads ... -Peter From Dave.Morton at ecrc.de Fri May 20 13:55:10 1994 From: Dave.Morton at ecrc.de (Dave Morton) Date: Fri, 20 May 94 13:55:10 +0200 Subject: register esa.ch ? Message-ID: <9405201155.AA10736@acrab25.ecrc> > > Dave Morton writes: > > > > Daniel - under that argument you wouldn't object either to someone > > registering RIPE.DE or NL or whatever ? > >I would not object to that given that they have been warned strongly >about all the requests for address space and what-have-you they will >receive and will have to forward. Or shall we register ripe.domains in the world>? No - of course not and as long as they have been warned - no problem - if someone is silly enough to register such... >Some TLD registrars would ask us for proof that we are a legal entity >in the country concerned. Sure - and the local registry might also face legal problems if they give away an "obvious" name to joe.smoke. The assumption is that the lcoal IR can spot the "obvious" ones - probably not always true unfortunately. Use common sense I'd guess is the only formula - assuming there is any... In this case, anyway, the problem is now solved I see. >Daniel Dave From Piet.Beertema at cwi.nl Fri May 20 13:57:38 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 20 May 1994 13:57:38 +0200 Subject: register esa.ch In-Reply-To: "Your message of Fri, 20 May 1994 13:47:05 +0200 " <9405201147.AA14735@lupine.techfak.uni-bielefeld.de> Message-ID: <9405201157.AA09264=piet@kraai.cwi.nl> Whatever you do under the esa.XX domain, postmaster at esa.XX *must* be a valid address. Who tells ? Just because it's a domain name it need not be a valid (domain part of a) mail address - unless there is an MX. At least under .NL it is a hard requirement that postmaster at domain.nl be a valid address. Have you ever tried postmaster at ac.uk ? ac.XX, co.XX, etc. are artifacts, not domains; the real domains go one level lower. Crazy idea: if company X moves from Cologne to Darmstadt, its domain name would change, they would have to reprint their letter heads, business cards, etc., and someone would have to cope with all the bounces of mails sent to the old domain name... Totally correct. If the company moves, they will have to change their business cards, letter heads ... PTT's take care of forwarding letters. Who is going to take care of forwarding e-mail? Piet From mfendt at eso.org Fri May 20 14:05:23 1994 From: mfendt at eso.org (mfendt at eso.org) Date: Fri, 20 May 94 14:05:23 +0200 Subject: register esa.ch Message-ID: <9405201205.AA09659@ws9.hq.eso.org> Hello, Piet wrote: >> Comments/Suggestions welcome! >> Contrary to what I've suggested to you long ago, I'd now >> recommend that you put ESA under the .INT domain; chances >> are zero that there will ever be a .EU domain for Europe, >> unless someone can convince the Powers That Be that there >> is a very clear need for such a "pseudo top level domain", >> quite analogous to the current 3-letter TLD's; or maybe >> the analogy could be carried even further by creating a >> domain .EUR; but then, who is going to manage it? The last two mails actually clarified the issue for me in the respect that there is a more serious problem (i.e how to register multinational organisations) and the as a part the current problem what happens to esa.ch. The esa.ch seems to be solved by the mail from Walter (if ESA doesn't want to use it and doesn't feel that it should be reservered than nobody in Switzerland has to explain a small company that you do not get it, even so you were the first) The other thing which still has to renaimed is the issue of multinational organisations. I asked once on that list about the advice (it was mentioned in the 14. Ripe meeting as the case of the day) indicating that I found the advice stupid (I still do, but not because of the ESA case now :-) and asked for clarification, reasons. I got no serious answer back, so I thought to skip that issue (and stay with .org; that's what we use now). But the advice now to change ESA to .int (even if it would be a good idea to do so) might cause some trouble and I have my serious doubts that they will do that. So it would be quite a good idea to keep that point in mind if an international organization want's to register for the first time, but changing already existing organisation will cause a lot of overhead for them (I just got new business cards :-). Maybe a better solution can be found too, but I can not recommend one off hand. Michael P.S.: .int for ESA was reject in the 14 Ripe meeting with: "workable, but ESA is not a world wide organization" :-) according to the minutes ________________________________________________________________________________ Michael Fendt ESO (European Southern Observatory) Karl-Schwarzschild-Str. 2 85748 Garching Germany Tel: +49 89 32006 441 Fax: +49 89 32023 62 email: mfendt at eso.org From gveldman at estcs1.estec.esa.nl Fri May 20 15:26:14 1994 From: gveldman at estcs1.estec.esa.nl (Gerbrand Veldman, BCS, ESA/Estec, Noordwijk, The Netherlands) Date: Fri, 20 May 1994 14:26:14 +0100 Subject: register esa.ch ? Message-ID: <9405201229.AA08385@ncc.ripe.net> I strongly advice against the use of ESA for anything else but the European Space Agency, even though we use subdomains as estec, esoc etc. It would be very impractical to share the ESA domain with another company, if not practically impossible. Besides, ESA is known internationally around the world as European Space Agency on the international networks and I do not think another company will want to be confused with that well known name. Kind regards, Gerbrand Veldman Mail: Gerbrand Veldman, ESA/Estec, P.O. Box 299, 2200 AG Noordwijk, The Netherlands. Tel: (Int) 31 1719 83113 Fax:- (Int) 31 1719 85095 E-Mail: Internet: gveldman at estcs1.estec.esa.nl HEP/SPAN: ESTCS1::GVELDMAN (29717::GVELDMAN) X.400: C=NL A=400NET P=ESA O=ESTEC S=VELDMAN From pk at TechFak.Uni-Bielefeld.DE Fri May 20 14:55:46 1994 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Fri, 20 May 1994 14:55:46 +0200 Subject: register esa.ch In-Reply-To: Your message of "Fri, 20 May 1994 13:57:38 +0200." <9405201157.AA09264=piet@kraai.cwi.nl> Message-ID: <9405201255.AA14855@lupine.techfak.uni-bielefeld.de> > Totally correct. If the company moves, they will have to > change their business cards, letter heads ... > PTT's take care of forwarding letters. Who is going > to take care of forwarding e-mail? Unless the outdated domain name is reissued immediately (not a good idea at all) it still lives and the owner is free to populate it with appropriate CNAME and/or MX records. So you yourself or your friendly service provider care about e-mail forwarding. Within "DE" there have been some cases in the past where organizations changed their domain name (for other reasons but physical relocation), and this kind of "forwarding" was used. -Peter From mfendt at eso.org Fri May 20 15:28:15 1994 From: mfendt at eso.org (mfendt at eso.org) Date: Fri, 20 May 94 15:28:15 +0200 Subject: register esa.ch Message-ID: <9405201328.AA09995@ws9.hq.eso.org> >> > Totally correct. If the company moves, they will have to >> > change their business cards, letter heads ... >> > PTT's take care of forwarding letters. Who is going >> > to take care of forwarding e-mail? >> >> Unless the outdated domain name is reissued immediately (not a good idea >> at all) it still lives and the owner is free to populate it with >> appropriate CNAME and/or MX records. So you yourself or your friendly >> service provider care about e-mail forwarding. >> >> Within "DE" there have been some cases in the past where organizations >> changed their domain name (for other reasons but physical relocation), >> and this kind of "forwarding" was used. >> >> -Peter >> A few exceptions are fine and managable, but that idea would probably leads to the fact that there are more than a few. The other issue I see is the fact that we have already problems in addressing multinational organizations in various countries. How do we address lets say companies sitting in Hamburg and Munic. Do you think they like being registered with (This is an example; nobody should be offended by that!) siemens.hh.de, siemens.m.de (or siemens.muc.de), ... I think they will go with siemens.com :_) I consider this idea as good or as bad as the advice of RIPE to register international organizations in the various countries :-) a) Is this plan actually to be considered as serious or more rumor? b) Is this mailing list the right forum to discuss it? Michael From yppawlus at cyf-kr.edu.pl Fri May 20 15:39:39 1994 From: yppawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Fri, 20 May 94 15:39:39 +0200 Subject: register esa.ch In-Reply-To: Piet Beertema's message of Fri, 20 May 1994 13:23:51 +0200 <9405201123.AA09181=piet@kraai.cwi.nl> Message-ID: <9405201339.AA00841@isc.cyf-kr.edu.pl> > > Btw, I also know about another potential conflict coming up - I've heard > of plans within Germany to align 2nd-level domain names with the regional > abbreviations known to all from German car plates - e.g. K for Cologne, > DA for Darmstadt, etc. > Crazy idea: if company X moves from Cologne to Darmstadt, > its domain name would change, they would have to reprint > their letter heads, business cards, etc., and someone would > have to cope with all the bounces of mails sent to the old > domain name... > But the change of postal address is normal in that situation so why not e-mail too? Jerzy Pawlus From VANNOZZI at NIS.GARR.IT Fri May 20 17:51:01 1994 From: VANNOZZI at NIS.GARR.IT (Daniele Vannozzi) Date: Fri, 20 May 94 17:51:01 MET Subject: Removal nameserver an rev-srv tags Message-ID: <9405201555.AA09749@ncc.ripe.net> Dear all, Blasco has informed us about the proposals and the decision taken during the last Ripe meeting. While we found all greats, we disagree about a particular proposal made at the dns working group. To be concise, we believe obsoleting the rev-srv and nameserver flags from the inetnum and domain objects to not be a meaningful action. Concerning the assumption of dns-wg about the useless of those tags and the absence of procedures based on them we would like to inform you that we are presently testing some automatic tools based exactly on those tags which we use before actually registering a new direct or inverse domain. Starting from the contained information, each server is queried on properly resolving the query. Daniele & Giuliana Daniele Vannozzi Phone: +39 50 593280 GARR-NIS Phone NIS: +39 50 593360 c/o CNUCE - Istituto del CNR Fax: +39 50 904052 Via Santa Maria 36 Telex: 500371 - CNUCE 56100 Pisa - Italy E-mail: vannozzi at nis.garr.it From jimi at dxcoms.cern.ch Fri May 20 18:03:18 1994 From: jimi at dxcoms.cern.ch (Jean-Michel Jouanigot) Date: Fri, 20 May 1994 18:03:18 +0200 (MET DST) Subject: Removal nameserver an rev-srv tags In-Reply-To: <9405201555.AA09749@ncc.ripe.net> from "Daniele Vannozzi" at May 20, 94 05:51:01 pm Message-ID: <9405201603.AA15806@dxcoms.cern.ch> >----- Text sent by Daniele Vannozzi follows ------- > Blasco has informed us about the proposals and the decision taken during > the last Ripe meeting. > While we found all greats, we disagree about a particular proposal made > at the dns working group. To be concise, we believe obsoleting the > rev-srv and nameserver flags from the inetnum and domain objects to not > be a meaningful action. > Concerning the assumption of dns-wg about the useless of those tags and > the absence of procedures based on them we would like to inform you that > we are presently testing some automatic tools based exactly on those > tags which we use before actually registering a new direct or inverse > domain. > Starting from the contained information, each server is queried on > properly resolving the query. > > Daniele & Giuliana > I also beleive these entries should be kept, at least the rev-srv one. -- Jean-Michel From artur at morgaine.fct.unl.pt Fri May 20 20:28:53 1994 From: artur at morgaine.fct.unl.pt (Artur Romao) Date: Fri, 20 May 94 18:28:53 GMT Subject: Removal nameserver an rev-srv tags Message-ID: <9405201828.AA03367@morgaine.fct.unl.pt> > Concerning the assumption of dns-wg about the useless of those tags and > the absence of procedures based on them we would like to inform you that > we are presently testing some automatic tools based exactly on those > tags which we use before actually registering a new direct or inverse > domain. > Starting from the contained information, each server is queried on > properly resolving the query. Do you mean, you first build the domain object, insert it into the database and then get a list of nameservers out of it, in order to do your querying? And only then you consider the domain configuration ok? If this is the case, why don't you get the NS list from the (soon to be) primary nameserver, and if all is ok then you register the domain itself and the domain object in the database? Or did I miss something? We do this before registering a domain under PT... .artur From woeber at cc.univie.ac.at Fri May 20 19:09:48 1994 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 20 May 1994 18:09:48 +0100 Subject: Removal nameserver an rev-srv tags Message-ID: <0097EB93.E2F90700.4707@cc.univie.ac.at> Dear all, >Blasco has informed us about the proposals and the decision taken during >the last Ripe meeting. >While we found all greats, we disagree about a particular proposal made >at the dns working group. To be concise, we believe obsoleting the I don't want to assess the technical merits of any decisions taken at the DNS-WG, however I'm worried about the organizational merits of any decisions that were taken in WG meetings that had to compete against the Routing-WG and the RIPE-81++ discussions. I for my part did certainly not feel having quorum in the DB-WG, and thus no decisions were taken this time. I'm also going to state this is my minutes... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Wilfried.Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 -------------------------------------------------------------------------- From Dave.Morton at ecrc.de Fri May 20 20:07:38 1994 From: Dave.Morton at ecrc.de (Dave Morton) Date: Fri, 20 May 94 20:07:38 +0200 Subject: register esa.ch Message-ID: <9405201807.AA10973@acrab25.ecrc> Mike - I think the context at that time (and I'm sure Piet will remind me if I'm wrong) was that in a few years we all might need to run this wonderful X.400 stuff and the addressing (if one can call it that) in X.400 did not foresee any ADMDs called INT or ORG so if one wanted to change later you'd have a problem (besides X.400 that is :-). Since X.400 seems more or less destined to die young now that we will have SMTP with all the goddies included (see the latest draft rfcs up for approval as standards) I would assume Piet's advice might be in this direction now. Again Piet will correct if I'm off the tracks here.... Given the above you can probably safely stay with .ORG and .INT until we all collect our pensions at least. Cheers. Dave PS: Also given that J. Postel recently suggested a scheme for a new TLD's you also might want to register under one of them ;- This could have interesting consequences for current TL country Ds and financing thereof (names changed to protect the innocent - but I wander as usual :-) From Dave.Morton at ecrc.de Sun May 22 07:34:15 1994 From: Dave.Morton at ecrc.de (Dave Morton) Date: Sun, 22 May 94 07:34:15 +0200 Subject: register esa.ch Message-ID: <9405220534.AA11379@acrab25.ecrc> > Btw, I also know about another potential conflict coming up - I've heard > of plans within Germany to align 2nd-level domain names with the regional > abbreviations known to all from German car plates - e.g. K for Cologne, > DA for Darmstadt, etc. >Crazy idea: if company X moves from Cologne to Darmstadt, >its domain name would change, they would have to reprint >their letter heads, business cards, etc., and someone would >have to cope with all the bounces of mails sent to the old >domain name... Walter - I don't know where you heard of plans - there is some brainstorming in progress to somehow put structure on the DE domain - that's about as far as things have progressed until now. I'd believe the people involved (many of whom are on the RIPE DNS list) are aware of the potential problems so don't expect any surprises. > Assuming that we as international organisation could stay out of this scheme > and retain esa.de, this would cause a clash with the region of Eisenach (also > ESA), and the same considerations as above would apply. >Which makes it unlikely that you could stay out of such a >"reorganisation" (I'd rather call it a mess-up). I, for one, would expect any such plan, assuming it ever were to be implemented, not to be implemented retrospectively, this would not be acceptable. > Comments/Suggestions welcome! >Contrary to what I've suggested to you long ago, I'd now >recommend that you put ESA under the .INT domain; chances >are zero that there will ever be a .EU domain for Europe, >unless someone can convince the Powers That Be that there >is a very clear need for such a "pseudo top level domain", >quite analogous to the current 3-letter TLD's; or maybe >the analogy could be carried even further by creating a >domain .EUR; but then, who is going to manage it? Good idea with INT now that X.400 is dying. Mabye EU or EUR is not such a good idea for ESA since one cannot exclude that they establish or have a launch facility in S. America but that's beside the point. Why shouldn't we beat up Mr. IANA for an .EUR and get the Commission to finance it, after the event that is :-) > Piet Dave From Dave.Morton at ecrc.de Sun May 22 08:53:24 1994 From: Dave.Morton at ecrc.de (Dave Morton) Date: Sun, 22 May 94 08:53:24 +0200 Subject: register esa.ch Message-ID: <9405220653.AA11449@acrab25.ecrc> >a) Is this plan actually to be considered as serious or more rumor? Serious but without consenus yet.. >b) Is this mailing list the right forum to discuss it? Well, yes and no. It's a national issue but has global effects. >Michael > Dave From nipper at xlink.net Sun May 22 14:49:58 1994 From: nipper at xlink.net (Arnold Nipper) Date: Sun, 22 May 1994 14:49:58 +0200 (MET DST) Subject: register esa.ch In-Reply-To: <9405220653.AA11449@acrab25.ecrc> from "Dave Morton" at May 22, 94 08:53:24 am Message-ID: <"xlink100.x.485:22.04.94.12.50.01"@xlink.net> Dave Morton wrote: > > >a) Is this plan actually to be considered as serious or more rumor? > > Serious but without consenus yet.. > One proposal actually is to register individuals and VSE under 1 to 3 letter secondlevel domains but not to rearrange the whole tdl. Another proposal is to take the 2-letter "Laender" codes instead. As with the first this only concerns individuals and VSE. > >b) Is this mailing list the right forum to discuss it? > > Well, yes and no. It's a national issue but has global effects. > Of course. Any other ideas how to cope with the problem? > >Michael > > > Dave -- Arnold Nipper / email: nipper at xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich XLINK /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany From VANNOZZI at NIS.GARR.IT Mon May 23 13:29:10 1994 From: VANNOZZI at NIS.GARR.IT (Daniele Vannozzi) Date: Mon, 23 May 94 13:29:10 MET Subject: Removal nameserver an rev-srv tags In-Reply-To: Message of Fri, 20 May 94 18:28:53 GMT from Message-ID: <9405231135.NA00686@nikhefh.nikhef.nl> On Fri, 20 May 94 18:28:53 GMT you said: >> Concerning the assumption of dns-wg about the useless of those tags and >> the absence of procedures based on them we would like to inform you that >> we are presently testing some automatic tools based exactly on those >> tags which we use before actually registering a new direct or inverse >> domain. >> Starting from the contained information, each server is queried on >> properly resolving the query. > >Do you mean, you first build the domain object, insert it into the database >and then get a list of nameservers out of it, in order to do your querying? >And only then you consider the domain configuration ok? > >If this is the case, why don't you get the NS list from the (soon to be) >primary nameserver, and if all is ok then you register the domain itself >and the domain object in the database? Or did I miss something? Artur, many thanks for your help. I think it's necessary to explain our procedure. When we receive a domain form (domain registration template) we check the primary nameserver (we use the first "nameserver:" tag to locate it). How to find otherwise that server without a nameserver tag? If the primary nameserver is reachable and properly configured we continue checking secondary nameservers which should be listed in the domain form and as NS records in the primary nameserver. The above is a useful check because many times there are discrepancies in what is "declared" and what is actually configured. In addition, if in the domain form there is our nameserver listed as a secondary, we also check the refresh time, retry time, expiration period and default ttl. Only after a successful check the domain object is added to database and the country master server is reloaded with the new information. Regards, Daniele > >We do this before registering a domain under PT... > >.artur > Daniele Vannozzi Phone: +39 50 593280 GARR-NIS Phone NIS: +39 50 593360 c/o CNUCE - Istituto del CNR Fax: +39 50 904052 Via Santa Maria 36 Telex: 500371 - CNUCE 56100 Pisa - Italy E-mail: vannozzi at nis.garr.it From Piet.Beertema at cwi.nl Tue May 24 10:24:02 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Tue, 24 May 1994 10:24:02 +0200 Subject: register esa.ch In-Reply-To: "Your message of Fri, 20 May 1994 14:55:46 +0200 " <9405201255.AA14855@lupine.techfak.uni-bielefeld.de> Message-ID: <9405240824.AA15146=piet@kraai.cwi.nl> > Totally correct. If the company moves, they will have to > change their business cards, letter heads ... > PTT's take care of forwarding letters. Who is going > to take care of forwarding e-mail? Unless the outdated domain name is reissued immediately (not a good idea at all) it still lives and the owner is free to populate it with appropriate CNAME and/or MX records. An outdated domain is unregistered right away and thus neither exists any longer nor has an owner. Piet From Piet.Beertema at cwi.nl Tue May 24 10:33:08 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Tue, 24 May 1994 10:33:08 +0200 Subject: Removal nameserver an rev-srv tags In-Reply-To: "Your message of Mon, 23 May 94 13:29:10 MET " <9405231135.NA00686@nikhefh.nikhef.nl> Message-ID: <9405240833.AA15191=piet@kraai.cwi.nl> >> Concerning the assumption of dns-wg about the useless of those tags and >> the absence of procedures based on them we would like to inform you that >> we are presently testing some automatic tools based exactly on those >> tags which we use before actually registering a new direct or inverse >> domain. >> Starting from the contained information, each server is queried on >> properly resolving the query. > >Do you mean, you first build the domain object, insert it into the database >and then get a list of nameservers out of it, in order to do your querying ? >And only then you consider the domain configuration ok? > >If this is the case, why don't you get the NS list from the (soon to be) >primary nameserver, and if all is ok then you register the domain itself >and the domain object in the database? Or did I miss something? When we receive a domain form (domain registration template) we check the primary nameserver (we use the first "nameserver:" tag to locate it). How to find otherwise that server without a nameserver tag? If you receive a domain registration, it ought to list the nameserver hosts and their IP addressess, the simple reason being that you have to enter them into DNS. But that has absolutely nothing to do with [the domain object in] the RIPE database. If the primary nameserver is reachable and properly configured we continue checking secondary nameservers which should be listed in the domain form and as NS records in the primary nameserver. The above is a useful check because many times there are discrepancies in what is "declared" and what is actually configured. That's what I do too before entering nameservers for a domain into the NL zone file. But again, this has nothing to do with [the domain object in] the RIPE database. In addition, if in the domain form there is our nameserver listed as a secondary, we also check the refresh time, retry time, expiration period and default ttl. Same comment as above. Only after a successful check the domain object is added to database and the country master server is reloaded with the new information. Once again: this relates ONLY to DNS. If you think it's really necessary to clog the RIPE database with useless information (like nameservers; info that is present already in DNS), you have to come with good arguments. And please note that it is not forbidden for a [TLD] registrar to keep a *local* database with all sorts of additional info about a domain. Piet From Daniel.Karrenberg at ripe.net Tue May 24 10:47:17 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 24 May 1994 10:47:17 +0200 Subject: register esa.ch In-Reply-To: Your message of Sun, 22 May 1994 14:49:58 MDT. <"xlink100.x.485:22.04.94.12.50.01"@xlink.net> Message-ID: <9405240847.AA00648@reif.ripe.net> > Arnold Nipper writes: > > Of course. Any other ideas how to cope with the problem? How about the latest Postel proposal: Create 999 subdomains 1.de to 999.de. In each of them create 999 subdomains 1.x.de - 999.x.de. You have just mapped namesapce for a million registries under DE with names that have little to no connotations with anything. To anyone who wants to run a registry for individuals, assign *randomly* an x.y.de combination. I can then find a friend who will register me as karrenberg.123.456.de, if I do not like his policy I will go to 453.295.de and register there. Anything wrong with that? Daniel From Piet.Beertema at cwi.nl Tue May 24 10:50:29 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Tue, 24 May 1994 10:50:29 +0200 Subject: register esa.ch In-Reply-To: "Your message of Tue, 24 May 1994 10:47:17 +0200 " <9405240847.AA00648@reif.ripe.net> Message-ID: <9405240850.AA15414=piet@kraai.cwi.nl> I can then find a friend who will register me as karrenberg.123.456.de, if I do not like his policy I will go to 453.295.de and register there. Still thinking German? :-) :-) Anything wrong with that? It's sort of copying what CompuServe does... ;-) Piet From Dave.Morton at ecrc.de Tue May 24 12:50:03 1994 From: Dave.Morton at ecrc.de (Dave Morton) Date: Tue, 24 May 94 12:50:03 +0200 Subject: register esa.ch Message-ID: <9405241050.AA11914@acrab25.ecrc> > > Arnold Nipper writes: > > > > Of course. Any other ideas how to cope with the problem? > >How about the latest Postel proposal: Actually I quite like Jon's proposal but it was not quite the same as you suggest. Replace .DE with .PVT below. >Create 999 subdomains 1.de to 999.de. Have to the the current DE-NIC consortium to agree to this and they probably wont... >In each of them create 999 subdomains 1.x.de - 999.x.de. >You have just mapped namesapce for a million registries >under DE with names that have little to no connotations with >anything. Agreed. >To anyone who wants to run a registry for individuals, >assign *randomly* an x.y.de combination. I can then find a >friend who will register me as karrenberg.123.456.de, if >I do not like his policy I will go to 453.295.de and register >there. > >Anything wrong with that? Nope, but it still doesn't help finance a NIC for DE or replace DE with your favourite European TLD. > >Daniel Dave From Piet.Beertema at cwi.nl Wed May 25 11:03:14 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 25 May 1994 11:03:14 +0200 Subject: register esa.ch Message-ID: <9405250903.AA18522=piet@kraai.cwi.nl> What's in a name...? Piet ---------------------------------------------------------------------------- Newsgroups: nlnet.announce From: jan at cs.ruu.nl (Jan van Leeuwen) Subject: ESA'94 accepted papers Message-ID: Keywords: ESA'94, algorithms Organization: Utrecht University, Dept. of Computer Science Date: Mon, 23 May 1994 15:03:36 GMT 2nd Annual EUROPEAN SYMPOSIUM ON ALGORITHMS (ESA'94) Utrecht (the Netherlands), September 26-28, 1994 ADVANCE INFORMATION The Final Program/Call for Participation for ESA'94 will be distributed around June 1st. Further information on ESA'94 can also be obtained by consulting the `ESA page' on World Wide Web under the following URL: http://www.cs.ruu.nl/esa/ or by sending email to esa at cs.ruu.nl (preferably). See you at ESA'94!