January 2004 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

abuse-c: proposal
by Niall O'Reilly 30 Jan '04

30 Jan '04

Co-authors: Randy Bush, Niall O'Reilly Proposal for Adding Abuse Contact to inet*num: Objects in RIPE Database Requirement: Net users who perceive abuse from some net source wish to contact some service which has officially agreed to deal with the abuse. Currently, they seem to scan the inet*num: objects and send mail to any or all contacts in that object, including strange things such as the email address in the changed: attribute. This need seems to be clearly applicable to the inetnum: and inet6num: objects, so those objects are addressed by this proposal. Should there be similar needs in other object types, it is anticipated that the abuse-c: attribute would be added to those objects as appropriate. Two things are needed: o The inetnum: and inet6num: objects are enhanced with an optional attribute "abuse-c:". The value of the attribute is a nic-handle: which must refer to an extant person: or role: object. There may be zero or more abuse-c: attributes in an inet*num: object. The value of the abuse-c: attribute MAY be extended by appending a hint string. This is expected to be useful to organizations who wish to advertise more than one abuse contact, and to give guidance as to which of these is the appropriate notification target in particular circumstances. In case a hint string is specified, it MUST be discarded when forming inverse keys. Therefore, the syntax of the inetnum: object would become inetnum: [mandatory] [single] [primary/lookup key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] o Document and Publish that the abuse-c: contact is the one and only contact that should be used to report spam and other forms of abuse. This documentation should be made prominently available so that manual seekers and creators of automated reporting tools will all clearly know that the abuse-c: is the one and only place at which abuse should be reported, and that other contacts in the objects should not be abused. The documentation should make it clear that automated reporting tools MAY always ignore the hint string, but SHOULD search the advertised abuse-c: attributes to find a hint string that matches the circumstances of the abuse to be reported. The hint string specified SHOULD be taken from a limited vocabulary. This vocabulary SHOULD be reviewed from time to time. It contains initially the following terms, treated as case-insensitive, and with the indicated semantics: '' Always notify this contact 'Spam' Notify this contact for spam abuse ONLY 'Security' Notify this contact for DDoS and intrusion abuse ONLY -- End --

12 32

Re: [db-wg] abuse-c: proposal
by Niall O'Reilly 29 Jan '04

29 Jan '04

Ulli, On 29 Jan 2004, at 14:03, Ulrich Kiermayr wrote (privately): > What is the difference between the following to answers from the > database (One with the existing Machine [ changing the default answer > behaviour] and one following the proposal): I want to share my response with the list. No difference between the answers. The difference is in the cost to (effort for) a netadmin in setting up the IRT stuff. Marco's statistics, as I understood them, seem to bear this out: there is a ratio of 2 orders of magnitude between the instances respectively of IRT references and free-text remarks about abuse notifications. I'm close to convinced that the IRT approach is correct, elegant, and the rest. I just find it too much trouble to use: I need it to be much easier than that to advertise my abuse contacts. As the saying goes, "Le mieux est l'ennemi du bien." Make it barely good enough, but simple; then we'll see it adopted. Niall PS. "Daddy, what does 'feature creep' mean?"

1 0

[announce] releasing a tool to help LIR visualizing IPv4 LIR-as signments vs RIPE-allocations
by TAYON, Julien 28 Jan '04

28 Jan '04

Hello, LDCOM Networks/N9uf telecom release its tool ripe_wrap. Its purpose is to enable a LIR to make a cross view between Assigned inetnums (such as seen when making a whois request) and the "netnames" allocated by the RIPE (such as seen through the lirportal). It gives usefull information such as biggest available holes per ip-range, % of assigned space over the space that was declared for a netname. Since LDCOM is not a software editor, it has been decided to release our tool under Afferro GPL licence. Temporarily, its location is http://www.julbox.net/ripe_wrap-1.0.tgz I use it every day and I think it is quite fine, but I made no intensive test. Please report to the author(s) (see AUTHORS) any bug(s) and suggestion. Our main gool is to build a toolbox for a LIR to work on its RIPE informations without hosting any Database by crossing various informations such as the configuration it have on its network equipments. Beware, first access is slow since it makes requests to the web and then sort out the data. We will think of a way to improve this ... later. Friendly, -- Julien Tayon - N9uf Telecom - BU DATA - +33 1 70 18 14 45

1 0

draft agenda (V1) for DB-WG meeting, RIPE 47, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 22 Jan '04

22 Jan '04

[ for whatever reason, this message of Jan.16th didn't leave the mail ] [ system to be distributed to all the intended recipients... :-( ] _______________________________________________________________________ Dear DB-WG community, below please find V.1 of the draft agenda for the DB-WG meeting at RIPE47 in Amsterdam, NL. Could every individual or group mentioned in the list of topics please check the lengh of the timeslot allocated and/or reply _to me privately, pls._ with information missing or change requests. If you want to see modifications made to the list of topics, then pls. send or cc: to the list. Pls. let me know asap if I missed any of the topic proposals or requests. If so, it was not done on purpose!! Just FYI, most probably I am not going to have access to my email between later today (Fr. 16.1.) and next Thursday, so I'll be slow in responding :-( Looking forward to see many of you in Amsterdam! Wilfried. ++++++++ A. Administrative Matters - scribe - list of participants - agenda - minutes B. DB Operational Update (N.N., RIPE NCC) [~20 min] C. ERX (Leo V., RIPE NCC) [~15 min] D. X.509 support implementation (N.N., RIPE NCC) [~10 min] E. CRISP/Joint-Whois status (Shane K.(?), RIPE NCC) [~15 min] F. Getting rid of auth NONE (N.N., RIPE NCC) [??? min] G. irt: / abuse: [60+ min] - populating inet[6]nums w/ irt links, DFN, SURFnet (Jan M./Marko T.) - abuse-c: discussion and proposal summary (MarcoH, mch2-ripe) - whois server: review of (default) behaviour & format (WW144) - how to get the other WGs involved? Spam? Routing? (WW144) H. RPSLng status and deployment (Simon L., SWITCH) [~20 min] G. S/MIME support (Denis W., RIPE NCC, t.b.c!) [~10 min] H. BCP on "use of the Registry Database"?? (WW144, t.b.c) [~15 min] Y. Input from other WGs Z. AOB --------------------------------------------------------------------------------

1 0

DNS Related Policy and Procedure Proposals
by Olaf Kolkman 22 Jan '04

22 Jan '04

Dear Colleagues, Apologies for duplicate mails. Shortly after this mail we will be sending two separate mails to the DNS Working Group mailing list. We will also be posting a draft policy document (see below). These mails also have relevance to the RIPE NCC Services and Database Working Groups. The two messages and revised policy document are part of a project started in October 2003 to streamline and simplify the process of requesting and managing reverse DNS delegation for the holders of the address space allocated or assigned by the RIPE NCC. The original proposal can be found at: http://www.ripe.net/reverse/proposal.html The content of the mails are: - A proposal for the introduction of a new "mnt-domains:" attribute in INETNUM objects to authorise the creation of DOMAIN objects. This proposal also suggests making "mnt-by:" a mandatory DOMAIN object attribute. This authorisation mechanism will enable address space users to delegate the responsibility for maintaining reverse address space to third parties in a flexible manner. - An assessment of the consequences of the introduction of the "mnt-domains:" attribute and of the "mnt-by:" attribute being made mandatory. The reverse delegation policy has been revised, relaxing the terms under which reverse delegation will be serviced and providing the framework to implement the authorisation mechanism described above. The draft "Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region" can be found at: http://www.ripe.net/ripe/draft-documents/reverse-draft-200401.html We would like to invite your comments on this. Please discuss these proposals on the DNS Working Group mailing list. More information can be found at: http://www.ripe.net/reverse/rdns-project/ -- Olaf Kolkman New Projects Group RIPE NCC

3 2

abuse-c
by Rev Adrian Kennard 14 Jan '04

14 Jan '04

Following up my own mail... > Also, the "trouble" field is a good thought - maybe we should add > "trouble" to inetnum, as there is already a field name defined for the > purpose essentially. Just an idea. "trouble" is not really the answer as it is freeform. It needs to be a syntax checked email address. abuse-c to a person/role object seems sensible. -- Rev Adrian Kennard Andrews & Arnold Ltd / AAISP www.aaisp.net.uk

8 25

RE: REMINDER - RIPE 47 Agendas
by Wilfried Woeber, UniVie/ACOnet 14 Jan '04

14 Jan '04

This is the very crude V0 for the draft agenda, DB-WG at RIPE47 in Amsterdam. Please expect a somewhat better polished version by tomorrow or Friday. But pls. let me know asap if I missed any of the topic proposals or requests. If so, it was not done on purpose!! ++++++++ Chair Agenda Format: A. Administrative Matters - scribe - list of participants - agenda - minutes B. DB Operational Update (N.N., RIPE NCC) C. ERX (Leo V., RIPE NCC) D. X.509 support implementation (N.N., RIPE NCC) E. CRISP/Joint-Whois status (Shane K.(?), RIPE NCC) F. Getting rid of auth NONE (N.N., RIPE NCC) G. irt: / abuse: discussion (MarcoH, mch2-ripe) H. RPSLng status and deployment (Simon L., SWITCH) G. S/MIME support (Denis W., RIPE NCC, t.b.c!) H. BCP on "use of the Registry Database" (WW144, t.b.c) Y. Input from other WGs Z. AOB A you can see we are goi8ng to have a pretty long program list :-) -------------------------------------------------------------------------------- Wilfried.

1 0

Erroneous Domain Cleanup Messages
by Olaf Kolkman 13 Jan '04

13 Jan '04

Dear Colleagues, Apologies for duplicate mails. == Introduction We recently informed the Working Groups about the start of a cleanup of inconsistencies between data in our reverse DNS and data in the Whois Database [1]. Since Wednesday 7 January, 2004 we have been sending out warning messages. Unfortunately a number of messages were sent out in error. == The Problem Due to a bug in the script, messages have been sent to contacts for /24 DOMAIN objects that have a more specific /16 object, stating that there are no matching NS RRs in the zone files and that the DOMAIN object will be deleted. This has been done in error and these DOMAIN objects will remain unaltered. The contacts for these /24 DOMAIN objects will be sent a message shortly confirming that their objects will remain unaltered and that no further action is required on their part. == Background The Whois Database holds informational data for domains in the reverse tree. The database holds information about reverse domains corresponding to /8, /16 and /24 address space. The '/8 domain' zone files at the RIPE NCC only contain NS RRs for the delegation corresponding to the most less specific address block. If there is a /16 DOMAIN object and a number of more specific /24 DOMAIN objects in the database only a delegation will be created corresponding to the /16 DOMAIN object. In other words, if the /16 domain has been delegated one cannot delegate its children any longer. Therefore, the absence of the NS resource records corresponding to the "nserver:" attributes in the /24 DOMAIN objects is not an error. Note: for End Users it is not obvious if an NS RR is in the zone files of the RIPE NCC since ns.ripe.net is a secondary DNS server for the /16 zones. Our apologies for any confusion and extra work this may have caused. For further clarification please do not hesitate to contact <ripe-dbm(a)ripe.net>. --Olaf Kolkman New Projects RIPE NCC [1]: http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00000.html Further information about the cleanup project can be found at: http://www.ripe.net/reverse/rdns-project/cleanup.html

1 0

Re: [db-wg] Defined roles
by Wilfried Woeber, UniVie/ACOnet 13 Jan '04

13 Jan '04

>> I don't have any problem with the concept of an abuse-c:, in whatever >> colour, shape or texture. the real problem that I (still) have after so >> many years is that we still lack a definition of "abuse", and which part >> of an organisation is supposed to deal with the "abuse". >> >> Also note that usually there is an aspect of "incoming" and >> "originated" abuse. > >In that case, db-wg will only supply the tools and not make any decision >on the contents or the usage and we should get other working groups >involved in this (anti-spam ?). Indeed. >However in some sort of way, the information in the database is 'abused' >by users in the way that they don't use the correct attributes. This in >some form can be explained as the current tools lacking some functionality >or being to complex to use for the larger public. I agree. >So what we need to decide on is whether there is a problem and users will >gain something if we add some functionallity to the system. > >I think that the usability of the system is on-topic for this working >group definitely > and as far as my personal opinion goes, we need to do something >extra to stop people from 'abusing' certain information before the >majority decides that it's a lost game and start removing information >which is usefull for other parts of the work like troubleshooting 'the >internet'. Private opinion: I am one of those who think it is a lost case already. How long has the info in changed: been abused to spam the folks for the address distribution, who simply update a record in the DB, with spam and port scan and xyz complaints? >We don't have to go further then to specify you can include only 1 valid >email address and advice people to insert the address where they want to >recieve the complaints and if you query the database for this information >use this field as a default. > >MarcoH Wilfried.

1 0