ipv6 handling issue
If an ipv6 is detected from glue or from resolver makes a difference because of different handling of :0: in the ipv6 address
grep 1c00:a8ff:fe00:fc ednscomp.input
zwembadforum.be. ns1.86id.nl. 2001:1460:1:0:1c00:a8ff:fe00:fc
--> From resolver zinkendakgoten.be. ns01.mijnkreanet.be. 2001:1460:1::1c00:a8ff:fe00:fc ---> From glue
Notice the difference in :0: and :: . Now it happens to be the case that genreport is doing some manipulation of the ipv6 records himself (problem 1b, if you want). For example it transforms 2001:1460:1::1c00:a8ff:fe00:fc to 2001:1460:1:0:1c00:a8ff:fe00:fc, causing evalzone.py to crash because it can not find 2001:1460:1::1c00:a8ff:fe00:fc in the endscompoutput
On top of that this issue also poses a "problem" for the optimization algorithm because this server will be scanned twice instead of once.
Fix problem 1: I found out that the python ipaddress library with the .compressed method uses the same conversion of ipv6 addresses then genreport does. For example both genreport as the ipaddress library do: 2001:1460:1::1c00:a8ff:fe00:fc to 2001:1460:1:0:1c00:a8ff:fe00:fc or 2001:678:6c::1 --> 2001:678:6c::1 (multiple zeros stay ::)
So I run the detected glue AAAA or the discovered AAAA via the resolver through the compressed ipaddress library before storing them in the sets/pickles. I did this in attached files nsname2ipset.py and zone2pickle.py. * * (minor) Problem 2: ::ffff addresses seems to be an exception between ipaddress library and genreport output.
Fix problem 2: Because these are ipv4 mapped addresses I added an extra conversion in evalzone.py so that the latter can still find back ::ffff addresses in the ednscomp out files. I did this in attached fileevalzone.py **
I will commit the fixes in a branch