它们无法无天了，防火Q把cloudfront.net也阻断了

Microcharon

iks 发表于 2024-9-20 00:42
1. github.com 的 80 和 443 端口均没有被阻断，可以观察到的是干扰；
2. *.eu.org 的阻断是 80 端口阻断 ...

就怕这只是开始，下一步DNS污染就凉透了

iks 发表于 2024-9-20 00:42
1. github.com 的 80 和 443 端口均没有被阻断，可以观察到的是干扰；
2. *.eu.org 的阻断是 80 端口阻断 ...

凡事抱着学习的态度，不然容易打脸。

itdog实际上是通过他自己的灰产解析了域名。显示的是ip的ping而不是域名。你应该能理解了

iks

iks 发表于 2024-9-20 00:42
1. github.com 的 80 和 443 端口均没有被阻断，可以观察到的是干扰；
2. *.eu.org 的阻断是 80 端口阻断 ...

确实我 CNAME 到 *.cloudfront.net 的站点还正常的

iks

toot 发表于 2024-9-20 00:45
凡事抱着学习的态度，不然容易打脸。

itdog实际上是通过他自己的灰产解析了域名。显示的是ip的ping而 ...

，，，那个是 http 请求不是 ping 球球你先学，，，

iks

说白了跟 IP 跟节点是不是 CloudFront 跟端口是不是 80 都没有什么关系，只跟 HTTP 明文请求中 Host Header 里的值 cloudfront.net 有关系。

验证也很简单，构造一个发往非 AWS 网络的请求：

curl --resolve d1174705pgz8b8.cloudfront.net:80:38.175.45.16 -v http://d1174705pgz8b8.cloudfront.net/robots.txt

或发往非 80 端口的请求：

curl --resolve d1174705pgz8b8.cloudfront.net:8080:38.175.45.16 -v http://d1174705pgz8b8.cloudfront.net:8080/robots.txt

均可以获得 reset 结果

其中 38.175.45.16 美国 加利福尼亚州 洛杉矶 edgenext.com

toot

toot 发表于 2024-9-20 00:45
凡事抱着学习的态度，不然容易打脸。

itdog实际上是通过他自己的灰产解析了域名。显示的是ip的ping而 ...

你就别丢人现眼了我看着都想笑

iks

iks 发表于 2024-9-20 00:56
，，，那个是 http 请求不是 ping 球球你先学，，，

犟种，求求你学习一下域名阻断/ip阻断的区别

截那个图别人会笑话你

toot

toot 发表于 2024-9-20 01:02
犟种，求求你学习一下域名阻断/ip阻断的区别

截那个图别人会笑话你

对对对，你说得都对好吧，顺从你了

iks

iks 发表于 2024-9-20 01:00
你就别丢人现眼了我看着都想笑

真是你.**丢人现眼的玩意儿。千万不要编辑你的内容，让更多人笑话一下

zhujibcomiks

toot 发表于 2024-9-20 01:03
真是你.**丢人现眼的玩意儿。千万不要编辑你的内容，让更多人笑话一下

怎么急了，你不觉得你是对的么，急能证明你更加对是不是？
https://hostloc.com/thread-1198673-1-1.html
啊再欣赏一遍

zeb

她说吞过他的它 发表于 2024-9-19 23:02
需要北岸才能用是把

恩 需要北岸的 没北岸用不了

zeb 发表于 2024-9-20 00:43
就怕这只是开始，下一步DNS污染就凉透了

CloudFront 默认域名阻断好些年了，看起来只有楼主跟捡到宝一样，实则无需担心