[Netalyzr] Netalyzr wrongly reports that we're redirecting traffic

[Stefan Winter]

Hi,

Netalyzr spits out some very uneasy WARNINGs when it comes to resolving
www.google.com, claiming that we unrightfully redirect traffic. This is
incorrect, and does not look very nice to people running Netalyzr on our
network.

http://n3.netalyzr.icsi.berkeley.edu/restore/id=36ea240d-13492-492bd4a9-1271-44ad-877b/rd

"We received unexpected and possibly dangerous results when looking up
important names
Your ISP is using DNS to redirect specific sites "

and

"3 popular names have a significant anomaly. The ownership suggested by
the reverse name lookup does not match our understanding of the original
name. This could be caused by an error somewhere in the domain
information, deliberate blocking or redirection of a site using DNS, or
it could be that your ISP's DNS Server is acting as a DNS
"Man-in-the-Middle".

We attempted to download HTTP content from the IP addresses that your
ISP's DNS server returned to you for these names. Where the download
succeeded, you can click on the IP address in the table below to
download a compressed file containing an HTTP session transcript.

Note! The session content is potentially harmful to your computer when
viewed in a browser, so use caution when examining it.
Name 	IP Address 	Reverse Name/SOA
encrypted.google.com 	188.93.174.42 	SOA: pri.authdns.ripe.net
www.google.com 	188.93.174.26 	SOA: pri.authdns.ripe.net
www.google-analytics.com 	188.93.174.16 	SOA: pri.authdns.ripe.net
"

This is very likely due to our peering setup. I'd like to report it
here, wondering if there's anything you can do on the code side to
detect the condition as being harmless.

We're connected to an internet exchange point, LU-CIX in Luxembourg.
LU-CIX hosts a Google Cache.

Our resolvers do not interfere with any name resolution requests for
www.google.com and friends; the resolver passes them on to Google as it
should.

Google however knows that our network is in the LU-CIX peering setup,
and will answer to any requests for google names coming from our
resolvers only with IP addresses of the cache in LU-CIX; not with its
"normal" IP addresses.

Using a "host www.google.com", this looks like:

> host www.google.com
www.google.com has address 188.93.174.53
www.google.com has address 188.93.174.48
www.google.com has address 188.93.174.35
www.google.com has address 188.93.174.57
www.google.com has address 188.93.174.38
www.google.com has address 188.93.174.24
www.google.com has address 188.93.174.31
www.google.com has address 188.93.174.42
www.google.com has address 188.93.174.27
www.google.com has address 188.93.174.49
www.google.com has address 188.93.174.16
www.google.com has address 188.93.174.37
www.google.com has address 188.93.174.46
www.google.com has address 188.93.174.20
www.google.com has address 188.93.174.26
www.google.com has address 188.93.174.59
www.google.com has IPv6 address 2a00:1450:4001:800::1011

(Funny enough, the Google Cache is IPv4-only, so the v6 result goes
another way)

I find it an important distinction to make that the non-expected IPs in
resolver response come from the authoritative name server; not from our
resolver.

I wouldn't know immediately how your code would detect this condition in
a proper way; but then I'm just the reporter :-)

Please don't accuse us of things we don't do :-)

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x8A39DC66.asc
Type: application/pgp-keys
Size: 3243 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20130918/cd98680d/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20130918/cd98680d/attachment-0001.bin