- dns-wg - mailman.ripe.net

Update on Reverse DNS Outage - Resolved
by Serge Radovcic 15 Jun '12

15 Jun '12

Dear colleagues, As of Friday, 15 June 2012 at 07:30 UTC, reverse DNS operations are fully back to normal. The service update has been posted at: http://www.ripe.net/lir-services/service-announcements/reverse-dns-services… However, if you are still experiencing abnormal reverse DNS responses, please email us at <dns-help(a)ripe.net>. ======================== Summary Report and Incident Analysis ======================== We are analysing the incident and preparing a summary report on the facts, cause and effects of the outage. We will send this report out early next week. We will follow up with a detailed incident analysis. ============== Service Updates ============== All RIPE NCC-related service announcements will be posted on <ncc-announce(a)ripe.net> and published at: http://www.ripe.net/lir-services/service-announcements We will also alert our Twitter and Facebook followers that an update has been posted. Social media updates are posted and maintained during regular business hours. Please note that the RIPE NCC does not use the <members-discuss(a)ripe.net> mailing list to post service announcements or updates. =================== Reporting Procedures Review =================== We strive to provide you with accurate updates on outages. We understand that for incidents of this nature, timely and regular updates to our stakeholders is of the utmost importance. We are analysing feedback from the incident and using it to improve our communication procedures. Kind regards, Serge Radovcic Chief Communications Officer RIPE NCC

1 0

Update: Reverse DNS Outage (as of 20:00 UTC, 14 June)
by Romeo Zwart 15 Jun '12

15 Jun '12

Dear colleagues, As of 20:00 UTC, Thursday 14 June 2012, all regular zone information is again complete and up-to-date. However, we are still processing some imported ERX zones from the APNIC region. If you are still experiencing any abnormal responses, other than related to the above mentioned ERX zone, you can contact us atdns-help(a)ripe.net. Provide as much detail as possible. This update is available online at: http://www.ripe.net/lir-services/service-announcements/reverse-dns-services… Kind regards, Romeo Zwart GII Services Manager RIPE NCC

2 1

Update 4: Reverse DNS Services Outage
by Romeo Zwart 14 Jun '12

14 Jun '12

Dear colleagues, We'd like to update you on the reverse DNS outage situation: As of 13:00 UTC on Thursday, 14 June 2012 the zones listed in the previous update have been restored to the state of 13:30 UTC, Wednesday, 13 June 2012. So all zones we maintain are now available and zones in the list are no longer special. There may be a very few ERX zones maintained by other RIRs that are still not fully restored. The update has been posted online at: https://www.ripe.net/lir-services/service-announcements/reverse-dns-service… <http://www.ripe.net/lir-services/service-announcements> All updates since 13:30 UTC yesterday are still pending and are not reflected in the zones. However, no updates were lost. Any updates you will submit or you have already submitted will eventually be reflected in the zones once we complete our restoration procedure. ============= Next actions ============= We will now create up-to-date zones that include all the updates since yesterday 13:30 UTC. We will also recreate all ERX zones with current data. We expect to complete this by this evening. Once that is complete, we will re-enable regular provisioning and everything will be back to normal. If you experience any abnormal responses beyond the residual inconsistencies described here, please let us know atdns-help(a)ripe.net with as much detail as possible. Kind regards, Romeo Zwart GII Services Manager RIPE NCC

1 0

Update 14 June (11:22 UTC): Reverse DNS Services Outage
by Romeo Zwart 14 Jun '12

14 Jun '12

Dear colleagues, We'd like to update you on the reverse DNS service outage situation. As of 10:45 UTC on Thursday, 14 June 2012, all reverse DNS zones we publish and that are not on the list below are correct and reflect the state of 13:30 UTC yesterday, 13 June. If you continue to see problems after this time, please contactdns-help(a)ripe.net with details of what responses you are getting. Please consider (negative) caching TTLs and restart your caching servers if possible. We've posted this update online at: https://www.ripe.net/internet-coordination/news/announcements/update-14-jun… =============== Outage Details =============== We know that some zones not mentioned in the list of the previous update (20:45 UTC, 13 June) were not correctly propagated to some authoritative servers after the roll-back last night. We do not know the extent of this at the present time. However we are sure that as of 10:45 UTC today all authoritative servers answer correctly with the state of 13:30 UTC 13 June for all zones but the few on the list in the previous update. We are working hard to restore the zones listed. We are busy adding all the updates since 13:30 UTC 13 June to all zones. We will report on how this work is progressing. The zones known to be still affected are: 0.4.1.0.0.2.ip6.arpa 185.in-addr.arpa 4.1.1.0.0.2.ip6.arpa 5.1.0.0.2.ip6.arpa 6.1.1.0.0.2.ip6.arpa 7.0.1.0.0.2.ip6.arpa 7.1.1.0.0.2.ip6.arpa 7.4.1.0.0.2.ip6.arpa 8.0.1.0.0.2.ip6.arpa a.0.1.0.0.2.ip6.arpa a.1.1.0.0.2.ip6.arpa a.4.1.0.0.2.ip6.arpa b.0.1.0.0.2.ip6.arpa b.1.1.0.0.2.ip6.arpa b.4.1.0.0.2.ip6.arpa We will publish a full report once we've restored all the zones and have had sufficient time to fully analyse what went wrong. We have been working hard over the past 18 hours to resolve this problem and we apologise for the considerable inconvenience. Kind regards, Romeo Zwart GII Services Manager RIPE NCC

2 1

Fwd: WG Action: Web Extensible Internet Registration Data Service (weirds)
by Kaveh Ranjbar 16 May '12

16 May '12

Hello all, Below you can find the announcement from the IESG on the formation of the IETF Web Extensible Internet Registration Data Service (WEIRDS) Working Group. The aim of the working group is to work on a unified whois request-and-response format based on the web technologies. If you find the subject interesting, please kindly participate in discussions using the pointers in the original announcement. The RIPE NCC will do its best to make sure requirements and current practices of our community are reflected in the discussions but your direct participation is really appreciated. Kind regards, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager Begin forwarded message: > From: IESG Secretary <iesg-secretary(a)ietf.org> > Subject: [weirds] WG Action: Web Extensible Internet Registration Data Service (weirds) > Date: May 15, 2012 6:58:40 PM GMT+02:00 > To: IETF Announcement List <ietf-announce(a)ietf.org> > Cc: weirds(a)ietf.org > > A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. > > Web Extensible Internet Registration Data Service (weirds) > ---------------------------------------------------------- > Status: Proposed Working Group > Last updated: 2012-04-24 > > Chairs: > Olaf Kolkman <olaf(a)nlnetlabs.nl> > Murray Kucherawy <msk(a)cloudmark.com> > > Applications Area Directors: > Barry Leiba<barryleiba(a)computer.org> > Pete Resnick<presnick(a)qualcomm.com> > > Applications Area Advisor: > Pete Resnick<presnick(a)qualcomm.com> > > Mailing List: > Address: weirds(a)ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/weirds > Archive: http://www.ietf.org/mail-archive/web/weirds/ > > Description of Working Group: > > Internet registries for both number resources and names have > historically maintained a lookup service to permit public access > to some portion of the registry database. Most registries offer > the service via WHOIS (RFC 3912), with additional services being > offered via world wide web pages, bulk downloads, and other > services, such as RPSL (RFC 2622). > > WHOIS has never been internationalized. In the absence of formal > specification, ad hoc solutions to signal internationalized > registration data have been adopted and deployed. Providing a > standards-based solution that scales well could minimize further > proliferation of ad hoc solutions. > > WHOIS also has no data model: replies are basically just free-form > text. This means that processing of WHOIS output amounts to > "screen scraping", with specialized handlers for every service. > While many of the domain name registries share a basic common output > format, the addition of data elements changes the output > and causes problems for parsers of the data. > > The WHOIS protocol does not offer any differential service; it > cannot differentiate among clients to offer different subsets of > information or to allow different access rates to it. > > Various attempts to solve the limitations of WHOIS have met with > mixed success. The most recent of these was IRIS (RFC 3891). > IRIS has not been a successful replacement for WHOIS. The primary > technical reason for this appears to be the complexity of IRIS, the fact > that it builds upon many available technologies that in the aggregate > form a complex system. There may also exist non-technical reasons, > but they lie in areas upon which the IETF does not pass judgement. > > In recent years, ARIN and RIPE NCC have fielded production RESTful > web services to serve WHOIS data, and each has met with success. > It is widely believed that this simpler re-use of Web technologies > familiar to modern web developers has enabled this success. The > purpose of this working group is to broaden the use of RESTful web > services by achieving simple and common URI patterns and responses > amenable to all number resource and domain name registries. > > This Working Group shall determine the general needs of such a > service, and standardize a single data framework. That framework > shall be used to encapsulate objects that could form part of an > answer. The framework shall be for data to be delivered via a > RESTful data service using HTTP (optionally using TLS), and may use > standard features of HTTP to support differential service levels > to different classes of user. The data shall have one mandatory > format, though the working group may consider other optional formats. > The overall effort will be broadly aligned with > a subset of the Cross Registry Internet Service Protocol (CRISP) > Requirements (RFC 3707), but with the explicit additional goals of > producing a simple, easy-to-implement protocol, supporting > internationalized registration data and, specifically for > name registries, capturing the needs of internationalized > domain names in the data model. > > As the number registries have more experience with these services > and have found common ground, with their dissimilarities resulting in > more complete working group input documents, the goals of the working > group are to produce standards-track specifications for both number > and name registries using the fashion and pattern of the number registry > input documents, draft-newton-et-al-weirds-rir-query and > draft-newton-et-al-weirds-rir-json-response, as an initial basis. > > Work to specify the query for domain name registration data will be > based on draft-sheng-weirds-icann-rws-dnrd. > > The Working Group shall determine the general requirements of such a > service, using draft-kucherawy-weirds-requirements as an input document, > and standardize a single data framework. The working group will likely > not seek publication of this draft. > > Should the Working Group reach a point where it determines that the > problem of producing a grand unified specification for both numbers and > names appears to be intractable, it will be permitted to divide the > problem into separate tasks and amend its milestones accordingly. > > Milestones: > > Nov 2012 Draft specifying the common infrastructure document to the > IESG for approval as a Proposed Standard. > > Feb 2013 Draft specifying the RESTful URL query format for RIRs to the > IESG for approval as a Proposed Standard. > > Mar 2013 Draft specifying the format for responses to RIR queries > to the IESG for approval as a Proposed Standard. > > Jul 2013 Draft specifying the RESTful URL query format for domain name > registration data to the IESG for approval as a Proposed > Standard. > > Aug 2013 Draft(s) specifying the format(s) for responses to domain name > registration data queries to the IESG for approval as a > Proposed Standard. > _______________________________________________ > weirds mailing list > weirds(a)ietf.org > https://www.ietf.org/mailman/listinfo/weirds

1 0

FWD from "policy-announce": Cosmetic Surgery Project: Extended Review Period on New Draft, Document for Reverse Address Delegation of IPv4 and IPv6 Address Space]
by Peter Koch 26 Apr '12

26 Apr '12

DNS WG, this announcement is potentially relevant to this forum. Please note that the 'Cosmetic Surgery Project' does not intend to _change_ policy but to enhance the text readability of the document. Discussion is invited onto the address-policy-wg mailing list (see below). -Peter ----- Forwarded message from Emilio Madaio <emadaio(a)ripe.net> ----- From: Emilio Madaio <emadaio(a)ripe.net> To: policy-announce(a)ripe.net Cc: address-policy-wg(a)ripe.net Subject: [policy-announce] Cosmetic Surgery Project: Extended Review Period on New Draft, Document for Reverse Address Delegation of IPv4 and IPv6 Address Space Date: Thu, 26 Apr 2012 15:10:22 +0200 Reply-To: address-policy-wg(a)ripe.net User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-302, "Policy for Reverse Address Delegation of IPv4 and IPv6 address space in the RIPE NCC Service Region". A draft of the policy document is online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… The Address Policy Working Group Co-Chairs decided to extend the review period until 24 May 2012 to allow the community more time to give their feedback. Please send your feedback on this draft document to the Address Policy Working Group at <address-policy-wg(a)ripe.net>. Kind regards, Emilio Madaio Policy Development Officer RIPE NCC ----- End forwarded message -----

1 0

DNSOK queries to k-root
by Daniel Karrenberg 20 Apr '12

20 Apr '12

Further to Olaf Kolkman's question at the meeting: we publish the number of queries with DNSOK set continuously at http://k.root-servers.org/statistics/ROOT/dnssec.html This can be at all times compared to http://k.root-servers.org/statistics/ROOT/nodes.html So the answer to Olaf's question is that at present roughly two thirds of the queries arriving at k-root have the DO-bit set.

4 4

ccTLDs the RIPE NCC provides secondary DNS service for
by Daniel Karrenberg 18 Apr '12

18 Apr '12

In addition to the response I gave at today's meeting about secondary DNS services here is the current list of ccTLDs that receive this service: ad, ae, af, al, am, an, ar, ba, bg, bi, bj, bt, by, ci, cm, cr, cu, cw, dz, er, et, ga, gd, gp, gs, gu, gy, il, is, jm, jo, kg, kh, kz, lk, lv, ly, ma, mc, md, mg, ml, mm, mt, mu, mw, nc, ne, np, om, ph, ps, py, qa, rs, sa, sd, sm, sn, sv, sy, sz, tc, th, tj, to, tp, tr, tt, ua, ug, uy, va, vg, vn, zw Note that for several of these, we also slave a number of SLDs, like co.TLD, org.TLD and so on. For four of these, we also slave their IDN ccTLDs. Daniel

1 0

yet another final WG agenda
by Jim Reid 13 Apr '12

13 Apr '12

This is almost certainly going to be the final version. Famous last words... I forgot to list Robert as the stuckee for the NCC report in the one sent earlier today. So here it is now: # # $Id: agenda,v 1.8 2012/04/13 12:38:07 jim Exp $ # DRAFT AGENDA FOR RIPE64 - There may be last-minute tweaks [0] Usual administrivia (5 mins) [1] NCC Report (10 mins) Robert Kisteleki, RIPE NCC [2] DNSSEC in .si (10 mins) Benjamin Zwittnig Observations and problems encountered during the preparations for .si signing, running a signed .si zone and future plans. [3] Dnssexy (15 mins) Willem Toorop, NLnetLabs Dnssexy (DNS SEc proXY) is a software-program to fortify DNSSEC availability. It operates as a bump in the wire between an hidden master and a public slave. It receives DNS-transfers from the hidden master, but only notifies the public slave when all records are properly assessed by means of a user defined programme. [4] Quality of DNS and DNSSEC in the .se zone (20 mins) Patrick Wallstrom, IIS As part of the Healthcheck programme in .SE, IIS have surveyed the .se zone for DNS quality and a more in-depth analysis of DNSSEC quality, looking at all DNSSEC related parameters and unexpected issues. [5] DNSSEC: dealing with hosts that don't get fragments (20 mins) Roland M. van Rijswijk, SURFnet Middleware Services Even of you sign your zone according to the book, querying hosts that don't accept large responses due to them blocking fragments may cause you grief. This presentation outlines the issues you may encounter and provides guidelines for dealing with them based on research we are currently doing at SURFnet. [6] Followup to Plenary DNS Presentations (10 mins) COFFEE [7] YADIFA Update (10 mins) Peter Janssen, EURid [8] Knot Update (10 mins) Ondřej Surý, CZ.NIC [9] OpenDNSSEC Status Update (15 mins) Jakob Schlyter, OpenDNSSEC The soon-to-be-release version 1.4 and roadmap for version 2.0 (planned for release later in 2012) and beyond. [10] ATLAS measurements & tools (10 mins) Robert Kisteleki, RIPE NCC [11] Dense Anycast Deployment of DNS Authority Servers (20 mins) Dave Knight, ICANN A description of the wide-scale anycast deployment of L-Root by ICANN with a focus on operations and architecture. The presentation will include details of the platform, approaches for automating deployment, distributed configuration management, monitoring and measurement. [12] Panel discussion on DNSChanger (30 mins) [13] AOB

1 0

final(?) agenda for RIPE64
by Jim Reid 13 Apr '12

13 Apr '12

Here's what I hope is the final version. The item on the SATIN conference has been dropped in favour of an update on YAFIDA from Peter Janssen. # # $Id: agenda,v 1.7 2012/04/13 12:14:56 jim Exp $ # DRAFT AGENDA FOR RIPE64 - There may be last-minute tweaks [0] Usual administrivia (5 mins) [1] NCC Report (10 mins) A N Other, RIPE NCC [2] DNSSEC in .si (10 mins) Benjamin Zwittnig Observations and problems encountered during the preparations for .si signing, running a signed .si zone and future plans. [3] Dnssexy (15 mins) Willem Toorop, NLnetLabs Dnssexy (DNS SEc proXY) is a software-program to fortify DNSSEC availability. It operates as a bump in the wire between an hidden master and a public slave. It receives DNS-transfers from the hidden master, but only notifies the public slave when all records are properly assessed by means of a user defined programme. [4] Quality of DNS and DNSSEC in the .se zone (20 mins) Patrick Wallstrom, IIS As part of the Healthcheck programme in .SE, IIS have surveyed the .se zone for DNS quality and a more in-depth analysis of DNSSEC quality, looking at all DNSSEC related parameters and unexpected issues. [5] DNSSEC: dealing with hosts that don't get fragments (20 mins) Roland M. van Rijswijk, SURFnet Middleware Services Even of you sign your zone according to the book, querying hosts that don't accept large responses due to them blocking fragments may cause you grief. This presentation outlines the issues you may encounter and provides guidelines for dealing with them based on research we are currently doing at SURFnet. [6] Followup to Plenary DNS Presentations (10 mins) COFFEE [7] YADIFA Update (10 mins) Peter Janssen, EURid [8] Knot Update (10 mins) Ondřej Surý, CZ.NIC [9] OpenDNSSEC Status Update (15 mins) Jakob Schlyter, OpenDNSSEC The soon-to-be-release version 1.4 and roadmap for version 2.0 (planned for release later in 2012) and beyond. [10] ATLAS measurements & tools (10 mins) Robert Kisteleki, RIPE NCC [11] Dense Anycast Deployment of DNS Authority Servers (20 mins) Dave Knight, ICANN A description of the wide-scale anycast deployment of L-Root by ICANN with a focus on operations and architecture. The presentation will include details of the platform, approaches for automating deployment, distributed configuration management, monitoring and measurement. [12] Panel discussion on DNSChanger (30 mins) [13] AOB

1 0