- dns-wg - mailman.ripe.net

RIPE 69 is coming! Send in your agenda items
by Jaap Akkerhuis 24 Sep '14

24 Sep '14

The subject is the Exec Summary. Yes, it is this time of the year again. Ripe is coming to town. We have a single slot reserved at on Thursday the 6th of November <https://ripe69.ripe.net/programme/meeting-plan/> and like to see that filled with your contributions. There has been quite some turmoil in DNS land lately, from the policy stuff (iana transition) via gTLD outroll and various options to accomodate CDNs (ALIAS, ANAME etc in the apex) to root zone KSK rollover so I expect that there will be a lot to talk about. Therefore, send you proposals ASAP. jaap

1 0

Root Zone KSK Rollover Operations Workshop (save the date)
by Joe Abley 16 Sep '14

16 Sep '14

Hi all, ICANN will facilitate an open, technical workshop to discuss operational plans for a future root zone KSK rollover, during the upcoming ICANN 51 meeting to be held in Los Angeles in October 2014. The workshop is intended for participants who have a technical, operational perspective and is an opportunity to explore potential options, operational considerations, and other aspects of rolling the root zone KSK. The workshop will be held on Thursday October 16, 2014 at the ICANN meeting venue in Los Angeles. This will be an open event, and remote participation will be available. More details including a tentative agenda, will be made available soon. If you are able to participate, please join the ksk-rollover mailing list at <https://mm.icann.org/mailman/listinfo/ksk-rollover> which will be used to coordinate this workshop, and to function as a venue for technical discussion as this work proceeds in the future. Regards, Joe & Roy & Jakob & Duane & Dan ad-hoc workshop coordinators

1 0

draft minutes from RIPE68
by Jim Reid 12 Sep '14

12 Sep '14

Colleagues, here are the draft minutes from the last WG meeting. Please let me know of any errors or omissions. Thanks.

1 0

Announcing changes to DNSMON
by Vesna Manojlovic 09 Sep '14

09 Sep '14

Dear colleagues, The DNS Monitoring Service (DNSMON) has been providing a comprehensive, objective and up-to-date overview of the quality of various global and regional DNS operators' services since 2003. As announced last year by Kaveh Ranjbar in the RIPE Labs article, "Future of RIPE NCC Technical Services", we are in the process of integrating DNSMON within RIPE Atlas, using RIPE Atlas anchors as vantage points. The beta version of the new DNSMON will be available next week, when we will invite you all to try the new service and provide your feedback. In the meantime, we wanted to let you know about some of the changes in the new DNSMON service: New interactive graphs that will allow you to zoom in on interesting details, such as servers, vantage points, and time intervals. Support of TCP queries. Data delay for non-DNSMON users will not be replicated because the measurements performed by RIPE Atlas anchors for the new DNSMON are public measurements. Therefore, the results will also be publicly available. Server-side generated RRD graphs will not be migrated, as the client-side visualisations provide a comparable replacement. However, the existing service will keep working in parallel and decommissioning plans will be discussed with the community. In the meantime, the graphs and data from the old system will still be available. We will publish a RIPE Labs article with more details when the new service becomes available next week. We’re confident the new DNSMON will continue to meet your needs and hope you'll be pleased with the new features. Please stay tuned for more information. Kind regards, Vesna Manojlovic Senior Community Builder Measurements Community Building RIPE NCC

8 14

127.0.53.53 in logs?
by David Conrad 03 Sep '14

03 Sep '14

Hi, I was wondering if any resolver operators were seeing 127.0.53.53 in log files. For anyone who isn’t aware, seeing that address would suggest a “name collision” (see https://www.icann.org/resources/pages/name-collision-2013-12-06-en if you don’t know what that is). As currently over 300 new generic TLDs have been delegated and there was much ... ‘discussion’ about the risk associated with the delegation of those TLDs, I’d be interested in hearing about anything anyone is seeing related to “name collision". Thanks, -drc

2 1

RIPE NCC Re-Affirms Commitment to Operate K Root Name Server
by Axel Pawlik 21 Aug '14

21 Aug '14

Dear colleagues, The RIPE NCC has been providing DNS root name service via k.root-servers.net since 1997. As the global Internet community considers changes to the NTIA oversight of key DNS functions, the RIPE NCC wishes to assure the Internet community that our commitment to providing this service and to coordinating appropriately with ICANN and the other root server operators will not be affected by the outcome of these discussions. The RIPE NCC is a not-for-profit membership association under Dutch law. It is governed by its General Meeting and Executive Board, and is guided by the RIPE community. Root name servers are a crucial part of the Internet DNS infrastructure and the RIPE NCC’s role in this area is supported by the membership for the benefit of the global Internet community. In an open letter to ICANN in 2009, the RIPE NCC affirmed our mutual commitment to coordination of DNS root name service operations, acknowledging that a single, unique DNS root is paramount to the stable operations of the Internet and to ensuring global reachability: https://ripe.net/s/kr2h We remain committed to the principles expressed in this letter, and will continue working to operationalise them, independent of changes to the IANA stewardship. More information about RIPE NCC's operation of K-root is available at: http://k.root-servers.org/ Best regards, Axel Pawlik Managing Director RIPE NCC

1 0

Proposed criteria for adding new zones to DNSMON
by Kaveh Ranjbar 14 Aug '14

14 Aug '14

Dear colleagues, The new DNSMON (https://atlas.ripe.net/dnsmon/) service has been available for several months now, and we would like to propose criteria for adding new zones going forward. Please note that we’ve provided this just as a starting point for consultation with the DNS community, and are asking for feedback about this proposal. First, we believe we should only add these TLDs when we receive a request from the TLD operators themselves, rather than from third parties. If we do receive requests to add a TLD from a third party, we will only do so after first checking with the TLD operator and receiving an official request from them at atlas(a)ripe.net. Second, we propose allowing the addition of ccTLDs operated by our members for countries within the RIPE NCC’s service region. The new DNSMON infrastructure is capable of handling this number of potential requests. Third, we propose adding up to five gTLDs under the control of any given operator, and only if the operator is a member of the RIPE NCC. We believe these criteria for including new zones will continue to make DNSMON a valuable tool for our members and the wider community. Once the DNS Working Group has provided feedback on these criteria, the RIPE NCC will provide a full service description for DNSMON that includes these criteria and that will be included in the DNSMON documentation. We look forward to hearing your thoughts, and ask you to please respond to this list with any feedback you have preferably before mid-September. Kind regards, Kaveh Ranjbar Chief Information Officer RIPE NCC

3 5

More anchors involved in DNSMON measurements
by Robert Kisteleki 16 Jul '14

16 Jul '14

Dear DNSMON users, Due to the growth of numbers in active RIPE Atlas anchors, we started involving more anchors from outside our service region in DNSMON measurements. This has a natural effect on the visualisations: the newly involved anchors don't have a measurement history yet, so they show up as "no data" before the addition. We're introducing these changes gradually for the monitored zones so the changes are not yet visible everywhere. Regards, Robert Kisteleki

4 5

DNSMON visualisation delay
by Robert Kisteleki 08 Jul '14

08 Jul '14

Dear DNS Working Group, At RIPE68 we were asked to "send an email to the mailing-list about advantages and disadvantages of delayed and non-delayed versions of DNSMON [visualisation], specifically related to the management of the software and the ongoing maintenance of the legacy systems that you want to retire". As many of you know, the old DNSMON service had an artificial delay of a couple of hours for visualising the incoming data, for everyone except a specific "DNSMON customers" group. With the changes to the service model as of 2013 there is no good definition of "DNSMON customers" any more. Also, the current DNSMON implementation does not apply any artificial delays, which in practice means all data points show up in the graphs within 10-15 minutes. As Daniel projected a few days ago, we see some realistic options regarding this visualisation delay: === 1. No changes to what the service offers now; ie. graphs will show results with minimum delay Development effort: none Pro: simplest solution Con: this is perceived by some to be "helping potential attackers" by making it easy to observe the effects of an attack on the DNS infrastructure === 2. Introduction of an artificial delay to *all* users, regardless of NCC member/non-member, or login status (known an anonymous users) Development effort: minimal (est. couple of developer days) Pro: not helping potential bad guys monitoring the zones/servers in real time Con: not helping the good guys monitoring the zones/servers in real time either === 3. Introduction of an artificial delay to users in general, except for RIPE NCC members. Authentication is done by RIPE NCC Access (Single Sign-On), authorization is controlled by the existing LIR portal mechanism. Development effort: minimal (est. couple of developer days) Pro: RIPE NCC members have early access to visualisations, others don't Note: the current number of SSO account belonging to RIPE NCC members is ~24000 Note: we may or may not help the attacker, depending on whether (s)he is a member of the RIPE NCC or not === 4. Introduction of an artificial delay to users in general, except for a specially designated DNSMON customers (zone operators) group. Authentication is done by RIPE NCC Access (Single Sign-On), authorization is controlled by a vetting process managed by the RIPE NCC. Development effort: moderate (est. more than a couple of developer days) Con: administration overhead is non-trivial -- we'll have to establish and keep tracking who is in the privileged group and who isn't; with people joining/leaving organisations this could be tricky and diverge from reality. Pro: members of the special group have early access to visualisations, others don't Note: people in this special group can come from organisations which may or may not be RIPE NCC members. Note: we may or may not help the attacker, depending on whether (s)he is a member of this group or not Please give us guidance about your your preferred solution by replying to this mail to the list. Regards, Robert Kisteleki RIPE NCC

4 3

Closure of Test Traffic Measurements Service and Changes to the DNS Monitoring Service
by Romeo Zwart 07 Jul '14

07 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, As of 1 July 2014, the old DNS Monitoring Service (DNSMON), based on the Test Traffic Measurements Service (TTM), has stopped receiving updates to its data. The new DNSMON interface is available at: https://atlas.ripe.net/dnsmon All historic DNSMON visualisations will remain available at: http://dnsmon-old.ripe.net We will keep these visualisations of the historic data available until at least the end of 2014. Existing URLs that point to specific periods or zones in the old DNSMON (for example http://dnsmon.ripe.net/dns-servmon/server/) will be redirected and will continue to work for as long as the old DNSMON visualisation servers are maintained. As discussed at the RIPE 68 DNS Working Group session in Warsaw, the RIPE NCC will provide some statistics on usage of the old visualisations at RIPE 69 in London. The DNS Working Group will be consulted regarding the further maintenance or possible decommissioning of these visualisations. Background The RIPE NCC announced a new version of DNSMON in March 2014 and informed the community that the old DNSMON would be phased out. The old DNSMON was dependent upon measurements run as part of TTM, which was in the last phase of its existence. TTM has been decommissioned, as announced previously, on 1 July 2014. In line with the closure of TTM, data collection in the old DNSMON has also been terminated from that same date. These changes are in line with our previous communications, notably the RIPE Labs article "Timeline for Phasing Out the Old TTM-Based DNSMON": https://labs.ripe.net/Members/romeo_zwart/copy_of_proposed-time-lines-for-p… Romeo Zwart RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO6fx4ACgkQGRL9suBV+eos8ACfUMImGvgAV9rJ1bxzLbt4hLmv HewAni2DYCGSLAWOAhYREtCsprGj8jKR =gI+O -----END PGP SIGNATURE-----

1 0