From pk at DENIC.DE Sun Sep 2 23:27:05 2012
From: pk at DENIC.DE (Peter Koch)
Date: Sun, 2 Sep 2012 23:27:05 +0200
Subject: [dns-wg] DRAFT DNS WG Agenda for upcoming meeting at RIPE65
Message-ID: <20120902212705.GD30635@x28.adm.denic.de>
Dear WG,
please find below (and soon at )
the first draft agenda for our meeting at RIPE65 in Amsterdam:
=============================================================================
D R A F T Agenda
=============================================================================
RIPE DNS WG Meeting at RIPE65, Amsterdam
=============================================================================
Session I Wed 26 Sep 1100-1230 // EIX
Session II Wed 26 Sep 1400-1530 // IPv6
=============================================================================
0 Administrivia
Introduction, mailing list, minutes, mic discipline
1 Software reports
OpenDNSSEC [Sara Dickinson]
Knot DNS [Marek Vavrua]
2 Interop & New Protocols
DNS Benchmarking effort [Ondrej Sury]
IETF [DANE] [Ondrej Sury]
3 RIPE NCC report [Romeo Zwart]
4 DNSMON future [Daniel Karrenberg]
5 Operational considerations [Roland van Rijswijk]
and recommendations for
DNS response packet sizes
6 Panel (tentative)
DNS amplification attacks: BCP38, mitigation, reputation or what?
7 Panel (tentative)
Overcoming the "first mover loses" paradigm for IPv6^WDNSSEC deployment
=============================================================================
The sequence of presentations/talks is subject to change to accomodate
timing and presenter availability. Please note that the panel sessions
are "in the making" and subject to up-to-dateness. Suggestions welcome
at .
Best regards,
Peter
From pk at DENIC.DE Thu Sep 6 09:37:05 2012
From: pk at DENIC.DE (Peter Koch)
Date: Thu, 6 Sep 2012 09:37:05 +0200
Subject: [dns-wg] FWD from address-policy-wg: Cosmetic Surgery Project:
Review Period on Version 2 of Draft Document,
for Reverse Address Delegation of IPv4 and IPv6 Address Space]
Message-ID: <20120906073705.GH21660@x28.adm.denic.de>
Dear DNS WG,
the following announcement and proposal may be relevant for this
audience. Please follow the instructions for comments.
Thanks,
Peter (as WG co-chair)
----- Forwarded message from Emilio Madaio -----
From: Emilio Madaio
To: address-policy-wg at ripe.net
Subject: [address-policy-wg] Cosmetic Surgery Project: Review Period on
Version 2 of Draft Document,
for Reverse Address Delegation of IPv4 and IPv6 Address Space
Date: Wed, 5 Sep 2012 14:52:18 +0200
Reply-To: address-policy-wg at ripe.net
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".
After the feedback in the previous review phase, a new draft (2.0) of
the policy document is online and ready for community review at:
https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents
The highlights of the changes from the previous version include:
-the removal of all unnecessary references to "reverse resolution"
-the rewording and simplification of section 4.0
In response to the community's request:
-section 3.0 focuses on who is able to ask for the delegation
-the reference to the obsolete RFC 2874 has been replaced with the
relevant active RFCs
The Address Policy Working Group Co-Chairs decided to extend the review
period until 3 October 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: .
Kind regards,
Emilio Madaio
Policy Development Officer
RIPE NCC
----- End forwarded message -----
From mir at ripe.net Thu Sep 6 16:32:36 2012
From: mir at ripe.net (Mirjam Kuehne)
Date: Thu, 06 Sep 2012 16:32:36 +0200
Subject: [dns-wg] New on RIPE Labs: Root Server Instances in Member Networks
Message-ID: <5048B404.7060404@ripe.net>
[apologies for duplicates]
Dear colleagues,
Please find a proposal on RIPE Labs how to create member instances of
K-root and how to implement this during a pilot phase:
https://labs.ripe.net/Members/dfk/root-servers-in-member-networks
Kind regards,
Mirjam Kuehne
RIPE NCC
From jim at rfc1035.com Sat Sep 15 16:53:20 2012
From: jim at rfc1035.com (Jim Reid)
Date: Sat, 15 Sep 2012 15:53:20 +0100
Subject: [dns-wg] draft minutes from RIPE64
Message-ID: <8C536A25-525A-40BE-B64C-0692BF85F6B2@rfc1035.com>
Colleagues, here they are. Please speak up if there are any errors or
omissions so that these can be approved by the WG at RIPE65. Thanks.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dnswg-ripe64.txt
URL:
-------------- next part --------------
From Roland.vanRijswijk at surfnet.nl Wed Sep 19 19:56:16 2012
From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij)
Date: Wed, 19 Sep 2012 19:56:16 +0200
Subject: [dns-wg] Draft recommendation for limiting the EDNS0 response size
on authoritative name servers
Message-ID: <4DB5CC80-D0DC-4F71-8CFC-8593D45C57DA@surfnet.nl>
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_-_DNSSEC_-_UDP_issues.pdf 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-dealing-with-fragmentation-in-DNS-v3.pdf
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 at surfnet.nl
From jim at rfc1035.com Thu Sep 20 15:50:03 2012
From: jim at rfc1035.com (Jim Reid)
Date: Thu, 20 Sep 2012 14:50:03 +0100
Subject: [dns-wg] Draft recommendation for limiting the EDNS0 response
size on authoritative name servers
In-Reply-To: <4DB5CC80-D0DC-4F71-8CFC-8593D45C57DA@surfnet.nl>
References: <4DB5CC80-D0DC-4F71-8CFC-8593D45C57DA@surfnet.nl>
Message-ID: <309D79E4-DA9E-4E3D-A54A-429D738045CA@rfc1035.com>
Many thanks for this Roland. I look forward to the discussion next
week. Or any followups that emerge on the list.
The "Not For Public Release" footer is a pity...
From fw at deneb.enyo.de Thu Sep 20 19:36:44 2012
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 20 Sep 2012 19:36:44 +0200
Subject: [dns-wg] Draft recommendation for limiting the EDNS0 response
size on authoritative name servers
In-Reply-To: <4DB5CC80-D0DC-4F71-8CFC-8593D45C57DA@surfnet.nl> (Roland van
Rijswijk's message of "Wed, 19 Sep 2012 19:56:16 +0200")
References: <4DB5CC80-D0DC-4F71-8CFC-8593D45C57DA@surfnet.nl>
Message-ID: <87wqzooatv.fsf@mid.deneb.enyo.de>
* Roland van Rijswijk:
> Remarks, comments, rants, etc. are all welcome via e-mail as well,
> of course :-)
What's your stance on atomic fragments for IPv6?
From broek at surfnet.nl Fri Sep 21 15:08:42 2012
From: broek at surfnet.nl (Gijs van den Broek)
Date: Fri, 21 Sep 2012 15:08:42 +0200 (CEST)
Subject: [dns-wg] Draft recommendation for limiting the EDNS0 response
size on authoritative name servers
In-Reply-To: <87wqzooatv.fsf@mid.deneb.enyo.de>
Message-ID: <919272091.27738157.1348232922611.JavaMail.root@surfnet.nl>
Hi Florian,
> What's your stance on atomic fragments for IPv6?
We did not particularly consider atomic fragments. Could you be a bit more specific?
Kind regards,
Gijs
From fw at deneb.enyo.de Fri Sep 21 19:39:31 2012
From: fw at deneb.enyo.de (Florian Weimer)
Date: Fri, 21 Sep 2012 19:39:31 +0200
Subject: [dns-wg] Draft recommendation for limiting the EDNS0 response
size on authoritative name servers
In-Reply-To: <919272091.27738157.1348232922611.JavaMail.root@surfnet.nl> (Gijs
van den Broek's message of "Fri,
21 Sep 2012 15:08:42 +0200 (CEST)")
References: <919272091.27738157.1348232922611.JavaMail.root@surfnet.nl>
Message-ID: <87txurxoks.fsf@mid.deneb.enyo.de>
* Gijs van den Broek:
> Hi Florian,
>
>> What's your stance on atomic fragments for IPv6?
>
> We did not particularly consider atomic fragments. Could you be a
> bit more specific?
I think we've got a classical pick-any-two situation: interoperability
with existing clients, statelessness in the server, and compliance
with the existing specification:
You can send atomic fragments if you've recently received an ICMPv6
message requesting for a particular address. This requires state in
the server.
You can unconditionally send atomic fragments. This breaks
interoperability with existing clients.
You can never send atomic fragments. This is not what the
specification requires.
This overlaps with concerns in your proposal because the size of the
Fragmentation header might have some impact on your size calculations.
From mir at ripe.net Mon Sep 24 10:18:05 2012
From: mir at ripe.net (Mirjam Kuehne)
Date: Mon, 24 Sep 2012 10:18:05 +0200
Subject: [dns-wg] New on RIPE Labs: Counting DNSSEC
Message-ID: <5060173D.4050305@ripe.net>
Dear colleagues,
Please find a new article on RIPE Labs:
Counting DNSSEC (by Geoff Huston):
https://labs.ripe.net/Members/gih/counting-dnssec
Kind regards,
Mirjam Kuehne
RIPE NCC
From bmanning at vacation.karoshi.com Mon Sep 24 12:47:47 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 24 Sep 2012 10:47:47 +0000
Subject: [dns-wg] Draft recommendation for limiting the EDNS0 response
size on authoritative name servers
In-Reply-To: <87txurxoks.fsf@mid.deneb.enyo.de>
References: <919272091.27738157.1348232922611.JavaMail.root@surfnet.nl>
<87txurxoks.fsf@mid.deneb.enyo.de>
Message-ID: <20120924104747.GA25420@vacation.karoshi.com.>
On Fri, Sep 21, 2012 at 07:39:31PM +0200, Florian Weimer wrote:
> * Gijs van den Broek:
>
> > Hi Florian,
> >
> >> What's your stance on atomic fragments for IPv6?
> >
> > We did not particularly consider atomic fragments. Could you be a
> > bit more specific?
>
> I think we've got a classical pick-any-two situation: interoperability
> with existing clients, statelessness in the server, and compliance
> with the existing specification:
>
> You can send atomic fragments if you've recently received an ICMPv6
> message requesting for a particular address. This requires state in
> the server.
>
> You can unconditionally send atomic fragments. This breaks
> interoperability with existing clients.
>
> You can never send atomic fragments. This is not what the
> specification requires.
>
> This overlaps with concerns in your proposal because the size of the
> Fragmentation header might have some impact on your size calculations.
your still stuck guessing the PMTU.
the problem is not just firewalls.
the server is going to be keeping more state, either by this method
or by switchig to TCP.
i talked about this a few years back: ww.interlab.ait.ac.th/aintec09/program.php
/bill
From labs at ripe.net Tue Sep 25 15:26:17 2012
From: labs at ripe.net (RIPE Labs Administrator)
Date: Tue, 25 Sep 2012 15:26:17 +0200
Subject: [dns-wg] New on RIPE Labs: Using RIPE Atlas: A DENIC Case Study
Message-ID: <5061B0F9.3010109@ripe.net>
[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
From ondrej.sury at nic.cz Wed Sep 26 11:22:25 2012
From: ondrej.sury at nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Wed, 26 Sep 2012 11:22:25 +0200
Subject: [dns-wg] Pointer to DNS Benchmarking list
Message-ID:
The mentioned mailing list is:
dns-benchmarking at 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 at nic.cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4150 bytes
Desc: not available
URL: