- dns-wg - mailman.ripe.net

RIPE 61 draft minutes
by Jim Reid 08 Jan '11

08 Jan '11

Colleagues, a belated happy new year to you all and best wishes for 2011. Here are the draft minutes from the Rome meeting. Please let me know if there are any errors, inaccuracies or omissions.

2 1

RIPE NCC to Discontinue Hostcount
by Mark Dranse 05 Jan '11

05 Jan '11

[Apologies for duplicates] Dear colleagues, For the past 20 years, the RIPE NCC has maintained Hostcount, a measurement of the number Address Resource Records (A RRs) in country code Top Level Domains (ccTLDs) in the RIPE NCC service region. The aim of this project has been to gain insight into the size and the growth rate of the Internet. It has been clear for some time though, that Hostcount no longer provides a reliable indication of these things. Therefore, as of January 2011, the RIPE NCC will discontinue Hostcount. More background information on this project and its closure can be found on RIPE Labs: http://labs.ripe.net/Members/markd/hostcount Kind Regards, Mark Dranse Information Services Manager, RIPE NCC

1 0

Changes to Reverse DNS DOMAIN Objects in the RIPE Database
by Denis Walker 09 Dec '10

09 Dec '10

[Apologies for duplicate mails] Dear colleagues, It was agreed at RIPE 59 in Lisbon that reverse DNS zones in the RIPE Database should not have child objects. Documentation relating to this decision and the discussion surrounding it can be found in the minutes of the RIPE 59 DNS and Database Working Groups: http://www.ripe.net/ripe/wg/dns/r59-minutes.html http://www.ripe.net/ripe/wg/db/minutes/ripe-59.html The RIPE NCC is now ready to deploy this change and clean-up the existing data. This will be done in the week commencing 13 December 2010. After deployment it will not be possible to create a reverse DNS DOMAIN object in the RIPE Database if either a more or less specific object already exists. During the data clean-up you may receive a notification that your DOMAIN object has been deleted. If this is the case there will be a less specific DOMAIN object in the database. Your object was only for documentation purposes and did not have any effect on reverse DNS. If you have any questions please contact us at <ripe-dbm(a)ripe.net>. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Fwd: FYI: ARPA DS record in the root
by Andrei Robachevsky 07 Dec '10

07 Dec '10

-------- Original Message -------- Subject: FYI: ARPA DS record in the root Date: Tue, 7 Dec 2010 09:26:57 +0100 From: IAB Chair <iab-chair(a)iab.org> To: IETF Announcement list <ietf-announce(a)ietf.org> Dear Colleagues, The ARPA DS RRset has been published in the root zone as of serial number 2010120601. This allows signed reverse address RRsets to be validated by DNSSEC aware recursive name servers that have the root configured as their trust-anchor. --Olaf Kolkman IAB Chair ----------------------------------- The Internet Architecture Board www.iab.org iab-chair(a)iab.org _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce

5 4

Replacing reverse zone delegations by DNAMEs
by Chris Thompson 02 Dec '10

02 Dec '10

I don't know whether this is the most appropriate forum to raise this issue --- but if RIRs can be persuaded to support the alternate form of reverse zone delegation suggested here, perhaps other authorities would do the same. Fragmentation of IPv4 space leads to organisations having lots of little reverse zones, each of which requires: managing the contents, maintaining the registration, organising official slaves, DNSSEC signing ... There is much uneconomic effort involved. Locally we have been using a scheme to map such reverse lookups into a single common zone, described at http://people.pwf.cam.ac.uk/cet1/prune-reverse-zones To take full advantage of this, however, requires promoting DNAMEs into the parent reverse zone. Logically, administrators of such zones ought to be delighted to replace delegations (multiple NS records, maybe DS records as well) with a single DNAME. But of course it has not been standard practice to support that. As DNAMEs do not redirect the name itself, there would be a problem for reverse zones containing significant records at the apex, e.g. PTR records pointing to a gateway host. (I think that practice, recommended in RFC 1033, has pretty much fallen into disuse.) If the IETF DNSEXT WG ever get their act together on "XNAME"/"CNAME+DNAME", that would cover that particular point, but meanwhile no-one would be obliged to use DNAMEs if they didn't want to. Anyway, I would welcome opinions on this idea. -- Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.

9 13

New DNSMON beta user interface
by Mirjam Kuehne 15 Nov '10

15 Nov '10

[apologies for duplicates] Dear colleagues, A new DNSMON beta user interface has been published. Please find a description of the enhancements on RIPE Labs: https://labs.ripe.net/Members/markd/dnsmon-new-user-interface-update Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Final(?) agenda for RIPE61
by Jim Reid 15 Nov '10

15 Nov '10

Here is what should be the final agenda for the WG sessions this week. There's one minor tweak from the draft agenda. Jelte Jansen and Dave Knight have swapped slots.

1 0

Draft agenda for RIPE
by Jim Reid 03 Nov '10

03 Nov '10

Colleagues, here is an almost final agenda for the WG at RIPE61. I don't expect there will be significant changes: perhaps minor tweaks to the running order. There are one or two loose ends that need to be clarified. However these are unlikely to make much impact on the overall agenda. Please note that the WG slots are not back-to-back for the first time in ages. The first one is on the Tuesday afternoon and is 2 hours long instead of 90 minutes. Your co-chairs have done some trading of slots with the other WGs to minimise the clashes with other WGs that would have been unpopular. That's why we gave up one of the usual Thursday slots this time. As always, comments and questions on the agenda are welcome. See most of you in Rome.

1 0

DNSSEC KSK Roll-over Event for RIPE NCC Zones
by Anand Buddhdev 25 Oct '10

25 Oct '10

[Apologies for duplicates] Dear Colleagues, On 21 September, we performed a roll-over of Key Signing Keys (KSKs) of all our signed zones. However, we encountered some issues with the signing infrastructure, and we had to perform a roll-back and delay the key roll-over event. We have resolved the issues with the signing infrastructure, and we will perform a roll-over of KSKs on Wednesday 27 October, and publish new trust anchor files on the RIPE NCC website: More information on DNSSEC keys is available at: https://www.ripe.net/dnssec-keys/index.html Regards, Anand Buddhdev DNS Services Manager, RIPE NCC

1 0

request about RIPE vs. ISP and RFC 1921, 2.1
by thoma spolnik 15 Oct '10

15 Oct '10

Hello, if RIPE assigns an large ip net to an ISP - Does RIPE accept, that this ISP ignores RFC 1921, 2.1 [1] (for commercial interests)? Are commercial interests a valid reason [2] for RIPE, that an ISP does not set (generic) PTR records for an used IP? Does or does not RIPE claim the compliance with (basic) RFCs (like RFC 1921, 2.1 - I think it is a basic, that every IP must have a correct PTR record.) for assigned IP nets? I hope, I found the correct mailing list for my question. If this the wrong list, which should I use for my question? Best regards, thomas polnik. [1] 2.1 Inconsistent, Missing, or Bad Data Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS. Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. [...] [2] RFC 2119 [...] 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. [...]

4 5