|
Mark Jeftovic of easyDNS Technologies Inc. has posted an item on ICANN’s “GNSO” registrars’ mailing list titled “unsanctioned Whois concepts”.
In that item he suggests that the control and actual publication of contact information about a domain be put into the zone file itself, a file maintained by the registrant (purchasor) of the domain name.
“Why not push the stewardship of the data back to the ultimate owner? The Registrant. Basically, the registrant could store their own Whois record in a well-known location on their own servers, similar to a P3P policy (i.e. /w3c/whois.xml ), and the registrars maintain publicly accessible “stub” records which point them.
Doing that allows the registrant to assume some control over the dissemination of their own data.
[...]
There are a few obvious fields, which can be added to the Whois records to enhance usable functionality of looking at a record.
Some additional data elements allow for more flexibility in controlling the data set presented and to what end.
For example, a field called “proposed use” we may decide that “personal” domain registrants are allowed to withhold their phone, address and email data from their published whois.xml records.
But a shadowy fraud site would not find this avenue useful for enacting fraud anonymously because things like web browsers would detect mismatches between the type of page one is on (a form asking for a credit card number) and the “proposed use” listed in the published whois.xml. Companies conducting ecommerce over the web would be best to use a more suitable “proposed use” or “current use” value which would have more comprehensive data requirements.
Other possible fields could be: serial number, to track revisions to the data; abuse contact; whois reference, containing the pointer to Registrant whois.xml; PGP keyid; User defined; etc.”
It turns out that such an idea has been floating around for several years - I have heard the idea credited to Kent Crispin. It is, by my way of thinking, a very good idea.
Take a look at the whois.cavebear.com[/t]. TXT resource records in the cavebear.com zone:
dig @cavebear.com. whois.cavebear.com. txt
What you will see is pretty much what Mark is asking for, the contact information for the zone, in a format that is readible by both people and software.
All I had to do was add a couple of TXT records to my zone file - a few seconds effort.
This technique is easily extensible and places the control of, and the responsibility for, the information, squarely in the hands of the person most likely to care and know - the registrant.
—-
This article originally published in the CaveBear Blog.
Sponsored byCSC
Sponsored byVerisign
Sponsored byRadix
Sponsored byWhoisXML API
Sponsored byIPv4.Global
Sponsored byDNIB.com
Sponsored byVerisign
The theory is good at a rough glance…. but over 50% of domains don’t have active websites or good DNS. Why not leave the Whois at a more central location like at the Registrar/Registry where it is already. One of the reasons for Whois is to get a hold of the owner and let them know they may have a problem with their network. Seems we need the whois to remain at a central location. The Thin-to-Thick registry migration we are seeing suggests that centralized whois is the popular opinion of the day. Perhaps a good solution is to have the Registrar/Registry sync their records to the owners? local whois IF and only IF they have one available. Overall it sounds like an administration nightmare, so I don’t think decentralizing whois is the correct solutions.
The idea isn’t new, you’re right - and I’d talked to others about it over a decade ago in terms of adding new fields in an anarchaic manner. You’ll remember the push to get ICBM targeting data into the DNS in TXT records back in the late 80’s / early 90’s. Wasn’t that fun?
But if you make it voluntary, only the geeks will put it in. And if you make it mandatory, then you mandate that the registrars and/or registry must do it, and, at that point, who cares if it’s stored in the DNS or in a database somewhere?
I posted a similar idea last winter, in a post on the GA list—see here, i.e. a “whois.txt” like a robots.txt file.
I don’t see it as a replacement to WHOIS, though (I like the status quo), just a supplement forthose who want to be easily found, and so that crawlers like Alexa could easily update the data on an “opt-in” basis, without mining the WHOIS.
Putting it on the web would make it easier for most people, rather than as TXT records in the zone file for a domain, which requires more technical skill. For a small business owner, etc., they’d want something easy to understand and publishing a file on their website is fairly simple for most.
Some domains may be registered, but have no active DNS for whatever reason. So we should not get rid of the usual whois database. But otherwise, DNSWI would be a very good way to augment the traditional whois data. And maybe registrars can update their records when the information changes in the appropriate authoritative name server(s). I do believe it should be made mandatory, at least to the extent of the RFCs.
What about contact records? There’s a lot of information there, and I wouldn’t want to always be pushing answers beyond what DNS can do in a UDP datagram. Maybe separate names for specific contact roles, like admin.whois.example.com for the Admin contact, tech.whois.example.com, abuse.whois.example.com, and so on.
As for a whois.txt on a web server, I say perhaps. Even more domains have no active web services (and many are actively used, as well). And there already is a whois protocol and well known services port number which could be directed via the A record of whois.example.com to whatever machine has that data (which may be the same whois server for many names).
I think the big question is what should be mandatory, if anything? I still think it should be the data received by the registrar. The reason for that is that it is stable data that can also be verified to be accurate (call the registrant to make sure that whoever is there acknowledges responsibiity for that domain). DNSWI will be abused by some, so despite the convenience, it won’t be 100% accurate. It can be forged. It can be synthesized, randomized, and rotated. It can even be mirrored to kick back the same information as whoever queries it.