makes sense.. then your ISP is probably | Dagger | Page 1

ashen lark Dec 12, 2024, 9:07 PM

#

coworker in another region is seeing a third IP.. good news is that they are all AWS IPs

meager sentinel Dec 12, 2024, 9:13 PM

#

strange..the dl.dagger.io is served by the 3.17 ip so maybe some proxies are caching some of those answers. It's a bit strange that you got two different files with the same URL though 🤔

solid lynx Dec 12, 2024, 9:15 PM

#

fwiw - we also started see'ing checksum failures on 0.15.1 - using the dagger-for-github action.

#

doing a dig +trace dl.dagger.io ends up with:

dl.dagger.io.        60    IN    A    99.86.74.102
dl.dagger.io.        60    IN    A    99.86.74.47
dl.dagger.io.        60    IN    A    99.86.74.105
dl.dagger.io.        60    IN    A    99.86.74.128

#

the +trace should resolve from root so by passing any isp stuff.

ashen lark Dec 12, 2024, 9:17 PM

#

FWIW, looks to me that the timestamps in the tar are the difference. the binary inside has the same checksum

solid lynx Dec 12, 2024, 9:21 PM

#

seems to have cleared up in our pipelines. maybe just a long dns propogation delay on githubs network for us or something.

solid lynx Dec 12, 2024, 10:22 PM

#

actually still happening sporadically for us.

upper swallow Dec 13, 2024, 12:12 PM

#

dl.dagger.io is served by CloudFront, meaning that IPs will be different depending on your region. This is a good third party service to check what the IPs should be in your region: https://dnschecker.org/#A/dl.dagger.io

As for your particular setup, one thing that might help is configuring nameservers to 8.8.8.8 or 1.1.1.1 explicitly on the host where this is failing. Before doing that, you can always use dig to see what the domain resolves to using those DNS servers: dig dl.dagger.io @8.8.8.8 or dig dl.dagger.io @1.1.1.1

You can also use the SOA NS directly:

dig +short dagger.io NS
ns-626.awsdns-14.net.
ns-1457.awsdns-54.org.
ns-1728.awsdns-24.co.uk.
ns-200.awsdns-25.com.

dig +short dl.dagger.io @ns-200.awsdns-25.com
18.154.84.126
18.154.84.10
18.154.84.92
18.154.84.82

These IPs will be anycast, meaning that the routing will be different depending on your location and network routing (usually your ISPs).

mtr is a great tool to check this. Attaching a screenshot for 18.154.84.126 for me.

How does that compare to what you're seeing?

ashen lark Dec 13, 2024, 5:15 PM

#

I see this:

#

yes, I see different DNS results because my VPN is in another region

#

but the checksums are now matching. if it wasn't clear, I was running what I knew as the recommended upgrade process:

sh debug downloading files into /tmp/tmp.iJt3sZtHFg
sh debug http_download https://dl.dagger.io/dagger/releases/0.15.1/dagger_v0.15.1_linux_amd64.tar.gz
sh debug http_download https://dl.dagger.io/dagger/releases/0.15.1/checksums.txt```
and the checksums.txt from the same endpoint did not match the payload that it was downloading

upper swallow Dec 13, 2024, 6:42 PM

#

Got it, that makes sense.

We hit a small bump in yesterday's release process, here is the public thread in case you are interested: #1316728366057132063 message

When we do a new release #maintainers is the place to follow for the latest updates / report issues.

cc @violet marsh @pure venture @midnight flicker for visibility

violet marsh Dec 13, 2024, 6:46 PM

#

as we were furiously fixing the checksums yesterday (trying to get the credentials to invalidate cloudfront cache) the SaaS releng dev in me was like "we should probably announce this breakage somewhere" but by the the time that occurred to me we were inches from fixing it outright

#

apologies for the interruptions 🙂

#makes sense.. then your ISP is probably