Interesting ... but where does tracert get its IP address information? You do a tracert on any of those domains and of course it takes "forever" (>>500ms). But tracert converts the domain to an IP address
before it starts looking for connections and that part of the process appears to be just about instantaneous. I suppose it could be in the order of 500ms but anything in excess of 20ms should be appreciable and there just doesn't
seem to be an appreciable delay - like
QUOTE(C:\>tracert hazefoul.net)
Tracing route to hazefoul.net [217.78.27.138]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms xxx.xxx.xxx.xxx
... etc.
Does anyone know what is going on here? Maybe I blinked - but I tried all 3 and the addresses of
- hazefoul.net [217.78.27.138]
- topusa.hk [222.84.88.74]
- jtnhjd.stratumikon.com [222.173.251.30]
appeared in each case very rapidly indeed at the start of the trace.
My thinking.
The null hypothesis/"falsifiable hypothesis" is that "Polyakov" sites do
not block address lookups by SC/Ironport/Miscellaneous snoops. The hypothesis is disproved if a single (replicatable) instance is found where the lookup of a snoop
is blocked. If they are blocked (an unverifiable assertion) then they are not
not blocked (a verifiable assertion) per the hypothesis - and yes, there really is a difference. But it seems
all queries to the domains in question are inhibited which affects the definition of "blocked". Also, it is a problematic test because the definition of "snoop" is arbitrary/self-defining, which complicates prior testing. (In other words, I think StevenUnderwood is being perfectly reasonable in requesting the data needed for a scientific test.)
Nevertheless,
if there is a class of query which is not inhibited the matter might be resolved in relation to that class of query. And which might point to a potential source of information for SC. Not that SC would particularly want to notify a Spamhaus star that his distribution is working. But there might be other uses for it.