Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Benchmarking DNS response times of TLDs

bunnycdn.com

Post reply on HN
Print view View original

41–50 of 141 posts

Re: Benchmarking DNS response times of TLDs

#41

Post by grose »

dsr_ wrote: post #35
danpalmer wrote: post #8

Earlier quoted context omitted.

I’ve heard anecdotally that getting .xyz email delivered is much harder than .com, some servers just blanket reject. I expect this will change as the domains become more popular.

I blacklist .xyz, .ninja, and a few others. Nobody complains.

I had to blacklist .top and .xyz registrations for a free service because they were being used exclusively for spam. xyz in particular I think is just so cheap (often $0.99 to $2) that it's tempting for spammers to register a bunch of throwaway domains.

Re: Benchmarking DNS response times of TLDs

#42

Post by cbg0 »

Eikon wrote: post #36
SiVal wrote: post #31

Earlier quoted context omitted.

Could you (or someone) explain this? (I'm not arguing, I'm interested.)

You can only put CNAME records at the zone APEX if there is no other records kinds as a CNAME is supposed to be a synonymous. If you had records such as: @ IN A 127.0.0.1 @ IN CNAME example.org. The server could not answer anything sensible as you now just introduced an ambiguity. The "nasty tricks" I was referring to is basically records such as ALIAS that you may find at some providers. The way they work is roughly…

What's so "nasty" about using ALIAS?

> Regarding cookies, the issue is that they are passed to subdomains so cookies that you set for `example.org` are also accessible from `*.example.org`.

This is only true for cookies that are not set as `HostOnly` as far as I'm aware.

Re: Benchmarking DNS response times of TLDs

#44

Post by Eikon »

cbg0 wrote: post #42
Eikon wrote: post #36

Earlier quoted context omitted.

You can only put CNAME records at the zone APEX if there is no other records kinds as a CNAME is supposed to be a synonymous. If you had records such as: @ IN A 127.0.0.1 @ IN CNAME example.org. The server could not answer anything sensible as you now just introduced an ambiguity. The "nasty tricks" I was referring to is basically records such as ALIAS that you may find at some providers. The way they work is roughly…

What's so "nasty" about using ALIAS? > Regarding cookies, the issue is that they are passed to subdomains so cookies that you set for `example.org` are also accessible from `*.example.org`. This is only true for cookies that are not set as `HostOnly` as far as I'm aware.

> What's so "nasty" about using ALIAS?

It's a not standard and therefore, is not a generally applicable solution.

When something not standard becomes common practice and is expected, here comes the pain.

Re: Benchmarking DNS response times of TLDs

#45

Post by LeonM »

random_savv wrote: post #6

Would love to hear if the same applies to SEO and/or spam filters. I have a .works domain, which looks nice, but it was a huge mistake and wish I had gone for a .com: - people often mispell it to .work, or just generally get confused - one customer actually couldn't receive my emails because some layer in their email stack was blocking this domain - .work exists, and somebody else owns [name].work, which is a potenti…

> Would love to hear if the same applies to SEO and/or spam filters.

I'm the founder of an email monitoring service.

I can confirm that lesser known TLDs can impact deliverability, but not much. It mostly happens with smaller email services that use white/black lists for spam filtering. These are often self-hosted email services. We've also seen 'enterprise' email security products that use hardcoded TLD lists.

Larger services such as Google, MS, Yahoo, etc don't seem to suffer from this, as they use ML based spam detection.

We've also seen email address validators that do not accept fancy TLDs, which can make it difficult to register to services with a fancy TLD email address.

Re: Benchmarking DNS response times of TLDs

#47

Post by chrisweekly »

Eikon wrote: post #21
frereubu wrote: post #16

We have a client who insisted on using a .house domain. It kept triggering alerts on our uptime monitoring service with DNS errors, so we had to reduce the sensitivity of that specific test. We also had a client who had to change their TLD from .healthcare to .org.uk because (a) people were confused because they didn't understand that there are all these new TLDs and kept adding .co.uk, .org etc and (b) some NHS syst…

> I still advise clients to use www rather than a plain domain name for websites And you should. Not only can’t you put CNAME at the zone APEX without doing nasty tricks but not doing so is also a security risk when dealing with cookies.

Use of CNAMES also leaves the door open to simple DDOS mitigation.

Re: Benchmarking DNS response times of TLDs

#48

Post by mytailorisrich »

mr__y wrote: post #40
frereubu wrote: post #16

We have a client who insisted on using a .house domain. It kept triggering alerts on our uptime monitoring service with DNS errors, so we had to reduce the sensitivity of that specific test. We also had a client who had to change their TLD from .healthcare to .org.uk because (a) people were confused because they didn't understand that there are all these new TLDs and kept adding .co.uk, .org etc and (b) some NHS syst…

>some NHS systems in the UK (one of their target audiences) refused to accept emails that finished with .healthcare not suprising at all, I've seen e-mail address validation code that (among other things) used a fixed list of TLDs. I could imagine some spam filters doing a similiar thing.

And I've seen validation that assumed that TLDs were 2 or 3 characters only.

Re: Benchmarking DNS response times of TLDs

#50

Post by 867-5309 »

Eikon wrote: post #36
SiVal wrote: post #31

Earlier quoted context omitted.

Could you (or someone) explain this? (I'm not arguing, I'm interested.)

You can only put CNAME records at the zone APEX if there is no other records kinds as a CNAME is supposed to be a synonymous. If you had records such as: @ IN A 127.0.0.1 @ IN CNAME example.org. The server could not answer anything sensible as you now just introduced an ambiguity. The "nasty tricks" I was referring to is basically records such as ALIAS that you may find at some providers. The way they work is roughly…

unless I am hosting separate sites/IPs on subdomains, or have a complex cookie situation, I think the www. prefix seems vestigial/legacy and completely unneeded. I am actually in the opposite camp of not including it at all and redirecting to non-www. it sounds awfully ambiguous in speech ("double-u double-u double-u dot", "all the double-us dot", "dub dub dub dot", etc.) and most times multiplies the syllabic length of a "catchy" address. I even had an older client who said "stop" instead of "dot", and another who used @www. in an email address. I also think it looks silly and unprofessional on business cards, on the side of vans, etc., especially when http:// and/or a trailing fowardslash is also included cringe. if it MUST exist, DNS does not always have to be involved, it could just be a simple http 301 forward or vhost config. we don't add :80 or :443 to the end of a web address. let the browser handle all that.
Post reply on HN