The purpose of DNS is to spread scams
23 points by whjms
23 points by whjms
I don't know what is gained by the framing "the purpose of a system is what it does" compared to the framing "the DNS scam problem is bad". The purpose of the Domain Name System is to create a distributed, hierarchical key-value store. Weak administration of some parts of it can be exploited to spread scams. If the purpose of the system were to spread scams, then that wouldn't be an abuse, that would be the normal use. But even the author describes this as an abuse. So the purpose of DNS must not be to spread scams.
To misuse a meme, if you're a dog walker and 20% of your dogs are eaten by wolves - you're in the wolf feeding business.
If wolves are eating 17% of dogs walked by Dogcheap and 72% of dogs walked on Locker St, the correct framing is "Dogcheap is feeding the wolves", not "the purpose of sidewalks is to feed dogs to wolves".
I don't want to strain this metaphor to breaking point, but if 20% of newly opened shops in your town were shut down within the year for defrauding customer - you'd probably conclude that the purpose of the business licencing board was to make it easy for criminals to act.
Resellers, registrars, registries, and ICANN all agree that this is a serious issue which requires tackling. Reading the minutes, everyone is concerned that this persistently high level of fraud is undermining trust in the DNS.
POSIWID is a well established framing of this sort of problem.
if 20% of newly opened shops in your town were shut down within the year for defrauding customer - you'd probably conclude that the purpose of the business licencing board was to make it easy for criminals to act.
I, for one, find it very unlikely that I would conclude that from that premise.
POSIWID is a bad framing because, to put it another way, it says that "there are no bugs, only features". But there are obviously such things as bugs: when a filesystem corrupts your data, that's because it failed to operate as intended, not because its purpose was to corrupt your data. If someone fixed the bug, nobody would object that they're "defeating the purpose of the filesystem".
I think what you're trying to get at is not that "systems have no flaws, only features", but that some systems' flaws are deliberately left unfixed because they serve some purpose. For example, some security flaws are introduced on purpose, like the xzutils backdoor. But other security flaws are introduced by accident. The way we respond to flaws introduced on purpose is different from the way we respond to flaws introduced by accident, but we can't make that distinction if we assert that the system's operation is always on purpose.
I think POSIWID doesn’t fit in this case for a different reason.
AIUI, POSIWID is mostly about undercutting and disarming the claims of those responsible for a system, when they say its purpose is to do Q but it demonstrably fails to do Q. POSIWID is about analysing the effects of a system regardless of intent; it does not imply that those effects are by design, especially because the slogan POSIWID was coined for situations where the overt intent doesn’t match the outcomes.
In this case I don’t think anyone is claiming that the purpose of the DNS is to prevent or reduce scams. Ever since domain names became cheap to register, the people responsible for the DNS have been trying to mitigate scams that use the DNS, but I don’t think anyone has ever claimed that the DNS is resistant to abuse. So I don’t think there’s a mismatch between slogans and reality that needs some POSIWID to realign them.
(I think your 20% figure is referring to this line.)
One in five newly registered domains with a gTLD are scams. That's a bloody crisis.
A domain with a misleading name is benign. It becomes a problem if it is actually seen by people.
The only (?) place I see misleading domains is my email spam folder. A closer technology to pin this blame on seems to be email, but even then, they are caught by spam detection!
Open systems are subject to sybil attacks, and our defences are strong enough that scammers are unable to build/keep reputation, and so are resorted to accounting for 20% of registrations.
Which percentage is cause for concern? I have no idea. It feels like the wrong figure to be looking at.
As the report shows, over 70% of new .locker domains end up blocklisted.
I'd say that was cause for concern.
I'm happy for you that you haven't been bombarded with spam texts and dodgy DMs. Most of us aren't so lucky.
I'm happy for you that you haven't been bombarded with spam texts and dodgy DMs. Most of us aren't so lucky.
Oh you're right, I do receive spam SMS. I just saw them in my SMS spam folder.
I think I'm with you on e-mail deserving more of the blame here than DNS. I get a few scam mails with legit-looking-but-fake domain names, but I get as many or more from <random garbage>@gmail.com. Many people probably don't even check for this, either because they never learned to or because mail made domain spoofing way too easy for way too long and they've learned not to trust it.
I think in this case “POSIWID” is a thought-terminating cliché because the problem of domain names registered for purely abusive purposes has been going on since the 1990s.
The blog post has a section title “what can be done?” but one thing it doesn’t discuss is pricing.
It has been very clear for a very long time that cheaper domain registration means more abuse. This was demonstrated by free 3LD domains in the 1990s (when 2LD registration was costly and bureaucratic) and in the 2000-2010 era by ccTLDs such as .tv that sold domains to the very cheap mass market. (Which is why many postmasters blocked spammy TLDs outright, and why there were email block lists that excluded new registrations (I remember “day old bread” for its peculiar metaphor).)
There’s evidently a pricing point for domain names that is large enough to make the spammy scams mostly uneconomical, but not large enough to be exclusionary. As far as I can tell it isn’t a very high price, about £10 or £20 per year. (I’ve never dredged the anti-abuse sewers myself, so I base that guesstimate on what I have seen the front-line folks say.)
Another thing I find weird about domain names is that they are one of the few cases where the value of a name (which you might measure as the cost incurred if you lost it) can be wildly different from the price to maintain the registration. I think the low cost of domain names leads people to treat them as throwaway rubbish, and I have often been frustrated when people register special purpose branded domain names instead of using a subdomain (both when I am a user and when I was a colleague) and it’s worse when they do so without a realistic lifetime or decommissioning plan. (In a bureaucratic corporate context I like yearly renewals with yearly budgetary reauthorization because that way you get to find out fairly quickly if a domain name is not worth the maintenance effort.) From a technical point of view there are many advantages to using a subdomain of an existing registration, and it’s free!
Of course the flip side of increasing prices is that domain names cost almost 0 to provide, so if you (if ICANN) increase the price you are giving a licence to print money to the TLD registry, and the customers rightfully object. (Sometimes the money firehose is used for good, eg .org fees help to fund the IETF, .cz fees fund Knot DNS and BIRD, .uk fees go to various open source infrastructure software; sometimes it is pissed away, like .uk before it set up its open source fund.) Having said that, it’s surprising to me how unsuccessful some of the new TLDs have been, which I think is because domain names are a mass-market commodity, and it’s very hard for a new TLD to go up-market when a new name with low recognition is by its nature down-market.
What the blog post does suggest is more bureaucratic impediments to domain name registration.
There’s an undesirable second-order effect of making it harder to run a mass-market customer-facing commodity sales org such as a DNS registrar: companies in this kind of market rely on economies of scale to be profitable, so they tend to consolidate (via mergers and acquisitions) to try to maximize profits. This is causing centralization of the DNS both at the registrar level and also at the registry services provider level. (A TLD might be nominally owned by some corporation or government, but its technical operations are often outsourced to one of a decreasing number of backend providers.)
What frustrates me about ICANN is how inward-looking it is: it cares about the concerns of TLD operators, registrars, and trademark lawyers, because those are the people who have a reason to turn up to the meetings. There’s comparatively little concern for the needs of DNS registrants or DNS users.
For instance, ICANN has failed to standardize an API between DNS registrants and registrars.
And relevant to this post, ICANN’s work on replacing whois with rdap has had a difficult time dealing with the conflicting concerns of abuse and privacy. A very large part of the debate has been about what information about registrations can be provided to which third parties: do law enforcement agencies get privileged access? can corporations pay for privileged access? can registrars offer extra privacy for an extra fee?
If anti-abuse providers can get access to useful information about new registrations, how can spammers abuse the same information?
The blog post finishes with:
I don't want to live in a world where I have to show my passport and pay thousands of pounds to register a domain which is only available after being vetted by private interests. But I also don't want to live in a world where scammers have effectively no deterrent from abusing millions of people.
Which I think is the author wanting to have it both ways, after suggesting a bunch of “remedies” that would inevitably lead to what he says he doesn’t want.
I think you are right that people have too many throwaway domains instead of subdomains, but you are kinda ignoring that higher usage of subdomains would increase the value of shorter and/or more generic domains in the first place, culminating in something like personal third level domains like .co.uk.
Contrived example - if I had manage to snag some w.org domain in the 90s, I'd probably be much more likely to have my "side projects" under foo.w.org or bar.w.org than registering fooproject.org or barproject.org. I was "late" to the internet, I have lastname.de and a three letter .org/.de - and I am using the hell out of them (also the others), but they're clunky to spell, etc.pp.
But yeah, I am not saying I'm free from vanity domain buying - and yet .de and .eu are both cheap and in my experience there's a lot less scam content on them.
I think part of it is the poor UX of URLs. They're read from the left, then right-to-left, then left-to-right again, and we expect non-computer-touchers to remember the middle part (tld in the case of gov, etc.) is what's authoritative.
We've also let organizations train us to click official links that are indistinguishable from scams, due to shortening them or using third-party survey tools.
If the purpose of a thing is what it does, the purpose of URLs is to assist scams using DNS, and DNS only takes part of the blame.
It's curious that domains aren't written in least-significant form so it emphasizes the domains you are connecting to. .rs.lobste:443/
It kind of opens the question why protocols are prepended with weird syntax to me as well. Why not .rs.lobste:https/ if we wanted a human-readable form of protocol usage? The obvious answer is serving different protocols from unreserved or non-standard ports, but idk that that is relevant when it comes to a browser window.
It would make much more sense for domain names to be formatted like Usenet groups, from most- to least-significant. I believe the current order was chosen to match the email address syntax people were already familiar with.
In 2006, Tim Berners-Lee gave this answer an interview:
Looking back on 15 years or so of development of the Web is there anything you would do differently given the chance?
I would have skipped on the double slash - there's no need for it. Also I would have put the domain name in the reverse order - in order of size so, for example, the BCS address would read: http:uk/org/bcs/members. This would mean the BCS could have one server for the whole site or have one specific to members and the URL wouldn't have to be different.
I believe the current order was chosen to match the email address syntax people were already familiar with.
It’s slightly more subtle than that.
The notion of domains as a structured hierarchial namespace was strongly motivated by email (since email was the first multi-network application protocol), and the DNS was developed to support the design. The point in time when the design was settled is RFC 819, roughly contemporary with the domain-based revisions of the email protocols RFC 821 and RFC 822. (Compare what the previous revision of SMTP says about domains!)
RFC 819 already has a dot-separated little-endian multi-level domain name syntax, and a notion of fully-qualified domain names and unqualified host names. (Contrast with an earlier proposal which has only single-level domains and confusing . and @ placement.)
When I met Paul Mockapetris I asked him why they chose little endian order, and he said it was to do with usability of unqualified domains. Users were likely to type in just a local unqualified name, and when it is expanded (whether interactively or (eg) during mail transmission) Jon Postel & co. considered it to be nicer to append the domain after the host rather than inserting it before. I speculate that the choice was influenced by interactive completion behaviour in TOPS10, which was very popular on the ARPANET at the time (and was the inspiration for completion in csh and later unix shells). Mockapetris’s DNS software JEEVES ran on TOPS10 on PDP10. (Or maybe 20, I dunno the exact versions!)
It wasn’t an entirely obvious choice even at the time. The UK academic network JANET had a name registration scheme designed at the same time as the DNS, with a similar hierarchial structure and similar support for both unqualified hostnames and fully qualified domain names. But the NRS was big-endian, so the local address fanf2@phx would be expanded to fanf2@uk.ac.cam.phx before transmission off-site.
Regarding ordering within a domain, according to Mockapetris, the ‘inventor’ of DNS:
I designed it this way for autocomplete. My vision at the time was that people would want to do autocomplete or they might want to just type part of the domain name and have it completed in a search list of the local environment. So it would not make sense to have the country code first. It had to be the least-significant part if you’re going to have any kind of reasonable search list or autocomplete. Imagine if we were to type “com.” and then wait for autocomplete. Out of 160 million choices, there would be a pretty long pull-down menu. So in the absence of any agreement or, in my view, cogent arguments about why the other way around made more sense, I did it that way.
https://www.welcometothejungle.com/en/articles/btc-interview-paul-mockapetris
Government domains in my country also tend to be gnarly. e.g. www3.guardian-foo.abc.gov. I can look at this and assume that guardian is probably some internal service and they're using wwwX for load balancing or something, but this is inscrutable for normal people and I suspect that fixing it is more of an organizational issue than a technical one at this point.
this used to be much more widespread and imho this has more to do that the unique departments of governments (and universities) had their own dedicated hardware with a somewhat 1:1 hostname to host mapping and in the following decades virtualization came around and people consolidated hosting, e.g. the same ministry has their stuff under $x.$virt.foo.gov and there's no 1:1 mapping anymore, except to keep old links.
We've also let organizations train us to click official links that are indistinguishable from scams, due to shortening them or using third-party survey tools.
It might also be how the organization works. Sometimes it's easier for a department to purchase a new domain than get a subdomain of the company's official domain.
In my experience it’s typically that someone hires an external web development agency who do their usual thing with their usual registrar and hosting provider, and never even try to contact the company’s IT department. Some months later the IT department has to add it to their inventory of third party web sites, at which point it’s too costly to tidy up.
Or it’s a SaaS provider who deliberately target the shadow IT market, so their setup instructions don’t consider how to configure an official corporate subdomain. Some months later the IT department has to add it to their inventory of third party services, at which point it’s too heavily used to be easily reconfigured.
I think part of it is the poor UX of URLs. They're read from the left, then right-to-left, then left-to-right again
Yeah, I was really confused by this when I first learned about URLs.
I am not sure that would help.
Why is uk.natwest-payment.www easier to spot as a scam? People will see the right name in the link (natwest) and the correct tld (uk).
Sure, the current design pushes the TLD off the screen sometimes, so reversing probably stops pizza.natwest from working as a phishing URl. But com.natwest-p.ayments-offic.ial-www looks pretty convincing to me.
It's mainly a guard against .gov impersonation.
I still think that more people would take care to spot scam domains if it wasn't so confusingly-ordered in the first place. Currently, people just give up.
That's fine if your country has a top-level government domain - like the USA.
But the rest of us have something like gov.cc - which means reversing it just means a scammer will buy cc.govpayments-tax-official and look mostly official.
I still think that more people would take care to spot scam domains if it wasn't so confusingly-ordered in the first place.
I don’t think there’s a clearly correct order for domain names.
In email addresses, little endian makes sense because it roughly matches postal address order: person building street city country. (This is a post-hoc rationale, not the reason domain names were designed that way.)
(However, note that postal addresses are not consistently little-endian: depending on the country, the building might be before or after the street, and the postcode might be before or after the city.)
But in URLs, big endian would be consistent with pathname order.
The security / usability studies that were conducted when trying to improve browser URL bars and to mitigate IDN homoglyphs suggested to me that typical users pattern match on individual words or abbreviations, regardless of order or punctuation or typographic style. Subtle adjustments to the syntactic minutiae (like . vs @ vs - vs /) will not have significant effect on how non-nerds react to scammy email addresses or URLs, especially since a lot of software will not show them the raw link, but instead hide it behind a display name.
The upshot is that it’s more effective to spend effort tackling the sources of the abuse rather than the victims.
In email addresses, little endian makes sense because it roughly matches postal address order: person building street city country. ...
(However, note that postal addresses are not consistently little-endian: depending on the country, the building might be before or after the street, and the postcode might be before or after the city.)
Depending on the country, postal addresses might be fully big-endian. :-) See, e.g., Chinese or Japanese addresses.
I don't think the reason internet scams are possible is that people can get domains with the words "gov" and "uk" in them: most normal (non-technical) people don't even look at the host name.
Part of that URLs are very rarely taught in schools (although this would do a lot more good than pushing for age verification!)... but a more important factor is that a weird hostname is generally not indicative of a scam.
It's very common for companies to outsource everything without setting up custom domains: If even the log-in flow redirects through ten different second-level domains, how in the world is a user supposed to spot phishing?
As an (anonymized) example, if all your legit links look like this:
login.nameofcomany.com
experience.someoneElse.com/nameofcompany
aGVscAo.annoying2FA.com/
nameofcompany.badWebMail.net/
... it's not DNS's fault that users also trust:
nameofcompany.NotAScam.xyz
Terrible title, clickbait at best and intellectual bankrupcy at worst.
I think it’s fine. A big rediscovery of the federated social media era is that trust & safety mechanisms are (1) very important and (2) very difficult to design around at a technical level while maintaining the freedom that federated services promise. So more noodling along these lines is good. “Spam, scams, and bigoted messages should be stopped before any legitimate user even sees/reports it” is a very hard problem to solve. We like hard problems, don’t we?
The title chosen by the author was not "DNS fails to prevent all scams" or "DNS permits some scams." Nor even "DNS is undermining trust & safety in federated social media." It was "The purpose of DNS is to spread scams" which, I have to agree with @eugeny, seems like clickbait at best and intellectual bankruptcy at worst.
I'm leaning towards intellectual bankruptcy: if we removed DNS from the world, and we went back to using IP addresses, would the scam problem be better or worse? It seems obvious, to me, that the answer is worse.
The author also acknowledges that they have no improved alternatives to suggest. So the honest version of their post would have been "DNS does a better job of balancing competing values than anything I can think of!"
I like this a lot. The unaddressed problem is that we’ve got a distributed database designed to make adding entries easy now being used to vouch for identity of a publisher.
The problem here is that people are looking at domain names at all. What’s needed is a completely fucking different system. SSL certs would be a perfect fix if they weren’t basically also completely open and not subject to any real verification. Of course part of the problem is that id verification is hard, especially if organizations.
The solution probably looks something like introducing a hard mode level of ssl cert and browsers basically telling people not to enter any information or do anything business looking if there’s no hard mode cert, and if there is a hard mode cert prominently display a visual embedded in the cert. lookalike checking would have to be part of the hard mode cert.
Obviously this makes for a much less open web. I’m not sure there’s a great solution that’s distributed and not also open to abuse.