- NANOG - lists.nanog.org

US Domain -- County Delegations
by US Domain Registration 26 Jul '95

26 Jul '95

Hello. We are planning to delegate every county name as a locality name in each State. For example, "Ventura.CA.US", "Dade.FL.US", "Riverside.CA.US". We are looking for volunteers to support the domain name registration and provision of name servers for these county domains. If you are interested in providing this service please return the template below. For further information about the US Domain please see RFC 1480. In the case where only one party requests a county delegation, they will be given that delegation. To be fair, where several requests are made for the same county(ies) those requests will be put in a hat and selected by lottery. If a locality name has already been delegated or it is both a city and county name we will not re-delegate it as a county. Only full names for counties, spelled out, with hyphens replacing spaces (e.g., Santa-Monica, or Fort-Collins"), will be considered. We must have a separate template for each county requested. It is important that you accurately fill in all the information requested on the template. If you alter it in any way, other than what is specified, it might not be considered. The data you supply will also be used to create your WHOIS entry. Be sure to accurately describe your domain name on the corresponding description question. Locality names should be in the following form: 2. Fully Qualified Domain Name 4. Description of Org/Domain ============================== ============================ VENTURA.CA.US Ventura, California DADE.FL.US Dade, Florida RIVERSIDE.CA.US Riverside, California We no longer use Internic NIChandles (Idents). We are creating our own US Domain Handles. It is important that you complete the Administrative and Technical contact information in full. We added an optional question "7j" for a Registration Request mailbox (i.e, hostmaster, support, dns-admin). We will accept all requests up to August 31, 1995. The current list of locality delegations can be found in the "us-domain-delegated.txt" file. For a list of counties in your state an atlas is a good place to look. RETRIEVAL OF DELEGATED SUBDOMAINS and CONTACTS URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt E-MAIL: To: RFC-INFO(a)ISI.EDU (include in message body) Help: us_domain_delegated_domains Ann Cooper US Domain Registry US DOMAIN TEMPLATE [7/95] PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY. Fields marked with an asterisk (*) may be duplicated. ************************************************************************** 1. REGISTRATION TYPE (N)ew (M)odify (D)elete..: 2.* FULLY-QUALIFIED DOMAIN NAME: 3. ORGANIZATION INFORMATION 3a. Organization Name.....: 3b. Address Line 1........: 3b. Address Line 2........: 3c. City..................: 3d. State.................: 3e. Zip/Code..............: 4. DESCRIPTION OF ORG/DOMAIN: 5. Date Operational......: 6. ADMINISTRATIVE CONTACT OF ORG/DOMAIN 6b. Whole Name............: 6c. Organization Name.....: 6d. Address Line 1........: 6d. Address Line 2........: 6e. City..................: 6f. State.................: 6g. Zip/Code..............: 6h.* Voice Phone...........: 6i.* Electronic Mailbox....: 6j. FAX Number............: 7. TECHNICAL AND ZONE CONTACT 7b. Whole Name............: 7c. Organization Name.....: 7d. Address Line 1........: 7d. Address Line 2........: 7e. City..................: 7f. State.................: 7g. Zip/Code..............: 7h.* Voice Phone...........: 7i.* Electronic Mailbox....: 7j.* Registration Mailbox..: 7j. FAX Number............: 8. PRIMARY SERVER: HOSTNAME, NETADDRESS 8j. Hostname..............: 8k.* IP Address ...........: 9. * SECONDARY SERVER: HOSTNAME, NETADDRESS 9a.* Hostname..............: 9b.* IP Address............: ^L ************************************************************************** DISCLAIMER By the registration of your name on the Internet, the IANA, the InterNIC, Network Solutions Inc., the University of Southern California, and the National Science Foundation are accepting in good faith that you have the right to the use the name. The IANA and InterNIC/Network Solutions' function in registering names on the Internet is to assure that the name does not conflict with any other name in the name space requested. The user by its registration and use of the name and/or their continued use of an existing name, agrees, as part of their request for name registration, to indemnify and hold harmless from any and all costs, fees, expenses arising from litigation involving trademark, trade name, service mark, and any other name infringements, or other reasons, the IANA, the InterNIC, Network Solutions Inc., the University of Southern California, and the National Science Foundation. The party requesting registration of this name certifies that to her/his knowledge, the use of this name does not violate trademark or other statutes. Registering a domain name does not confer any legal rights to that name and any disputes between parties over the rights to use a particular name are to be settled between the contending parties using normal legal methods (See RFC 1591). **************************************************************************

2 1

Subscribe
by ser＠exodus.net 25 Jul '95

25 Jul '95

Who do I email to get on the NANOG list? -- Steven Eric Rubin - Senior Network Administrator Exodus Communications, Inc. 948 Benecia Ave, Sunnyvale, CA 94086 Email: ser(a)exodus.net - Phone: (408) 522-8473

1 0

CERT Vendor-Initiated Bulletin VB-95:05 - OSF
by CERT Bulletin 21 Jul '95

21 Jul '95

CERT Vendor-Initiated Bulletin VB-95:05 July 21, 1995 Topic: OSF/DCE Security Hole Source: Open Software Foundation (OSF) To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from the Open Software Foundation. OSF urges you to act on this information as soon as possible. OSF contact information is included in the forwarded text below; please contact them if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ Advisory on OSF/DCE Security Hole July 19, 1995 It has been discovered that OSF/DCE security has a flawed aliasing mechanism in its registry that can potentially yield a less secure DCE cell. PROBLEM: Multiple administrators in a DCE cell (i.e., principals with the privileges required to create principals and accounts within the DCE registry), some of which are intended to be less trusted than the cell administrator (e.g., principals intended to be restricted to create principals and accounts only within a subset of DCE registry name space), cannot be prevented from acquiring full privileges of the cell administrator. Due to a flaw in the DCE security registry such less privileged administrators are able to gain full privileges by creating an alias to the cell administrator. The security server grants an alias principal full rights of the principal it is aliased to. DCE security registry principals are generally not allowed to create accounts. Only an account designated as some type of administrator, by explicitly creating ACL entries for that principal, allows it to do things to the registry that normal users are not allowed to do, that is, create principals and accounts in a certain part of the security name space. In OSF/DCE as it ships, only cell_admin is given such privileges. To that effect, the DCE cell administrator can prevent any loss of security by following the guidelines described below. HOW TO AVOID: This security hole has existed in all releases of OSF/DCE todate. To avoid the problem in releases prior to OSF/DCE 1.1, the DCE cell administrators should not explicitly give registry administration rights to principals that would not otherwise have access to the cell administrator account itself. As distributed by OSF, only cell_admin is given such rights. OSF is in the process of providing a fix for this defect to DCE 1.1 support licensees for them to apply to their DCE 1.1 based products. The end-users may ask their DCE vendors for such a fix. All future releases of OSF/DCE will have this fix incorporated. ********************************************************************** OSF Systems Engineering Open Software Foundation 11 Cambridge Center, Cambridge, MA 02142 Telephone: +1 617 621 8990 E-mail: dce-support-admin(a)osf.org =========================FORWARDED TEXT ENDS HERE============================= CERT bulletins, CERT advisories, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce. If you would like to have future advisories and bulletins mailed to you or to a mail exploder at your site, please send mail to cert-advisory-request(a)cert.org. If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT staff for details). Internet email: cert(a)cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT is a service mark of Carnegie Mellon University.

1 0

Continued IP Spoofing Attacks (INFO#95.16723)
by CERT Coordination Center 21 Jul '95

21 Jul '95

-----BEGIN PGP SIGNED MESSAGE----- ============================================================================== CONTINUED IP SPOOFING ATTACKS CERT Coordination Center July 21, 1995 ============================================================================== **** This note is the same ``heads-up'' that was originally sent on June 29, **** 1995. It is being resent because some recipients were unable to read **** it. Because of the importance of the subject matter, we are resending **** with a PGP signature but without a MIME header. Over the past few weeks, we have received reports of 170 IP spoofing attacks against Internet sites internationally. We are sending you this "heads-up" because you, a network service provider, are a likely target. At least 80 of the targets we know of are name servers, routers, and other network operation systems. The attacks have been largely successful, we continue to receive reports, and we are concerned that more attacks are going undetected. We urge you to check your systems and routers for any signs of compromise and to use the information in CERT advisory CA-95:01, "IP Spoofing Attacks and Hijacked Terminal Connections," to help protect yourself, detect IP spoofing attacks, and recover from root compromises. The advisory is available by anonymous FTP from ftp://info.cert.org/pub/cert_advisories This "heads-up" contains additional information about what you can do, as well as issues to consider before taking action. Please feel free to forward this to other providers of Internet services. What is IP Spoofing? - -------------------- To gain access, intruders create packets with spoofed source IP addresses. This exploits applications that use authentication based on IP addresses and leads to unauthorized user and possibly root access on the targeted system. Examples are the rsh and rlogin services. It is possible to route packets through filtering-router firewalls if they are not configured to filter incoming packets whose source address is in the local domain. It is important to note that the described attack is possible even if no reply packets can reach the attacker. Examples of configurations that are potentially vulnerable include: - - routers to external networks that support multiple internal interfaces - - routers with two interfaces that support subnetting on the internal network - - proxy firewalls where the proxy applications use the source IP address for authentication Communicating with us - ---------------------- Warning: For sensitive information, use encrypted email. You will find the CERT public PGP key at the end of this document. We would appreciate it if you would let us know whether you are watching for IP spoofed packets on your networks (or plan to do so). If you see spoofed packets, we'd like to learn how many you see and from how many different sites; this will help us determine the scope and pattern of the attacks. We will keep all detailed information and the identity of organizations confidential. Because of our workload, we must ask you not to send log files of activity, but we would be happy to work with you as needed on how to interpret data that you may collect. If you see activity that indicates an attack is in progress, we encourage you to contact your customer, or other involved sites or their service provider. We have some general information on IP spoofing and on recovering from a compromise that we can make available to you for your customers' use. We would also be happy to provide guidance and advice, if needed, on how to handle incidents and work with law enforcement. ............................................................................. Some things you can do - ---------------------- It is possible to check network traffic for indications of the type of attack we are currently seeing. Before doing so, please look at the next section, "Issues to consider before taking action." There are several classes of packets that you could watch for. The most basic is any TCP packet where the network portion (Class A, B, or C or a prefix and length as specified by CIDR, the Classless Inter-Domain Routing specification) of the source and destination addresses are the same but neither are from your local network. These packets would not normally go outside the source network unless there is a routing problem, worthy of additional investigation, or the packets actually originated outside your network. The latter may occur with Mobile IP testing, but an attacker spoofing the source address is a more likely cause. For a NAP or NSP, the interface into which a packet arrived indicates the direction of the source of the attack. The packet's destination address indicates the "trusted" host involved in an attack. That information suggests which hosts may be under attack. There are public domain and vendor provided tools available for checking your networks for IP spoofed packets. Among them are Argus, tcpdump, and snoop. Argus 1.5 - --------- Argus is an IP network transaction-auditing tool developed at the Software Engineering Institute of Carnegie Mellon University. The Argus 1.5 distribution includes scripts that perform simple network administrative tasks, one of which is IP spoofing detection. The data that Argus generates makes it possible to analyze network activity and performance in ways that have not been possible before. For example, you can answer questions such as, "Were there any IP spoofing attempts into our firewall network over the past 8 hours?" The developers of Argus have made the tools available from ftp://ftp.sei.cmu.edu/pub/argus-1.5 If you have any questions, comments, or suggestions, please send mail to argus(a)sei.cmu.edu. Scripts - ------- At the end of this document ("Attachment A") are scripts you may want to use to check your network. We are aware that the Internet is now "classless," meaning that the old notion of class A, B, and C addresses is being replaced with a prefix and length notation, also known as CIDR. Even so, the scripts, which are based on classes, may be useful to some service providers. In all the IP spoofing incidents reported to us to date, we believe that the scripts would have shown the spoofed packets. (The problem here is that these scripts may either show other packets labeled as spoofed or not show true spoofed packets due to CIDR.) A standalone machine running tcpdump or equivalent should be able to run these scripts without affecting the performance of the local net. It may be possible to configure routers to do this check directly but we are not currently aware of any systems on which this is possible. .............................................................................. Issues to consider before taking action - --------------------------------------- Before writing this "heads-up," we consulted colleagues on other response teams, several network service providers, and other technical experts. They raised the following issues, and there surely are others you should consider before taking action. Technical and performance issues: - There may be too many "false positives." Two causes are mobile IP and misconfigurations; there may be other causes as well. - The feasibility of installing network monitors may depend on network topology. - It is not clear how many monitoring machines you would need to pinpoint the problem. - When the tcpdump and snoop scripts were tested on a dedicated Sun IPX connected to a T1, the impact on performance was only marginal. Long-haul tests with similar scripts do not have performance problems either. - Anything above a T1 is going to cause some performance problems (applications like tcpdump and snoop do not work very well at all on DS3 or FDDI interfaces). Legal issues: - - Some service providers believe that checking your network as we suggest is all right; others believe that there may be a problem. We urge you to check with your legal advisors about analyzing packet header information, analyzing traffic content to detect unauthorized activity, and analyzing internal traffic and customer-bound traffic. - - For US service providers, the Digital Telephony Bill of 1994 is relevant; in particular, check the amended provision found at 18 U.S.C. 2511(2) (a) (i), which permits an electronic communications service and its employees to ...intercept, disclose, or use that communication in the normal course of...employment while engaged in any activity which is a necessary incident to the rendition of...service or to the protection of the rights or property of the provider of that service.... .............................................................................. Attachment - Scripts for Checking Networks - -------------------------------------------- We have tested the following scripts on a recent version of tcpdump and snoop (192.9.200.0 would be replaced by the site's local net, of course): --- script for tcpdump --- #!/bin/sh tcpdump 'tcp and not dst net 192.9.200.0 and ( (ip[12]&0x80=0 and ip[12]=ip[16]) or (ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or (ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18]) )' (Note this only seems to work with tcpdump-3.0.2 and libpcap-0.0.6 currently.) --- script for snoop --- #!/bin/sh snoop 'tcp and not net 192.9.200.0 and ((ip[12]&0x80=0 and ip[12]=ip[16]) or (ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or (ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18]))' (Note that this does not appear to work with Solaris 2.3 machines.) To more accurately analyze network traffic, it is useful to first describe the network topology; for example: ---------------- | INTERNET | ---------------- | ---------- | | NETWORK | ---------------- | MONITOR | | ROUTER | ---------- ---------------- | | | | ----------------------------------------------------------------- |MAC-A |MAC-B |MAC-C --------- --------- --------- |ROUTER | |ROUTER | |ROUTER | --------- --------- --------- | | | | | | | | | | | | | | | | | | | | | | | | | | | Ca Cb Cc Cd Ce Cf Cg Ch Ci (MAC-A, MAC-B, and MAC-C refer to the ethernet addresses of the router interfaces attached to the same network as the network monitor machine.) In this case, the machine used to check network traffic could be any machine capable of running tcpdump, snoop, or any other packet capture and analysis software. This machine could be programmed so that any packets that match the following expression are displayed. tcp and ( not ether src MAC-A and ( src net Ca or src net Cb or src net Cc ) not ether src MAC-B and ( src net Cd or src net Ce or src net Cf ) not ether src MAC-C and ( src net Cg or src net Ch or src net Ci ) ) This expression looks at the source address of each packet and identifies those that did not originate from the correct interface. This example should be extensible to take CIDR into account. For example, if the CIDR specification of network Ca is 192.9.200/21, then the sub-expression: src net Ca should be replaced with: ip[12:4]&0xfffff800=192.9.200.0 .............................................................................. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMA/8F3VP+x0t4w7BAQGKfgQArR6jBz+HjRbPBRAjO88aNIaH/ZbBzt1K cPDE54nLWa0+CP4F4ZWhn+UH1SMdRrLFdYZdD1sn5j56zx+nXmzo2sL3eRvylpdp LigpavVWJoOoC8XY8AJqUCT+A4txd4QacawGZMMbedIi9IyzU/33ia7BIb4wW/k6 bidvD0ExGNQ= =nyX9 -----END PGP SIGNATURE-----

1 0

Internic procedure problems
by Michael Dillon 21 Jul '95

21 Jul '95

I've been thinking about this incident with the wrong address in the .net domain for ns2.bc.net and I have come to the conclusion that the Internic needs to review some of their procedures. First of all, I wonder why they don't run a sanity check on the top level zone files from time to time to make sure that the correct domain names and IP addresses are recorded. If this were done and a sanity check was also done at the time of any changes to the zone files, then this kind of problem would not occur. THis is not the first time I have encountered such a problem. A few weeks ago I helped a small college in California sort out a problem with their email which was the result of the incorrect nameserver being recorded in the .ca.us domain. Another thing that would be nice to see is some method for updating domain information similar to the way routing policy is updated. If I wish to change secondary nameservers, I should be able to directly update records for my domain rather than submit an email request and wait 3-4 weeks for an overworked human being to get around to it. This is especially irritating for us because when we switched providers and therefore needed to switch secondary nameservice, it only took a few days to get the in-addr domains changed but our .net domain is dragging on forever. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael(a)memra.com

3 2

New and improved Traceroute
by Ehud Gavron 21 Jul '95

21 Jul '95

Steffen Baur identified a long-standing bug in traceroute that causes it to appear to hang on non-returned packets on hosts which received lots of ICMP traffic. This fix, as well as some ANSI stuff to make it work on SunOS, Ultrix, BSDI, (and of course, VMS), have now been integrated. ftp.aces.com, cd [.software.traceroute], mget *.*, there's a 0_readme.txt and traceroute.c. This pretty much completes any of the major fixes I'd planned to do for this quarter, so unless someone comes up with anything revolutionary to put in, I won't post another comment for a while... Ehud gavron(a)aces.com

1 0

RIPE automatic inaddr-arpa checking tool available
by RIPE NCC IN-ADDR. ARPA Role Account 21 Jul '95

21 Jul '95

Dear all, After many requests I have published the inaddr-arpa checking tool I developed at the RIPE NCC. We use it now at RIPE NCC quite for some time and it really saves us a lot of time, although the program is not perfect and still needs some polishing. Beware of changing/adapting the tool too much since I expect to make some big changes in the output format to facilitate further automatic processing. Furthermore, I want to split it in some smaller files and a config file for better maintainability. Of course comments and bug reports are welcome. Please read the included README file for more details. Kind regards, David Kessens RIPE NCC PS I am on vacation during the next two weeks, but I will certainly deal with any comments/bug reports when I return! -------- README for the inaddrtool v0.1 Date: 950719 Author: David Kessens, RIPE NCC NOTE: THE TOOL HAS BEEN MADE PUBLICLY AVAILABLE BECAUSE OF THE LARGE NUMBER OF REQUESTS OF OUR CUSTOMERS TO DO SO. THE TOOL ITSELF HAS PROVEN IT'S USEFULNESS, BUT NOTE THE FACT THAT I EXPECT TO MAKE SOME BIG CHANGES BEFORE RELEASING A FINAL VERSION. ALSO SOME ADD-ON PROGRAMS THAT WILL MAKE IT POSSIBLE TO ADD THE REVERSE DELEGATION CHANGES/REQUESTS AUTOMATICALLY TO (Y)OUR ZONEFILES ARE STILL MISSING. THE PROGRAM IS DESIGNED AS SITE INDEPENT AS POSSIBLE. PLEASE USE THE NORMAL PROCEDURE AS DESCRIBED IN RIPE-105 IF YOU WANT TO DO A REVERSE DELEGATION REQUEST FOR A REVERSE DOMAIN MANAGED BY THE RIPE NCC, BUT SEND YOUR REQUEST TO <AUTO-INADDR(a)RIPE.NET> INSTEAD OF <HOSTMASTER(a)RIPE.NET> Reverse delegation tool (Alpha version!) ---------------------------------------- As of today the RIPE NCC offers an automated method for the submission of reverse zone delegations in 193.in-addr.arpa and 194.in-addr.arpa. The reverse delegation requests and the zone files on all nameservers will be checked automatically. The diagnostics generated by these checks will be returned to you automatically too. This will make you aware of any problems very quickly, so that you can correct them and re-submit your request. The most recent version of the tool is now publicly available at: ftp://ftp.ripe.net/tools/inaddrtool0.1.tar.gz The tool uses some other external programs for gathering the information it needs for checking your zone files: ftp://ftp.ripe.net/tools/ping.tar.Z ftp://ftp.ripe.net/tools/dns/host.tar.Z ftp://ftp.ripe.net/pride/tools/prtraceroute-2.0beta3.shar.gz Installing the software: - uncompress/unzip and untar the tool and the external programs - edit the variables in the source code (if needed): $TESTMODE=1 for testing, 0 for normal use $UPDLOGDIR="Directory for logging the incoming requests"; $ACKLOGDIR="Directory for logging the outgoing acknowledgements"; $FWLOGDIR="Directory for logging the outgoing approved requests"; $MSGQUEUEDIR="Directory for temporarily storing the requests"; $NSNAME="The name of your nameserver"; $NAMESERVERCHECK=; see for details the source code $MAILCMD=; see for details the source code $NICECMD="Your nice program if you want" else use ""; $HUMANMAIL="The E-mail address of the human processing the approved requests and answering questions. When $TESTMODE=1, all mail will be send to this address"; $AUTOMAIL="The E-mail address of the mail box that will auto process incoming requests"; - Put something like: "|/home/user/bin/inaddrtool 2>/dev/null" in the .forward file of user $AUTOMAIL Note: there is *NO* queuing mechanism yet, so beware of overloading your machine with a large number of requests. The input: The tool expects to read an E-mail message from standard input although there is no problem when using it stand-alone. The E-mail message should contain a valid RIPE database object as described in the ripe-105 (ftp://ftp.ripe.net/ripe/docs/ripe-105) procedure. When the automated procedure does not detect any errors, the request is forwarded to the $HUMANMAIL role account person for some additional manual checks and the processing of the delegation itself. An acknowledgement of this fact is also sent to the people mentioned in the From:/Reply-To: and Cc: field in the E-mail message. The tool will return an error report if errors are found. If $TESTMODE=1 all mail will be send to $HUMANMAIL. You can use some keywords in the 'Subject:' line of your E-mail to control the checking process. The use of the LONGACK keyword is very recommended. HELP - will send you a (patched) ripe-105 document CHANGE - is needed if you want to change an existing reverse delegation LONGACK - will give you the most verbose output as possible TEST - do the checks, but sent only a report back to the user even if no errors are found You also might want to use the special variable NSNAME that's documented in the source code itself (for experts only). RIPE document ripe-105 requires you to send in a RIPE database 'inetnum' object with a 'rev-srv' attribute for each nameserver for single/multiple C's reverse delegation requests and for whole blocks 'domain' objects with 'nserver' attributes for each nameserver. I am neither a DNS expert or native English writer ;-) so all your comments are welcome! Please send them together with complaints, bug reports or special requests to <inaddr(a)ripe.net>.

1 0

Re: Internic procedure problems
by Geoff Huston 21 Jul '95

21 Jul '95

That last null message from me was fat finger syndrome - sorry 'bout that. I was just noting that there is a WEB page which deals in in-addr delegations at http://aunic.net/aunic/inaddr-template.html The procedure does not email the SOA with the delegation details unless the listed nameservers are a) visible b) functioning and c) consistent. It would be trivial to modify this form to handle generic domain names rather than the special case of in-addr.arpa domain names. Geoff >From list-admin(a)merit.edu Fri Jul 21 08:32:34 1995 >From: Geoff Huston <G.Huston(a)aarnet.edu.au> >Subject: Re: Internic procedure problems >To: markk(a)internic.net (Mark Kosters) >Date: Fri, 21 Jul 1995 07:31:46 +1000 (EST) >Cc: kozowski(a)structured.net, nanog(a)merit.edu > >> >> Its coming - now that the new domain templates are getting to be a larger >> and larger percentage of the total daily domain intake. >> >> Mark >> > >> > >Another thing that would be nice to see is some method for updating domain >> > >information similar to the way routing policy is updated. If I wish to >> > >change secondary nameservers, I should be able to directly update records >> > >for my domain rather than submit an email request and wait 3-4 weeks for >> > >an overworked human being to get around to it. >> > >> > Somthing along the lines of the auto-dbm for the RADB would be great for >> > domain name chages, etc. Just my $.02. >> >> -- >> >> Mark Kosters markk(a)internic.net +1 703 742 4795 >> Software Engineer InterNIC Registration Services >> >> > > >

2 1

Re: Internic procedure problems
by Eric Kozowski 20 Jul '95

20 Jul '95

>Another thing that would be nice to see is some method for updating domain >information similar to the way routing policy is updated. If I wish to >change secondary nameservers, I should be able to directly update records >for my domain rather than submit an email request and wait 3-4 weeks for >an overworked human being to get around to it. Somthing along the lines of the auto-dbm for the RADB would be great for domain name chages, etc. Just my $.02. Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS3

4 3

Mae-East instability
by Curtis Villamizar 20 Jul '95

20 Jul '95

Some of our peers have been dropping BGP a bit more often lately. Somebody had a real bad day on Tuesday. Jul.18: 192.41.177.252 1:35:13 mae-east-rt2.es.net Jul.18: 192.41.177.125 1:23:29 mae-east.nsn.nasa.gov Jul.18: 192.41.177.251 0:59:05 mae-east-rt1.es.net Jul.18: 192.41.177.241 0:08:56 sl-mae-e-F0/0.sprintlink.net Here's a list giving the number of disconnects (where there were 5 or more disonnects per day). The majority of flapping seems to be at Mae-East and Mae-West. date peer hits Jul 18 192.157.69.250 8 rs1.sprint.ra.net NY NAP Jul 18 192.41.177.125 72 mae-east.nsn.nasa.gov MaeE Jul 18 192.41.177.251 34 mae-east-rt1.es.net MaeE Jul 18 192.41.177.252 56 mae-east-rt2.es.net MaeE The July 18 problem was mostly concentrated over one 3.5 hour period of continuous flap. Jul 18 07:19:28 to Jul 18 10:52:30 (122:47 / 213:02) 192.41.177.125 took 50 hits (57:00) 192.41.177.252 took 41 hits (62:31) 192.41.177.251 took 17 hits (34:19) Any clues from NASA and ESNET as to why this instability occurred at Mae-east? Was this some form of BGP meltdown or just hardware trouble at or getting to the Mae? Curtis

2 1