Live data from Hacker News

Mess with DNS

jvns.ca

41–50 of 94 posts

Re: Mess with DNS

#41
post #16

This is a neat tool! FYI, make sure the domain is registered with Safe Browsing in advance. If one subdomain is cataloged as malicious by google the entire domain can be flagged. It can be a pain to deal with.

hypothetically, what happens if a domain is catalogued by malicious? Also who catalogues it? If you haven't bought the domain from Google, the only thing that Google can do is not show the domain on google search results. Did I miss anything?

Most major web browsers will display a scary red warning to visitors to your website. It can take days for a human at Google to fix the issue.

Re: Mess with DNS

#42
post #27

The tech is fantastic, and your writing skills also stood out to me. This is excellent work all around.

Julia's writing always feels breathable and fun.

It's impressive to get technical stuff to be this friendly.

Re: Mess with DNS

#43
post #32

Quoted post unavailable.

Note that this sentence was about browser-based integration tests. Browser automation has come a long way, but even on very frontend-fluent teams I've been on we had a few flakey tests, and browser-based integration tests are sometimes flakey in ways that are difficult and tedious to debug! Not understanding why doesn't necessarily indicate any lack of understanding of DNS.

But maybe it increases the odds of a "Let's understand Playwright!" post in the future!

Re: Mess with DNS

#45
post #32

Quoted post unavailable.

Great job reading the article: she's talking about frontend E2E testing which literally has nothing to do w/ the mechanics of DNS. Every one of these frameworks I've used _is_ a bit flaky too, so this should be completely unsurprising to anyone who actually knows anything about this.

Re: Mess with DNS

#46
This tool is so neat! One thing I've learned from it is my ISP (sonic.net) seems to be doing queries to _.example.com. For instance:

$ dig @50.0.1.1 nelson.lily6.messwithdns.com a

Results in two queries being answered by the messwithdns server. One for nelson.lily6.messwithdns.com as expected, but also one for _.lily6.messwithdns.com.

Any guesses what that naked underscore query is for? Not every nameserver does it (Cloudflare, Google, Quad9, and Adguard all don't). But Sonic isn't the only one that does.

I've asked on Twitter and the best guess right now is it has something to do with RFC2782 or RFC 8552. But those are about using _ to make unique tokens that aren't likely domain names, things like _tcp or _udp. What would a naked _ mean?

Re: Mess with DNS

#47
post #4

There's another AWS outage, & presently the top comment is talking about us as barbarians that have stumbled into fancy hot baths & are amazed but have no idea how to keep them running. And a wonderful follow-up reply[1] talking about living in an apartment in a storm versus living in a cave during a storm. It presents another severe image of how much drift there has been in the world, how much more built up, but how…

Humans individually are pretty useless. Abandon a random human in a jungle and they will likely perish soon no matter how smart and well educated they are. The strength of humanity is teamwork, working together to build things other groups can build things upon. Abandon 100 random humans in the same jungle and they will build a town.

> The strength of humanity is teamwork, working together to build things other groups can build things upon.

This is why I don't trust anybody who tries to tell me that human population growth is an actual problem and not just our rulers' fear of irrelevance.

Re: Mess with DNS

#48
post #14

On the security aspect, I wonder how is this site affected services that do domain ownership verification [1] where they assume that only a person who owns the domain can edit dns records. I think letsencrpt ACME protocol [2] does it for SSL certs too. This site does create a subdomain for every user, so may be these issues don't apply. [1] https://support.google.com/a/answer/183895?hl=en [2] https://letsencrypt.org/…

At least for certificate issuance they can turn it off via a CAA record: https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au...

One inconvenience is that although RFC8657 explains how to tell a CA that it must use particular methods, the most obvious public CA (Let's Encrypt) has not shipped RFC8657 support. So you can write a CAA record which says "Only Let's Encrypt may issue" or indeed say "Only Sectigo may issue" but you cannot write a record which says e.g. "Only Let's Encrypt may issue, and they must use the tls-alpn-01 method". Or rather, you can write that record but it won't work.

Now, there are a bunch of things you could do about that, and I believe this cool toy does one of the obvious ones: Don't have any certificates for the problematic domain. The web site isn't in the domain you can mess with. But it would be nice if Let's Encrypt got to this, periodically I check so far each time somebody has pestered them for RFC 8657 recently, so I don't pile on since that's unhelpful.

Re: Mess with DNS

#49
Very smart idea and great execution.

Allowing to experiment quickly on infras/devops knowledge is the key and tools like Ansible are useless for that.

Re: Mess with DNS

#50
post #16

This is a neat tool! FYI, make sure the domain is registered with Safe Browsing in advance. If one subdomain is cataloged as malicious by google the entire domain can be flagged. It can be a pain to deal with.

You need multiple subdomains to be flagged in order to cause the eTLD+1 domain to be flagged. But then since this is open for anyone to change, I imagine it's really easy to cross that threshold.

This is a real risk. When people start adding CNAME's or A's that point to known phishing sites, it's very easy for Google to notice and block.

Post reply on HN