- dns-wg - mailman.ripe.net

RIPE 57 minutes
by Jim Reid 29 Apr '09

29 Apr '09

Here are the minutes from the WG sessions in Dubai. As before, apologies for the delay in circulating these.

1 0

RIPE 56 WG minutes
by Jim Reid 29 Apr '09

29 Apr '09

Apologies for the delay in circulating the minutes. Here are the minutes from RIPE56: the Berlin meeting.

1 0

Turning off lameness checks for reverse
by Shane Kerr 29 Apr '09

29 Apr '09

All, Is there any support for disabling lameness checks for reverse DNS? 1. It seems that they cause some annoyance to administrators. 2. As far as I know there has never been a study showing improvement for DNS users based on removing lameness in reverse DNS (or in any DNS). These two things suggest to me that the pro-active lameness checks should be disabled, at least until it is shown that lameness actually causes problems. Cheers, -- Shane

6 6

Deprecation of "rev-srv:" attribute
by Denis Walker 28 Apr '09

28 Apr '09

[Apologies for duplicate emails] Dear Colleagues, The RIPE NCC will begin implementing the deprecation of the "rev-srv:" attribute. This was discussed on the DNS WG mailing list and at the RIPE 54 Meeting in Tallinn, Estonia, during the Database Working Group session. More details are available at: http://www.ripe.net/ripe/maillists/archives/dns-wg/2007/msg00090.html The plan suggested on the mailing list will be used and there are three stages: - Stage 1: Announcement - Stage 2: Syntax change - Stage 3: Clean-up The details of each stage are outlined below. Stage 1: Announcement ---------------------- The announcement will let users know that the process is starting. Over the next month you will need to check any scripts that auto-generate INET(6)NUM objects. Make sure that no "rev-srv:" attributes are included in the generated objects. Stage 2: Syntax change ---------------------- This stage will begin on May 27 2009, when the RIPE NCC will remove the "rev-srv:" attribute from the RIPE RPSL syntax for INET(6)NUM objects. Any new objects created after this date must not have this attribute included. If any objects that include this attribute are modified, then the "rev-srv:" attributes must be removed. If you wish to keep the information for documentation purposes, change the"rev-srv:" attributes into "remarks:" attributes. The "rev-srv:" attribute will also be removed from the list of inverse query options. Stage 3: Clean-up ------------------ The final stage will begin before the RIPE 59 Meeting, which takes place from 5-9 October, 2009. The clean-up will remove any remaining "rev-srv:" attributes from these objects. They will be converted into "remarks:" attributes. If you have any questions about this, please contact <ripe-dbm(a)ripe.net>. Regards, Denis Walker Business Analyst RIPE NCC

3 2

Draft DNS WG Meeting Agenda for RIPE 58
by Peter Koch 27 Apr '09

27 Apr '09

Dear WG, please find below the draft agenda for next week's two sessions of the DNS working group. Some assignments are preliminary and scheduling is still subject to change. Comments/requests to <dns-wg-chair(a)ripe.net>, please. Regards, Peter

1 0

Call for Agenda Items for the DNS WG meeting(s) at RIPE58
by Peter Koch 14 Apr '09

14 Apr '09

Dear DNS WG, it is a bit less than four weeks until the RIPE 58 meeting in Amsterdam and your WG chairs would like to collect proposals for contributions to the agenda. According to the most recent meeting plan we will meet Wed, 2009-05-06, 14:00-15:30 CEDT (//EIX) Thu, 2009-05-07, 09:00-10:30 CEDT (//Address Policy) (See also <http://www.ripe.net/ripe/meetings/ripe-58/meeting-plan.html>) Anyone who would like to suggest a presentation or would like to see a particular topic covered during the meeting is encouraged to submit ideas to <dns-wg-chairs(a)ripe.net>. Also, please keep in mind that there are several DNS related events scheduled for the RIPE meeting week, starting with a CENTR Technical Meeting (CENTR members only) on Sunday, the DNS WG on Wednesday and Thursday and the OARC Workshop on on Saturday, 9 May. Even though we expect different audiences, the organizers have agreed to coordinate on presentations to avoid undue overlap. To allow for this coordination and feedback to presenters, we'd appreciate suggestions to be sent prior to Friday next week, April 17. For new subscribers (and for everybody else as a refresh), the RIPE DNS WG homepage is at <http://www.ripe.net/ripe/wg/dns/>. Best regards, Peter [for the co-chairs]

1 1

Q: "lameness checks" - error messages for servers at the NCC?
by Wilfried Woeber, UniVie/ACOnet 30 Mar '09

30 Mar '09

Dear DNS-Folks, I'd like to understand whether receiving error messages that report problems related to the name server(s) run by/at the NCC is a rare case or rather "widespread". I am working on one such case now for a university served by our team. Please report back to me privately as I don't intend to see the list spammed with "mee too" messages :-) and I'll summarize to the list if useful. Thanks, Wilfried.

1 0

DNS lameness question
by Matus UHLAR - fantomas 23 Mar '09

23 Mar '09

Hello, We have received informations about DNS lameness in our reverse delegations. We have delegated (most of) our reverse zones to: ns.nextra.sk ns1.nextra.sk dns.nextra.sk dns.gtsi.sk Some time ago, since there were some problems, I removed the dns.nextra.sk record from the nextra.sk zone, and assigned its IP address to ns.nextra.sk. No direct zones were delegated to it (hopefully, not by us), this caused no problem there (at least not caused by us). However the delegations in RIPE do still point to dns.nextra.sk. There are plenty of them, and I plan to change the NS scheme to make it more reliable, easier to implement and harder to abuse (e.g. naming only some of NS records), so the structure will change even more. For this reason I decided not to change all delegations (to spare our RIPE contacts from modifying it all twice) until I will do that. However on Feb 24, RIPE sent lameness notifications to us and our RIPE contact got angry at me for not notifying them about this change, and requesting that I add the record back. I prefer not to do that, since my plans are very different and customers tend to put anything to NS records without asking. Adding CNAME record would not solve this problem since NS must not point to CNAME (scripts at RIPE check for that, right?). So I'm asking you for an advice - is it possible to mass-remove the "dns.nextra.sk" from delegations? - would it cause big problem if I kept it as it is, even if dns.nextra.sk does not exist? (I hope no delegations will be removed because of this) - is there anything other to advise me? Thank you -- Matus UHLAR - fantomas, uhlar(a)fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "To Boot or not to Boot, that's the question." [WD1270 Caviar]

2 4

New key-signing keys (KSKs) for RIPE NCC forward and reverse zones
by Anand Buddhdev 17 Mar '09

17 Mar '09

Dear Colleagues, On 12 March 2009, the RIPE NCC generated new key-signing keys (KSKs) for all the DNSSEC-signed zones that it operates. We have published updated trust anchor files for inclusion in validating resolvers. A list of all the zones that we sign and the trust anchor files are available at: https://www.ripe.net/projects/disi/keys/index.html The old KSKs are deprecated and will be removed from the zones on 15 June 2009. Please update your trust anchors before this date. Regards, Anand Buddhdev DNS Services Manager RIPE NCC

5 8

DNS lameness notifications
by Gilles Massen 10 Mar '09

10 Mar '09

Dear colleagues, I was wondering if there is a detailed description of what and how is tested in order to check the lameness of a server (i.e. how are the names resolved, timeouts and retransmits of the queries, checks made,....)? Any pointer would be welcome. The background is that I got notifications ("Unable to resolve nameserver ") which are most probably wrong, unless the resolving algorithm is very delicate... Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473

12 13