March 2017 - dns-wg - mailman.ripe.net

Draft minutes from the DNS working group at RIPE 73
by Shane Kerr 24 Mar '17

24 Mar '17

DNS Colleagues, Draft minutes from the DNS working group at RIPE 73 are available here: https://www.ripe.net/participate/ripe/wg/dns/minutes/ripe-73 Please send any corrections to the DNS working group chairs at <dns-wg-chairs(a)ripe.net>. Cheers, -- Shane

1 0

Re: [dns-wg] [dns-operations] Additional information about the RIPE NCC reverse DNS issue
by Shane Kerr 20 Mar '17

20 Mar '17

Doug, At 2017-03-18 18:34:25 -0700 Doug Barton <dougb(a)dougbarton.email> wrote: > On 03/18/2017 08:46 AM, Anand Buddhdev wrote: > > Dear colleagues, > > > > This is a follow-up to our message of Friday about issues with some > > reverse delegations. > > > > After doing a thorough analysis, and with the help of ARIN staff, we > > found more issues with our zonelet generation code > > Can you say more about the benefit of this "zonelet" system vs. ARIN > simply delegating the appropriate zones to you, and you managing them > like any other DNS zone? > > I do appreciate you keeping the community informed about the causes of > the outage, but it seems that at least part of the root cause is that > you're operating what sounds like a fairly fragile system in the first > place, with (de fact) insufficient validity checking. I was at the RIPE NCC when we adopted the zonelet approach, although I haven't worked for them for over a decade. The zonelet system was designed to allow reverse DNS for IPv4 space that was originally assigned to one RIR but was later partially migrated to other RIRs. This happened when LACNIC and AfriNIC were formed, although I think that an audit was done at the time and so space was moved around between all 5 RIRs. The problem is that we could have a delegation like 999.in-addr.arpa going to the RIPE NCC and then 888.999.in-addr.arpa being managed by ARIN... but want 888.999.in-addr.arpa to point to the **address holder's** name servers, not **ARIN's** name servers. So ARIN needs a way to get the information about the name servers to the RIPE NCC somehow (and RIPE NCC to LACNIC, and so on). Zonelets are used for this, which is basically just the NS records needed, probably picked up using SSH. I think that we discussed using dynamic DNS (DDNS) for this at the time, but decided that the simplest & best solution was zonelets. DNAME could be used, but it would involve an extra lookup for resolvers, right? (DNAME was pretty new when zonelets were adopted, and I don't know that BIND 8 supported them, which was still the most popular DNS server at that time.) My guess is that the bugs are probably more due to ancient Perl code than an overly-complicated system for exchanging this information. Heck, it's possible that the bugs are due to MY ancient Perl code, although I really don't remember who wrote or tested the code.... Cheers, -- Shane

5 5

f.root-servers.net unreachable for a few days?
by Max Grobecker 19 Mar '17

19 Mar '17

Hello, I noticed that f.root-servers.net is unreachable via IPv4 from my test locations (most of them in Germany). Relying on RIPE ATLAS [1] I'm pretty sure I'm not alon with this "problem". A traceroute from my home DSL connection (DTAG, AS3320) shows that packets are surprisingly routed to somewhere in Pakistan and never get answered. Also Port 53/UDP/TCP is unresponsive. --------------------------------- traceroute to f.root-servers.net (192.5.5.241), 30 hops max, 60 byte packets 1 87.186.224.133 (87.186.224.133) [AS3320] 18.144 ms 2 87.190.177.174 (87.190.177.174) [AS3320] 18.843 ms 3 217.239.49.30 (217.239.49.30) [AS3320] 23.291 ms 4 te0-0-0-16.agr21.fra03.atlas.cogentco.com (130.117.14.149) [AS174] 33.528 ms 5 * 6 be2959.ccr21.muc03.atlas.cogentco.com (154.54.36.54) [AS174] 38.948 ms 7 be3072.ccr21.zrh01.atlas.cogentco.com (130.117.0.17) [AS174] 41.687 ms 8 be3080.ccr21.mrs01.atlas.cogentco.com (130.117.49.1) [AS174] 46.415 ms 9 be2345.agr21.mrs01.atlas.cogentco.com (154.54.38.170) [AS174] 46.891 ms 10 ptcl.demarc.cogentco.com (149.6.155.146) [*] 156.865 ms 11 static-10GE-KHI275-P01-SwA.pie.net.pk (202.125.128.173) [AS17557] 155.095 ms 12 221.120.251.178 (221.120.251.178) [AS17557] 153.854 ms 13 * 14 * 15 * 16 * 17 * --------------------------------- Has something happened to the F-Root instances in Europe? Or has the IP address changed? [1] https://atlas.ripe.net/results/maps/root-server-performance/?t=1489877040&s… Greetings Max

2 3

Additional information about the RIPE NCC reverse DNS issue
by Anand Buddhdev 18 Mar '17

18 Mar '17

Dear colleagues, This is a follow-up to our message of Friday about issues with some reverse delegations. After doing a thorough analysis, and with the help of ARIN staff, we found more issues with our zonelet generation code, and this showed that we had indeed published some empty zonelet files. From ARIN's point of view these were valid zonelets, with no content, and that is why the delegations were removed. Similarly, three zonelets that APNIC picks up also had empty content. We fixed these issues late on Friday afternoon, and by Friday evening, both registries had re-imported the correct zonelets and were again publishing the missing delegations. We will evaluate our code review and testing to prevent this from happening again, and add some monitoring to alert us to such a situation earlier. We are also discussing this with the other RIRs to find ways to improve the zonelet exchange process. Regards, Anand Buddhdev RIPE NCC

1 0

Reverse DNS issue for some delegations in the RIPE NCC service region
by Anand Buddhdev 17 Mar '17

17 Mar '17

Dear colleagues, Between 17:00 UTC yesterday and 10:00 UTC today, we had an issue that affected some reverse DNS delegations. The delegations in the RIPE Database where the parent zone is operated by ARIN were affected. RIPE NCC publishes zonelet files containing these delegations, and these are picked up by ARIN's DNS provisioning system periodically. At the end of these zonelet files is a summary of the counts of various types of DNS records. A bug in our code accidentally published these summaries with zero counts, and as a result, the ARIN DNS provisioning system appears to have removed the delegations. We have corrected this bug, and the zonelet files now contain the correct counts. They have been published on the RIPE NCC FTP server, and ARIN's DNS provisioning system has picked them up and reintroduced the delegations. We apologise for any inconvenience caused by this. This is the first time that such an issue has occurred with delegations that are exchanged by the zonelet mechanism, and we will try to engineer monitoring to prevent such an outage in the future. RIPE NCC's delegations in the following ARIN-operated zones were affected. The majority of the other delegations in these zones come from ARIN and the other registries, and were not affected. 104.in-addr.arpa. 107.in-addr.arpa. 128.in-addr.arpa. 129.in-addr.arpa. 130.in-addr.arpa. 131.in-addr.arpa. 132.in-addr.arpa. 134.in-addr.arpa. 135.in-addr.arpa. 136.in-addr.arpa. 137.in-addr.arpa. 138.in-addr.arpa. 139.in-addr.arpa. 13.in-addr.arpa. 140.in-addr.arpa. 143.in-addr.arpa. 144.in-addr.arpa. 146.in-addr.arpa. 147.in-addr.arpa. 148.in-addr.arpa. 149.in-addr.arpa. 152.in-addr.arpa. 156.in-addr.arpa. 157.in-addr.arpa. 158.in-addr.arpa. 159.in-addr.arpa. 160.in-addr.arpa. 161.in-addr.arpa. 164.in-addr.arpa. 165.in-addr.arpa. 166.in-addr.arpa. 168.in-addr.arpa. 169.in-addr.arpa. 170.in-addr.arpa. 173.in-addr.arpa. 198.in-addr.arpa. 199.in-addr.arpa. 206.in-addr.arpa. 209.in-addr.arpa. 216.in-addr.arpa. 23.in-addr.arpa. 24.in-addr.arpa. 45.in-addr.arpa. 52.in-addr.arpa. 65.in-addr.arpa. 66.in-addr.arpa. Regards, Anand Buddhdev RIPE NCC

4 6

Reverse problem Delegation
by Thierry Bagnoud 17 Mar '17

17 Mar '17

Hi, do you have problem with reverse delegations (subnet 153.109.0.0/16) or it's a problem for ARIN ? Thanks for your response. VSnet

2 1

Call for input for the DNS working group at RIPE 74
by Shane Kerr 16 Mar '17

16 Mar '17

Dear DNS fans, We are rapidly approaching the upcoming RIPE 74 meeting in Budapest, 8-12 May 2017. We plan on having a DNS working group session there, and would like your input, presentations, or suggestions for discussions. Please e-mail my co-chairs and I at <dns-wg-chairs(a)ripe.net> and let us know what you'd like to have in this session. (You can also mail any of us individually if you prefer.) I'm looking forward to seeing you there! Cheers, -- Shane

1 0

RIPE Atlas Infrastructure Maintenance (14 March)
by Paul de Weerd 13 Mar '17

13 Mar '17

Dear all, We'll carry out maintenance work on the core RIPE Atlas and RIPEstat infrastructure tomorrow (14 March 2017), approximately between 09:00 and 11:00 UTC+1. As a result, we will switch over to the reduced data set, limiting the amount of history available from the service. This affects RIPE Atlas, RIPEstat, RIS and DNSMON. We apologise for the inconvenience. Best regards, Paul de Weerd Senior Systems Engineer RIPE NCC

1 0

New on RIPE Labs: New RIPE Atlas Root Zone DNS Measurements
by Mirjam Kuehne 10 Mar '17

10 Mar '17

Dear colleagues, Two new DNS measurements, both designed to assess the impact of issues with one or more root name servers, have been added to every RIPE Atlas probe. Please find more details on RIPE Labs: https://labs.ripe.net/Members/chris_amin/new-ripe-atlas-root-zone-dns-measu… Kind regards, Mirjam Kuhne RIPE NCC

1 0