[DNSOP] New addresses for b.root-servers.net on 2023-11-27
USC/ISI is renumbering both its IPv4 and IPv6 addresses for b.root-servers.net on 2023-11-27. Our new IPv4 address will be 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b. USC/ISI will continue to support root service over our current IPv4 and IPv6 addresses for at least one year (until 2024-11-27) in order to provide a stable transition period while new root hints files are distributed in software and operating system packages. We are renumbering to increase the resilience of the Root Servers System by further diversifying the number of Regional Internet Registries (RIRs) that have allocated IP addresses to Root Server Operators. Our addresses will be the first in the Root Server System to have been allocated by LACNIC and our routes will be verifiable through LACNIC’s Resource Public Key Infrastructure (RPKI) Trust Anchor Location (TAL). We thank LACNIC for helping make this renumbering possible, and ARIN for supporting our prior addressing assignments. The LACNIC announcement, with English, Spanish and Portuguese translations, can be found on their website here: https://www.lacnic.net/6868/1/lacnic/lacnic-asigna-recursos-de-numeracion-al-servidor-raiz-de-usc_isi Please direct any comments or questions to b-poc isi.edu. Regards, The USC/ISI root operations team P.S. Apologies to anyone receiving multiple copies of this announcement. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP WG Interim June 2023 planning: draft-ietf-dnsop rfc8499bis and lame delegation
Hi WG, Gentle reminder to fill in the doodle to schedule the interim in June. Will extend the poll until Thursday, June 1! -- Benno On 24/05/2023 16:11, Benno Overeinder wrote: Dear WG, As mentioned earlier on the mailing list, the chairs are planning an interim meeting in June to discuss the three options on how to proceed with draft-ietf-dnsop-rfc8499bis wrt. lame delegation: 1) Stick with the current text in the document – the original definition from RFC8499 plus a note that "These early definitions do not match the current use of the term "lame delegation", but there is no consensus on what a lame delegation is." A possible follow-up to this is for someone to start a WG consensus document on "lame", which can update 8499bis. 2) We still find a rough consensus on the definition proposed in the "Meaning of lame delegation" email thread, and the WG can agree that this is a definition useful to DNS engineers/operators. 3) Withdraw the document from WGLC so we can add definitions. Do not propose any new terms and definitions at this stage if we choose this option. Please fill in the Doodle poll to settle on a day and time: - https://doodle.com/meeting/participate/id/az7Z5AOb The options for the time slots are a compromise for CEST/EDT/PDT/AEST/JST. We will close the Doodle poll at the end of Tuesday 30 May. Best regards, Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
