While investigating. Magic Banana's elegant & correctly interpreted solution:
echo 2a02:2788:1000:0:6037:fc9a:27ac:10c7 | sed s/'[0-9a-f]\{4\}'/$(openssl
rand -hex 2)/$(shuf -i 4-7 -n 1)
I discovered that this script occasionally places the newly generated
four-digit hex number in the eighth field.
Examples:
2a02:2788:1000:0:6037:fc9a:27ac:5467 and
2a02:2788:1000:0:6037:fc9a:27ac:5558
However, {shuf -i 4-7 -n 1} stays within its allotted boundaries, producing
4's, 5's, 6's & 7's randomly; never 8's.
Also, {openssl rand -hex 2} consistently cranks out four-digit hex numbers.
What I'm actually trying to do is to replace all of the last six fields of
the initiating IPv6 address with new
four-digit hex numbers, run the script 65,536 times, and then use a
simplified version of my nmap script to capture
the registered PTR for each new IPv6, a far quicker approach than my earlier
method of capturing the PTR records of
a hundred, 64K groups of IPv6 addresses, which does the hostname lookups
6,553,600 times. Much more probitive and
a hundred times quicker.
So far, I've tried replacing (shuf -i 4-7 -n 1) with $i in a six-step "do"
loop and nesting that inside a 65,536
step nested do loop (as in Basic) but I'm wrestling with the syntax of that
approach.
Back to the prospect that nslookup (and dig -x) are getting hijacked: Doesn't
matter, as the server's gratuitous
hostname lookups would be hijacked the same way. And none of them can be
resolved to any usable numerical address.
George Langford
