Re: [DNSOP] Proposal: Whois over DNS

[Jim Reid <[e-mail]>]

On 8 Jul 2019, at 22:38, John Bambenek <jcb=[e-mail]> wrote:
> 
> In response to ICANN essentially removing most of the fields in WHOIS for domain records, Richard Porter and myself created a draft of an implementation putting these records into DNS TXT records. It would require self-disclosure which mitigates the sticky issues of GDPR et al. Would love to get feedback. 

I think this is a spectacularly bad idea.

1. The intractable policy problems around whois won't/can't be solved by moving them from port 43 to port 53.

2. These policy problems are out of scope for the IETF. It deals with technical and operational matters around protocol design and deployment. Policy issues are handled in other fora - like ICANN. The IETF should keep well away from the whois policy swamp. The wrangling over whois policy at ICANN has gone on and on for 20+ years. It shows no sign of reaching a consensus. Dragging the IETF in to that screamfest is not going to improve matters.

3. Your proposal doesn't mitigate GDPR issues. At best it'll just move the goalposts. The roles of Data Controller/Processor/Subject won't necessarily fit with the roles that update, manage and publish DNS data.

If I outsource my DNS to $registrar and/or $dnshoster, one or other of them might (or might not) be the Data Controller. Or it might (or might not) be me. The same does for the Data Processor role. So who'd be on the hook for GDPR compliance?

DNS providers who are largely untroubled by GDPR today could be obliged to register because your proposal would mean they'd be publishing and processing Personal Data. As things stand currently, it's already clear who has those responsibilities - the registry that provides the whois server. In your proposal, it's not so obvious. And when I am the Data Controller, I will probably need to get consent to publish Personal Data in the DNS (or anywhere else) for an admin or tech or whatever contact who isn't me. Why should I be expected to bother with that hassle?

4. It's unwise to use TXT records in this way. Pick another RRtype. TXT records are already overloaded and used for all sorts of things. What if someone's already got a TXT record with RDATA that begins with (say) "aname="? It's also a bad idea to require a specific subdomain for these RRs. How will this work for a domain name that's too long to accommodate an additional _whois label? And where would the contact data for _whois.example.com get stored? That doesn't necessarily have the same contact data as its parent.


BTW, whois was originally intended to provide a way to publish out-of-band contact data so the domain holder could be contacted whenever their DNS or email was broken. Putting this info in the DNS would defeat that.