- db-wg - mailman.ripe.net

Announcement: Redirecting reverse DNS updates
by RIPE Database Manager 05 Dec '03

05 Dec '03

Dear Colleagues, From 8 December 2003, as part of the effort to streamline reverse DNS operations, domain updates that contain in-addr.arpa or ip6.arpa type entries sent to <auto-dbm(a)ripe.net> will automatically be forwarded to <auto-inaddr(a)ripe.net> for processing. This will continue until the two processes are combined into one. Such updates will be processed as follows: - If the update contains only domain objects whose "domain:" attributes end with 'in-addr.arpa' or 'ip6.arpa' , it will be redirected to: <auto-inaddr(a)ripe.net> - If the update contains a mixture of domain objects whose "domain:" attributes end with 'in-addr.arpa' or 'ip6.arpa', as well as other types of database objects, the message will be rejected. The user will receive an e-mail requesting that the objects be separated and re-submitted. - All other e-mails will be processed as normal. - It will not be possible to update these domain objects using syncupdates. Please don't hesitate to contact <ripe-dbm(a)ripe.net> for questions, comments or suggestions. Regards, -- Can Bican Software Engineering Department RIPE NCC

1 1

Domain Cleanup Proposal
by RIPE Database Manager 03 Dec '03

03 Dec '03

Dear Colleagues, A. Introduction This proposal is part of the effort to streamline reverse DNS operations [1] and make it easier for network range users to manipulate related domain objects. Local Internet Registries (LIRs) maintain their reverse delegations at the RIPE NCC through the use of domain objects. For several historical reasons there are a number of inconsistencies between the domain objects and the reverse delegation information in the DNS. Since we want to move to a system in which the Whois Database is the authoritative source for data that is published in the DNS (see [1]), there is a need to remove these inconsistencies. In this proposal, we will address the inconsistencies between data represented through the domain objects in the Whois Database and the reverse delegation data in our zone-files. We will also propose solutions to fix these inconsistencies. Note, this proposal is only relevant for domain objects that the RIPE NCC provides reverse delegation services for i.e. networks delegated to it by the Internet Address and Numbering Association (IANA) and networks transferred to the RIPE Database via the Early Registration Transfer (ERX) Project [2]. This proposal is NOT relevant to domains in the e164.arpa space. B. Type of Inconsistencies - Domain objects that have no delegation in the zone configurations: Reverse DNS-related updates to the RIPE database must be sent to <auto-inaddr(a)ripe.net>, otherwise zone configurations can not be updated. There are objects in the RIPE Database created via methods other than by sending an e-mail to <auto-inaddr(a)ripe.net>, causing this type of inconsistency. - Zone configuration entries that do not exist as domain objects in the RIPE Database: When zone files are updated manually, and not by sending an e-mail to <auto-inaddr(a)ripe.net>, this type of inconsistency occurs. - Conflicting entries in the RIPE Database and zone files: A mismatch between the "nserver:" attributes and the NS Resource Records (RRs) in our zone files occurs as a mixture of the first two inconsistencies. The domain object has been added or modified at one point via <auto-inaddr(a)ripe.net>, but then either updated manually or by <auto-dbm(a)ripe.net>. - Invalid domain objects in the RIPE Database: This type of inconsistency occurs in domain objects that can not map to a valid DNS entry. As an example, 8080.80.in-addr.arpa is an invalid entry. Only reverse address space mapping is taken into account. - Invalid "nserver:" attributes in the RIPE Database: "nserver:" attributes must contain hostnames rather than IP entries. This type of inconsistency occurs when one of the "nserver:" attributes does not contain a host name. C. Preventive remedies - Enforcing domain updates to <auto-inaddr(a)ripe.net> We are in the process of integrating <auto-inaddr(a)ripe.net> and <auto-dbm(a)ripe.net>, so that domain updates and other types of updates can be performed from the same source. Until then, in order to prevent further inconsistencies, updates sent to <auto-dbm(a)ripe.net> containing only reverse domain objects will automatically be forwarded to <auto-inaddr(a)ripe.net>. Updates that contain a mixture of domain and other types of objects will be returned to the user unprocessed, warning him/her to split the objects and resend. A separate announcement has already been sent to related mailing lists about this change. D. Clean-up of Inconsistencies The goal of the clean-up is to streamline the contents of domain objects and zone configuration files so that we can create zone files from the Whois Database. If choices have to be made about which data is more accurate , the data in the DNS has prevalence over the data in the Whois Database. The approach followed in the clean-up is to identify inconsistencies, notify the contact persons for the domain objects, provide them with a suggested fix and allow maintainers to fix their objects (details below). After about six weeks the RIPE NCC will send messages about inconsistencies still present in the system. Two weeks after this message has been sent, the RIPE NCC will apply the suggested fix to the domain objects automatically. - Domain objects that do not exist in zone configurations: Contact persons(*) in the domain object will be notified that the object will be deleted by the given deadline unless it is updated. This procedure will be followed even if the domain object contains valid delegation information. Resubmitting the object will ensure that a valid delegation is created in the DNS. - Zone configuration entries that do not exist as domain objects in the RIPE Database: The contact persons(*) in the less specific inetnum object will be notified that, at a given deadline, place holder records in the RIPE Database will be created for these objects. These can be overridden by the maintainer of the inetnum object. The notification contains a suggested domain object that can be modified and submitted before the deadline if the LIR does not want to have a domain object created automatically. - Conflicting entries in the RIPE Database and zone files: Contact persons(*) in the domain object will be notified that the object will be updated to reflect the contents of the delegation NS RR in the reverse zone files by the given deadline. They will be notified that they can fix these entries by updating them. The notification contains a suggested domain object that can be modified and submitted before the deadline if the LIR does not want to have a domain object modified automatically. The clean-up is not meant to solve lame delegation data (e.g. when the NS RRs at the parent side are different from NS RRs at the child side of a zone). Therefore the suggested domain object might not represent the actual set of authoritative nameservers and fail during submission by the maintainer. - Invalid domain objects in the RIPE Database: Contact persons(*) in the domain object will be notified that the object will be deleted by the given deadline. - Invalid "nserver:" attributes in the RIPE Database: Contact persons(*) in the domain object will be notified that the contents of the "nserver:" attributes will be replaced by the entries in zone files if there are any, otherwise the object will be deleted. One IP address may refer to many hostnames, therefore automatically replacing it with its host entry may be erroneous. *: Contact persons are defined by the NIC handles listed in the "admin-c:", "tech-c:", "zone-c:" and the "mnt-by:" attributes of the domain object. E. Timeline - 7/12/2003: Filtering domain updates to <auto-dbm(a)ripe.net>. Domain objects submitted to <auto-dbm(a)ripe.net> are redirected to the <auto-inaddr(a)ripe.net> interface. - 3/12/2003: An announcement will be sent to the Database WG and DNS WG mailing lists - January 2004:Listing inconsistencies and sending notifications to contact persons. - End of February 2004 (announced approximately two weeks before): Cleanup (creation of place holder records and synchronising conflicting entries) This timeline allows for a two month period in which customers are informed and have the opportunity to fix inconsistencies. The end of February milestone is tentative and may extended during the cleanup if unexpected problems are encountered. E. References [1]: Original proposal http://www.ripe.net/reverse/proposal.html. Discussion on this proposal has taken place on the RIPE NCC Services WG mailing list and was summarised in: http://www.ripe.net/ripe/mail-archives/ncc-services-wg/2003/msg00361.html [2]: Early Registration Transfer [ERX] Project http://www.ripe.net/db/erx/erx-ip/ Regards, -- Can Bican Software Engineering Department Olaf Kolkman New Projects Group RIPE NCC

1 0

Re: [db-wg] Proxy abuse
by Thor Kottelin 30 Nov '03

30 Nov '03

> db-wg-request(a)ripe.net wrote: > From: "CMC" <icaliber(a)voicenet.com> > People using proxies on IRC is getting out of hand. On the Undernet as > example, proxy users can abuse a chat channel; be properly banned and > then return with their real hostmasks... > > I realize that the above statement is very general, however if any people > who are channel operators on any IRC chat network have been experiencing > problems with proxies, is there any solutions that the membership can > offer? Channel modes +ikm +s. Bans; if you run out of space, use dynamic, bot-controlled ban lists. On the server level, proxy checks on connect, and K: lines for the worst offenders. (This isn't at all on topic for db-wg, so follow-ups should go elsewhere. Apologies to everyone.) Thor -- http://thorweb.anta.net/

1 0

Proxy abuse
by CMC 30 Nov '03

30 Nov '03

Hi Friends People using proxies on IRC is getting out of hand. On the Undernet as example, proxy users can abuse a chat channel; be properly banned and then return with their real hostmasks... I realize that the above statement is very general, however if any people who are channel operators on any IRC chat network have been experiencing problems with proxies, is there any solutions that the membership can offer? thank you, charles

1 0

RE: [db-wg] ACCESS to INVALID OBJECTS
by Wilfried Woeber, UniVie/ACOnet 28 Nov '03

28 Nov '03

Dear Allen Turner! >Hello, >For some time now we have been expecting to be given direct access to >INVALID OBJECTS via the LIR Portal. Thanks for bringing this to our attention! >This will be a useful tool for a large LIR to run in conjunction with >public Asused. > >Can we be given a realistic date when it's going to be made available? >It's introduction will save time for both LIR's & RIPE NCC. At first glance that seems to be more like an issue for the Services WG? Or are there anything "database technology"-related aspects to be taken care of? >Regards, >Allen Turner >uk.bt LIR Thanks, Wilfried.

1 0

Searching the RIPE Db
by ipmaster＠bt.com 28 Nov '03

28 Nov '03

Hi, When searching the Database using http://www.ripe.net/ripencc/search.html for previous assignments, it returns a list of INETNUM's without the date. I have to open each one individually to check if it has been assigned within the last 12 months. Q: Is their any way to display the changed line without opening each one individually, hopefully Dave Trickett +44 20 7555 8226

2 1

ACCESS to INVALID OBJECTS
by preston.dialip＠bt.com 28 Nov '03

28 Nov '03

Hello, For some time now we have been expecting to be given direct access to INVALID OBJECTS via the LIR Portal. This will be a useful tool for a large LIR to run in conjunction with public Asused. Can we be given a realistic date when it's going to be made available? It's introduction will save time for both LIR's & RIPE NCC. Regards, Allen Turner uk.bt LIR

1 0

Maintenance on RIPE Whois Server, 28 November 2003
by DB-News 27 Nov '03

27 Nov '03

Dear Colleagues, [apologies for duplicate messages] Tomorrow, 28 November 2003, we need to perform a maintenance work on the RIPE Whois Server for hardware replacement. During the maintenance work, - Whois Database updates will be stopped, - all update mails to auto-dbm(a)ripe.net will be queued to be processed later, - Webupdate and syncupdate interfaces will be unavailable, - The whois queries will _not_ be interrupted. The maintenance work will start at 07:00 UTC (08:00 Amsterdam time) on 28 November 2003, Friday, and expected to last 2 to 3 hours. We apologise for the inconvenience caused, and we are sorry for the short notice. Please do not hesitate to contact ripe-dbm(a)ripe.net for any questions. Best regards, -- Engin Gunduz Software Engineering Department RIPE NCC

1 0

Input for DB-WG agenda for Jan.2004 [was: First Call: RIPE 47 Working Group Agendas]
by Wilfried Woeber, UniVie/ACOnet 25 Nov '03

25 Nov '03

Dear DB-WG participants, >To: wg-chairs(a)ripe.net >From: Nick Hyrka <nick(a)ripe.net> >Subject: First Call: RIPE 47 Working Group Agendas >CC: meeting(a)ripe.net >Date: Tue, 25 Nov 2003 12:16:46 +0100 > >Dear RIPE Working Group Chairs, > >RIPE 47 is quickly approaching and we are now seeking your session agendas. Thus: Could you pls. let me know which topics you want to discuss during the Januray 2004 DB-WG meeting in Amsterdam?! Of course I'll work with the NCC and I will add the administrivia, but your input is essential to meet the "real" needs of the RIPE DataBase user community :-) Please forward suggestions to me directly [to keep down noise on the list], or to the list if you think an issue should be discussed in a broader forum starting _now_! TIA for your input, looking forward to see as many of you as possible in Amsterdam, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Announcement on "mnt-lower" changes in the RIPE Whois Database
by Katie Petrusha 17 Nov '03

17 Nov '03

[ Apologies for duplicate e-mails ] Dear colleagues, The following changes will become effective in the RIPE Whois Database starting from November 26, 2003. These changes are intended to make the database work more consistently, as well as provide an increased level of security and control to users. 1. When creating an inetnum, inet6num or domain object, the "mnt-lower:" attribute in the parent object must authorise the creation. If it is not present, the "mnt-by:" attribute must authorise the creation. This behaviour will allow a more secure hierarchical authorisation scheme in the RIPE Whois Database (similar to RPSS) for those object types. This change is implemented according to the following proposal: Proposed change 2003.0: default to protected inetnum/inet6num/domain http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00478.html RIPE NCC allocations that don't have "mnt-lower:" attribute will be affected by this change as they are maintained by the RIPE NCC. To prevent this, affected inetnum objects have been updated to include a "mnt-lower:" attribute. More details about this project are available at: http://www.ripe.net/db/allocations_mnt-lower_update.html 2. The "mnt-lower:" attribute will become optional for all set object types (as-set, filter-set, peering-set, route-set, and rtr-set). The "mnt-lower:" of the parent object attribute must authorise creation when hierarchical names are used. If it is not present, the "mnt-by:" of the parent object must authorise the creation. This change is implemented according to the following proposal: Proposed change 2003.4: "mnt-lower:" on set objects http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00482.html -- Katie Petrusha Software Engineering Department RIPE NCC

1 0