Re: New addresses for b.root-servers.net

[Matthew Petach]

On Fri, Jun 2, 2023 at 10:40 AM William Herrin  wrote:

> On Fri, Jun 2, 2023 at 9:57 AM Jim  wrote:
> > A major concern would be if the IP address were eventually re-assigned
> to something else that
> > ended up reporting false answers due to a malicious or misconfigured DNS
> service.
>
> Hi Jim,
>
> That's one reason I suggested intentionally making it a false
> responder for the final year of its post-service hold. Return wildcard
> A and  records for all queries pointing to a web site which
> responds to any URL with, "Hey buddy, your DNS software is so grossly
> out of date that now it's broken and will stay broken until you fix
> it."
>
> Anybody still sending queries after that gets what they get and
> deserves it -- as long as the time that passes until the final year is
> long enough that only the most reckless and incompetent users are
> still sending queries.
>

I think you underestimate the time frames involved in some projects.
My older brother was deeply involved in the James Webb space telescope
project.
At one point, while visiting him at the giant clean room in Redondo Beach,
we started talking about the specifications on the computers onboard the
telescope.  I was aghast at how out-of-date the systems being installed
were,
and noted I could pop over to Fry's and pick up something with 20x the
memory,
running 10x as fast with pocket money.
He countered by pointing out there were thousands of subcontractors
involved
in the project, and everything had to come together smoothly at the end.
Once
the design work was completed, *everything* was frozen; no changes were
allowed,
no matter how well-intentioned, because there could be unanticipated ripple
effects
on other components being worked on by completely independent
subcontractors.
The end result being that what was being launched was based on hardware and
software that was finalized nearly two decades earlier.

It's a bit unkind to think that only "reckless and incompetent users" will
still be
sending queries years later, when there are plenty of projects like the
James
Webb space telescope where the elements were locked in years before any
decision to renumber root servers might have been made.

I agree with Jim.  Once a block was in use by a root server instance,
encoded
in root hints files, it should be forever reserved as such.  If we want to
make
use of different RIRs and distribute responsibility around the planet,
transfer
the ownership of a block from one RIR to another; don't count on everything
on and off the planet being able to update their root hints.

Thanks!

Matt

(IETF I-D) Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-ietf-opsec-ipv6-addressing-00.txt)

[Fernando Gont]

Folks,

The IETF OPSEC WG has adopted our IETF I-D entitled "Implications of 
IPv6 Addressing on Security Operations".


The IETF-ID is available at:

 * TXT: 

 * HTML: 




We have tried to make the document as practical as possible for anyone 
doing security operations. Your comments and suggestions will be highly 
appreciated.


P.S.: Thanks to those of you that sent feedback for previous revision of 
this document, by the way!


Regards,
Fernando




 Forwarded Message 
Subject: New Version Notification for 
draft-ietf-opsec-ipv6-addressing-00.txt

Date: Fri, 02 Jun 2023 07:26:18 -0700
From: internet-dra...@ietf.org
To: Fernando Gont , Guillermo Gont 




A new version of I-D, draft-ietf-opsec-ipv6-addressing-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:   draft-ietf-opsec-ipv6-addressing
Revision:   00
Title:  Implications of IPv6 Addressing on Security Operations
Document date:  2023-06-02
Group:  opsec
Pages:  13
URL: https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6-addressing-00.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-addressing/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-addressing



Abstract:
   The increased address availability provided by IPv6 has concrete
   implications on security operations.  This document discusses such
   implications, and sheds some light on how existing security
   operations techniques and procedures might need to be modified
   accommodate the increased IPv6 address availability.




The IETF Secretariat

Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 03 Jun, 2023

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  924953
Prefixes after maximum aggregation (per Origin AS):  350297
Deaggregation factor:  2.64
Unique aggregates announced (without unneeded subnets):  450284
Total ASes present in the Internet Routing Table: 74484
Prefixes per ASN: 12.42
Origin-only ASes present in the Internet Routing Table:   63929
Origin ASes announcing only one prefix:   26283
Transit ASes present in the Internet Routing Table:   10555
Transit-only ASes present in the Internet Routing Table:440
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  55
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:  1055
Number of instances of unregistered ASNs:  1062
Number of 32-bit ASNs allocated by the RIRs:  42004
Number of 32-bit ASNs visible in the Routing Table:   34658
Prefixes from 32-bit ASNs in the Routing Table:  172526
Number of bogon 32-bit ASNs visible in the Routing Table:27
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:579
Number of addresses announced to Internet:   3056305152
Equivalent to 182 /8s, 43 /16s and 132 /24s
Percentage of available address space announced:   82.6
Percentage of allocated address space announced:   82.6
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.6
Total number of prefixes smaller than registry allocations:  308714

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   246035
Total APNIC prefixes after maximum aggregation:   69651
APNIC Deaggregation factor:3.53
Prefixes being announced from the APNIC address blocks:  240032
Unique aggregates announced from the APNIC address blocks:98413
APNIC Region origin ASes present in the Internet Routing Table:   13444
APNIC Prefixes per ASN:   17.85
APNIC Region origin ASes announcing only one prefix:   3964
APNIC Region transit ASes present in the Internet Routing Table:   1798
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   8752
Number of APNIC addresses announced to Internet:  773473152
Equivalent to 46 /8s, 26 /16s and 67 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-153913
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:269929
Total ARIN prefixes after maximum aggregation:   122853
ARIN Deaggregation factor: 2.20
Prefixes being announced from the ARIN address blocks:   272782
Unique aggregates announced from the ARIN address blocks:130493
ARIN Region origin ASes present in the Internet Routing Table:19126
ARIN Prefixes per ASN:

Re: New addresses for b.root-servers.net

[William Herrin]

On Fri, Jun 2, 2023 at 9:57 AM Jim  wrote:
> A major concern would be if the IP address were eventually re-assigned to 
> something else that
> ended up reporting false answers due to a malicious or misconfigured DNS 
> service.

Hi Jim,

That's one reason I suggested intentionally making it a false
responder for the final year of its post-service hold. Return wildcard
A and  records for all queries pointing to a web site which
responds to any URL with, "Hey buddy, your DNS software is so grossly
out of date that now it's broken and will stay broken until you fix
it."

Anybody still sending queries after that gets what they get and
deserves it -- as long as the time that passes until the final year is
long enough that only the most reckless and incompetent users are
still sending queries.

Regards,
Bill Herrin

--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: New addresses for b.root-servers.net

[Jim]

On Thu, Jun 1, 2023 at 5:59 PM William Herrin  wrote:

A server generation is about 3 years before it's obsolete and is
> generally replaced. I suggest making the old address operable for two .
> generations (6 years) and black-holed for another generation (3 more  
>

As you mention.. there is No TTL for the root hints.  The TTL is Infinite.
And not
all users will be retired after 3 years... there are DNS resolvers online
running
10-year old code and there are DNS resolvers on the internet that may not
see a roots hint
update in the next 10 years.It is unlikely that there is any practical
way of giving notice
to the operators of such servers.

Therefore, I would suggest IP Addresses that ever appeared in the official
root hints
should be reserved permanently and exclusively for official root service,
then blackholed indefinitely once service
is not in operation anymore to prevent any DNS service other than an
official root server appearing at
that IP at any point in time in the future  no matter how many years have
elapsed (Infinite TTL).

A major concern would be if the IP address were eventually re-assigned to
something else that
ended up reporting false answers due to a malicious or misconfigured DNS
service.

DNS resolvers can handle no answer by trying other servers,  but
a false answer from an unauthorized and malicious root service being
received by non-validating
resolvers would be fairly certain to be capable of causing total failure in
the resolver;
while an IP address being offline would more likely only cause impairment
or delays.

It's understandable if some root service IP addresses stop providing
service years after
the end of service, and resolvers should still be able to function at some
level with
reduced resiliency and increased errors  if only a small number have
changed.


> Regards,
> Bill Herrin
>
--
-JH

Re: New addresses for b.root-servers.net

[Jared Mauch]

I know when I did the openresolver project stuff I saw a number that would send glue or referrals from before they moved to the root servers domain names. - Jared Sent via RFC1925 compliant deviceOn Jun 2, 2023, at 8:49 AM, Nathan Ward  wrote:

On 2/06/2023 at 10:22:46 AM, Wes Hardaker  wrote:



2. I'll note that we are still serving DNS requests at the addresses thatwe switched away from in 2017 [1][2].  At that time we actually onlypromised 6 months and we've doubled that time length with our latestannounced change.  But we do need a date after which we can turn offservice to an address block if some reason demands it.



Hi Wes,Seems to me that this could be heavily informed by historical data from this earlier renumbering.Do you have query rates over time for the old and new addresses since this change in 2017?Even if you end up with the same answer of 12mo, data supporting it may give comfort to the community.Maybe you make a call that once it’s at say 1% or 0.1% or something like that, then it’s OK to turn off - and make a prediction for when that might be based on the historical data.--Nathan Ward

Re: New addresses for b.root-servers.net

[Nathan Ward]

On 2/06/2023 at 10:22:46 AM, Wes Hardaker  wrote:

>
> 2. I'll note that we are still serving DNS requests at the addresses that
> we switched away from in 2017 [1][2].  At that time we actually only
> promised 6 months and we've doubled that time length with our latest
> announced change.  But we do need a date after which we can turn off
> service to an address block if some reason demands it.
>

Hi Wes,

Seems to me that this could be heavily informed by historical data from
this earlier renumbering.

Do you have query rates over time for the old and new addresses since this
change in 2017?

Even if you end up with the same answer of 12mo, data supporting it may
give comfort to the community.

Maybe you make a call that once it’s at say 1% or 0.1% or something like
that, then it’s OK to turn off - and make a prediction for when that might
be based on the historical data.

--
Nathan Ward