- ncc-services-wg - mailman.ripe.net

Maintaining DOMAIN objects
by Denis Walker 16 Oct '08

16 Oct '08

[Apologies for duplicate emails] Dear Colleagues, The RIPE Data Protection Task Force advised the RIPE NCC that all objects in the RIPE Database should be maintained. Maintaining Routing Policy Specification Language (RPSL) objects in the RIPE Database was optional for PERSON, ROLE and DOMAIN objects. All the DOMAIN objects in the RIPE Database are now maintained and protected. As there may have been a possibility to exploit this data if any advance warning had been made, the RIPE NCC did not publicly announce that it was going to add maintainers to unmaintained DOMAIN objects before doing so. For further details of what was done, please see this web page: http://www.ripe.net/db/support/security/domain/syntax.html Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Outage report for updates to the RIPE Database
by Denis Walker 13 Oct '08

13 Oct '08

[ Apologies for duplicate mails ] Dear colleagues, >From approximately 19:41 (UTC) to 20:15 (UTC) on Friday, 10 October 2008, some e-mail update messages to the RIPE Database service, auto-dbm(a)ripe.net, were not processed due to a problem with our system. During the same period it was not possible to connect to the syncupdates or webupdates services. All the messages received by auto-dbm(a)ripe.net were stored on our mail server. The problem was resolved on Friday evening. All the saved update messages have been processed. If you sent an e-mail update to the RIPE Database service during this period, you will have already received an acknowledgement message. There is no need to re-send any update messages. We apologise for any inconvenience that this may have caused. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Reverse DNS lameness alerts
by Anand Buddhdev 01 Oct '08

01 Oct '08

[Apologies for duplicate emails] Dear Colleagues, Some of you received email messages last month from the RIPE NCC with alerts about lame DNS servers. These messages were generated as part of the RIPE NCC's DNS lameness project. Unfortunately, the alerts were not entirely correct, and showed all the servers of some reverse zones as lame. This was caused by programming errors in the software that produced the messages. We have identified these errors, and we are correcting them. We are also introducing additional tests and safeguards to improve the quality of our DNS lameness measurements. For more information on the RIPE NCC's DNS lameness project, please see: http://www.ripe.net/info/stats/dns-lameness/ Regards, Anand Buddhdev DNS Services Manager, RIPE NCC

1 0

Agenda Items for RIPE57
by Sanghani, Bijal 22 Sep '08

22 Sep '08

Dear All, It's about 5 weeks till the RIPE meeting in Dubai and we've started compiling items for the draft agenda for the NCC Services working group. If anyone would like to suggest a presentation or raise a topic for discussion please let either Kurtis or me know and we'll arrange a spot on the agenda for you. Kind Regards Bijal Sanghani Senior Engineer - Technical Services Group Reliance Globalcom (UK) Ltd Sovereign Court, 635 Sipson Road, West Drayton Middlesex, UB7 0JE, UK Direct: (+44) 020 8282 1564 | FAX: +44 208 282 1566 E MAIL: bsanghani(a)relianceglobalcom.com <mailto:bsanghani@relianceglobalcom.com> | URL: www.relianceglobalcom.com <http://www.relianceglobalcom.com> IMPORTANT - Please note the change of my email id from bsanghani(a)flagtelecom.com <mailto:bsanghani@flagtelecom.com> to bsanghani(a)relianceglobalcom.com <mailto:bsanghani@relianceglobalcom.com> Disclaimer : Please note that Flag Telecom is now Reliance Globalcom. Accordingly, our Emails IDs have also changed from xyz(a)flagtelecom.com to xyz(a)relianceglobalcom.com.

1 0

spurious(?) revDNS lameness alerts?
by Wilfried Woeber, UniVie/ACOnet 06 Sep '08

06 Sep '08

Dear colleagues, has anyone (other than myself) received an alert message from the NCC regarding "lameness" of revDNS zones for IPv4 and IPv6 PA allocations? At first glance the alerts seem not to be justified, at least not as seen from my end. Thanks for any feedback, on-list or private, Wilfried.

2 1

Upgrade of the reverse DNS provisioning system at 8 September 2008, between 09:00 and 12:00 (UTC)
by Wolfgang Nagele 03 Sep '08

03 Sep '08

[Apologies for duplicate emails] Dear Colleagues, On 8 September 2008, between 09:00 and 12:00 (UTC), the RIPE NCC will upgrade the reverse DNS provisioning system. This change will enable the server ns.ripe.net to perform zone transfers over IPv6. If your reverse zone has a master server with an IPv6 address, this will be used in preference to the IPv4 address after the change. We apologise for any inconvenience this change may cause. If you have any questions or concerns about this, please email <dns-help(a)ripe.net>. Regards, -- Wolfgang Nagele DNS System Engineer RIPE NCC Singel 258 1016 AB Amsterdam Tel: +31 20 535 4444 Fax: +31 20 535 4445

1 0

Planned maintenance on ns.ripe.net, 2 Sept.
by Sjoerd Oostdijck 01 Sep '08

01 Sep '08

[Apologies for duplicate e-mails.] Dear Colleagues, On Tuesday, 2 September 2008, the RIPE NCC will perform maintenance on the ns.ripe.net server between 10:00 and 12:00 (UTC). During this period, it may not be able to answer DNS queries. The aim of this maintenance is to introduce a second server to improve performance of the system. If ns.ripe.net provides secondary DNS name service for your zone, no changes on your side will be required. During the maintenance, other servers in your NS set will take over and no downtime will be visible to the Internet. We apologise for any inconvenience this maintenance may cause. If you have any questions or concerns about this, please email dns-help(a)ripe.net Regards, Sjoerd Oostdijck DNS Services The RIPE NCC

1 0

from Kazakhstan
by Асель Нурушева 26 Aug '08

26 Aug '08

Hello, We have LIR-status (Asia, Kazakhstan). We have address space IPv/19 (see Application 1, described below), DNS and AS-number (ASN-15549 ticket NCC#200073996 for BankNet Data Network). Unfortunately, we did not use address space (Assigned and Allocation) and AS (autonomous system) for a long time. Now we decide to use own address space and to announce (route) it in the Internet. We have all necessary equipment for it (routers, switches, firewalls, servers, workstations). We service all state structures of Kazakhstan Republic, as we need to announce the networks in all cities of country. Please refresh the information about AS-number if it's really. How can we use address space? What will you advise for us? Our specialists (staff) need to learn all LIR-training courses (Local Internet Registry Training Course, DNS for LIRs Training Course, Routing Registry Training Course). Now we are registered on courses in Great Britain on September, 10th, but it is very far and expensive to one-day course. Could we have learning courses in our country (Astana, Kazakhstan). It's very important and urgent for our company. Thanks for information Yours faithfully, Cherepanov Dmitriy the Management director JSC "National Information Technology" www.nitec.kz T: +7 7172 741152 F: +7 7172 741064 E: <domain(a)nitec.kz> If you need more information feel free to contact me. Application 1. Assignment Window History Date Prefix Size Ticket No. 19970724 - 0 19990622 /27 32 NCC#1999063055 Allocations Made by RIPE NCC to kz.banknet Date IP / Prefix Size Status Ticket No. 19970806 195.12.96/19 [Edit Object] 8192 PA Assignments Approved by RIPE NCC Date Size Netname Ticket No. 19970806 /24 (256) IFTC NCC#1997080422 19971209 /24 (256) KISC NCC#1997123015 19971217 /24 (256) GATU NCC#1997112703 19990122 /27 (32) KSISTI NCC#1999016891 19990415 /27 (32) IFTCPETR NCC#1999040390 19990420 /27 (32) IFTCKOST NCC#1999040668 19990622 /27 (32) IFTCPAVL NCC#1999063055 19990705 /28 (16) IFTCTALD NCC#1999063704 19990712 /27 (32) IFTCUSTK NCC#1999073974 19990830 /27 (32) AERUSTK NCC#1999085469 19990913 /26 (64) KIPAVL NCC#1999096599 19990923 /27 (32) IFTCAKMO NCC#1999097029 20000726 /27 (32) IFTCAKTA NCC#2000073813 20000808 /27 (32) IFTCAKTOBE NCC#2000074333 20000829 /27 (32) IFTCATYR NCC#2000085434 20000928 /27 (32) IFTCKARA NCC#2000097312 20001110 /27 (32) IFTCKORDA NCC#2000110878 20001116 /27 (32) IFTCSEMEY NCC#2000111563 20021023 /24 (256) IFTCAKMO NCC#2002101657

2 1

RIPE Database legal documents
by Denis Walker 28 Jul '08

28 Jul '08

Apologies for duplicates] Dear Colleagues, The RIPE Data Protection Task Force (DP TF), working with the RIPE NCC and the company lawyers, has finalised a set of legal documents for the RIPE Database. These documents are: - RIPE Database Terms and Conditions - RIPE Database Acceptable Use Policy - Procedure for the Removal of Personal Contact Details from the RIPE Database They can be seen on the RIPE DP TF web page at this address: http://www.ripe.net/ripe/tf/dp/index.html The documents have been subjected to a final review by the DP TF but they are not yet legally effective. They are now available for review and comments by the wider community. Please let us know if you have any considerations or issues. Please bear in mind that with any documents such as these, the wording can always be changed. However, we would prefer not to make any subjective changes at this stage but only amend anything that is inaccurate. The documents will become legally effective from 1 September 2008 and they will then be available on a new Legal Documents page on the RIPE NCC website. Regards, Denis Walker (on behalf of the RIPE DP TF)

2 1

Locally caching riswhois results
by Laurent Zimmerli 22 Jul '08

22 Jul '08

Hi list I'm making use of the riswhois service and would like to cache queries locally. However, I am not sure whether I can do it the way I want to. My idea is to store the ASN an the corresponding route of each query I execute. Before performing another query I would then check whether I already stored the ASN of a route which contains the IP for which I want to find the AS. Can I do that? Or is then the following case possible: I store an AS an its route -- say ASx, 123.0.0.0/8 -- whose IP range includes another one -- say ASy, 123.100.0.0/16. When I store ASx first and then query an IP of ASy, I will assign ASx to this IP instead of ASy. Is such a case possible? Or is there even another problem with my caching approach? Thanks for your time! Best, Laurent

2 1