I'm finding it unreachable from at least one Level 3 router. I'm seeing
behavior which makes me suspect 1.1.1.1/32 has been incorrectly defined an
interface IP on that device; one of our locations gets an immediate ping
response for 1.1.1.1, and a traceroute of one hop, which is that first upst
Very interesting...
I just heard about this problem today from one of my friend’s who supports of
the big SP network (Russia). He got complains from one of their peer. After
short investigation he found that they blackholing 1.1.1.1.
When I asked him about the reasons, he can’t explain because
On 2018-04-03 (Tue) at 01:22 EDT, Tore Anderson wrote:
> Any plans to support NSID and/or "hostname.bind" to allow clients to
> identify which node is serving their requests? For example:
FWIW:
$ dig @1.0.0.1 id.server. CH TXT
[...]
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1
Great article!
Thanks for sharing :)
On Mon, Apr 2, 2018 at 11:12 PM, Hank Nussbacher
wrote:
> On 03/04/2018 01:39, Matt Hoppes wrote:
>
> You might be interested in these links which compare the services:
> https://medium.com/@nykolas.z/dns-resolvers-performance-
> compared-cloudflare-x-googl
1.1.1.1 not usable via Windstream peering in Chicago.
# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
...
3 be4.agr01.chcg02-il.us.windstream.net (40.136.99.22) 5.158 ms
5.116 ms 7.565 ms
4 ae13-0.cr01.chcg01-il.us.windstream.net (40.136.99.44) 4.673 ms
* Marty Strong via NANOG
> Routing from ~150 locations, plenty of redundancy.
Any plans to support NSID and/or "hostname.bind" to allow clients to
identify which node is serving their requests? For example:
$ dig @nsb.dnsnode.net. hostname.bind. CH TXT +nsid
[...]
;; OPT PSEUDOSECTION:
; EDNS:
On 03/04/2018 01:39, Matt Hoppes wrote:
You might be interested in these links which compare the services:
https://medium.com/@nykolas.z/dns-resolvers-performance-compared-cloudflare-x-google-x-quad9-x-opendns-149e803734e5
https://webxtrakt.com/public-dns-performance
-Hank
> So in all this discu
So in all this discussion, what I'm finding interesting is that 8.8.8.8
is actually more hops away from me than either 9.9.9.9 or 1.1.1.1
On 4/2/18 6:06 PM, Seth Mattinen wrote:
On 4/2/18 14:58, Marty Strong via NANOG wrote:
Routing from ~150 locations, plenty of redundancy.
https://www.cloud
On 4/2/18 14:58, Marty Strong via NANOG wrote:
Routing from ~150 locations, plenty of redundancy.
https://www.cloudflare.com/network/
I recommend 9.9.9.9 to people (if they must use a public resolver)
because Quad9/PCH serves local markets of all sizes with anycast nodes
and peering, not ju
Routing from ~150 locations, plenty of redundancy.
https://www.cloudflare.com/network/
Regards,
Marty Strong
--
Cloudflare - AS13335
Network Engineer
ma...@cloudflare.com
+44 7584 906 055
smartflare (Skype)
https://www.peeringdb.com/asn/13335
> On 2 Apr 2018,
On Mon, Apr 2, 2018 at 8:14 PM, Saku Ytti wrote:
> If they are for redundancy, wouldn't it be preferable to route them to
> different place to cover more fault scenarios.
>
> I would complain if they are routed to same place.
Better start complaining then :-)
Kind regards,
Job
If they are for redundancy, wouldn't it be preferable to route them to
different place to cover more fault scenarios.
I would complain if they are routed to same place.
On 2 April 2018 at 22:56, Colin Johnston wrote:
> dont know if this is a problem but seeing different as paths for 1.0.0.1 and
dont know if this is a problem but seeing different as paths for 1.0.0.1 and
1.1.1.1 in UK as lands
2 185.61.135.25 (185.61.135.25) 1.964 ms 72.824 ms 72.835 ms
3 10.254.84.3 (10.254.84.3) 2.671 ms 2.577 ms 2.601 ms
4 31.28.72.22 (31.28.72.22) 2.798 ms 2.897 ms 3.123 ms
5 * * *
6
13 matches
Mail list logo
