- dns-wg - mailman.ripe.net

New on RIPE Labs: Securing Network Infrastructure for DNS Servers
by Mirjam Kuehne 29 Jun '16

29 Jun '16

Dear colleagues, Ramtin Kiaei shows how to mitigate DNS attacks by implementing a stateless firewall filter at the aggregation or edge router. Please find his article on RIPE Labs: https://labs.ripe.net/Members/ramtin_kiaei/securing-network-infrastructure-… Kind regards, Mirjam Kuehne RIPE NCC

6 10

New on RIPE Labs: K-root Reachability in the Middle East and Central Asia
by Mirjam Kuehne 27 Jun '16

27 Jun '16

Dear colleagues, Babak Farrokhi looked at the reachability of K-root from countries in the Middle East and Central Asia. Please find the results on RIPE Labs: https://labs.ripe.net/Members/babak_farrokhi/k-root-reachability-in-the-mid… Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Call for Presentations - DNS-OARC Fall Workshop, Oct 2016
by Stuart, Sean 16 Jun '16

16 Jun '16

Apologies if you are on multiple lists and see multiple copies of this email. Call for Presentations The DNS-OARC 25th Workshop will take place in Dallas, Texas during October 15th and 16th 2016, the Saturday and Sunday before NANOG68. To attract the best DNS minds, DNS-OARC is requesting proposals for presentations, with a preference for Resolver's Operations experiences, including running DNSSEC validating resolvers. This workshop intends to build from previous strong DNS-OARC workshops, where both operational content and research are welcome. All DNS-related subjects are accepted. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. A timeslot will be available for lightning talks (5-10 minutes) on Sunday October 16th, for which submissions will be accepted during October 15th on a first-come first-served basis. Workshop Milestones • 15th June 2016, Call for Presentations posted and open for submissions • 14th August 2016, Deadline for submission • 1st September 2016, Final Program published • 10th October 2016, Final deadline for slideset submission Details for presentation submission will be published here: https://indico.dns-oarc.net/event/25/call-for-abstracts/ The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To ensure the quality of the workshop, submissions should include slides. Draft slides are acceptable on submission. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> if you have questions or concerns. Sebastian Castro, for the OARC Programme Committee OARC is also seeking sponsorship for this workshop, please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) Thanks, Sean ‹ Sean Stuart Engineer, Resolution Operations sstuart(a)verisign.com <mailto:sstuart@verisign.com> 12061 Bluemont Way, Reston, VA, 20190

1 0

Question about use of cname in Google's services
by Anurag Bhatia 04 Jun '16

04 Jun '16

Hello everyone Someone asked me question on why google uses cname for their services anyways? I mean I get it that for Google Apps customers it makes sense to have mail.domain.com pointed to a cname rather then A record to a host which may die. But why for their own services? Like e.g "mail.google.com" is cname to googlemail.l.google.com. and googlemail.l.google.com. eventually returns A record. This adds up one extra step in resolution and I wonder why Google does it this way? What advantage they get ? or What advantage they miss if they simply return record which I am getting for googlemail.l.google.com. directly as A record for mail.google.com ? Curious to hear your thoughts. Thanks! -- Anurag Bhatia anuragbhatia.com

4 4

New on RIPE Labs: Anycast vs. DDoS - Evaluating the November 2015 Root DNS Event
by Mirjam Kuehne 31 May '16

31 May '16

Dear colleagues, IP anycast has been widely used to replicate services in multiple locations as a way to deliver better performance and resilience. It has been largely employed by CDNs and DNS operators, such as on the root server system. However, there is little evaluation of anycast under stress. Please find this short guest post by Giovane Moura on RIPE Labs: https://labs.ripe.net/Members/giovane_moura/anycast-vs-ddos-evaluating-the-… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [dns-wg] DNS Privacy
by Sara Dickinson 27 May '16

27 May '16

> On 25 May 2016, at 19:13, Roland van Rijswijk - Deij <Roland.vanRijswijk(a)surfnet.nl> wrote: Hi Roland, > I've already run a number of benchmark tests with TLS-enabled Unbound, That’s interesting, we are doing the same although there still are a couple of features that are missing from Unbound for it to be fully performant/production ready. We have also had a lot of discussions about how existing load balancers might be modified do to the TCP/TLS connection management for DNS, so it would actually be interesting to have resolvers with differing configurations. > and would be willing to host one or two public resolvers at SURFnet that > are TLS-enabled. Would that be helpful? That sounds great. > I even have (relatively) nice IP > addresses available ;-) (145.0.0.145 comes to mind). nice :-) Sara.

4 3

Tweaks to RIPE 663: Secondary DNS Service for ccTLD Operators
by Shane Kerr 26 May '16

26 May '16

Hello, Anand just mentioned at his presentation at RIPE 72 that the RIPE NCC is now implementing RIPE 663: https://www.ripe.net/publications/docs/ripe-663 There were a couple of suggestions for tweaks to that: 1. Gaurab and I think that there should be an exemption for ccTLD who do not currently have IPv6 service. (There are a few tens of ccTLD who do not yet have IPV6, and I would like the RIPE NCC to be able to help them get IPv6 service if they want it.) 2. Gaurab mentioned that there are some ccTLD who have 3 servers but they are all in the same network. The document should be flexible in order to insure network diversity. I know the document is less than 6 months old and just being implemented now, but maybe we can revise it to include these two changes? I'm happy to do a quick pass at text for this if that makes sense. Cheers, -- Shane

3 3

Re: [dns-wg] DNS Privacy
by Sara Dickinson 26 May '16

26 May '16

Hi All, As you will probably know RFC7858 "Specification for DNS over Transport Layer Security (TLS)” was recently published as a result of work in the IETF DPRIVE working group. Reference implementations of this Standard (and associated supporting features such as those specified in RFC7766) are in progress. However, since this is a significant evolution for DNS, the first stage in moving towards a deployable production solution would seem to be to run one (or preferrably a few) DNS Privacy servers as research experiments. This would allow practical experience of running the service at scale and serve as a research platform for other DNS Privacy activities. A number of organisations have expressed interest in running such a DNS Privacy enabled server and we would like to start a discussion in the RIPE community to see if there is similar interest from within this group. We would very much like to hear from interested parties who might consider becoming involved in this effort. Additionally, there have also been exploratory discussions around the possibility of RIPE NCC running such a service as a limited fixed term pilot, if there was sufficient support from the RIPE members. This seems to be something that would fit well with the mission of the RIPE NCC and we would like to hear views from the community about this proposal. There will be a short presentation in the RIPE DNS working group tomorrow on this topic, so please participate if you are interested. Regards Sara.

4 5

Yeti DNS and the RIPE NCC
by Shane Kerr 25 May '16

25 May '16

Dear DNS folks, As many of you are aware, a group of researchers and other interested people and groups has been building and operating a root server testbed over the past year. This is the Yeti DNS project: http://yeti-dns.org/ We have just finished our first experiment, and have started our second one. The network has 25 root servers from 14 different organizations, along with a number of recursive resolvers configured to use them. We have approached the RIPE NCC to encourage them to run a Yeti root server, and they feel that this is something that we should engage with the RIPE community about. We are still looking for more Yeti root operators, and we think that the RIPE NCC would be awesome in this capacity, given their unique role in the DNS world (they are the only RIR who is also a root operator, plus they do a lot of work supporting various ccTLD). Personally I think that the goals of the Yeti project fit in very well with the mission of the RIPE NCC. Please let us know what you think about this idea. I'm happy to answer any questions about the project or what it would mean for the RIPE NCC to run a Yeti root server. Cheers, -- Shane

10 13

Incorrect RCODE values in DNSMON and DomainMon
by Romeo Zwart 25 May '16

25 May '16

Dear colleagues, It has been brought to our attention that the RCODE values resulting from DNS measurements in RIPE Atlas are sometimes presented incorrectly in DNSMON and DomainMon. We are currently examining this in more detail, but preliminary investigations suggest that this is due to a bug in the software parsing and storing DNS measurement results in our backend systems. Note that there is no impact on the DNS measurement data itself - only the RCODE values are affected. This issue has a potential impact on DNSMON and DomainMon visualisations if one filters on RCODE by checking the "Exclude errors" tick box. This filter is not enabled by default, so it will not normally have an impact on these visualisations. We are still investigating the full extent of this problem. Based on the information available, we expect to have fixed the issue and corrected the historic RCODE values by the end of June. We will update you via this list when we have more information and a more accurate ETA for the fix. Kind regards, Romeo Zwart

1 0