- dns-wg - mailman.ripe.net

Fwd: Advisory — D-root is changing its IPv4 address on the 3rd of January.
by Keith Mitchell 17 Dec '12

17 Dec '12

(Apologies if you already saw this elsewhere) -------- Original Message -------- Subject: [dns-operations] Advisory — D-root is changing its IPv4 address on the 3rd of January. Date: Thu, 13 Dec 2012 17:54:41 -0500 From: Jason Castonguay <castongj(a)umd.edu> To: <castongj(a)umd.edu> Advisory ? D-root is changing its IPv4 address on the 3rd of January. This is advance notice that there is a scheduled change to the IPv4 address for one of the authorities listed for the DNS root zone and the .ARPA TLD. The change is to D.ROOT-SERVERS.NET, which is administered by the University of Maryland. The new IPv4 address for this authority is 199.7.91.13 The current IPv6 address for this authority is 2001:500:2d::d and it will continue to remain unchanged. This change is anticipated to be implemented in the root zone on 3 January 2013, however the new address is currently operational. It will replace the previous IP address of 128.8.10.90 (also once known as TERP.UMD.EDU). We encourage operators of DNS infrastructure to update any references to the old IP address, and replace it with the new address. In particular, many DNS resolvers have a DNS root ?hints? file. This should be updated with the new IP address. New hints files will be available at the following URLs once the change has been formally executed: http://www.internic.net/domain/named.root http://www.internic.net/domain/named.cache The old address will continue to work for at least six months after the transition, but will ultimately be retired from service.

1 0

DNSMON Measurements lost 9:00 - 11:00 CET
by Sean McAvoy 10 Nov '12

10 Nov '12

[Apologies for duplicate e-mails] Dear colleagues, As a side effect of upgrading the DNSMON/TTM backends, some DNSMON measurement data was lost this morning between 9:00 and 11:00 CET (8:00 and 11:00 UTC). We apologise for any inconvenience this may have caused. Regards, Sean McAvoy, Senior Systems Engineer RIPE NCC

1 0

DNS Amplification in numbers
by Lutz Donnerhacke 09 Nov '12

09 Nov '12

About 7% if hosted servers are open relays causing between 20 to 80% of DNS traffic when misused by DNS reflection and amplification attacks. Which numbers do you see? http://lutz.donnerhacke.de/eng/Blog/DNS-Amplicfication-in-the-eyes-of-a-hos…

1 0

New on RIPE Labs: Counting IPv6 in the DNS
by Mirjam Kuehne 29 Oct '12

29 Oct '12

[apologies for duplicates] Dear colleagues, Geoff Huston gave an interesting presenting at the recent NANOG meeting showing another way to measure IPv6 deployment. This time he looked at the DNS. His findings are now published on RIPE Labs: "Counting IPv6 in the DNS" https://labs.ripe.net/Members/gih/counting-ipv6-in-the-dns Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: Re-Counting DNSSEC
by Mirjam Kuehne 23 Oct '12

23 Oct '12

Dear colleagues, Following-up from his earlier article "Counting DNSSEC", Geoff Huston published a new article on RIPE Labs, further examining the collected data and revising some of the results: "Re-Counting DNSSEC" https://labs.ripe.net/Members/gih/re-counting-dnssec Kind regards, Mirjam Kuehne RIPE NCC

1 0

Comparing TCP and UDP response times of root name servers
by Anand Buddhdev 22 Oct '12

22 Oct '12

[Apologies for duplicates] Dear colleagues, The RIPE NCC has just published an article on RIPE Labs, comparing the TCP and UDP response times of DNS queries to the root name servers: https://labs.ripe.net/Members/bwijnen/tcp-udp-dns-soa-rt-ratio Your comments, questions and suggestions are welcome. Regards, Anand Buddhdev RIPE NCC

4 3

final version of RIPE64 minutes
by Jim Reid 11 Oct '12

11 Oct '12

Here are the final version of the WG minutes from Ljubljana.

2 1

Pointer to DNS Benchmarking list
by Ondřej Surý 26 Sep '12

26 Sep '12

The mentioned mailing list is: dns-benchmarking(a)lists.dns-oarc.net and the archives are located: https://lists.dns-oarc.net/pipermail/dns-benchmarking/ with pointer to git: https://lists.dns-oarc.net/pipermail/dns-benchmarking/2012-June/000008.html you can subscribe here: https://lists.dns-oarc.net/mailman/listinfo/dns-benchmarking O. -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------

1 0

New on RIPE Labs: Using RIPE Atlas: A DENIC Case Study
by RIPE Labs Administrator 25 Sep '12

25 Sep '12

[apologies for duplicates] Dear colleagues, Please find a new article on RIPE Labs: Using RIPE Atlas: A DENIC Case Study, by Peter Koch: https://labs.ripe.net/Members/pk/denic-case-study-using-ripe-atlas Kind regards, Mirjam Kuehne RIPE NCC

1 0

Draft recommendation for limiting the EDNS0 response size on authoritative name servers
by Roland van Rijswijk - Deij 24 Sep '12

24 Sep '12

Hi all, During the last RIPE meeting, I presented on research that SURFnet has been doing over the past year into DNS response delivery issues caused by firewalls or other network equipment blocking fragments (see https://ripe64.ripe.net/presentations/91-20120418_-_RIPE64_-_Ljubljana_-_DN… and the meeting minutes for the last WG meeting). After the meeting, Jim Reid suggested that we write a draft WG recommendation containing some of the suggestions we made for dealing with this issue (specifically, dealing with it by reducing the maximum EDNS0 response size on the authoritative side). Gijs van den Broek, who has performed most of the research, has spent the past couple of weeks writing such a recommendation. I'm circulating the draft document here hoping that we can discuss whether or not it makes sense to issue a recommendation on this. I realise this may be a controversial issue. Many have argued in the past that the only real solution to this problem is that people stop doing second rate Internet by blocking fragments, or that operators of caching recursive name servers should correctly configure their systems according to the maximum response size they can receive. Our approach to this has been a rather pragmatic one. Rather than looking at what should be the ideal situation we are trying to strive for maximum interoperability and ensuring that we maximise the chance that a response is delivered to a query while still not completely giving up on the ideal that fragmentation should just work and be accepted. The reason for approaching this from the authoritative side, by the way, is that there are already a number of recommendations out there that deal with the caching recursive side of things. If there is one thing our research shows its that these recommendations are not followed by most operators, unfortunately. As an operator of a substantial number of zones, we would like to be able to influence the deliverability of responses for the zones we are authoritative for. Since we cannot chase down every operator of a caching recursive name server that experiences delivery issues, even if we wanted to, the only way to do this is to avoid fragmentation on the authoritative side. I will present some more of our reasoning behind the recommendations in the document at the DNS WG meeting. I'm hoping for a good discussion next week :-) The document can be found here: https://dnssec.surfnet.nl/wp-content/uploads/2012/09/Recommendations-for-de… Remarks, comments, rants, etc. are all welcome via e-mail as well, of course :-) Cheers and see you next week, Roland -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk(a)surfnet.nl

5 5