Marco Davids
Marco Davids
The visualizer doesn't seem to recognise IPv6 address as belong to same device as the IPv4 address. See image below. The IPv6-address is also the Nexus5x in this case. Possible...
With '/etc/init.d/firewall stop' it seems that outgoing IPv4 traffic is blocked and IPv6 traffic isn't. The behaviour, whatever it is, should be the same between v4 and v6.
The visualizer shows 192.168.8.255 as a regular IP-address. No DNS-translation is obviously made. But perhaps it can show alternative text such as: "LAN broadcast-address".
SPIN/Valibox announces itself as IPv4-local resolver (192.168.8.1) via DHCP. But how does this work for IPv6? I noticed a fe80::e695:6eff:fe40:298c in /etc/resolv.conf at some point. Does this work, is this...
Sometimes service.example.com resolves to many IP-addresses, for example when it is provided by a CDN. Blocking 'service.example.com' in the 'bolletjesapp' therefore has limited effect, until all possible options are blocked....
Perhaps we can alert the user if a device is connecting to the outside world via unencrypted (ie non-TLS) traffic?
Tested on Ubuntu 17.04.
I don't think the explanation for the 'referrer-policy' header is correct anymore. It says the default is 'no-referrer-when-downgrade', but that seems to be 'strict-origin-when-cross-origin' these days [1]. I also wondered...
internet.nl has a section called "Further email testing", with some handy tools. I propose to add the excellent https://www.dmarctester.com/ tool there.
We noticed that some domains (in fact, only a very few under .nl) might cause issues when RFC8189 (aggressive NSEC caching) is used. DNSviz has the capability of showing this...