mnordhoff

Wait, Namecheap deactivates your domain name if you have a temporary DNS outage?

You should email them about the form and about your domain. Their email address is listed on the website. <https://quad9.net/support/contact/>

Sometimes the upstream blocklist provider will be easy to contact directly as well. Sometimes not so much.

Even without "all-servers", DNSMasq will race servers frequently (after 20 seconds, unless it's changed), and when retrying. A sudden outage should only affect you for a few seconds, if at all.

Unless the privacy policy changed recently, Google shouldn't be doing anything nefarious with 8.8.8.8 DNS queries.

This sounds like a very serious security vulnerability...?

Wellp. Incident report: "We posted our first incident report to Cloud Service Health about ~1h after the start of the crashes, due to the Cloud Service Health infrastructure being down due to this outage."

Related: <https://www.sprint.net/>'s IP address was 2600:: for many years, but they sadly started using a DDoS mitigation service with different IPs.

Is collecting a shipping address because PayPal's JavaScript is broken legal under the GDPR?

In 2011, Gmail accidentally some people's email and restored it from tape. https://gmail.googleblog.com/2011/02/gmail-back-soon-for-eve...

Maybe not the entire region. Amazon was reportedly building a data center complex next to the natural gas Hermiston Generating Plant some distance from the river.

I have bad news for you, Linode's authoritative DNS service also uses Cloudflare DNS Firewall.

  $ dig +short ns1.digitalocean.com aaaa
  2400:cb00:2049:1::adf5:3a33
  $ dig +short ns1.linode.com aaaa
  2400:cb00:2049:1::a29f:1a63

As I understood it, the difference between the $2.50 and $3.50 Vultr VPSes is an IPv4 address. I don't know why that page doesn't explain. Maybe it's changed.

This has a couple bugs:

1.1.1.2 and 1.1.1.3 both return the SVCB records for 1.1.1.1. (I don't know if clients would ignore them, or actually switch to 1.1.1.1.)

Non-SVCB-type queries for _dns.resolver.arpa return NXDOMAIN instead of NOERROR. (This probably doesn't have significant impact, but might break it for some clients, e.g. if they can be tricked into making queries for _dns.resolver.arpa, or if a downstream resolver makes DS queries.)

They moved data centers (to Hurricane Electric Fremont 2). It's not unusually unreliable.

Yup. I'm still upset (but not angry) about https://status.linode.com/incidents/kqhypy8v5cm8.

Or if you open the EC2 console (it's up this time!) and scroll down to the bottom.

https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#...:

(Edit: I hope I didn't sound sarcastic. I don't open random console pages and scroll all the way down to check for new features. Some people will have noticed, some won't.)

Amazon seems to have stopped randomizing them in newer regions. Another reason to move to us-east-2. ;-)

Resolvers typically cache successful "does not exist" responses for no more than 1-3 hours. (And authoritative servers often have a lower negative TTL.)

(There's a corner case related to DNSSEC that can make it go higher, but that's being worked on, and isn't relevant here.)

In this situation, the nameservers were just down. I haven't done exhaustive research, but the resolvers I'm aware of cache that kind of thing for no more than 15 minutes.

No idea. I'd speculate that it's some kind of historical reasons from before FB acquired IG.

"Because of this Cloudflare’s 1.1.1.1 DNS resolver could no longer respond to queries asking for the IP address of facebook.com or instagram.com."

The instagram.com zone itself uses a third-party DNS service and didn't go down. (But e.g. www.instagram.com is a CNAME to a zone on FB DNS.)

"While Cloudflare signs all of its BGP routes with RPKI..."

That's not correct. https://rpki.cloudflare.com/?view=bgp&asn=13335 itself says Cloudflare still doesn't sign 12% of them.

They shouldn't lose sleep over it, though.

Who sent them first, and why?

Instead of going from relying on a single provider to relying on a single provider, you could use both AWS and Azure.

DigitalOcean has /32s from ARIN and RIPE.

(And a /48 from APNIC???)

(Edit: And a /36, /40 and /48 from APNIC?)

Yup. And also one of the IPv4 IPs isn't doing TCP.

I'm not sure nothing else is wrong, but the IPv6 issue is likely why 1.1.1.1 is having trouble resolving it.

Sharing the domain is usually critical.

Picking a random domain hosted on those nameservers, mdfs.net, it looks like, of the 4 IPs, 2 are down and 1 of the remaining ones doesn't support TCP.

http://dnsviz.net/d/mdfs.net/W48OcQ/dnssec/ https://ednscomp.isc.org/ednscomp/4040283963

1.1.1.1 is less tolerant than some resolvers of that level of breakage.

https://community.cloudflare.com/t/ipv6-timeouts-appear-to-b...

> why the DNS test usualy takes >60 seconds

The server-side part of DNS validation takes about a second. The delay is all about clients waiting for their authoritative DNS servers to update. If you use a fast DNS provider, there's no reason to wait longer than necessary.

> If any certs were issued for hijacked domains (which as far as I've ready was only one, not using LetsEncrypt), it's a pretty glaring failure on the issuer, assuming they used "DNS Validation"

It wouldn't be a compliance failure, though. CAs are not required to be invulnerable to BGP hijacking attacks.

That's correct.

Certbot can use different plugins for validating the name and for installing the certificate.

You can configure HTTP-01 to work and use "certbot -a webroot -i nginx -w /path/to/whatever -d example.com -d www.example.com".

https://community.letsencrypt.org/t/solution-client-with-the...

A number of web pages from better writers than me will argue why you need HTTPS. E.g. it provides integrity (so the coffee shop WiFi can't insert ads in your site), and browsers only enable some features on HTTPS sites.

https://doesmysiteneedhttps.com/