Below — John Bambenek
On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sa...@bambenekconsulting.com for details On Jul 9, 2019, at 08:32, Jim Reid <j...@rfc1035.com> wrote: >> On 8 Jul 2019, at 22:38, John Bambenek >> <jcb=40bambenekconsulting....@dmarc.ietf.org> 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. This seems only slightly hyperbolic. What exact harm will be caused here? The most likely risk is non-adoption. If everyone adopted this, nothing would break. > > 1. The intractable policy problems around whois won't/can't be solved by > moving them from port 43 to port 53. Self-disclosure cures a lot. It also removes an itinerant middleman more concerned with their business objectives than public goods. It very much solves those two problems. > 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. This creates a protocol and standard to facilitate voluntary information exchange. No more. If I want to publish these DNS records, it is not ICANN’s business. What we are discussing here is a workable standard should someone wish to. There is a policy backdrop, sure. That’s driving the need to move to a self-disclosure system without middlemen. > 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. In GDPR there are minimal controls against what I publish about myself and control about myself. The sticky issues about whois are that they are required by ICANN. No requirements are here. We have a standard for SMTP here, no one is forced to use it. > 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? Who’s on the hook for GDPR compliance for A records? IP addresses are PII. Shall we make a GDPR-compliant DNS system with authentication, auditing, tiered access, and disclosure of purpose in accessing data? Should we do the same for websites? > 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? If I create the TXT records, it is less important whose server it sits on. All these arguments apply to webpages which may also contain PII. Is GoDaddy on the hook if I put my phone number as contact info on my webpage hosted on their server? No. As I said, IP addresses are personal info. If your statement were true, they’d already be required to register. This is an already solved problem. > > 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. Valid feedback. Do you have a suggestion of a record type or just make a new one? Would that make you more or less likely to support this? As far as subdomains, that’s up to the domain owner/operator. Some will delegate subdomains, some manage centrally. Is it the roll of the IETF to decide such a question globally? As far as domain records too long for a whois label, do you have a legitimate and non-abusive domain I can look at for an example that is actually in use today? There are several “subdomains” already standard (DKIM, for instance). This is an already solved problem. I’ve checked, no one as far as I can tell is using _whois or the labels I have proposed today TOGETHER. Maybe there is an aname= TXT record (I haven’t found one). But there isn’t one anywhere in the world tied to _whois that I can find. > > > 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. Yes, I agree that whois SHOULD be out of band. But ICANN won’t allow such a system with meaningful data, so here we are. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
