Regardless of the privacy implications, if someone who wants to look up a hostname and can't find can't figure out what the authoritative nameservers are for the domain, DNS quite simply will not work and with it the internet is down; go home.
Plenty of RDS failures happen - with some registries/registrars their whois is down more than up, and the internet still works, the domains still work and so on - domains resolve based on the nameservers of the domain returning an appropriate answer, neither the nameserver details nor the answer are retrieved from any RDS, and the inclusion (or not) in RDS will not be changing that in any way
My point wasn't that RDS has to be correct... my point was the registries need to collect and present this data anyway and it has to be globally consistent and accessible (via DNS).
We aren't talking about DNS, we aren't (able to or even contemplating) changing DNS - so the nameservers being available for DNS (as they would have to be) I think is a perfectly good reason _not_ to include them in RDS Data should exist once, only once and exactly once :) If there is already a way to get it, why create yet another store/display method _in addition to not replacing_ the correct existing method ? (especially with the inherrant issues we have now that the data isn't necessarily accurate)
So the entities collect and display it to users using the right commands anyway, so turning around and saying we have to shield it from RDS as a privacy risk is a fallacy
I (personally) don't think _nameservers_ is privacy risk (I can already find out your nameservers should your domain have them set) -as _something_ needs to be able to query them for things to work I still don’t think duplicating data is ever a good idea, and in the (current) case of WHOIS is actively hurting rather than helping Rob --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus