- db-wg - mailman.ripe.net

whois -v option.
by RIPE Database Administration 16 May '97

16 May '97

Dear Colleagues, A new version of the C client for whois is available at ftp://ftp.ripe.net/tools/ripe-whois-tools-2.2.tar.gz Thanks to Steven Bakker for the patch. However, the problem appears to be system dependent as I never had a core dump with "whois -t xyz" or "whois -v abc". If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 1

Hierarchical Authorisation in the RR
by Carol Orange 15 May '97

15 May '97

Hi again, Here is another brief proposal for your perusal. This time for an implementation of hierarchical authorization in the Routing Registry. The mechanism described below will implement a hierarchy in the RR for which I believe there is consensus. The ideas in the proposal below were sifted from discussions which took place on the <routing-wg(a)ripe.net> mailing list and in the Routing WG meetings at RIPE-25 and RIPE-26. Please review this if you have time. We are hoping to have a go ahead on this from the Routing and Database WG's at or shortly after RIPE-27. Greetings, Carol Orange RIPE NCC -------------------------------------------------------------------- Hierarchical Authorisation in the RR Proposal for an Implementation Carol Orange, May 1997 At the January meeting of the Routing WG in Amsterdam, various possible hierarchies for authorization in the Routing Registry (RR) were considered. Whereas extensive discussion took place on the extent to which authority can be established in the RR, there was clear agreement that the maintainer of an AS should have authority over what routes are announced with a given aut-num in the "origin:" attribute. In the following, we specify an implementation to support the authority of "aut-num:" maintainers to determine who can announce routes under their AS. The mechanism can be extended as the need arises and consensus on other forms of authorization is achieved. For more information on the discussions leading up to this proposal, see: http://www.ripe.net/wg/routing/haro-d.html. Implementation -------------- If you (or your organization) manages an AS, then you should have authority over the routes announced in your AS. This can be implemented if we: a) add a "mnt-lower:" attribute to the aut-num object b) allow routes to be announced with a given "origin:" by those given authority as defined in the mntner object specified in the "mnt-lower:" attribute of the aut-num object. Example ------- If we add a "mnt-lower:" attribute to the aut-num object of the RIPE NCC, then only those who know what peEw8Gb4xBNqI encrypts can add and remove routes originating in AS3333. ---- aut-num: AS3333 ... mnt-lower: AS3333-MNT ... ---- mntner: AS3333-MNT descr: RIPE-NCC Maintainer ... auth: CRYPT-PW peEw8Gb4xBNqI ... ---- route: 193.0.0.0/23 descr: RIPE-NCC origin: AS3333 ... Summary ------- Other forms of hierarchical authorization and notification can be implemented in the future if a well defined hierarchy can achieve consensus. To provide some initial functionality which may meet the needs of many RR users, we propose to implement the above in the short term.

2 2

Re: whois -v option.
by Steven Bakker 15 May '97

15 May '97

==> From: RIPE Database Administration <ripe-dbm(a)ripe.net> ==> Thu, 15 May 1997 13:02:17 +0200 > To use "whois -v", you will need a new whois client. The new > version of the whois client is available at > > <ftp://ftp.ripe.net/tools/ripe-whois-tools-2.1.tar.gz> And it still goes "boom" when you try to use "whois -v" or "whois -t": kappa-~ & whois -v netnum zsh: 5855 segmentation fault (core dumped) whois -v netnum I have a patch for it (incidentally identical to the one I sent in last September ;-), which I'll attach below. It's basically a tiny error in the argc/argv handling. Cheers, Steven

2 1

X-Notification in the RR
by Carol Orange 15 May '97

15 May '97

Hi all, The following is a proposal for a cross notification mechanism in the Routing Registry. I post it for your perusal and hope to discuss it during the Routing WG meeting in Dublin. The initial suggestion was made by Daniel Karrenberg at the Routing WG meeting in January, and discussions with Joachim Schmitz and Wilfried Woeber have helped me work it into the following proposal. Such a mechanism was given a high priority by those who participated in the recent RIPE Database priority survey, so we are hoping to reach consensus on this at or shortly after RIPE-27. Greetings, Carol Orange RIPE NCC ---------------------------------------------------------------------- Cross Notification in the Routing Registry A Proposal Carol Orange, May 1997 At the January meeting of the Routing WG in Amsterdam, various possible hierarchies for authorization in the Routing Registry (RR) were considered. During the discussion, a suggestion was made that "hierarchical notification" would be useful even in cases where authority is not well defined. This suggestion enjoys strong support of both the Routing WG and the Database WG. In the following, we propose a simple cross notification mechanism which will allow routing registry users to be notified of overlapping route announcements in the RR. Route Announcement Notifications in the RR ------------------------------------------ Suppose you announce a route in your address space covering some /24. It may be useful when you make the announcement, to know that the /24 has already been announced in another AS. Likewise, should the user of that address space later decide to become multi-homed, it may be interesting to know that as well. Moreover, overlapping routes are often unintentionally announced in a single AS. In all of these cases, it would be useful to get a notification from the RR. Consider the route object: route: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] origin: [mandatory] [single] [primary key] hole: [optional] [multiple] [ ] withdrawn: [optional] [single] [ ] comm-list: [optional] [multiple] [ ] advisory: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Suppose we add a new field called "x-notify:" (cross-notify) which a) can contain either + a NIC-handle pointing to a person or role object, the email address of which will get the notification; or + a mntner ID pointing to the maintainer who will be notified b) is optional The contact in "x-notify:" will receive an e-mail whenever + a route is announced with overlapping address space + the address range in the route being added (with the "x-notify:" attribute) overlaps any address space currently announced in the RR. Issues ------ Does this cross notification satisfy the needs of network operators? Due to the global nature of the RR, some effort will be involved to provide notifications in a timely manner. What is an acceptable upper bound for cross notifications to be sent out? Using a NIC-handle or mntner for notification is different than the traditional e-mail address. However, it simplifies data maintenance for users significantly.

1 0

nic-hdl mandatory
by RIPE Database Administration 15 May '97

15 May '97

Dear Colleagues, The nic-hdl attribute is now mandatory in the person object. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

A DNS Database Referral Mechanism
by Carol Orange 14 May '97

14 May '97

Hi all, Below is a proposal put together by Wilfried Woeber and myself to address the need for a referral mechanism for domain name queries in the RIPE database. The mechanism is designed to address the immediate needs of those trying to get domain related information, and of DNS administrators trying to provide it. Certainly the mechanism may be adapted with time (see the three options below), however we choose to start with something that can provide the required functionality immediately. We hope to discuss this proposal on the mailing lists and in the database and dns working group meetings in Dublin. Carol Orange RIPE NCC --------------------------------------------------------------------- RIPE Database Referral Mechanism for Domain Queries - A Proposal Carol Orange & Wilfried Woeber, April 1997 ------------------------------------------ In the following, we propose a mechanism for forwarding whois queries to the appropriate database if the RIPE database does not contain the authoritative data for a given tree in the DNS name space or subset thereof. It is thus applicable for the "domain" object only: domain: [mandatory] [single] descr: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] zone-c: [mandatory] [multiple] nserver: [optional] [multiple] sub-dom: [optional] [multiple] dom-net: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] mnt-lower: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] The goal of the mechanism is to provide a means for TLD domain administrators (and other "high-level" domains) to enable users to obtain an authoritative response for a domain object query sent to the RIPE database, regardless of whether the data for the domain is maintained in the RIPE database itself. Algorithm --------- If the following query is submitted to the RIPE database: whois [flags] xxx.yyy.zz the algorithm will work as follows: ------- NAME="xxx.yyy.zz" until (NAME = "") { If object with domain = NAME found, If object contains referral (see "Referral" below) forward query (see "Forward" below) Else return object Else Strip(NAME) (xxx.yyy.zz -> yyy.zz, etc) } NOTES ----- 1. We move up the tree here, and return the next level answer if present. If the query requests "tuintje.cwi.nl" (Piet, do you mind?), they currently get "No entries found ...". In the new mechanism, they would get: domain: cwi.nl . . . mnt-by: NL-DOMREG changed: hostmaster(a)domain-registry.nl 19950227 source: RIPE Moreover, if the object for cwi.nl contains a referral, the query would be passed on to the specified server as explained below. 2. The algorithm will be set off by any query which causes a search in the domain object index. This means any query with "-T domain", or any general query (no -T flag) with something that "looks like a domain". Referral -------- A whois referral can be entered in a "refer" attribute by specifying the type of database in which the data is maintained, and the domain name of the server that should be queried: refer: <type> <host> <port> where <type> is one of RIPE, InterNIC or SIMPLE, indicating which style of whois service is provided. <host> is the DNS name of the whois service. <port> is the TCP port number (optional: 43 is the default). Examples: (CWI again): refer: RIPE domain-registry.nl 43 (InterNIC): refer: InterNIC whois.internic.net (Generic): refer: SIMPLE my.dns.tld Initially queries for the three types of databases shown here would be supported. If RIPE is specified, then the initial query together with all arguments would be passed to the specified whois server. If an InterNIC database is specified, then a query expected by the InterNIC database software would be generated for the specified domain name. The same would be true of "SIMPLE". In that case a simple query for the domain name would be passed on. If in the future, another domain name database is implemented with a given query language, it can be added. Forward ------- If the TLD object contains a whois referral, we can a) query the server, and pass the response to the requester, preceded by a comment of the form: "The following data has been obtained from domain-registry.nl". b) pass the referral to the requester c) send the query to the server with the address of the requester a) has the advantage of giving the user an immediate answer, and requires that only the RIPE database software be modified, not that of the TLD admins. Nothing has to be changed there. a) has the disadvantage that the RIPE server can become a bottleneck. However, local mirrors of referred to databases can be set up on a RIPE NCC server to alleviate this problem. Summary ------- We propose the above mechanism with (option (a) request forwarding) be used for TLD/domain referrals. We believe it will make the domain part of the database more transparent to users and easier to manage for TLD administrators. Acknowledgements ---------------- We would like to thank Chris Fletcher, Daniel Karrenberg, and David Kessens for useful comments.

3 6

Re: A DNS Database Referral Mechanism
by Wilfried Woeber, UniVie/ACOnet 14 May '97

14 May '97

Hi Carol, Blasco, Piet et.al.! >We actually discussed this point a bit in a slightly different light. >An important question is: should the forward type be up to the object >maintainer, to the whois server providing the referral (in this case >RIPE), or the whois client, or end user. > >As proposed here, it is the whois server, but could be modified in the >future to also be the whois client. > I think this touches on a line of discussion that we already began a while ago, but became forgotten later: What's the mechanism and who does maintain (e.g. supply, control, register) the necessary information? >The object maintainer can in fact always prevent automatic request >forwarding by putting the referral information in a remarks field. > >However, if such a mechanism should become popular, then it may be >suitable that whois clients be developed that can parse the refer >field and resend the request to the appropriate server. If we allow >the object maintainer to determine this in the <forward-type> field, >then it actually limits flexibility in the future. When and if we decide to eventually implement that flexibility (and we already had some private exchange on this aspect), then my first reaction would be to move that to some sort of maintainer object!? Initially, given the small set of affected objects, this can probably be sorted out infomally, but as soon as we open the flood gates... >Or is my thinking twisted? I don't think so, but mine might be :-) Wilfried.

1 0

A DNS Database Referral Mechanism
by Wilfried Woeber, UniVie/ACOnet 13 May '97

13 May '97

>Subject: A DNS Database Referral Mechanism >Date: Tue, 13 May 1997 10:44:31 +0200 >From: Carol Orange <Carol.Orange(a)ripe.net> Dear Carol! >Hi all, > >Below is a proposal put together by Wilfried Woeber and myself to >address the need for a referral mechanism for domain name queries in >the RIPE database. Thank you very much for putting that into proper wording and having it distributed to the groups. I feel it is appropriate to add that, while Carol and me did some finishing and sanity checking, we already received a considerable amount of very valuable comments and ideas from quite a few others. A big thank you to all of them! I thus urge the community to have a focussed discussion of the proposal, leading to a conclusion and implementation decision at the DNS & DB-WG meeting(s) is Dublin. Thanks, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)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 --------------------------------------------------------------------------

1 0

NIC-Handle Mandatory.
by RIPE Database Administration 06 May '97

06 May '97

Dear Colleagues, >From 15th May, new person objects must have a NIC-handle. Normally, RIPE nic-hdl's are used. RIPE format NIC-handle's may be obtained using the "AUTO-1" process (see below). If a person being registered in the RIPE database currently holds a registered NIC-handle assigned by the the InterNIC or the APNIC, it can be used as the NIC-handle in the RIPE database person object. If, in conjunction with the work on registry database exchange taking place in the RIDE working group of the IETF, the list of databases, and in particular the list of acceptable NIC-handles should be expanded or otherwise modified, the above statement will of course be modified accordingly. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration. How to get a RIPE NIC-Handle ------------------------- You can get a RIPE NIC-handle by putting the following in the NIC handle field of the person object update: nic-hdl: AUTO-1 OR nic-hdl: AUTO-1YourInitials The second case advises the database software to use YourInitials (no more then 4 characters) for build- ing the NIC handle while the first case asks the database software to find the initials itself. You can use the same identifiers (AUTO-1 or AUTO-1YourInitials) in the same update message in other objects as a reference. The database software will then fill in the freshly assigned NIC handles in the objects. Note that you can also use other numbers (example: AUTO-2) so that you can update more person objects and objects that reference the persons in one E-mail message. Example: domain: over.ripe.net admin-c: AUTO-1 tech-c: AUTO-2 [ ... stuff deleted ...] person: Ambrose Magee nic-hdl: AUTO-1 [ ... stuff deleted ...] role: RIPE DBM nic-hdl: AUTO-2 [ ... stuff deleted ...] N.B. To obtain a NIC-handle for a role object, use the same procedure as for a person object. Further information is available from: <http://www.ripe.net/docs/ripe-153.html> <ftp://ftp.ripe.net/ripe/docs/ripe-153.ps> <ftp://ftp.ripe.net/ripe/docs/ripe-153.txt>

1 0

Inaddr Robot <auto-inaddr@ripe.net>
by Carol Orange 22 Apr '97

22 Apr '97

Dear All, First off, my apologies to all who get more than one copy of this message. I'm hoping not to miss anyone who may be effected. As many of you may know, we have long been planning to more fully automate our inaddr robot <auto-inaddr(a)ripe.net>. Well, we've gotten around to it and are happy to announce we will soon be doing almost all processing automatically, with just a touch of human intervention at the end to make certain our robot behaves as expected. The result will be a substantial reduction in rather tedius work for the NCC staff, and consistent short response times (one working day) for inaddr requests. The new robot, programmed by Mal Morris, will be installed on *** Tuesday, May 6, 1997 *** It is essential that users take the following changes into account: 1. The domain or inetnum database object must be in the RIPE database before the request is submitted to <auto-inaddr(a)ripe.net>. 2. As is required in ripe-140 (Section 3.4.2), the "status" field must be filled in properly for any inetnum associated with the request. The robot will complain and fail if either of these does not hold. We hope the new robot serves you well, Carol

1 0