Tangential rant: I hate it when sites ask for your domain name (eg. for setting up hosting) and say that they want the "fully qualified domain name", but they don't actually accept the FQDN. eg. they reject "www.example.com.", but accept "www.example.com" (without the trailing dot). But the FQDN by definition includes the trailing dot. https://en.wikipedia.org/wiki/Fully_qualified_domain_name
This happens with AWS, which I find just incredible. It'll silently accept a password when changing, but fail when you try to log in.
I think in that case it might a matter of length, rather than symbols, but I've never put in the effort to pin down the problem exactly, now that my password manager settings work.
Like, I caught them doing the "ask for FQDN but reject FQDNs" a couple of weeks ago in either Route53 or something immediately adjacent (i.e. where people who know better should have been involved), yesterday SageMaker stopped launching kernels because of a "known issue" (don't worry, it doesn't meet the definition of downtime though), and today I had to diagnose an unresponsive control panel by opening the console and digging up a REST error response that they didn't bother to handle in any way.
Everything about AWS is not merely broken and half-assed, but fractally so, so that even after using a service for years you are still uncovering severe caveats and awkward limitations. Password validation traps fit that pattern to a T.
Even if they have validation built in when you are signing up! How is it possible that they have taken steps to ensure passwords meet their stringent criteria, but the user still ends up unable to log in?
Most recently, I've experienced this problem with two of the big three credit bureaus.
I have an address that is firstname@lastname.com and am unable to use it on a number of ecommerce sites, because they're doing some sort of validation to filter out people who are too clueless to know what an email address is. Or something. There's no + or other special characters in it, or xn-- international domain name.
Yikes. I've got my own first@firstlast.com but I've never ran into an instance where I wasn't able to use it.
I do now have a hyphen in my last name which is not accepted everywhere. Some companies accept the hyphen but replace it with a space (some credit cards), some reject the hyphen so I either make it all one word or add my own space.
I wonder if yours is more successful because the domain is firstlast.com , not just lastname.com. I've run into it most often with checkout systems that have separate fields for first and last name, it appears that some systems are matching for the field for last name cannot be exactly the same as the part of the email address after the @ symbol.
> I've run into it most often with checkout systems that have separate fields for first and last name, it appears that some systems are matching for the field for last name cannot be exactly the same as the part of the email address after the @ symbol
That's incredibly obtuse of them; what possible reason could they have for doing that?
My best guess is an overly cautious UX guard rail for elderly people, persons very new to the internet, or people who think they can type their twitter username, facebook account name, or some other non properly formatted email address into the "Email:" field and get things delivered.
What category of site do you observe this issue on? My curiosity suggests that there may be a huge UX problem for extreamly popular sites; banks, government services, etc., where a large percentage of their usage base absolutely will entery 100% incorrect information unless extrenous safe guards are in place.
Essentialy, if your site targeted every age demographic or even had a preference for older and/or less tech savy demographics, how can you prioritize the edge case that <0.00001% of your users has their own lastname.tld vs is entering an incorrect email address.
It's spread out across a wide range of things. No specific market segment comes to mind. Personally I encountered it with enough things, often enough that it became a point of frustration, and I started using a gmail address for most 'ordinary' online purchases, which is an inbox set to auto-forward-everything to the firstname@lastname address.
I agree that it's a huge UX problem - one of the reasons why a lot of online checkout processes have you type your email address in two separate fields, twice. Without some guardrails in place, there is probably a not insignificant number of people who typo their email address in a single field, or type a malformed address, and then complain to customer service or their credit card company when they never receive an emailed invoice.
Interesting. Of course I'd speculate that some service like AnonAddy [1] or just having a secondary, anonymous, domain would be a better solution. Or even the most simplest is using a somthing-else@lastname.com email as I would expect them to at least check both parts.
Worse case scenario, you could use firstname@subdomain.lastname.com. Even something like 1.lastname.com would likely work.
I suppose it depends on your reasons for using your own domain in the first place but having to employ the use of a gmail acount negates a lot of the privacy & security of a personal domain IMO.
Yeah, try signing up fro steam with your protonmail.ch address... I have a personal .nl one, also caused me some grief in the past, it is the reason I still have my gmail address, because it always works.
In 100% of cases, this is either because someone copied a bad regexp, or they made an explicit decision to not allow local-part wildcarding.
I have in the past normalized email addresses per the rules I know specific providers have to help people login. Did I sign up with mike+hn@ or mike+hackernews@?
Nobody blocks dots in email addresses, although I have had some sites in the past email me using the first part of my email address as my name; it's amusing to open an email from example.com saying "Hi, example.com!"
Funny, that's exactly how I do it! One of the reasons is, I know who lost/leaked/sold my data when the spam starts coming in. (Of course today we also have haveibeenpwned.)
Fastmail has a feature it calls "subdomain addressing" [0], where instead of "me+thing@mysite.com", you use "thing@me.mysite.com", which is much better supported.
Other hosts (e.g. Mailbox.org, the host I'm with now) can support the feature as well, with some configuration.
I have a 4 letter tld to my domain name for my email address. The two times that I had to chase up someone to let me create an account was absolutely bonkers. And it only happened with two systems that were crucial: my bank, and my company's payment system.
> Once it was decided that domain names should be arranged hierarchically, it became necessary to decide what sits at the root of that hierarchy. That root is traditionally signified with a single ‘.’. In fact, ending all of your domain names with a ‘.’ is semantically correct, and will absolutely work in your web browser: google.com.
But the accepted answer on SO that I copied the code that I have no idea what it does should work, right? There's no bogus accepted answers. The community would have fixed that, so it's trust worthy for me to use as is.
It gets worse. Some think the FQDN is the domain zone. Some think it's with elements you find in an URL like the protocol or a part of a path. Humans. Ugh.
I've never heard of this. When / how / why would you use the trailing dot? I checked my sites and they redirect to the non-trailing version. Is that bad?
A trailing "." represents the root of the DNS namespace like a leading "/" represents the root of the Linux (or Unix, etc.) filesystem.
The root has children like "com", "net", "uk", etc.
There are DNS records at the root level. Try this command:
host -t ANY .
Also, just as Linux searches PATH (in order) when you run a command, the DNS resolver searches a path when you look up a host. (Usually the resolver path is specified by directives in /etc/resolv.conf.) Just as Linux will skip this process if you specify a leading "/", the DNS resolver will skip that process if you specify a trailing ".".
It used to be pretty common to put your organization's domain in /etc/resolv.conf so that you can use the short version of a hostname. If your company is example.com and you have example.com in the DNS search path, you can type a command like "ping www", and it will do the same thing as "ping www.example.com". Most software still supports this, but it isn't used by that many people. (Some organizations don't put their domain in /etc/resolv.conf, and many users don't know they can abbreviate hostnames in this way.)
You would typically use the trailing dot if you want to be sure the DNS lookup doesn't use the search path and checks only against the root of the DNS namespace. You also use the trailing dot in some data files for DNS servers.
In many cases the trailing dot is not necessary, practically speaking, because the DNS resolver has special logic where if you give it a string that contains any dots (not just trailing), the search order is rearranged to try the root first instead of last. (In /etc/resolv.conf, this is controlled by the "ndots" option.)
So if you look up "www.example.com", it will check for the existence of "www.example.com." before it checks for "www.example.com.example.com." instead of the other way around. Which is good because only the first is likely to exist. If you look up "www", it will check for "www.example.com." before it checks for "www.", which again is a good heuristic because again the first is the one that likely exists.
I just tried it with the domain rakso.at and when I enter rakso.at. there is an htst error. Shouldn't it work because it is technically the same domain?
That is an effect. But the standard states that a fully qualified domain ends with the dot. The reason your resolver doesn't use the search domains is because the dot tells it that what you provided is the entire thing so there is no point in looking up the domain in a search list.
While you're certainly not wrong, the phrasing of the question suggests that the asker didn't know the history of the final dot, and was asking the way they did only because they didn't know what to ask, thinking its purpose was to provide some effect rather than being historically (and currently) the correct FQDM.
It bothers me that a “fully-qualified domain name” is still relative to some implicit DNS network class. There’s no syntax for specifying whether you mean an Internet domain, or some other kind. Because of this, there’s no way to have a URL that resolves from an Internet-relative origin to, say, a Chaosnet-relative origin. Lame :(
> The presence of a host subcomponent within a URI does
not imply that the scheme requires access to the given host on the
Internet. In many cases, the host syntax is used only for the sake
of reusing the existing registration process created and deployed for
DNS, thus obtaining a globally unique name without the cost of
deploying another registry. However, such use comes with its own
costs: domain name ownership may change over time for reasons not
anticipated by the URI producer. In other cases, the data within the
host component identifies a registered name that has nothing to do
with an Internet host. We use the name "host" for the ABNF rule
because that is its most common purpose, not its only purpose.
So, the fact that the host part of http(s) URLs are resolved using DNS is not a limitation of the URL spec. Instead that's an implementation restriction.
Heck, I still find sites that don't like "nonstandard" TLDs in your email address. Try putting an address that's not .com, .net, etc and it throws an error.
The sin here isn't not accepting "nonstandard" TLDs. It's that validating an email address is extremely hard to do correctly, and that you often really want to know if the person entering it has access to the address. The only way to do that is to accept pretty much anything that has an @ sign in the middle of some other characters, and then attempt to send email to that address with a clickback link.
The thing that really annoys me though isn't email address handling. It's credit card number and social security number entry fields.
For credit cards, the number of times you should have to specify which type of card you're entering is literally zero. All credit cards of the same type (e.g. Visa) begin with the same number sequence. Visa always starts with 4, so, if I type 4 as the first digit, just call it a Visa card. Do the Luhn checksum validation to make sure it's a valid number and that I probably entered it correctly, and try to run the charge. If it fails, then provide an appropriate error message.
For SSN fields, the thing that annoys me is that there are basically 2 common ways of entering the number: XXX-XX-XXXX and XXXXXXXXX. So many sites and apps only accept one of the two and will complain about the other. It's ridiculous, because the presence or absence of the dashes literally has no bearing on the validity of the number. Just let me enter it the way I want.
As long as we're ranting about stupid form design.
Dear everyone: Denmark does NOT have states. Literally dozens of times have I encountered a form that absolutely requires that I input something in the state field before they will ship my stuff. A sufficiently motivated individual could traverse the major landmasses of Denmark by bicycle in about a day[0], we don't need no damn states.
I usually put in "NULL" for state, and hope something breaks.
Ugh, try address fields. I mildly regret having moved to my current home last year, as inputting this address into forms is an impossible task. The "correct" address according to the formatting standards of my federal postal service, including street address plus unit number, is 47 characters long. I can put the UNIT number on the 2nd address line (when available), which makes the first line (just the street address) 37 characters long. I've come across more than a dozen services (Amazon, Apple, pizza places, etc.) that have length limits on address lines of between 25 and 35 characters.
The worst are the companies who (somewhat strictly, to varying degrees) verify the address of credit cards. I've barely managed to always verify by shortening into a grotesque form of the address that logistically makes no sense, but is apparently just close enough to match whatever fuzzy formula is used (eg. Levenshtein distance).
Sure, that all sucks, but, at least address handling is actually hard. Dealing with credit card numbers, even if you want to go beyond the basic Visa / MasterCard / Discover / American Express, isn't that hard. Neither is sanely dealing with SSNs (except that most uses of SSNs are insane by default, but that's just a matter of using it as an ID number when it shouldn't be).
FYI, Most credit card verification is just using the house number and the zip code. If there's no physical delivery, you can just put in Elm St or whatever.
I was a fan of that until I experienced that they don't actually test the code. I've had it break in entertaining ways, most recently getting a new monitor from Dell and trying to enter a phone number (on Firefox on Android, both current & Preview) went like this for the number 123-555-1212, typed without dashes:
Enter number, result is: 125-535-2112 .
On the plus side it was predictable and I was able to eventually enter the number something like 2153552121 and have it appear on page as 123-555-1212. When I encountered this a second time a few days later (reordering due to DOA) I discovered pasting the entire number in allowed the 'automatic' nature to add dashes correctly.
The correct answer to me is to strip out non-numbers and then verify the number is a valid phone number (which should be easier than programmatically determining names or dates).
Yes! And it really is so easy to implement all of this validation and checking without it being too complicated. How is parsing some numbers and running a few math equations the source of so much trouble?
The only two explanations I can think of are ignorance and laziness. Ignorance doesn't really fly, IMO, because when you have an input field, you should be at least thinking about validating said input. From there, the simplest of google searches will lead you to the checksum algorithm.
Laziness seems most likely for that reason, but, on top of that, it's not like you even have to go to Stack Overflow to find an implementation. Wikipedia has one! Wiki. Pedia.
Just take my input, run the checksum, check that my expiration date isn't in the past and that the CVV value is the correct number of digits, and just run the charge. It's not like if I mistype my MasterCard's first digit as a 4 that it's going to work anyway. Just do the checks that are feasible, and then just run the charge.
> For credit cards, the number of times you should have to specify which type of card you're entering is literally zero
From what I can recall, the number of times I've had to specific what type of card I have when filling out an online form is zero, because every form I can remember using did autodetect it. I admit I'm fairly young (only have had a card for 10-12 years), but from the amount of frustration you seem to have about this, I feel like you must have run into it much more recently than that.
Interestingly, if I go to news.ycombinator.com., I get the logged out version of the site. Probably because my browser treats it as a different site entirely
It's technically a different domain. HN cookie is created for a domain without dot at the end, so there's no match when you open a domain with the dot.
In the same way, if a website does not do www->nowww / nowww->www redirect (example.com / www.example.com), you might have www version be logged in and nowww version be logged out or vice versa (depending how exactly it creates its cookies).
