Outside the box thoughts

Installman inquired as to what is it about the traffic that makes it resolvable.

The traffic comes into your system as packets identifiable by their Internet
address, IPv4 (four three-digit numbers between 0 & 255) or IPv6 (eight four-
character hex numbers between 0 & FFFF). The host/domain/pointer name is
resolved by a DNS (domain name service) lookup. No single IP address can have
more than one name, controlled by one or another assigned number clearing
house.
Alas, the reverse isn't controlled at all. A host name can have any number of
addresses. Some IPv6-based servers send out the same name in response to all
DNS queries, making it appear that the name has an infinite number of addresses
associated with it, a quantity that would take forever to assign to the actual
information storage devices.
The IPv4 address space is being squandered by the practice of filling servers
with like-named hosts, not unlike the hoarding of wealth.

Regarding the puzzling output in my data plot:
The sharp drops in November and December 2019 remain a mystery to me ...

After failing to find any glitches in the Webalizer software & my associated scripting.
I went back to the beginning and evaluated the data for November 2019, December 2019,
and January 2020. The results are quite different from Passed.Fraction.II_.jpg
but there are still a few of the original PTR's that should be evaluated lest I include
inactive PTR's.

Here's an outline of my progress:
The initial test for resolvability was done by editing the output of the nmap scan of
the list of PTR's with sed to convert "92.242.140.21" and "127.0.0.1" to "unresolvable,"
the "unresolvable" placed in what would be the IPv4 position in the outputs. Some PTR's
are not flagged as 92.242.140.21's by the barefruit errorhandling service and appear as
"Failed to resolve" standard error outputs including the associated PTR's.
Those FTR's are the subject of this communication.
It could taint the data to include "No_DNS" addresses and "Failed to resolve" PTR's in
the unresolvable counts; whereas the "No_DNS" addresses are simply dropped from the
analysis, some of the "Failed to Resolve" PTR's can actually still be looked up with dig -x
or nmap by evaluating the 24 permutations of the four IPv4 octets often included in the
PTR names, so those subsequently resolved PTR's must still be live and belong in the
"unresolvable" counts.
The FTR's for the three months in this analysis were concatenated and subjected to Magic
Banana's 4321-permutations script:
awk -f ./Script-MB-4321-permutations -v sep='\n' <(awk '{print $1}' GB.FTRs.txt) | sudo nmap -Pn -sn -T2 --max-retries 8 -iL '-' oG - | grep "Nmap scan report for " '-' | awk '{print $6,$5}' '-' | sed 's/()/(No_DNS)/g' | tr -d '()' > GB.FTR.Extracted-IPv4s.Permutations-oGnMap.txt
Some of these nmap results clearly are resolutions of the 1234-arranged IPv4 octets, but
only the following grep scripts include them in their outputs:
grep -f GB.CurrentVisitors-2019-11.FTR.txt Temp-05162021-B01.txt > GB.CurrentVisitors.IPv4-PTR-Pairs-2019-11.txt
grep -f GB.CurrentVisitors-2019-12.FTR.txt Temp-05162021-B01.txt > GB.CurrentVisitors.IPv4-PTR-Pairs-2019-12.txt
grep -f GB.CurrentVisitors-2020-01.FTR.txt Temp-05162021-B01.txt > GB.CurrentVisitors.IPv4-PTR-Pairs-2020-01.txt
The many false positives are troubling, so I attempted the same end with awk:
awk '{print $1}' GB.CurrentVisitors-2019-11.FTR.txt | awk '/-/' Temp-05162021-B01.txt > GB.Awk.CurrentVisitors.IPv4-PTR-Pairs-2019-11.txt
awk '{print $1}' GB.CurrentVisitors-2019-12.FTR.txt | awk '/-/' Temp-05162021-B01.txt > GB.Awk.CurrentVisitors.IPv4-PTR-Pairs-2019-12.txt
awk '{print $1}' GB.CurrentVisitors-2020-01.FTR.txt | awk '/-/' Temp-05162021-B01.txt > GB.Awk.CurrentVisitors.IPv4-PTR-Pairs-2020-01.txt
All three of these scripts produce the same 35.1 kB output, so they are not working as I
might expect. I tried changing the end-of-line character in GB.CurrentVisitors-20??-??.FTR.txt
to the pipe ("|") symbol and re-running the last three scripts, but the same 35.1 kB output
was produced by those as well.

Here's the updated graph, where I've patched in the recalculated data for November and
December 2019, as well as January 2020. The middle three of the five stars are the new
data, but the first and last of the five stars are the original data used to keep the
spline-fit line continuous. The puzzling drop in the passed fraction remains and might
only be explained by finding out the specific activity of the unresolvable PTR's.