News for hackers. Stuff that matters.

sajal83

sajal83 on Hacker News

Re:Fastly S-1 on Friday April 19, 2019 @04:00PM (#19702525)
Most, if not all websites require more than one round trip.
Re:WebSub: Open protocol for distributed pub–sub communication on the ... on Thursday July 05, 2018 @12:39PM (#17464665)
> 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.

Re:My home lab setup for highly-available Internet on Wednesday July 04, 2018 @01:49AM (#17455475)
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.

Re:Yubico sent marketing email to address submitted for product replac... on Sunday May 13, 2018 @11:49PM (#17062529)
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"

Re:1.1.1.1 might lead to slower CDN performance on Wednesday May 02, 2018 @04:24PM (#16980833)
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.
Re:Suspicious event hijacks Amazon traffic for 2 hours, steals cryptoc... on Wednesday April 25, 2018 @07:33AM (#16920541)
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.

Re:Hijack of Amazon’s domain service used to reroute web traffic for t... on Tuesday April 24, 2018 @03:59PM (#16916022)
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

Re:AWS Route 53 was misrouted for nearly 2 hours on Tuesday April 24, 2018 @09:37AM (#16912438)
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.

Re:Cloudflare's 1.1.1.1 might lead to slower CDN performance on Saturday April 21, 2018 @02:52PM (#16892727)
Yeah I quoted that in the post. Regardless, I make the case for EDNS Client Subnet
Re:DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Qua... on Monday April 02, 2018 @07:39AM (#16733732)
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.

Re:DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Qua... on Monday April 02, 2018 @06:33AM (#16733519)
9.9.9.9 does not pass along EDNS client subnet resulting in wrong geo-located responses. It is their "feature".
Re:DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Qua... on Monday April 02, 2018 @05:55AM (#16733401)
Yep you are right right.

    ~# mtr --report --address 192.168.2.2 1.1.1.1
    Start: Mon Apr  2 16:53:31 2018
    HOST: apu                         Loss%   Snt   Last   Avg  Best  Wrst StDev
      1.|-- 192.168.2.1                0.0%    10    0.9   1.1   0.9   1.2   0.0
      2.|-- 10.137.128.1               0.0%    10   11.3  12.8  10.7  17.1   1.8
      3.|-- 10.246.253.133             0.0%    10    7.7   8.2   7.5   9.1   0.0
      4.|-- 10.185.94.203              0.0%    10    9.1   8.4   6.9   9.4   0.6
      5.|-- 10.185.94.25               0.0%    10    9.5   8.7   7.7  10.0   0.5
      6.|-- 61-91-220-101.static.asia  0.0%    10   11.7  11.7   8.6  25.7   5.2
      7.|-- 58-97-82-116.static.asian  0.0%    10   10.7  10.2   8.6  15.4   1.9
      8.|-- ppp-171-102-254-81.revip1  0.0%    10    9.2   9.2   7.1  10.8   0.9
      9.|-- ppp-171-102-250-134.revip  0.0%    10    8.4  10.0   8.4  11.3   0.7
     10.|-- ppp-171-102-250-149.revip  0.0%    10    9.0   9.7   9.0  10.9   0.3
     11.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
    ~# mtr --report --address 192.168.2.2 1.0.0.1
    Start: Mon Apr  2 16:54:05 2018
    HOST: apu                         Loss%   Snt   Last   Avg  Best  Wrst StDev
      1.|-- 192.168.2.1                0.0%    10    1.2   1.1   0.8   1.3   0.0
      2.|-- 10.137.128.1               0.0%    10   12.1  12.8   9.2  18.2   2.4
      3.|-- 10.246.253.133             0.0%    10    9.8   9.0   7.5  14.7   2.0
      4.|-- 10.185.94.203              0.0%    10    4.4   7.9   4.4   8.8   1.2
      5.|-- 10.185.94.17               0.0%    10    9.2   9.1   7.2  10.3   0.9
      6.|-- 61-91-220-55.static.asian  0.0%    10    9.7  10.6   8.0  17.2   2.6
      7.|-- 58-97-82-120.static.asian  0.0%    10   10.5   9.7   8.2  11.2   0.7
      8.|-- ppp-171-102-254-65.revip1  0.0%    10   10.5   9.7   8.8  10.7   0.0
      9.|-- ppp-171-102-254-227.revip  0.0%    10    8.9  13.1   8.8  44.0  10.8
     10.|-- 61-91-213-130.static.asia  0.0%    10   10.9   9.8   8.3  10.9   0.6
     11.|-- TIG-Net242-40.trueinterga  0.0%    10   15.0  14.1  10.9  16.1   1.8
     12.|-- TIG-Net245-243.trueinterg  0.0%    10   38.1  38.0  36.4  40.6   0.9
     13.|-- 13335.sgw.equinix.com      0.0%    10   37.4  38.6  36.4  48.5   3.5
     14.|-- 1dot1dot1dot1.cloudflare-  0.0%    10   36.9  36.3  35.0  36.9   0.5
Edit: Formating
Re:DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Qua... on Monday April 02, 2018 @05:39AM (#16733346)
https://pulse.turbobytes.com/results/5ac1f967ecbe4078c200ee4...

Cloudflare consistently times out from these networks.

Netherlands - AS13127 Philippines - AS135132 Thailand - AS17552 (One of the largest consumer internet providers) US - AS7018 (AT&T)

Re:1.1.1.1: Fast, privacy-first consumer DNS service on Monday April 02, 2018 @03:45AM (#16732992)
https://pulse.turbobytes.com/results/5ac1deefecbe4078c200ed8...

Query times and rechability from 58 locations. 3 locations still can't reach 1.1.1.1, but for most users cached response is faster from Cloudflare.

Re:Use streaming JSON to reduce latency on mobile on Tuesday February 20, 2018 @01:11AM (#16418199)
If the concern is HTTPS overhead, why not use HTTP/2 and send multiple requests?

I think streaming would be useful only if the responses are stateful and it's hard to share it across requests.

Re:Show HN: Certmon – Monitor and track TLS endpoints for certificate ... on Thursday February 01, 2018 @01:23PM (#16284291)
Looks cool, but it appears to have the same problem I have with all other similar tools, i.e. I can't specify which IP(or hostname) I want to test against. This is not an issue if your service is behind a single server(or loadbalancer)

Check out the "endpoints" portion in example config : https://github.com/turbobytes/certmon/blob/master/example_co...

Re:Show HN: Certmon – Monitor and track TLS endpoints for certificate ... on Thursday February 01, 2018 @12:48PM (#16283916)
The main goal of this project is as a helper for monitoring/alerting, a very basic UI is present and is optional.

I made this tool for our internal use, and posted it here just in case anyone else has similar issues.

Edit: Added screenshot https://github.com/turbobytes/certmon#screenshot

Older »