Live data from Hacker News

Before you buy a domain name, first check to see if it's haunted

bryanbraun.com

181–190 of 195 posts

Re: Before you buy a domain name, first check to see if it's haunted

#181
post #178

Another variant of this is cached or preloaded security configurations. HSTS (which forces browsers to validate HTTPS when connecting) asks browsers to cache the configuration for a set "max-age". Some sites set huge values here, like Twitter's 20 year max-age[1]. There's also the preload lists [2] to consider. This creates a problem if you want to serve non-HTTPS/unencrypted HTTP on your new domain and the previous…

FWIW, you can invalidate MTA-STS cache by updating the DNS assertion record to a different 'id' value. This is how you indicate a policy has changed. So the sender is supposed to obey the normal DNS TTL caching period, and re-query the assertion record if TTL expired. It should re-fetch the MTA-STS policy if the 'id' value in the DNS assertion changed, or the max_age in the previously fetched policy has expired.

Almost, it's a little more involved.

> RFC 8461 section 3.3: Conversely, if no "live" policy can be [...] fetched via HTTPS, but a valid (non-expired) policy exists in the sender's cache, the sender MUST apply that cached policy.

You'll also need to host a "none" policy doc. Full instructions are here: https://www.rfc-editor.org/rfc/rfc8461.html#section-8.3

Re: Before you buy a domain name, first check to see if it's haunted

#182

Earlier quoted context omitted.

You're looking at this from the perspective of a haunted domain owner. And from that perspective your idea is fine. A good technique to evaluate ideas though is to try and view it from different perspectives. In this case from the owner of a non-haunted domain. Can you see any potential problem with your idea when viewed from that perspective? Now, if there are potential problems, consider the relative sizes of the t…

The parents rules seemed to indicate only reevaluating the status of a haunted domain. I see nothing about evaluating a normal domain.

(Therefore, this has a one-way function of improving the status of haunted domains and why I think anything is better than nothing unless it blocks a better strategy.)

Re: Before you buy a domain name, first check to see if it's haunted

#184

This happened to me and I found this tool super helpful to get my site unblocked: https://dnsblacklist.org/ I purchased a valuable premium domain to host a personal art collection (of anime cels). For some bizarre reason, the site was inaccessible from my work computer and it was de-listed from Google even if I typed the url itself into search. I hired a square space specialist to figure out why, to no avail. I then…

It’s wild how these past associations can stick and haunt a domain, even after it’s changed hands entirely.

Re: Before you buy a domain name, first check to see if it's haunted

#185
post #26

Another "haunted domain" check is by trying to post about it on social media. I ran into this with my current project's domain name. After building an MVP and trying to test the social sharing functionality, I found that Facebook was blocking the domain outright. Turns out there was some spamming from it years ago. Getting it unblocked was extra fun, as the page to request manual review was itself broken! Thankfully…

Social media platforms can be some of the biggest canaries in the coal mine when it comes to a domain’s “haunted” reputation

Re: Before you buy a domain name, first check to see if it's haunted

#186

Earlier quoted context omitted.

I wonder if it would be a reasonable requirement of registrars to now allow domains to be purchased if they are some edit distance away from existing/active domains. Its fine if Google wants to protect its users, but ideally this would be caught sooner.

That would be a pain... Look at the milka.fr problems... Milka is also a female name over here, and that already proved to be a problem in france. But so are Mirka and Minka so yeah... no domain for them? Also Micka. Oh and mivka is (beach) sand. Want to sell beach sand? It's just one letter away from milka, so no domain for you either.

Is it really better if Mirka, Minka and Micka get to pay for a domain but won't be able to use it because the dominant webbrowser shows super scary warnings?

Still seems better to raise the issue as early as possible so they can find a solution (appeal or chose a different domain) before investing into the unusable domain name. It would also mean that the dispute is at a layer (ICANN) where you at least theoretically have some rights instead of at the hands of a megacorporation that thinks the best way to reduce customer support costs is to make it impossible to get support.

Re: Before you buy a domain name, first check to see if it's haunted

#187

Another variant of this is cached or preloaded security configurations. HSTS (which forces browsers to validate HTTPS when connecting) asks browsers to cache the configuration for a set "max-age". Some sites set huge values here, like Twitter's 20 year max-age[1]. There's also the preload lists [2] to consider. This creates a problem if you want to serve non-HTTPS/unencrypted HTTP on your new domain and the previous…

The worst part about HSTS is that the spec doesnt just define the interaction between the browser and the website but also goes as far as mandating that the browser restricts the options it provides to the user ... and would-be user agents actually go along with that.

Re: Before you buy a domain name, first check to see if it's haunted

#188

Interesting. Domain as a unit of trust makes sense until it doesn't. Buying a second hand domain is like a second hand car. But you may not know it is second hand! I think the mistake here is the redirect old to new. That is always risky so only do it if deseprate. In this case I would have done the redirect from new to old. Then just use the new as a vanity url.

> Buying a second hand domain is like a second hand car.

I have never hear of anyone being denied business because their car has a bad reputation from a previous owner.

Re: Before you buy a domain name, first check to see if it's haunted

#190
post #13

I’ll add: and if you lease a VPS, check out its address reputation and reverse DNS record.

Isn't it pretty safe to just assume that any IP addresses belonging to public clouds, especially cheap ones, have bad reputations?

The individual IPs may not all have too bad reputation but you don't control who shares the block with you and don't have any control over new neighbors - and that is enough for some agressive organizations (Microsoft) to block you.
Post reply on HN