Launching RDAP; sunsetting WHOIS
icann.org
icann.org
So far the sunsetting has had little effect with most TLDs still having their WHOIS services online. In reality, I think we'll see a period of time where many TLDs and nTLDs have both WHOIS and RDAP available.
Additionally, since ccTLD's aren't governed by ICANN, many don't even have an RDAP service available. As such, there's going to be a mix of RDAP and WHOIS in use across the entire internet for some time to come.
Disclosure: I run https://viewdns.info/ and have spent many an hour dealing with both WHOIS and RDAP parsing to make sure that our service returns consistent data (via our web interface and API) regardless of the protocol in use.
Training, sure, but that's buy once cry once.
Whether this means it's a good idea, I don't think so, but the energy usage for parsing isn't why.
Of course you were already saying it’s not a good idea, but I think the above definitely plays a role at scale as well.
> energy usage for parsing isn't why
You'll need to provide actual figures and benchmark these against an actual parser.
I've written parsers for larger-scale server stuff. And while I too don't have these benchmarks available, I'll dare to wager quite a lot that a dedicated parser for almost anything will outperform an LLM magnitudes. I won't be suprised if a parser written in rust uses upwards of 10k times less energy than the most efficient LLM setup today. Hell, even a sed/awk/bash monstrosity probably outperforms such an LLM hundreds of times, energy wise.
You're assuming OP needs an LLM to write a parser, since they mentions writing many during their career they probably don't need it ;)
Especially since the parser(s) I wrote were rather straightforward finite state machines with stream handling in front, parallel/async tooling around it, and at the core business logic (domain).
Streaming, job/thread/mutex management, FSM are all solved and clear. And I'm convinced an LLM like copilot is very good at writing code for things that have been solved.
The LLM, however, would get very much in the way in the domain/business layer. Because it hasn't got the statistical body of examples to handle our case.
(Parsers I wrote were a.o.: IBAN, gps-trails, user-defined-calculations (simple math formulas), and a DSL to describe hierarchies. I wrote them in Ruby, PHP, rust and perl.)
For small problems it’s not worthwhile, for large problems it is.
It’s similar to choosing to manually do something vs automate it.
This is the kind of thinking that leads to modern software being slower than software from 30 years ago, even though it is running on hardware that's hundreds of times faster.
LLM's are not the solutions, they are the source of big troubles.
This doesn't work for all use cases but data extraction is pretty safe. Treat it like a database query -- a slow but high availability and relatively cheap call.
It feels like using AI to do computing things instead of writing code is just like when we moved to relatively inefficient web technology for front-ends, where we needed beefier systems to get the same performance as we used to have, or when cloud computing became a thing and efficiency / speed became a factor of credit card limit instead of code efficiency.
Call me a luddite but I think as software developers we should do better, reduce waste, embrace mechanical sympathy, etc. Using AI to generate some code is fine - it's just the next step in code generators that I've been using throughout all my career IMO. But using AI to do tasks that can also be done 1000x more efficiently, like parsing / processing data, is going in the wrong direction.
Example: https://github.com/weppos/whois is a very solid library for whois parsing but cannot handle all servers, as they say themselves. That has fifteen + years of work on it.
Using LLMs to parse whois data is okay in the meantime (preferably as a last resort!), but structuring the data properly in the first place (i.e. RDAP) is the better solution in the long run.
Can you imagine how many ridiculous errors we would have if LLMs structured data into protobufs. Or if they compiled software.
It's more than 1000x more wasteful resources wise too. The llm swiss army knife is the Balenciaga all leather garbage bag option for a vast majority of use cases
If it can convert from one format to another, then it can generate test cases for the parser. Then hopefully it can use those to iterate on parser code until it passes the tests.
In a sense, asking it to automate the work isn't as straightforward as asking it to do the work. But if the approach does pan out, it might be easier overall since it's probably easier to deploy generated code to production (than deploying LLMs).
It's not like this is a new concept. There are plenty of algorithms we've been using for decades that are only statistically correct. A perfect example of this is efficient primality testing, which is probabilistic in nature[0], but you can easily make the probability of error as small as "unlikely to happen before heat death of the universe".
--
[0] - https://en.wikipedia.org/wiki/Primality_test#Probabilistic_t...
- LLMs != ChatGPT interface, they don't need to be run in isolation, nor do they need to do everything end-to-end.
- There are no 100% reliable systems - neither technological nor social. Voltages fluctuate, radiation flips bit, humans confabulate just as much if not worse than LLMs, etc.
- We create reliability from unreliable systems.
LLMs aren't some magic unreliability pixie dust that makes everything they touch beyond repair. They're just another system with bounded reliability, and can be worked into larger systems just like anything else, and total reliability can be improved through this.
EDIT: In fact, my example with probabilistic primality tests is bad because those tests are too nice - they let us compute tight bounds on the error rate in advance. LLMs are not like that. But then, a lot of systems we rely in our daily lives also have this property - their reliability is established empirically, i.e. we improve them until they work reliably enough, and then we hope they'll keep on working, and deal with random failures when they occur. So that's nothing new, either.
Saying LLMs are no worse than random bit flips is, again, an unjustified comparison. We can control bit errors with ECC, we cannot control the output of an LLM except to shackle it into uselessness.
Yeah, sure, we can hypothetically engineer a system that tolerates a key step in the process which has, say, a 30% chance of being wrong, including a 10% chance of being dangerously wrong (appears correct but is broken in subtle ways), and a 5% chance of being batshit insane, but why would we? The amount of training, vetting, and supervision of human operators necessary to make a working process here immediately raises the question of whether the machine serves man or the other way around.
The best uses of an LLM are those where engineering levels of precision are neither required nor useful.
However, an LLM for automated code generation (the context of the thread as I understand it) is basically a dubious-code-copy-paster on steroids. That was already the wrong way to develop code to begin with, automating and accelerating it is not an improvement.
There has never been a single case where I took code from Stack Overflow, which is already a relatively high quality source of such snippets, and didn't have to adapt it in at least some way to work with the code I already had. Heck, I often find rewriting the snippet entirely is better than copying and pasting it. Of course, I also give attribution, both for credit and for referring back to the original in case I made a mistake, the best solution changes in the future, there's context I didn't cover, etc. And in between the problems I solve with other people's help is a whole lot of code I write entirely on my own.
There are many cases of code in the wild being bad, not just from a "readability" or "performance" standpoint, but from a security standpoint. LLMs regurgitate bad code despite also having good code, and even the blog posts explaining what's good and what's bad, in their training corpus! And an LLM never gives attribution, partly because it was designed not to care, and partly because the end result is a synthesis of multiple sources rather than a pure regurgitation. Moreover, LLMs don't have much continuity, so they mix metaphors and naming conventions, they tie things together in absurd ways, etc. The end result is an unmaintainable mess, even if it happens to work.
So no, an LLM is not like a compiler, even though compilers often have their own special brand of crazy magic that isn't necessarily good. Nor is it going to deliver a robust way to turn abstract human thoughts into concrete code. It is still a useful tool, but it's not going to be an automated part of developing quality code. And this is going to be true for any non-coding scenario that requires at least the same level of reliability.
... on conformant inputs, when it has no bugs.
On non-conformant inputs, there's absolutely no telling what an LLM will do, which is precisely the problem. It might barf, or it might blissfully continue, and even if the input was right you couldn't remotely trust it to regurgitate the input verbatim.
As for bugs, it is at least theoretically possible to write a parser with no bugs, whereas an LLM is fundamentally probabilistic.
Ever tried to parse WHOIS data? You literally have to write a parser per TLD.
And things get even more stupid when you start talking about WHOIS records for IP ranges. Then you have to write a parser per IP-range delegation — starting at IANA, and working recursively, all the way down to the individual ASN. Where you have no idea how many delegating parties are going to be involved — and so get their own step in the chain, formatted however they wish — for any given IP address. (Ask me how I know.)
You only have one job, don't delegate authority.
Disclosure: Work in the ccTLD space.
Last post from yesterday:
> As of today 82.25% (1187) of all 1443 Top Level Domains have an authoritative RDAP service declared.
> These TLDs were added:
> .ye
I have a .es (my nickname berkes, domain berk.es) for almost 16 years now, and live in the EU, but not in Spain. In the beginning I used a small company that offered services for non-spanish companies to register .es through them (I believe they technically owned the domains?). But today it's just in my local domain registrar without need for an ID.
That .es has no whois has struck me as somewhat of a benefit actually. Back in the days, it kept away a lot of spam from spammers that'd just lift email-addresses off the whois. My .com, .nl and other domains recieve(d) significant more such spam. Let alone phone-number and other personal details delivered over an efficient, decentralized network. Though recent privacy addons(?) have mitigated that a little.
It's not very well documented, but you can register at a government site using a national ID and they'll open WHOIS access for a fixed IP address, for a maximum of 10 queries a minute. [0]
Context for any of you not used to the .es ccTLDs: Until some years ago, and simplifying a bit, if you wanted to register a .es TLD you had to be an Spanish national or company, and be the legal holder of the domain name you wanted to register (or your name and surnames).
--
0: https://sede.red.gob.es/es/procedimientos/solicitud-de-acceso-servicio-de-whois-por-el-puerto-43Is this new? I had an .es domain around 2011, and am not Spanish, or even European.
--
0: https://news.ycombinator.com/item?id=43392356Some ccTLD's have rules against registrations by people not located within the country that owns the ccTLD, in which case a valid national id or organization number would be required. From what I can see, .es does not have that requirement.
--
0: https://news.ycombinator.com/item?id=43392356The only way (that I've found) to use the WHOIS service with the .es ccTLD is whitelisting a fixed IP address with your national ID at a government site [1]. And even then, you're rate limited to 10 queries per minute.
--
0: https://en.wikipedia.org/wiki/WHOIS
1: https://sede.red.gob.es/es/procedimientos/solicitud-de-acceso-servicio-de-whois-por-el-puerto-43If I register a domain, the registrar will basically extort me a couple extra dollars per year for “domain privacy” for the privilege of not having my name, home address, phone number, and email publicly available and then mirrored across thousands of shady scraped content sites in perpetuity. Even If you don’t care about that, then begins the never ending emails texts and calls begin from sleazy outfits who want to sell you related domains, do SEO for you, revamp your site, schedule a call, or just fill your spam box up with legitimate scams and bootleg pharma trash.
All because you wanted a $10/year dot com without paying the bribe.
And yes I grew up leafing through well worn phone books next to corded phones. This is not comparable.
Two decades late on a problem
Oh, I have unintentionally become a GoDaddy customer (a company I have spent ample time hating and shitting on over the years) because I was a legacy Media Temple customer going back to like 2006 and I still just can't be bothered to clear out everything on those sites/domains and they eventually got acquired
There are 160 million registered .com domain names.
I understand that operating root servers isn't free, but surely they don't cost $1.5 billion per year! Wikipedia's hosting costs are $3 million per year, for comparison.
(.com is basically price-regulated because of this, FWIW, Verisign can't just raise prices whenever or however it wants. But obviously it's still a pretty sweet deal for them, I'd imagine.)
Which begs the question, why doesn't ICANN just replace Verisign them with a different authoritative register that charges much less?
We could use anti-scalping techniques, but that’s non-trivial to implement. Perhaps some name squatting policy? No idea how to enforce it though, especially without money.
Shouldn't ICANN collect that margin and use it for charitable purposes instead?
I think the current system is inherently flawed... but it kinda works, and nobody wants to figure out the politics of fixing it – so I guess we’re stuck with it for a while.
The vast majority of people in the world have $0 on the line and no clue how these systems work.
The majority who have an interest in fixing it have something like N×$10 per year on the line for a fairly small N.
Those who don't want it fixed have billions on the line.
It's not getting fixed anytime soon.
I assume some registrars sell these at a loss and expect to offset that by selling you WordPress Supreme Ultra Enterprise hosting for... $40/yr? No idea how this works.
Also, why the title is not same as the article? It makes no sense.
I’ll often post loosely related tangents like this because I would enjoy discussing the tangent with the HN crowd, but there’s often not a better opportunity to discuss it, so why not while we’re sort of on the topic anyway.
Ack that I don’t think it makes sense to discuss not even remotely related topics. But as long as it’s in the ballpark and it’s not going against other guidelines and leads to interesting discussion, I think it’s fine.
RDAP offers several advantages over WHOIS including [...] the ability to provide differentiated access to registration data.
Somewhere enshitification fits all over the place.
Between the countless DB leaks and numerous infostealer campaigns, and considering that anyone who has you in their contacts list is extending the exposed surface area, it's untenable. Other events like marriage and home ownership further complicate any attempt to keep your name and address private.
Not saying you shouldn't opt for domain privacy, just giving a reality check. To really enforce your privacy you have to have multiple phone lines and a shell company, at the least. And really, even that isn't enough unless you can also commit to being a hermit.
It's a useful filter, a seller without identifiable people and location is a big red flag.
A freelancer's sites are also considered commercial use.
And such sites without imprint have been fined & taken down.
If you engage in commerce, you need to publish enough contact information that others could serve you a court summons.
b) You need a valid postal address where you can receive mail but this doesn't have to be your home address. A PO box is fine.
c) You don't need to have a phone number in your Imprint.
The base requirement of commercial operations having to have valid contact information (that can be used for legal communication) is pretty sensible. The details could be a bit friendlier towards individuals running purely personal sites.
the idea is to have individuals accountable while not annoying owners.
in that sense it makes _perfect_ sense and works as intended.
a proper solution ingredient would be trustworthy and affordable pseudonymity, and that can be lifted by court orders only. but then who guarantees the independence of courts? and the fairness of laws?
we're in a tough ride.
Except for the guy who tried to sell me annuity liquidation. Yes, if the person gets unalived earlier than expected, you win.
In related news, I saw someone buy $150 worth of lottery tickets, as I was on the way to a large hospital to visit a sick friend. The lottery guy I am sure lost, and the hospital guy (profit-care) won, while the ward was understaffed( a profit-center). And 7 out of 8 fare collection machines were out of order ( deferred maintenance as a profit-center). I get the distinct feeling that corporate America, just does not even care in the slightest.
For the organization that managed the WhoIs? The horse left the barn so long ago, it's great great great grand-children are old and gone. Long gone.
Call me 1-800-555-1212.
[1]: https://www.registry.in/system/files/Terms_and_Conditions_fo...
I have two .in domains with namecheap and whois data is all "REDACTED FOR PRIVACY" despite namecheap not allowing me to add domain privacy when I purchased the domains.
In fact Namecheap explicitly state that they can't provide privacy services for .in domains on this page: https://www.namecheap.com/security/what-is-domain-privacy-de...
- “Privacy service”, which is these funky named LLCs replacing your data in the WHOIS
- Just the redaction, which replaces almost all data with REDACTED FOR PRIVACY (except for registrant's country, state, and organization name).
No idea why or how any of this works! Apparently, Porkbun does both: on my another domain, aedge.dev, it shows REDACTED FOR PRIVACY and replaces org name with “Private by Design, LLC”. For notpushk.in, it does show my country (RU... looks like I haven’t updated my address in a while lol) but everything else is redacted, too.
Spaceship on the other hand doesn’t bother and returns only this tiny response:
Domain Name: lunni.dev
Registry Domain ID: 4AF9AE073-DEV
Registrar WHOIS Server: whois.nic.google
Registrar URL: None
Updated Date: 2025-03-10T13:01:35Z
Creation Date: 2022-12-11T02:30:54Z
Registry Expiry Date: 2025-12-11T02:30:54Z
Registrar: Spaceship, Inc.
Registrar IANA ID: 3862
Registrar Abuse Contact Email: abuse@spaceship.com
Registrar Abuse Contact Phone: +1.6027723958
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: coco.bunny.net
Name Server: kiki.bunny.net
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of WHOIS database: 2025-03-17T17:11:09Z <<<
Edit: or, rather, that’s what whois.nic.google returns for a domain registered in Spaceship.Porkbun docs on WHOIS privacy options: https://kb.porkbun.com/article/97-new-whois-privacy-settings...
Im one of those that think that developers are hiding too much, which makes things like vs code extension viruses rampant.
I wont force you to not be anonymous, but if you are going to run your software on my device I want some accountability. Our salaries should also reflect that.
Im sure that this will be unpopular though.
How do you come to that conclusion?
>vs code extension viruses rampant.
So far I haven't encountered a single actual virus, and if you're referring to the recent Material Theme debacle, there was never any malicious code involved, only third party libraries with obfuscation.
Either way, your aversion to anonymity of developers is interesting. It's a discussion for a different thread, but I think an important one.
It’s one thing if you have a PO Box, and it’s consistently used in your various documents and registrations. I get wanting a firewall to direct availability.
But if I can barely find evidence you exist other than your software, or if you operate a fairly large scale service and you haven’t filed a yearly required corporate report (a specific example I recently came across), then those are red flags to me. Not immediate showstoppers necessarily, but if you’re trying to get me to make a purchase, I probably won’t.
It’s fine if you have domain privacy turned on, but you’re selling me software or services you have got to offer some kind of evidence that you have some kind of business nexus someplace. In a business context, I’ve got to know that for avoiding sanctions violations at the least.
My personal take is that we need a society with a lot more trust.
How do you trust that food from McDonalds is safe? How do you trust that Samsung hasn't empowered parties to control the mic on your phone? How do you trust Wells Fargo to hold your deposits? How do you trust the kennel to walk your dog?
Trust is really really hard. So a lot of people choose to adopt a zero trust philosophy.
Except they still eat at McDonalds and buy Samsung and bank at Wells Fargo. But they drop their dog off with Aunt Lawana now, instead of the commercial kennel.
Do you remember when Sony installed rootkits? Do you remember when Windows got compromised every 5th day for two years straight? Do you remember when HP broke every HP printer with a firmware update? Do you remember when the whole world got put on pause because an "anti" malware software pushed a flawed update? Do you remember when a certain credit-rating bureau got breached and exposed the PII of, well, everybody?
Do you remember that every one of these companies went on to post record profits?
Trust is really really hard to figure out.
Be careful about concluding things like that.
The TLD has a requirement that you publish your info. That doesn't mean they have any way of verifying it. If someone could prove that the info was false then they might lose the domain, but they also lose the domain if someone can prove that they're operating a scam. So the scammers just make up fake info and all the requirement is doing is impacting the privacy of honest people who want a .us domain.
If you go by the book e.g. Cloudflare not every field (e.g. state and country) is hidden. So not exactly.
Dear User,Our system has identified an unpaid toll charge linked to your vehicle. To avoid additional fees or service disruptions, please settle this matter within 12 hours.
https://e-zpass.org-qrh.xin/indexshtml"
Best of luck trying to get an unknown Chinese registrar to stop their spam. My carrier does not even have a clue. My routers now block anything *.Xin. Anything and everything.
> Two protocols that have the same data would be quite redundant.
When one is plaintext, underspecified, and decades old, they're not. I don't think you realize how primitive WHOIS is; this is the entirety of its RFC: https://datatracker.ietf.org/doc/html/rfc3912 Note how it doesn't go any farther than "it's a plain text blob retrieved over TCP". Now contrast with the RDAP RFCs, which fully specify every aspect of how an RDAP service works:
https://datatracker.ietf.org/doc/html/rfc7480 https://datatracker.ietf.org/doc/html/rfc7481 https://datatracker.ietf.org/doc/html/rfc7482 https://datatracker.ietf.org/doc/html/rfc7483
Integrating with WHOIS is a nightmare, as every registrar/registry does it differently since there's no common specification other than "connect over TCP". RDAP is fully specified, so you can simply use a language-specific library and then inspect a strongly typed response object returned by said library to get specific information out of the response. It's a night-and-day difference, and there's obviously a reason for the new spec to exist even though it conveys the same data. It's absolutely not redundant.
And yet all German sites must have such thing: https://0pointer.net/imprint
Mastodon _instances_ have Impressumspflicht, sure. But normal users don‘t and I have never seen anything contrary about private accounts.
Edit: unless the Account is for/by a business of course.
https://allaboutberlin.com/guides/website-compliance-germany...
If I were some kind of crazy maniac, I could pay him a visit and shut down systemd for good. You see why having this information out there is dangerous?
One can see this in practice in that company registration information is usually still available (through often behind a captcha), while personal information of private registrations require additional steps to demonstrate a legitimate interest. All this is also generally occurring at the registry level, rather than at the registrar.
It should be mentioned that privacy proxy is very similar to a straw man registration. If the registered owner is the proxy, then you are trusting that the proxy will honor the contract that is linking you with the property.
The concept of most internet things has felt sleazy for many years. Right around the time that businesses started monetizing the internet is when that feeling really kicked off tbqh
More recently, yes. But the original (perhaps naive) goal was to keep domain owners accountable for whatever they were serving from hosts under their domains. That seems reasonable, at least on a more "polite" internet, where things weren't scraped and monetized and SEO'd into garbage.
For large companies, and registrants under those ccTLD's that require local presence, it not uncommon that a legal firm acts like a proxy for the domain owner. This is a service that they take a few dollars for, and is in many ways similar to domain privacy.
The requirement of having the registrant as the contact person for a domain is something that (to my knowledge) comes from ICANN, and I think it has a positive effect. A domain should be owned and controlled by the registrant and not the registrar, which is then reflected in the contact information. In an alternate history we could see that the registrar (or even registry) owned the domain and only leased it to the registrant, in which case the registrant's power would be limited to other online services that people "buy" today.
Your registrar is scamming you.
Doing some WHOIS lookups, we found a point of contact at a university, called the network admin said hello and launched into an impromptu network admin interview. It was cool stuff. I emailed him later in the day to apologize to and thank him for being a good sport about the whole thing. He (fortunately) found it all rather enjoyable.
Otherwise, what did you expect the registrar to divulge to you, a random passer-by?
The US has a reputation of being a hypercapitalist society, yet they seem to be behind Australia in the descent into hypercapitalism by not (yet) privatising the registration of land titles. [0]
[0] https://www.abc.net.au/news/2017-04-12/$2.6-billion-price-ta...
A private industry would be able to maintain the records for next to nothing by advertising or offering related services.
The govt could restrict themselves to ensuring no monopoly.
It also means that banks can't sell mortgages out from under their borrowers because all liens and other finanacial liabilities attached to a title are known.
Huge protocol for cybersecurity
When I started using the internet, it’s how I contacted people. If I liked their site or their blog, I’d check who was behind it and get an email address I could contact.
Now… humans don’t really own domains anymore. Content is so centralized. I obviously noticed this shift, but I had forgotten how I used to be able to interact with the internet.
Even when they do, it's generally a smart idea to anonymize the whois information.
You might be looking up my domain to make a buddy, but someone else might be looking up my domain to SWAT me.
Stuff felt less homogeneous; everyone had kind of a loose understanding of HTML, and people would customize their pages in horrendously wonderful ways. It felt more personal.
And personally I found it more horrendously ugly than horrendously wonderful. But that's just my opinion.
I'll acknowledge that the old web was ugly, even at the time. I guess I just liked how much of it was, for lack of a better word, "custom". Most people were pretty bad at HTML, common web standards really hadn't caught out outside of "make it work in Internet Explorer", and CSS really hadn't caught on, so people glued together websites the best that they could.
Most websites looked pretty bad, but they were genuine. They didn't feel like some corporation built them, they felt like they were made by actual humans, and a lot of the time, actual children. I was one of those children.
I posted about this a week ago [1], but my first foray into programming was making crappy websites. It felt cool to me that a nine year old could make and publish a website, just like the grownups could. I didn't know anything about style so I had bright green backgrounds and used marquee tags and blink tags and I believe I had a midi of the X-files theme song playing in the background.
I guess it's the same sentimentality that I have when I look at a child's terrible drawing or reading one of my old terrible essays I wrote when I was eleven years old that my mom kept around. They're bad, they're embarrassing, but they're also kind of charming.
By 1999 you could create a LiveJournal or find a niche forum through Google. You didn't need to know anything very technical.
I've found so many interesting YouTube videos from people that I haven't ever heard of, just because of YouTube recommending them to me. Stuff like that didn't really exist for quite awhile; for a long time the best you had was aggregator sites like ThatGuyWithTheGlasses.com or similar sites.
I think a lot of people fail to appreciate that the alternative to big tech taking over was not keeping things exactly the same as they were 20 or 30 years ago, but developing in a different direction.
It was the direction in which people expected things to develop: decentralised and democratised. There was a lot of optimism about empowering individuals.
There's a big gap between looking up someone's contact info using a protocol that many tools and websites implement (anyone can open www.who.is from search results) and the second example of needing an understanding of HTML to make a webpage. I don't think it's gatekeepey to be able to email the human behind a given website, whereas the current internet is full of walled gardens, gatekeepers, and faceless/supportless services (thinking of Discord, Cloudflare, and Google as respective examples)
We can have both human-run services and WYSIWYG website builders on the internet concurrently
Should it exist? Maybe not, probably not, but that doesn't stop me from using it when I want to try to do some sleuthing. Most of the time though it doesn't work because they have privacy enabled.
I did get screwed once with certain TLDs not being able to enable privacy. I had registered a .at domain to use with a video site I had that at the time was reasonably popular and going viral fairly regularly. I hadn't realized beforehand that privacy wasn't possible, but once I learned, I didn't love it, but I wasn't sure if it would matter that much. I was wrong. I was getting calls and emails regularly from random people on the internet who found our content on reddit or whatever and decided to do some sleuthing
If you use fake info in relation to WHOIS data, you also need to be prepared to forge an identity document (a pretty bad felony in most countries per my understanding)
That said, on most forms I enter fake info because they they have no legitimate use for it anyway and they also can't compare it against anything. Buying a game or event ticket needs my address? For what, linking my purchase to a profile they're building? Nah, fake address it is
It is fascinating to consider how our experience with the internet is changing over time.
Remember phreaking? Having been born in the Netscape era, I certainly don't, but I can imagine that losing the ability to pull that trick off must have felt like a loss to those who were initiated in the art.
Thankfully the trend appears to be that new technologies and thus new 1337 h4x are still forthcoming.
> ICANN Update: Launching RDAP; Sunsetting WHOIS
Bit deceptive to editorialize it into something that sounds like something else much more interesting (removing contact info from domains) but isn't the case at all (they're just changing the method to access the same info).
[0] https://datatracker.ietf.org/doc/html/rfc3912
"A JS-derived serialization format" ... You mean JSON, which is about the lowest common denominator in Internet data exchange these days (and has been ever since we found out that XML was overly complex and JSON was much easier to use). You'll have to use something like jq instead of grep to extract information from the data manually. Or rather, you'll be able to use the powers of jq. Again, I don't really see the problem here.
To clarify my point of view, an ad hoc HTTP client for this indeed should not be hard to write from scratch, demonstrating that there is not much complexity in that. The server part would be a little more tricky; still doable, but not as easily as for WHOIS, and in most cases a more sensible approach would be to use libraries (or a program like curl, in case of shell scripting or manual usage) for that, as you said. Likewise with JSON: though one can deal with it as with text, some added tools (a library or jq, depending on context) would be sensible to use. But then added dependencies lead to all kinds of issues in non-ideal conditions (e.g., when it is problematic to install those). But again, I am not saying that this should stop adoption of RDAP.
On top of that, a complete and proper HTTP 1.1 implementation, server or client, would be quite large. And JSON, while indeed common and not particularly complicated, still has bits I find awkward (no sum types or a standard way to encode those, but has "objects", arbitrary-looking primitive types; no single standard for streaming, either), so working around it is not exactly pleasurable. Those add up to a difference between a trivial protocol and, well, a non-trivial one. I appreciate such trivial yet working and useful solutions, though the other kind is commonly useful as well.
curl -s https://rdap.verisign.com/com/v1/domain/example.com|jq -r '.events[] | select(.eventAction == "expiration") | .eventDate'
And https://data.iana.org/rdap/dns.json to find the endpoints for TLDs.You could argue that a more compact, binary, wire format is more appropriate (though I wouldn't, in this case, since for small, simple payloads, I think simplicity and human readability trumps sheer wire efficiency). You could argue that JSON's a poor serialization language in general (which is debatable, contextual, and in this case, I don't think there's a widely-accepted better option).
But let's not act like "a JS-derived serialization format" is some kind of mark of the beast here.
DNSBelgium: https://github.com/DNSBelgium/rdap
RedDog: https://www.reddog.mx/home/2017/12/14/server-1.2.2-patch-rel...
Golang, single binary, cross platform, download and use.
Except if it's not in your name
So yep, as you say: make this decision (fake or real information) knowing the risks involved in not legally owning it
https://www.zdnet.com/home-and-office/networking/court-rules...
See: Are IP Address Allocations Property? (2014) https://www.ethanheilman.com/x/19/index.html
Websites are more like books when they have a domain no else else cares about.
Content/expression related harms are outside of ICANNs bylaws and any obligations related to what a domain points at are not from ICANN, but from the laws in the jurisdiction in which the registrar operates. This is generally good. There is no global standard for acceptable limits on expression, with the possible exception of CSAM which is illegal everywhere.
Requiring domain registrars to arbitrate what content should be accessible via the DNS is perilous.
Sadly, we were not able to secure the domain on time, and after 11 years, the attempted trick is becoming irrelevant.
apt cache search rdap
on a Debian (well, Devuan) system, and found nothing. Also could not find that phrase in the name of any executable in /usr/bin or /usr/sbin .:-(
Name Server: NS-1411.AWSDNS-48.ORG
Name Server: NS-1914.AWSDNS-47.CO.UK
Name Server: NS-225.AWSDNS-28.COM
Name Server: NS-556.AWSDNS-05.NET
But if you run `dig ycombinator.com ANY +noall +answer` you'll see name servers here too. ycombinator.com. 21600 IN NS ns-556.awsdns-05.net.
ycombinator.com. 21600 IN NS ns-1914.awsdns-47.co.uk.
ycombinator.com. 21600 IN NS ns-225.awsdns-28.com.
ycombinator.com. 21600 IN NS ns-1411.awsdns-48.org.
ycombinator.com. 900 IN SOA ns-225.awsdns-28.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
If you see all the output together, you'll find the same name servers are present in WHOIS output and the DNS NS records. But wait, there's more.The name server `ns-225.awsdns-28.com` is present three times- in WHOIS, in DNS NS records, in DNS SOA record.
Which of these name servers get used to resolve `ycombinator.com` to its IP address like when I do `ping ycombinator.com`?
What if the information between the WHOIS and DNS NS records and the DNS SOA records are inconsistent? Which record wins?
WHOIS data are irrelavant to resolving the host IP address. The SOA will be used to find the primary name server (for an AXFR lookup perhaps), but generally, each NS entry will work in a round-robin fashion and SOA isn't queried.
Most resolves just ignore duplicate records, but I imagine some resolvers may change the "odds" to likely pick the duplicated NS entry.
Finally, most authorative resolvers do not want to spend resources on ANY queries and almost always don't return all records, or like you saw, do not de-duplicate answers.
Same question for SOA record. If the NS entries are used in a round-robin fashion, why is the name server present in SOA record too?
The NS returned from the registrar's WHOIS server reflects the registrar's view; the NS returned from the TLD nameservers reflects the registry's view; the NS returned from the zone's authoritative nameservers reflects the registrant's view. These should typically be the same, but can differ.
> why is the name server present in SOA record too?
The NS in the SOA record is used for RFC2136 dynamic updates and RFC1996 zone replication.
Which data though? Is it the WHOIS name server data that is used for round-robin? Or the DNS NS record data?
Do you know why the name server is present in SOA if it isn't used?
The SOA nameserver is pretty much only significant for DNSSEC these days. In the AWS case there, I don't think it does anything unique. Pretty much there just to meet the standard.
I guess I still don't understand why the name servers need to be both in WHOIS records and DNS NS records. Does the name resolution use the name server data in WHOIS records in any form or manner?
Think of the WHOIS information as more of an administrative database, and the actual DNS servers (which are located at the location of the NS records) as the operational database.
It is useful to know, in your administrative database, how to get to the organisational database, but it does not hold all of the information -- just where it is located.
In operational contexts (actual DNS lookups), you only use the operational database (the nameservers).
In administrative contexts (transferring a domain between registrars), you use the information from the administrative database (WHOIS).
There are additional wrinkles, like GLUE records, but those are probably a bit beyond the scope of what you're asking.
Which server gets used is usually randomized from the set of possible ones. Same for which of multiple A or AAAA records are used to connect to.
Us sysadmins would love to be able to specify weights or round robin or retries (like with SRV records) to move load balancing and failover to the clientside but for whatever reason browser vendors have rejected this for years.
Hopefully RDAP will be a suitable replacement. I haven't tried it yet.
The issue for me is that you can't simply publish contact information. It requires you to either publish a legal owner in full or nothing. I can't publish abuse@example.org as contact method (because, yes, I do want to receive an email if someone finds an issue with my services), I need to publish also a legal name, address, sometimes a phone number. Those things cost money to set up to be fake-but-legit (burner SIM card, rent a letterbox somewhere, get someone else to submit their name and ID card) whereas an email address is inconsequential to publish and I can rotate it monthly to avoid it becoming enrolled on too many spam lists
So my sites never provided contact info via WHOIS when I could avoid it, yet I'd think my sites are as reputable as they come. You can always find a plain old email address via some link on the homepage and I have no spam filter (just email address rotation) so there is no chance that you're algorithmically filtered out, either
For what it's worth one can publish that email address in their DNS zone SOA record. Some people will figure it out.
dig +short -t soa ycombinator.com
ns-225.awsdns-28.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
In the case of YC they defer to the AWS dns admins but you can set it to whatever you want unless your DNS provider does not let you. I've always run my own DNS so maybe that's less of an option for hosted DNS these days for all I know.However, there are no checks in place to make sure the email is valid.
cargo install icann-rdap-cli
rdap -O json ycombinator.com| jq .nameservers
(or brew install, etc., depending on your os and tooling). The jq formatted output is a little more verbose than the whois one, but three cheers for a well-specified machine-parsable format. (and rdap has a pretty-printed format output also)Btw, I tried the icann-rdap CLI tool and the default rendered-markdown output mode is atrocious. Sea of output, each nameserver has one or more standalone tables taking up 15x$repetition lines, almost impossible to fish out useful info. The retro gtld-whois mode is so much cleaner. Their web tool https://lookup.icann.org/en/lookup is fine too, don't know why the rendered markdown mode isn't like that. WTF.
"No registry RDAP server was identified for this domain. Attempting lookup using WHOIS service."
"Failed to perform lookup using WHOIS service: TLD_NOT_SUPPORTED."
As suggested by another comment, it looks like not all ccTLDs support RDAP. For example, .io does not.
Anyone experienced with this, I am not seeing abuse contact info, usually a phone number or email. Am i supposed to follow hyperlinks to get this info or something? Like search the registrar for this data?
I think rdap with a request/response authentication on the requestor but that the provider can't mask would be more practical.
Also requiring that registrars keep a history of changes from the time the domain was first registered would be very helpful vs relying on 3rd parties that cache the data over time (and charge for it) like domaintools.
Unlikely that this is in the protocol but I think it would better the entire ecosystem.
I can remember times when you could still see the names and addresses of registrants in whois records. That was before abuse and fraud became everyday occurrences in today's internet.
I miss the times when we could still believe in basic human decency.
though it seems this belief is tested on multiple fronts nowadays.
We should totally have a free .uuid TLD (which will predictably get blocked by 90% of networks... Although DoH would probably still work)
I'll admit it works sometimes. "news.ycombinator.com" is not as memorable as "hackernews.com" would be. But I like being able to have my website be chadnauseam.com (the name was unavailable on reddit), I like that no one is going to decide I'm not using it enough and take it away from me, and $1/month is so trivial that I think it's worth the benefits.
Besides, if you don't care about having a short and memorable name people can type exactly, why not just host your site on the free subdomain vercel or heroku gives you?
...and to host associated services to resolve this name to an IP address, as well as administrative overhead
I'd rather not that my domain name is funded by ads and sponsorships, the way that "X, YouTube, Facebook, Reddit, Twitch, etc all" are (no love for open source or decentralised platforms btw? The more commercial the better, except when it costs you money?)
the early internet was fun. whois was always a fun dimension.
is there a canonical rdap client that will end up everywhere? one of the nice things about the early Internet was that there were canonical utilities that were everywhere.
Seems far simpler than a whole custom protocol.
owner IN TXT Max Mustermann
email IN TXT mustermax@example.org
Or some other class, so that keys can't clash (already exist), similar to how version.bind is partitioned into the chaos classAnd that's besides the point that the registrar doesn't check this information. If you wanted to lie, they're not stopping you from getting false info into whois (or any alternative)
If it needs to be authentic, then DNS does have signatures nowadays, or a delegation as iirc you mentioned already. I just don't know why it should be more authentic than the unverified information that's currently in whois
> whois ycombinator.com % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object
refer: whois.verisign-grs.com
domain: COM
organisation: VeriSign Global Registry Services address: 12061 Bluemont Way address: Reston VA 20190 address: United States of America (the)
contact: administrative name: Registry Customer Service organisation: VeriSign Global Registry Services address: 12061 Bluemont Way address: Reston VA 20190 address: United States of America (the) phone: +1 703 925-6999 fax-no: +1 703 948 3978 e-mail: info@verisign-grs.com
contact: technical name: Registry Customer Service organisation: VeriSign Global Registry Services address: 12061 Bluemont Way address: Reston VA 20190 address: United States of America (the) phone: +1 703 925-6999 fax-no: +1 703 948 3978 e-mail: info@verisign-grs.com
nserver: A.GTLD-SERVERS.NET 192.5.6.30 2001:503:a83e:0:0:0:2:30 nserver: B.GTLD-SERVERS.NET 192.33.14.30 2001:503:231d:0:0:0:2:30 nserver: C.GTLD-SERVERS.NET 192.26.92.30 2001:503:83eb:0:0:0:0:30 nserver: D.GTLD-SERVERS.NET 192.31.80.30 2001:500:856e:0:0:0:0:30 nserver: E.GTLD-SERVERS.NET 192.12.94.30 2001:502:1ca1:0:0:0:0:30 nserver: F.GTLD-SERVERS.NET 192.35.51.30 2001:503:d414:0:0:0:0:30 nserver: G.GTLD-SERVERS.NET 192.42.93.30 2001:503:eea3:0:0:0:0:30 nserver: H.GTLD-SERVERS.NET 192.54.112.30 2001:502:8cc:0:0:0:0:30 nserver: I.GTLD-SERVERS.NET 192.43.172.30 2001:503:39c1:0:0:0:0:30 nserver: J.GTLD-SERVERS.NET 192.48.79.30 2001:502:7094:0:0:0:0:30 nserver: K.GTLD-SERVERS.NET 192.52.178.30 2001:503:d2d:0:0:0:0:30 nserver: L.GTLD-SERVERS.NET 192.41.162.30 2001:500:d937:0:0:0:0:30 nserver: M.GTLD-SERVERS.NET 192.55.83.30 2001:501:b1f9:0:0:0:0:30 ds-rdata: 19718 13 2 8acbb0cd28f41250a80a491389424d341522d946b0da0c0291f2d3d771d7805a
whois: whois.verisign-grs.com
status: ACTIVE remarks: Registration information: http://www.verisigninc.com
created: 1985-01-01 changed: 2023-12-07 source: IANA
# whois.verisign-grs.com
Domain Name: YCOMBINATOR.COM
Registry Domain ID: 147225527_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.gandi.net
Registrar URL: http://www.gandi.net
Updated Date: 2025-02-14T02:53:36Z
Creation Date: 2005-03-20T23:51:07Z
Registry Expiry Date: 2026-03-20T22:51:07Z
Registrar: Gandi SAS
Registrar IANA ID: 81
Registrar Abuse Contact Email: abuse@support.gandi.net
Registrar Abuse Contact Phone: +33.170377661
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: NS-1411.AWSDNS-48.ORG
Name Server: NS-1914.AWSDNS-47.CO.UK
Name Server: NS-225.AWSDNS-28.COM
Name Server: NS-556.AWSDNS-05.NET
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2025-03-17T01:27:31Z <<<$ rdapper ycombinator.com # cf. https://github.com/gbxyz/rdapper
Handle : 147225527_DOMAIN_COM-VRSN Status : client transfer prohibited secureDNS : {"secureDNS":{"delegationSigned":false}} objectClassName : domain ldhName : YCOMBINATOR.COM nameservers : {"nameservers":[{"ldhName":"NS-1411.AWSDNS-48.ORG","objectClassName":"nameserver"},{"ldhName":"NS-1914.AWSDNS-47.CO.UK","objectClassName":"nameserver"},{"ldhName":"NS-225.AWSDNS-28.COM","objectClassName":"nameserver"},{"ldhName":"NS-556.AWSDNS-05.NET","objectClassName":"nameserver"}]} events : {"events":[{"eventDate":"2005-03-20T23:51:07Z","eventAction":"registration"},{"eventAction":"expiration","eventDate":"2026-03-20T22:51:07Z"},{"eventDate":"2025-02-14T02:53:36Z","eventAction":"last changed"},{"eventDate":"2025-03-17T01:38:05Z","eventAction":"last update of RDAP database"}]}
================================ Terms of Use ================================
Service subject to Terms of Use.
================================ Status Codes ================================
For more information on domain status codes, please visit https://icann.org/epp
======================= RDDS Inaccuracy Complaint Form =======================
URL of the ICANN RDDS Inaccuracy Complaint Form: https://icann.org/wicf
Edit: Fixed formatting of command line/comment.
There's no need for people to know my information because I happen to own a domain.
> No registry RDAP server was identified for this domain. Attempting lookup using WHOIS service.
> Failed to perform lookup using WHOIS service: TLD_NOT_SUPPORTED.
Finger is not officially retired but no one supports it. NNTP seems it had a similar fate.
No first hand experience, however.
This is not a hypothetical, by the way.
99% of the target users will resolve it if they want access (by installing the necessary browser extension).
As for system emails, etc., they can come through any regular domain.
In contrast, when offering a service that is politically incorrect, at least in some geographies, it is useful to remain anonymous as the service provider. It is also then useful to not collect any unnecessary user data that could put the user at risk due to a data leak, although an email address is commonly still required for each user.
The crypto-privacy-coin world is at an altogether different level wrt privacy than the rest of the world. It is a lot closer to being the real deal.
it's still unsupported by a lot of tld's and the rate limits are atrocious. some registrar's only allow 10 requests per day and will group huge netblocks into one single block.
Major regression. How can we trust the internet now ?
https://en.wikipedia.org/wiki/Protocol_ossification is a big enough problem that we're being taught about this in school so that we're aware of the problem and maybe things get better in the future
I won't even notice its gone
Maybe I'm confused but whois gave me domain owner, but whois -r gave me Arin IP netblock ownership.
Arin is useful, whois is not.