- db-wg - mailman.ripe.net

Meet Debbie, the RIPE Database Robot!
by Sandra Bras 24 Sep '12

24 Sep '12

[Apologies for duplicates] Dear colleagues, RIPE NCC E-Learning is pleased to introduce you to Debbie, the RIPE Database Robot. Debbie is your guide through a new series of e-learning videos designed to help you get the most out of the RIPE Database: http://www.ripe.net/lir-services/training/e-learning/ripe-database The RIPE Database e-learning collection has also expanded with the addition of three new videos: - Create More Specifics (Hierarchical Authorisation) - Create IPv4 Assignments - Create IPv6 Assignments There are now eight brief video tutorials (most around three minutes duration) giving step-by-step instructions for users to perform a range of different operations in the RIPE Database. If you have any comments or questions, please send an email to <e-learning(a)ripe.net>. Happy learning! Sandra Bras Trainer / E-Learning Project Manager, RIPE NCC

1 0

status and use/fulness of the geoloc: attribute
by Wilfried Woeber 19 Sep '12

19 Sep '12

Dear DB-Folks, in preparation for the upcoming WG Meeting in Amsterdam, and following up on dicussions during the previous one, I'd like to start the review and discussion on the geoloc: attribute in IPv4 and IPv6 inetnum objects. To get things going I'd like to solicit input from people and entities who/which have populated objects, and those making use of the information. What was your experience? Is this stuff useful? On a more general basis I'd like the community to review the current (sort of experimental) functionality and comment on the problems - if any - or suggest improvements! At the same time I am asking the NCC to provide us with some insight on the current use of this attribute. Thanks, Wilfried.

5 6

New on RIPE Labs: Registration History for Members - A Demo
by Mirjam Kuehne 17 Sep '12

17 Sep '12

[apologies for duplicates] Dear colleagues, Please see a new article on RIPE Labs describing a way to look at registration history in RIPEstat. This is a first demo and is only available to members: https://labs.ripe.net/Members/dfk/registration-history-for-members-a-demo Please note the request for feedback at the end of the article. Kind regards, Mirjam Kuehne RIPE NCC

4 5

RIPE65 DB-WG Draft Agenda V1
by Wilfried Woeber, UniVie/ACOnet 10 Sep '12

10 Sep '12

Dear DB-WG folks, Chairpersons, "Meeting"! This is the 1st draft of an agenda for the DB-WG at RIPE65 in Amsterdam, September 26, 2012. For time slot allocations please refer to the most up-to-date meeting plan at http://ripe65.ripe.net/programme/meeting-plan The DB-WG Meeting is scheduled for *Wednesday*, starting at 09:00 local time / 07:00 UTC in the morning. The length of our timeslot is 90 Minutes. The overall (draft) RIPE 65 meeting outline is already available at https://ripe65.ripe.net/programme/meeting-plan/ Please feel free to propose additional topics to be discussed! I'd also suggest that you submit your points of view regarding the topics on the proposed agenda on the mailing list, preferably before the WG meeting's start :-) Best regards, hope to see you soon in Amsterdam (which happens to *not* be in Slovenia :-) as I have been told ), Wilfried. ________________________________________________________________________ A. Administrative Matters . Welcome . select scribe . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list B. Data Base Update (N.N., RIPE NCC) C. Discussion GeoLoc data in the DB (WW144) - status, statistics, use - use / usfulness? D. Status update on IETF WEIRDS activities (Olof Kolkman, t.b.c.) Y. Input from other Working Groups and/or Task Forces Z. AOB ________________________________________________________________________

1 0

Call for agenda items, DB-WG Meeting during RIPE65, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 03 Sep '12

03 Sep '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear DB-WG folks, planning activities for the next RIPE Meeting - RIPE65 in Amsterdam, NL, September 24 - September 28, 2012, have already started a while ago - thus this _call for agenda items_ for the meeting of the Database Working Group. Please submit (to the WG list!) your item requests and|or suggest topics for discussion to be included in the draft agenda! Please note that the DataBase-WG meeting is *at the moment* scheduled for *Wednesday* (starting at 9:00 local time). This is according to the *draft* meeting plan - which is pretty stable already but may still need to be changed as we get closer to the meeting date! The overall (draft) RIPE 65 meeting outline is already available at https://ripe65.ripe.net/programme/meeting-plan/ Looking forward to a successful meeting and see you soon in Slovenia, Wilfried. PS: although the meeting is in Amsterdam, this time it is *not* at the Krasnapolsky, in the city center. Please consult the meeting pages! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQCVAwUBUESqFd/RXX7wrLNpAQJL5wQAqFgVPVkB5WEtkMQQ0qz+8CEu6L1inVXS gsbFit2L7IZddtQUtmHIJEHV4MPvHMglSfJlmA3x2dAX68mDtohjgy1yfrxx7mBu /IfcBIckExYX3ROCYEO/v7cQarreZnuIF4Vt0D7d96fS8e9uOwJoBytDCSMewSaq 3TWrDVpfu08= =ooqk -----END PGP SIGNATURE-----

1 0

Update of mntner object with mixed authentication
by Alexander Gall 29 Aug '12

29 Aug '12

I'm trying to update the "shared" 6to4 anycast-relay maintainer object RFC3068-MNT. My own authentication for the object is PGP. But how the heck do I get a full copy of the object including the other people's MD5 hashes if I don't have a password myself? Puzzled, -- Alex

5 6

Deprecation of DOMAIN object attributes
by Denis Walker 21 Aug '12

21 Aug '12

[Apologies for duplicate emails] Dear Colleagues, At RIPE 62, the RIPE NCC was asked to look at the attributes in DOMAIN objects. A suggestion was put forward to deprecate the following attributes: mnt-lower: sub-dom: dom-net: refer: These were considered to be of no use after the removal of forward domain data and no longer allowing hierarchical, reverse delegation data. The RIPE NCC is now removing these attributes from the syntax. It will no longer be possible to create objects with these attributes. To modify objects already containing them, these attributes will need to be removed. As a follow up the RIPE NCC will "clean" the reverse delegation and ENUM DOMAIN object data to remove these attributes. The web forms for both updates and queries will also have these attributes removed. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

New delegation checking software
by Anand Buddhdev 08 Aug '12

08 Aug '12

[Apologies for duplicates] Dear colleagues, Tomorrow, 8 August 2012, the RIPE NCC will deploy a change to the RIPE Database update software. As part of this deployment, we will switch to a new DNS delegation checker, developed by .SE, the Swedish domain name registry. This change should not have any impact on the process of registering a reverse DNS delegation in the RIPE Database. However, the informational and diagnostic messages this software returns will look different from the ones you have been seeing so far. There should be no noticeable outage in any of the services during this deployment. There will be no change to any other parts of the RIPE Database update or query software with this deployment. Along with these changes to the back-end software, the RIPE NCC will also update the web-based delegation checker at: http://www.ripe.net/data-tools/dns This new web-based delegation checker will use the same software as the back-end. We will send another announcement after we have deployed this new software. If you have any questions or comments, please send an email to <dns(a)ripe.net>. Regards, Anand Buddhdev RIPE NCC

1 1

Support for SHA256 in ds-rdata checker
by Alexander Gall 02 Aug '12

02 Aug '12

I'm not sure whether this belongs here or in the dns-wg (or somewhere else?). I just updated the ds-rdata of one of our domain objects and realized that the RDNS checker does not support SHA-256, neither for the DS record nor as part of signature algorithm 8 (RSASHA256) ***RDNS: (related to set) INFO: 6199 8 2 03A50B02CC5FCBCC8071AD93212C923E8C399DE64AE7C042442E2DE2F0029592 ; uses a Digest type that is not implemented by this checker. We cannot verify if the chain of trust is intact. You should be conciously using digest types other than SHA1 ***RDNS: (related to ns2.switch.ch) INFO: The signature over DNSKEY is made with algorithm code 8 The checker does not implement this algorithm and can therefore not validate the chain of trust It is assumed that using algoritm type 8 is a conscious choice. SHA256 has been in use for both purposes for a number of years. Are there any plans to support it in the RDNS checker? Regards, Alex -- SWITCH Serving Swiss Universities -------------------------- Alexander Gall, Global LAN Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 15 22 alexander.gall(a)switch.ch, http://www.switch.ch

2 2

Syntax of the "nserver:" Attribute in Domain Objects
by Anand Buddhdev 27 Jul '12

27 Jul '12

[Apologies for duplicate emails] Dear colleagues, Following on from the removal of the forward DOMAIN objects from the RIPE Database, all DOMAIN objects are now used for either reverse DNS or ENUM delegations. For both these cases, the "nserver:" attribute is required. Currently this attribute is optional and there are many objects in the RIPE Database that do not have any "nserver:" attributes. These objects are ignored by the DNS provisioning service, because they have no operational value. The RIPE NCC proposes to make the "nserver:" attribute mandatory in DOMAIN objects and delete any objects from the RIPE Database that do not have this attribute. To simplify the parsing of DOMAIN objects, the RIPE NCC also proposes to deprecate the list option on the "nserver:" attribute (a list, when used in combination with end-of-line comments and continuation lines, is very complex to parse). This means adding multiple name servers to a single attribute will no longer be allowed. For example, an attribute currently formatted as: nserver: ns1.example.com ns2.example.net will have to be rewritten as: nserver: ns1.example.com nserver: ns2.example.net If glue records are required, they would be written like this: nserver: ns1.2.0.192.in-addr.arpa 192.0.2.1 nserver: ns1.2.0.192.in-addr.arpa 2001:db8::1 nserver: ns2.2.0.192.in-addr.arpa 192.0.2.2 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2 There are a number of domain objects in the RIPE Database which use the list feature, and list multiple name servers in a single "nserver:" attribute. As part of this syntax change, we would update these objects to use the new syntax. This would not affect DNS delegation in any way. This message has been sent to both the DNS and Database working groups, but we ask that discussion of this matter be kept on the DNS WG mailing list. Regards, Anand Buddhdev RIPE NCC

1 0