[dns-operations] 答复: L-Root IPv6 Address renumbering

Terry Manderson terry.manderson at icann.org
Mon Mar 14 05:47:39 UTC 2016

Hi Doug,

The operational "burden" is long tailed, and if you were thinking only
about 1 server listening for tcp and udp on one extra address and
maintaining 1 simple acl, then I think I would be with that. But it's
simply not.

L-root has some 140+ instances out there (not counting actual running
servers) all with at minimum 1 upstream. An upstream that will need to be
advised when we stop announcing the prefix, and all the trappings that go
with that such as LOAs, ACLs, route filters, and so on.. Not even
considering the infrastructure behind that to do stats collection and
reporting. This project will take a long time as it is. It's not easy, and
sometimes people put things like it into the too hard basket and from my
perspective (warning, my opinion only!) we are left with a less concise
root server system that ultimately can be targeted more easily affecting
stability. (again, my opinion)

More of my opinion: I think it is far better for everyone to just change
their hints files, be done with it, and in 6 months we get to start the
process of unwinding the address from the L-Root infrastructure so that
the prefix is dark (best service option for all) therefor it 1) cannot ba
DDoS vector against L-Root or anyone else by reflection/amplification; 2)
is able to be reused elsewhere or for research; and 3) is not sending
misinformation or lulling anyone into a false sense of active service.


On 14/03/2016, 2:41 PM, "Doug Barton" <dougb at dougbarton.email> wrote:

>On 03/13/2016 07:52 PM, Stephan Lagerholm wrote:
>> It does not seem to be to be a large operational burden to keep the old
>>address longer, what is the driving force behind this aggressive
>I have some thoughts on this topic, but Stephan asked the question
>directly that I was planning to ask. I'm not sure it was answered, is it
>something you are comfortable responding to?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6343 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160314/cd69ac4f/attachment.bin>

More information about the dns-operations mailing list