Hacker News new | past | comments | ask | show | jobs | submit | sajal83's comments login

Most, if not all websites require more than one round trip.


HTTP2 can reduce this significantly.


> The subscriber must be directly network-accessible and is identified by its Subscriber Callback URL

Does this mean the subscriber needs to have a forwarded port open to the internet for this to work? Without IPv6, users behind NAT (and specifically behind CGNAT) wouldn't be able to use it.


I have a redundant 2 ISP setup, and use multipath TCP to use both of them at the same time.

A very outdated post about my setup : https://www.sajalkayan.com/post/fun-with-mptcp.html

I now have 2 broadband ISPs, and optionally I can hook in my phone's 4g into the mix.

Multipath TCP allows me to "mix" bandwidth of both ISPs at the same time.


My policy: if email is interesting/relavent. Do nothing.

If I remember subscribing and haven't attempted to unsubscribe in the past, attempt to unsubscribe. Spending max 10 seconds.

All other situations, hit "mark as spam"


I currently run my own (DNSSEC validating) Bind. But it has some drawbacks. For occasionally visited sites/tlds, my bind would need to contact root more often than if using a shared resolver.


https://pulse.turbobytes.com/results/5adf2844ecbe40692e003ad...

Some traceroutes captured during the incident. The results that show "Target unreachable" were the ones seeing the hijacked paths.


https://pulse.turbobytes.com/results/5adf2844ecbe40692e003ad...

Some traceroutes captured during the incident. The results that show "Target unreachable" are the ones seeing the hijacked paths


The bad routes can be seen by agents: 219-YVR-Canana, 221-qeast, 16-TurboBytes, 6-VPS TH, 10-TurboBytes, 220-TurboBytes, 17-aks-seattle and 190-ATT-AS7018

From outages mailing list, following subnets were affected.

205.251.192.0 205.251.193.0 205.251.195.0 205.251.197.0 205.251.199.0

The issue has since been fixed, outage lasted for ~2 hours.

If you are still using a single DNS provider for your domain, you should consider having a dual-provider setup.


Yeah I quoted that in the post. Regardless, I make the case for EDNS Client Subnet


9.9.9.9 does not pass along EDNS client subnet resulting in wrong geo-located responses. It is their "feature".


According to the FAQ[1], they also offer 9.9.9.10, which passes client subnet at the cost of other features.

[1] https://www.quad9.net/faq


Fair enough, but most users won't care enough look it up and use 9.9.9.10 instead of 9.9.9.9 if they want better performance in exchange for allegedly lower privacy.

It appears 1.1.1.1 also does not pass client-subnet, atleast not by default. Queries to my authoritative from Google always includes client subnet, OpenDNS required request for whitelist. For Cloudflare its unclear.


>It appears 1.1.1.1 also does not pass client-subnet, atleast not by default.

Wow, this is actually a huge issue. Just as a simple test, I tried nslookup google.com for both 1.1.1.1 and 8.8.8.8, and Cloudflare's responses ping at about 200ms, whereas Google's responses ping at ~10ms.


That also explains the abnormally low response time of CloudFlare's solution compared to the 2nd and 3rd place solutions; the geo-location lookups require more time to reach and resolve a decision and thus represent an increase in response time from the resolver (in exchange for improved latency in all future communications to the target server).


If you have a CF PoP close to you, the absent of it shouldn't really matter. Will only have an effect for those with a Google peering much closer than CF peering.


Should, but does not.

  dig @8.8.8.8 o-o.myaddr.test.l.google.com txt +short 
  "74.125.46.11"
  "edns0-client-subnet 94.181.44.185/32"
  dig @9.9.9.10 o-o.myaddr.test.l.google.com txt +short
  "2620:171:57::240"


Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: