Subject: [DNSOP] Proposal: Whois over DNS

From: John Bambenek <[email-masked]>
Date: Mon, 8 Jul 2019 16:38:58 -0500

All-

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. 

Name:        draft-bambenek-porter-dnsop-whois-over-dns
Revision:    01
Title:        Domain Contact Information (WHOIS) over DNS
Document date:    2019-06-30
Group:        Individual Submission
Pages:        13
URL:            https://www.ietf.org/internet-drafts/draft-bambenek-porter-dnsop-whois-over-dns-01.txt
Status:         https://datatracker.ietf.org/doc/draft-bambenek-porter-dnsop-whois-over-dns/
Htmlized:       https://tools.ietf.org/html/draft-bambenek-porter-dnsop-whois-over-dns-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bambenek-porter-dnsop-whois-over-dns
Diff:           https://www.ietf.org/rfcdiff?url2=draft-bambenek-porter-dnsop-whois-over-dns-01

Abstract:
  Domain contact information over DNS provides a vehicle for
  exchanging contact information in a programmatic and reliable
  manner. DNS has a ubiquitous presence within the internet
  infrastructure and will act as a reliable publication method for
  contact information exchange. This RFC provides an agreed upon
  structure, voluntarily, to publish points of contact for domains.

  This document outlines the methodology for utilizing DNS TXT records
  for voluntary publication of various forms of contact. The intended
  purpose is to provide a faster means of reliable contact for
  professionals, cyber-defense of domains.

—
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 [email-masked] for details

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 8 Jul 2019 14:42:25 -0700

> On Jul 8, 2019, at 2:38 PM, John Bambenek <jcb=[email-masked]> wrote:
> 
> All-
> 

Good in principle, but the information in whois has always been, at least nominally, third-party vetted.  This would not be.  So my worry is that either it would get no uptake, or it would get filled with bogus information.  It’s a little hard for me to imagine it being widely used for valid information, though that would of course be the ideal outcome.

So, no problem with this in principle, but I’d like to see some degree of consensus that user-asserted content is sufficient for people’s needs.

                                -Bill

---

From: John Bambenek <[email-masked]>
Date: Mon, 8 Jul 2019 16:47:15 -0500

That is the weakness but if the third party vetting (which let’s be honest consisted of sending an email to any address and seeing if someone clicked a link) won’t be done anymore because registrars and registries refuse to do it under the guise of “privacy”, where else can you go for vetting?

That said, my profession is an intel analyst. I’m ok with junk data because junk data tells me something (the owner of the domain is a liar, and I should be weary). Also, even intelligence agencies have a hard time generating truly random but believable data. We were able to use information reuse (even though it was junk info) to track and enumerate election information operations. 

—
John Bambenek

---

From: Steve Crocker <[email-masked]>
Date: Mon, 8 Jul 2019 17:52:40 -0400

John and Bill,

Let me offer a slightly different perspective.  The proposal would provide
a way for domain name owners to publish information that they want
published, and it would, of course, be publicly available.

The pre-GDPR whois system collected contact information from registrants
irrespective of whether the registrant would have chosen to provide it.
That's a fundamentally flawed structure, i.e. the incentives are misaligned.

I'm not immediately persuaded the proposed solution, i.e. allowing
registrants to publish what they want via DNS records, will result in a
large amount of incorrect data.  What's the motivation to publish wrong
information as opposed to simply not publishing anything?  On the other
hand, it doesn't address the main issue under consideration these days, a
differentiated access system.  Thus, in my view, the proposal would provide
a solution to the easiest portion of the problem space and would not
address any of the deeper issues.

Steve

On Mon, Jul 8, 2019 at 5:45 PM Bill Woodcock <[email-masked]> wrote:

>
>
> > On Jul 8, 2019, at 2:38 PM, John Bambenek <jcb=
> [email-masked]> wrote:
> >
> > All-
> >
> > 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.
>
> Good in principle, but the information in whois has always been, at least
> nominally, third-party vetted.  This would not be.  So my worry is that
> either it would get no uptake, or it would get filled with bogus
> information.  It’s a little hard for me to imagine it being widely used for
> valid information, though that would of course be the ideal outcome.
>
> So, no problem with this in principle, but I’d like to see some degree of
> consensus that user-asserted content is sufficient for people’s needs.
>
>                                 -Bill
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 8 Jul 2019 16:52:52 -0500

On 2019-07-08 16:38 -0500, John Bambenek 
<jcb=[email-masked]> wrote:
> implementation putting these records into DNS TXT records.

Not all registered domains are published (no NS records), so what about 
those?

Also your proposal puts the onus of (valid) information publishing on 
the registrant of each domain, no more on the registrar or the registry, 
because
_whois.example.com is under the control of example.com and not under 
control of the registry under which example.com lives and neither its 
registrar as the DNS provider may not be the registrar.

So what did I not understand about who controls and where do the 
_whois.example.com RRs exist?

As for:
"This means that if a domain owner were compromised,
    someone else has contact information to get in touch with the true
    own to organize remediation."
It depends on how you define "domain owner were compromised".
This could as well mean "have access to registrar panel to configure 
this domain" which in turns means "being able to put whatever 
nameservers, and hence DNS records as one wishes". But you may be 
relying on the TTLs of old records?
(a point not discussed I think; would long TTLs be good for those records?).

Also, a similar idea was floated on the regext mailing list sometimes ago:
https://www.ietf.org/archive/id/draft-brown-whoami-02.txt
This was using well known URIs to publish whois data and the URI DNS RR.
-- 
Patrick Mevzek

---

From: John Bambenek <[email-masked]>
Date: Mon, 8 Jul 2019 17:01:07 -0500

Like I said, I’m ok with someone lying to me. Its easy to detect and easy to deal with. For instance, in DNS a mailserver could query these records, see phone number is set to 0000000000 and then just reject email from said domain. With existing whois that was never possible, due to rate limiting. 

The domain registrant system issue was easy to solve. Make private domain registrations free for everyone who wanted it. That solution was rejected out of hand be registries and registrars at ICANN. Likely because they want the system to die entirely. Differentiated access sounds nice, but those who govern such things have made clear it will the differentiation is “do you have a court order”. I’ve been party to those discussions and my view is that the multi-stakeholder model isn’t going to work. 

The fundamental issue is voluntary interconnection. If you want to connect to me, I should have a programmatic way to get something about you to make that decision. You can publish nothing if you want, or publish fake info. And I can do what I want with it. 

But having been part of the conversation at ICANN, I have zero confidence that RDAP or any other system will ever be deployed in a meaningful way to get access to this data. Hence this proposal, which I harbor no illusions is a second-best to an independent third party making this available in a way usable by systems in a programmatic fashion. The best way just isn’t going to happen. 

—
John Bambenek

On Jul 8, 2019, at 16:52, Steve Crocker <[email-masked]> wrote:

> John and Bill,
> 
> Let me offer a slightly different perspective.  The proposal would provide a way for domain name owners to publish information that they want published, and it would, of course, be publicly available.
> 
> The pre-GDPR whois system collected contact information from registrants irrespective of whether the registrant would have chosen to provide it.  That's a fundamentally flawed structure, i.e. the incentives are misaligned.
> 
> I'm not immediately persuaded the proposed solution, i.e. allowing registrants to publish what they want via DNS records, will result in a large amount of incorrect data.  What's the motivation to publish wrong information as opposed to simply not publishing anything?  On the other hand, it doesn't address the main issue under consideration these days, a differentiated access system.  Thus, in my view, the proposal would provide a solution to the easiest portion of the problem space and would not address any of the deeper issues.
> 
> Steve
> 
>

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 8 Jul 2019 15:04:00 -0700

> On Jul 8, 2019, at 2:47 PM, John Bambenek <jcb=[email-masked]> wrote:
> 

It’s also worth remembering that forward and reverse work very differently in this regard, and the RIRs haven’t given up the whois fight yet.  They do strong vetting (requiring articles of incorporation, tracking down and eliminating fraudulent entries, etc.) that’s not done in the forward DNS space.

So now you’d have the potential for conflicting RIR-provided and user-provided whois information in the reverse space.  Again, not a reason not to do this, but a word of caution that it’ll make the world a slightly more complicated place.

> That said, my profession is an intel analyst. I’m ok with junk data because junk data tells me something (the owner of the domain is a liar, and I should be weary). Also, even intelligence agencies…

Oh, I think we’re all a little weary by now.  :-)

Yes, I take your point and agree that bad data is significantly better than no data, if it’s all taken with the appropriate grain of salt.

---

From: John Bambenek <[email-masked]>
Date: Mon, 8 Jul 2019 17:05:59 -0500

For domains with no NS records? Who cares, they aren’t in actual use. (Or if they are something is broken or more likely malicious so block it). 

Yes, the onus is on domain owners (and that requires consensus and adoption which are not given but why its being brought up here). The registrars and registries don’t want it and won’t accept it (see other email). 

As to your last point, yes, whoever can modify DNS owns these records and if compromised means you can’t trust it in real time (but passive DNS helps solve this). Its distinct from a web server which means “most” of the time you have to compromise two separate systems. What is best is independent third-party verification but we don’t get that and we won’t. So, here we are. 

—
John Bambenek

On Jul 8, 2019, at 16:52, Patrick Mevzek <[email-masked]> wrote:

> 
> 
> 
> 
>> On 2019-07-08 16:38 -0500, John Bambenek <jcb=[email-masked]> 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.
> 
> Not all registered domains are published (no NS records), so what about those?
> 
> Also your proposal puts the onus of (valid) information publishing on the registrant of each domain, no more on the registrar or the registry, because
> _whois.example.com is under the control of example.com and not under control of the registry under which example.com lives and neither its registrar as the DNS provider may not be the registrar.
> 
> So what did I not understand about who controls and where do the _whois.example.com RRs exist?
> 
> As for:
> This could as well mean "have access to registrar panel to configure this domain" which in turns means "being able to put whatever nameservers, and hence DNS records as one wishes". But you may be relying on the TTLs of old records?

---

From: John Bambenek <[email-masked]>
Date: Mon, 8 Jul 2019 17:07:15 -0500

Yes, bifurcation of whois is a problem. I’d rather it all be in one place, but that door was closed and not by me. 

—
John Bambenek

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 8 Jul 2019 15:09:26 -0700

> On Jul 8, 2019, at 2:52 PM, Steve Crocker <[email-masked]> wrote:
> I'm not immediately persuaded the proposed solution, i.e. allowing registrants to publish what they want via DNS records, will result in a large amount of incorrect data.  What's the motivation to publish wrong information as opposed to simply not publishing anything?

A few years ago, we’d have said the same thing about signatures on PGP public keys, right?

The problem is that as the number of people connected to the Internet grows, the likelihood that there will be at least one person prone to graffiti, that is, vandalizing an unprotected system simply for the purpose of vandalism, not out of any other motivation, approaches one.

> Thus, in my view, the proposal would provide a solution to the easiest portion of the problem space and would not address any of the deeper issues.

Yes, I think that’s true.  But it doesn’t necessarily militate against moving this forward.  If it solves some problems for some people, and doesn’t hurt anyone else, that’s sufficient.

                                -Bill

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 8 Jul 2019 17:14:54 -0500

On 2019-07-08 17:05 -0500, John Bambenek <[email-masked]> 
wrote:> For domains with no NS records? Who cares, they aren’t in actual 
use. (Or if they are something is broken or more likely malicious so 
block it).

They could be (in use), at some point. See past "fast flux" cases.

WHOIS was invented to be able to contact "someone" for any kind of 
problems, technical or administrative. A domain not having NS records 
may be a technical problem, or not, but if it is a problem who to 
contact if that information lives in the DNS itself?

> Yes, the onus is on domain owners (and that requires consensus and adoption which are not given but why its being brought up here).

So you are expecting registrants to abide by this, and then all DNS 
providers to update their web interface so that people will be able to 
enter those records? What incentives will they all have to do that?

I am probably less optimist than you.

But my understanding is that it seems you are trying to publish some 
data to derive some "reputation" based on it, instead of really data to 
be able to contact people. They are different goals probably.
-- 
Patrick Mevzek

---

From: John Bambenek <[email-masked]>
Date: Mon, 8 Jul 2019 17:23:40 -0500

If there is no auth NS there is no whois. Acceptable limitation. 

In short term, no incentives. My hope is to get consensus, make it an RFC, then start encouraging auditors and the like to flag on it. But yes, it needs some critical mass of adoption or its just another idea on paper. 

Reputation and contact-ability intersect in this use case in my mind. 

—
John Bambenek

On Jul 8, 2019, at 17:14, Patrick Mevzek <[email-masked]> wrote:

> On 2019-07-08 17:05 -0500, John Bambenek <[email-masked]> wrote:> For domains with no NS records? Who cares, they aren’t in actual use. (Or if they are something is broken or more likely malicious so block it).
> 
> WHOIS was invented to be able to contact "someone" for any kind of problems, technical or administrative. A domain not having NS records may be a technical problem, or not, but if it is a problem who to contact if that information lives in the DNS itself?
> 
> So you are expecting registrants to abide by this, and then all DNS providers to update their web interface so that people will be able to enter those records? What incentives will they all have to do that?
> 
> But my understanding is that it seems you are trying to publish some data to derive some "reputation" based on it, instead of really data to be able to contact people. They are different goals probably.
> -- 
> Patrick Mevzek
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Jul 2019 21:01:43 -0400 (EDT)

On Mon, 8 Jul 2019, John Bambenek wrote:

An interresting idea, but ....

>   contact information exchange.

It's not really reliable in the case of malicious DNS. The point for me
for using whois is hardly ever to find a domain contact, but to find
a way to step beyond the malicious registrant. WHOIS/RDAP lets me jump
to the Registrar.

In the case where you would want to reach the domain for non-malicious
purposes, a contact form on their website or using the SOA record email
address would (and does) work fine.

Appendix A and the Copyright notice at the top conflict or repeat.

As for some technical points:

- The WHOIS/RDAP can be rate limited, DNS queries can't.
- WHOIS can be recorderd historically, for DNS queries this is much
   harder to do - especially if domains use a TTL=0 as default that
   also applies to these records.
- One cannot know where zone cuts are (public suffix problem), so
   mis-redirection can happen
- Which is more secure/valuable, the topmost _whois entries or the lower
   ones? eg _whois.toronto.nohats.ca or _whois.nohats.ca.

- Use example.com, not exampledomain.com (see RFC 2606)

- sub-types in TXT records

You put everything under _whois.example.com but then use sub-typing
within the TXT record. Wouldn't it be better to use the prefix instead
of subtyping,eg:

 	_name._admin._whois.example.com IN TXT "Dan Draper"
 	_tel._admin._whois.example.com IN TXT "+1-555-123-4567"
 	_name._billing._whois.example.com IN TXT "Peggy Olson"
 	_email._techical._whois.example.com IN TXT "[email-masked]"

This would avoid awkward references to "aname" (which might become an
RRTYPE) or "tname", etc.

- The use of "all" is also a bit awkward.

In the end, I feel this effort shares most of its issues with the
"security.txt" efforts of https://tools.ietf.org/html/draft-foudil-securitytxt
which I also thought was not a good idea. See the various discussions
on the saag list there for details on trustworthiness of information,
and the multiple locations of information problem, which are problems
present here as well.

Paul

---

From: John Bambenek <[email-masked]>
Date: Mon, 8 Jul 2019 20:32:30 -0500

Below

—
John Bambenek

> a way to step beyond the malicious registrant. WHOIS/RDAP lets me jump

Reliable for what use case? Creating benevolent data artificially is hard. 

Whois/rdap WOULD let you jump to the registrar, but all the data will be redacted and odds are we won’t get access at all anyway. 

> address would (and does) work fine.

If the website is owned, the contact form can’t be trusted. I know of no one who uses SOA for anything other than tracking and correlating domains. Odds are for the overwhelming majority of domains, SOA points to registrar or a non-existent or unmonitored mailbox. 

> Appendix A and the Copyright notice at the top conflict or repeat.

Will fix. 

> - The WHOIS/RDAP can be rate limited, DNS queries can't.

This is a feature, not a bug. 

>  also applies to these records.

Whois CAN be recorded historically, but that data is inaccessible until DomainTools came along. In response, the registrars and registries (who consider Domaintools a criminal operation but oddly the criminals using their service they regard as clients) have used the smoke of GDPR to simply redact everything in whois. 

>  mis-redirection can happen

Similar with whois today, no?

>  ones? eg _whois.toronto.nohats.ca or _whois.nohats.ca.

Most specific, assuming you want toronto.nohats.ca as opposed to nohats.ca. But this is possible in DNS. It is not in whois. 
> - Use example.com, not exampledomain.com (see RFC 2606)

Ok will fix. 
> This would avoid awkward references to "aname" (which might become an

Valid feedback. Submitting an I-D was the starting point to finalize a standard. It can be done any number if ways, in theory. The point is to come up with some consensus that makes sense. 

> - The use of "all" is also a bit awkward.

Recommendation?

---

From: william manning <[email-masked]>
Date: Mon, 8 Jul 2019 21:26:26 -0700

you mean something like this?

https://www.isi.edu/division7/publication_files/novel_use.htm

On Mon, Jul 8, 2019 at 2:39 PM John Bambenek <jcb=
[email-masked]> wrote:

> All-
>
> In response to ICANN essentially removing most of the fields in WHOIS for
> domain records, Richard Porter and myself created a draft of an
> URL:
> https://www.ietf.org/internet-drafts/draft-bambenek-porter-dnsop-whois-over-dns-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bambenek-porter-dnsop-whois-over-dns/
> Htmlized:
> https://tools.ietf.org/html/draft-bambenek-porter-dnsop-whois-over-dns-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-bambenek-porter-dnsop-whois-over-dns
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-bambenek-porter-dnsop-whois-over-dns-01
>
> Abstract:
> 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
> [email-masked] for details

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 9 Jul 2019 12:09:49 +0200 (CEST)

> Il 9 luglio 2019 00:01 John Bambenek <jcb=[email-masked]> ha scritto:
> 
> 
> Like I said, I’m ok with someone lying to me. Its easy to detect
> and easy to deal with. For instance, in DNS a mailserver could 
> query these records, see phone number is set to 0000000000 and 
> then just reject email from said domain. With existing whois that 
> was never possible, due to rate limiting.

At first sight, your proposal looked ok - if someone wants to publish their information voluntarily, why not? But then I read this and now I am seriously concerned: it looks like this is explicitly being designed to penalize registrants that care about their privacy and choose not to publish information about themselves (or publish fake information, which used to be the only practical way in the old mandatory Whois times).

> The domain registrant system issue was easy to solve. Make 
> private domain registrations free for everyone who wanted it.
> That solution was rejected out of hand be registries and 
> registrars at ICANN. Likely because they want the system to die 
> entirely. Differentiated access sounds nice, but those who govern
> such things have made clear it will the differentiation is “do 
> you have a court order”. I’ve been party to those discussions and
> my view is that the multi-stakeholder model isn’t going to work.

Your frustrations are understandable, and personally I hope that ICANN manages to set up a usable differentiated access system soon and I even contributed some ideas to it. However, basically what you are saying is that you are not happy with the result of the policy development process in the proper place (i.e. ICANN), so you are now trying to use the IETF to bypass that consensus. Is this really the right thing to do for the IETF?

> The fundamental issue is voluntary interconnection. If you want
> to connect to me, I should have a programmatic way to get 
> something about you to make that decision. You can publish 
> nothing if you want, or publish fake info. And I can do what I
> want with it.

I understand this viewpoint, I'm not saying it does not make sense, but this looks too much like the email authentication stuff that has made it increasingly difficult to run independent mail servers and still get your messages accepted by the big platforms. If between "you" and "the entity that wants to connect to you" there is a fundamental difference in size and power, this becomes a way for you to force the other party into whatever you want - it is not a peer relationship any more. So, before proceeding with this (if ever), some thoughts should be given to potential centralizing effects and how to deal with them.

--
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 07:50:57 -0500

Below

—
John Bambenek

> At first sight, your proposal looked ok - if someone wants to publish their information voluntarily, why not? But then I read this and now I am seriously concerned: it looks like this is explicitly…

One use case is to create reputational data. Punish is an interesting word, it assumes one has the right to access another parties resources. They do not. A fundamental principle of the internet is voluntary interconnection. I can deny access to anyone at any time, for any reason I wish. 

> Your frustrations are understandable, and personally I hope that ICANN manages to set up a usable differentiated access system soon and I even contributed some ideas to it. However, basically what…

I have contributed ideas to it. It has been made clear the differentiation will be “do you have a court order or not” which means the system will assuredly be useless. 

If there were a serious policy development process at ICANN, you’d have a point. 

That said, this isn’t about policy this is about a protocol. If someone wanted to publish information, this is a means to do it. IETF can’t make anyone do anything. This could be an RFC tomorrow and everyone could ignore it. The same way if someone got fed up with HTTP, they could make a different protocol and submit it here. 

> I understand this viewpoint, I'm not saying it does not make sense, but this looks too much like the email authentication stuff that has made it increasingly difficult to run independent mail serve…

Not unfair, but the ease of implementation of these methods is far simpler than, say DKIM.

---

From: Jim Reid <[email-masked]>
Date: Tue, 9 Jul 2019 14:32:19 +0100

> 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.…

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.

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 09:07:51 -0500

Below

—
John Bambenek

> 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.…

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 pub…

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.…

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…

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 b…

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…

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.

---

From: Bjarni Rúnar Einarsson <[email-masked]>
Date: Tue, 09 Jul 2019 14:15:12 -0000

Hello everyone,

Jim Reid <[email-masked]> wrote:
> 
> 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.

Implementation details aside, I think having a technical
specification like this would be quite interesting from the point
of view of automatically updates to existing Whois databases,
without requiring the registrant directly (or indirectly)
interact with complex APIs or provider-specific web interfaces.

Much like CDS for DS records, and CSYNC for NS records, having a
well defined vocabulary for this data in DNS could be a useful
step towards such automation. Assuming a cautious implementation,
this need not make whois any less reliable.

So, that's a potential use-case which I haven't seen mentioned
here yet.

That said, I agree it cannot solve GDPR or other policy concerns.

Also, I really don't see this data as meaningfully useful in
fighting abuse, if only because it's very unlikely to see wide
adoption in the near future, and because it will be incredibly
easy to just create plausible looking (or maliciously
Joe-jobbing) fake records. This will largely boil down to 2 bits
of information: "did someone in the domain's chain of tools &
admins decide to implement this standard?" and "did anybody
decide to fill out the relevant forms?" - neither of which are
meaningful when combating abuse. I am extremely skeptical of any
claims that there's more information to be extracted here.

The fact that it will be easier to programmatically look up this
information seems to me unlikely to actually make things better,
I see it mostly adding complexity and more GI for the GO. Just my
opinion, obviously.

But I remain vaguely excited about the potential for automation!

Cheers,
 - Bjarni

- -- 
Sent using Mailpile, Free Software from www.mailpile.is

---

From: David Waitzman <[email-masked]>
Date: Tue, 9 Jul 2019 10:21:14 -0400

To go along with this proposal, maybe we can adapt the approach from RFC3514 for DNS?
We could send a new RRTYPE with a bitfield value, giving a more granular level of detail than that in RFC3514.  RFC3514 was constrained to only use one bit because IP headers are small; with DNS, we don't have the same level of constraint.

I would suggest that responses for all new GTLDs have the bit for "evil" set to 1, unless responses are sent via RFC1149, in which case they'd merit a default of 0.

On Jul 9, 2019, at 05:09, Vittorio Bertola <vittorio.bertola=[email-masked] <mailto:vittorio.bertola=[email-masked]>> wrote:
> 
>> Il 9 luglio 2019 00:01 John Bambenek <jcb=[email-masked] <mailto:jcb=[email-masked]>> ha scritto:
>> 
>> 

-david waitzman

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Jul 2019 10:25:33 -0400

> 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 work…

The principal reason for standardising this behaviour is presumably to allow and promote interoperability.

Interoperability is required for there to be a useful, common framework for general data exchange: that is, data exchange between parties on a scale or of a kind that precludes simple, bilateral agreement. To me, that's indistinguishable from policy. The idea of both the IETF and ICANN working on different policies for disseminating this kind of information is simply a headache. The conversation is already difficult; I think there is harm in making it more difficult.

I agree with pretty much everything else Jim said, but really this seems like the core issue: this seems like a proposal in the wrong venue.

I also agree that without any widespread incentive to implement, test and maintain, the data is going to be noisy and sparse to the point where it's useless for any practical use anyway.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Jul 2019 10:28:51 -0400

On Jul 9, 2019, at 10:07 AM, John Bambenek <jcb=[email-masked]> wrote:
> But ICANN won’t allow such a system with meaningful data, so here we are. 

The question you should be asking is “why not?”   The answer is that nobody whose info you need will publish it, because the info you need is from people who are engaging in misfeasance or malfeasance.  The people who will publish accurate information here are likely naive, so you’ve really just created a vuln that bad actors can exploit.

You can’t use the fact that no information, or false information, is provided as a basis for seeking out bad actors, because any sensible person will not put their information in this database unless they have to to get something they need.  If they have to to get something they need, they will likely put in false information, because they have no legal obligation to do otherwise, and putting in correct information would not be in their interests.   So all you’ve done here is create two attack surfaces.

The first attack is against people who are naive: you now have personal information about them that they shouldn’t have given you.   The second attack is that you can use the fact that someone posts false information, or doesn’t provide information, as a pretext for investigating them.

If you genuinely think this is worth doing, please come up with a real-world use case that meets the following three criteria:

It would be in my interest to put information about myself in this database
That information would be useful to you, or to someone specific whom you can identify
My participation in, or non-participation in, this mechanism is entirely voluntary, and can’t be used against me

You haven’t done that yet.  If this depends on people acting against their own interests, we shouldn’t publish it.  If it solves a paper problem but isn’t actually useful, we shouldn’t publish it.  It needs to solve a real problem in a way that is ethical.   I don’t think it does.

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 09:36:50 -0500

Below

> I agree with pretty much everything else Jim said, but really this seems like the core issue: this seems like a proposal in the wrong venue.

If the proposal is to create a standard by which to put contact
information into DNS records, what venue would you suggest?

> I also agree that without any widespread incentive to implement, test and maintain, the data is going to be noisy and sparse to the point where it's useless for any practical use anyway.

You could say the same for SPF.

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 9 Jul 2019 11:37:56 -0300

I like the overall idea, but I believe we should let go the name WHOIS. What about "_contact" for the fields instead of "_whois" ? 
I like the All record as an option. 

I don't agree with your reasoning for this, but we can agree on something to be done for different reasons, too. 

I understand the limitation for domains without DNS servers, or with DNS servers but in clientHold or serverHold status, but I don't think they make this less useful since in most cases where people want to be contacted, they have the domain up. 

What are the interactions between possible record sizes, DNS fragmentation, DNS over TCP blocking ? This might be worthy discussing in the draft. 

Rubens

> Em 8 de jul de 2019, à(s) 18:38:000, John Bambenek <jcb=[email-masked]> escreveu:
> 
> All-
> 
> URL:            https://www.ietf.org/internet-drafts/draft-bambenek-porter-dnsop-whois-over-dns-01.txt <https://www.ietf.org/internet-drafts/draft-bambenek-porter-dnsop-whois-over-dns-01.txt>
> Status:         https://datatracker.ietf.org/doc/draft-bambenek-porter-dnsop-whois-over-dns/ <https://datatracker.ietf.org/doc/draft-bambenek-porter-dnsop-whois-over-dns/>
> Htmlized:       https://tools.ietf.org/html/draft-bambenek-porter-dnsop-whois-over-dns-01 <https://tools.ietf.org/html/draft-bambenek-porter-dnsop-whois-over-dns-01>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-bambenek-porter-dnsop-whois-over-dns <https://datatracker.ietf.org/doc/html/draft-bambenek-porter-dnsop-whois-over-dns>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-bambenek-porter-dnsop-whois-over-dns-01 <https://www.ietf.org/rfcdiff?url2=draft-bambenek-porter-dnsop-whois-over-dns-01>
> 
> Abstract:
> 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 [email-masked] <mailto:[email-masked]> for details

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 09:45:05 -0500

Below

On 7/9/19 9:28 AM, Ted Lemon wrote:
> On Jul 9, 2019, at 10:07 AM, John Bambenek
> <jcb=[email-masked]
> <mailto:jcb=[email-masked]>> wrote:
> The question you should be asking is “why not?”   The answer is that
> nobody whose info you need will publish it, because the info you need
> is from people who are engaging in misfeasance or malfeasance.  The
> people who will publish accurate information here are likely naive, so
> you’ve really just created a vuln that bad actors can exploit.

Why ICANN won't? The answer is not that altruistic.

If there are incentives they will, yes, wide spread adoption is a
problem, but define accurate? Role-based accounts are fine here (some of
which, I believe are codified in RFCs already). If you'd like, I can get
you the anti-spam people to chime in on their thoughts about how much
abuse would happen compared to how much anti-abuse would be facilitated
given adoption.

> You can’t use the fact that no information, or false information, is
> provided as a basis for seeking out bad actors, because any sensible
> person will not put their information in this database unless they
> have to to get something they need.  If they have to to get something
> they need, they will likely put in false information, because they
> have no legal obligation to do otherwise, and putting in correct
> information would not be in their interests.   So all you’ve done here
> is create two attack surfaces.
>
I most certainly can and do use no information and false information for
making policy decisions. In fact, so do you and everyone here, every
day. Would you give you credit card information over the phone when
receiving a call with no caller ID?
> The first attack is against people who are naive: you now have
> personal information about them that they shouldn’t have given you.  
> The second attack is that you can use the fact that someone posts
> false information, or doesn’t provide information, as a pretext for
> investigating them.
>
You're making an assumption that people SHOULDN'T ever give contact
information. That's not true. Every business puts their contact
information their website. They WANT to be contact. Individuals often
will do the same. On twitter, journalists routinely put their phone numbers.

As far as pretext for "investigating people", as long as I break no
laws, I can't investigate anyone for anything I want at any time I want
for any reason I want. So can you. But that's not the question here.
Voluntary interconnection is. I can deny people access to my resource
for any reason I want.

> If you genuinely think this is worth doing, please come up with a
> real-world use case that meets the following three criteria:
>
>   * It would be in my interest to put information about myself in this
>     database
>
You'd want me (or others) to let you know about compromises, for one.
DMARC does this already, in a sense. I get email reports about potential
abuse of my domain and spoofing emails. To do this, it needs an email. I
get something. But wide-spread adoption is the risk, I don't make any
illusions of that.
>
>   * That information would be useful to you, or to someone specific
>     whom you can identify
>
I can provide lots of use cases and provide others who will attest to
the same. Victim notification, correlation of domains and resources,
investigations, generating reputational data...

>   * My participation in, or non-participation in, this mechanism is
>     entirely voluntary, and can’t be used against me
>
There is no protocol, communication, human endeavor where this will be
every true as far as "not used against me". DNS records is entirely
voluntary now. You control what you put or don't put in there, no one is
changing that. But using it against you or not, someone could use the
fact you are running an IIS web server against you.
>
> You haven’t done that yet.  If this depends on people acting against
> their own interests, we shouldn’t publish it.  If it solves a paper
> problem but isn’t actually useful, we shouldn’t publish it.  It needs
> to solve a real problem in a way that is ethical.   I don’t think it does.
Exactly what ethical standard do you claim is violated here? And if the
answer is that you have some unfettered right to access my network
resources, that is simply false.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 09 Jul 2019 14:46:36 +0000

On Tuesday, 9 July 2019 14:36:50 UTC John Bambenek wrote:
> ...

john, (all,) my own prior review of this proposal was effectively neutral but 
actually negative. dns does not permit the kind of rate limiting and logging 
needed by individual domain holders around their whois details unless they 
operate their own authority servers, which is rare these days.

i would prefer to see a SRV RR at _whois._tcp.$apex, and a separate service 
running on the designated server(s) to actually provide the whois information. 
i believe there's a JSON or similar encoding now, to make it machine readable.

i'd like to know who fetches my registration information, and how often. some 
friend with whom i exchange secondary name services will likely not thank me 
for asking to see their dnstap output, or to run my preferred DNS RRL config.

-- 
Paul

---

From: Jim Reid <[email-masked]>
Date: Tue, 9 Jul 2019 15:47:01 +0100

> On 9 Jul 2019, at 15:15, Bjarni Rúnar Einarsson <[email-masked]> wrote:
> 
> I think having a technical specification like this would be quite interesting from the point of view of automatically updates to existing Whois databases, without requiring the registrant directly (or indirectly) interact with complex APIs or provider-specific web interfaces.

Interesting in the sense that novichok is interesting? :-)

DNS and whois are very different protocols which get used and abused for very different things. I'm struggling to understand why they should be coupled like this or what problem(s) would get solved by doing that.

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 09:49:06 -0500

> So, that's a potential use-case which I haven't seen mentioned
Good view point, will consider.
> That said, I agree it cannot solve GDPR or other policy concerns.
Why? GDPR applies to IP addresses, that doesn't impact DNS yet. Contact
info can be on a webpage, why not in DNS as long as I am the one putting
it there (also bear in mind, role-based information is fine, thus you
can put non-PII records there, or nothing at all).
> Joe-jobbing) fake records. 

I'm genuinely curious of something. The most I've engaged in this debate
about WHOIS records and what is or is useful in fighting abuse, the
opinions of those who actually fight abuse for a living are discarded a
priori. This is WHAT I DO. I can give you hundreds of others. We are in
near unanimous consent that this information is valuable in fighting
abuse EVEN WHEN ITS FAKE. And as someone who knows a thing or two about
deception, creating plausible fake records are a harder problem than you
think.

> This will largely boil down to 2 bits
I harbor no illusion, it depends on adoption. Agreeing on a standard is
the first step. If there is no standard, there can be no meaningful
adoption. Putting adoption before setting a standard is to ensure
failure from the start.

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 09:50:49 -0500

I'm not married to any name, I chose WHOIS for historical reasons. We
can call it _hamsandwich if it builds consensus.

On 7/9/19 9:37 AM, Rubens Kuhl wrote:
>
> I like the overall idea, but I believe we should let go the name
> WHOIS. What about "_contact" for the fields instead of "_whois" ? 
> I don't agree with your reasoning for this, but we can agree on
> something to be done for different reasons, too. 
>
> I understand the limitation for domains without DNS servers, or with
> DNS servers but in clientHold or serverHold status, but I don't think
> they make this less useful since in most cases where people want to be
> contacted, they have the domain up. 
>
> What are the interactions between possible record sizes, DNS
> fragmentation, DNS over TCP blocking ? This might be worthy discussing
> in the draft. 
>
>
> Rubens
>
>
>
>
>> Em 8 de jul de 2019, à(s) 18:38:000, John Bambenek
>> <mailto:jcb=[email-masked]>> escreveu:
>>
>> All-
>>
>> 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. 
>>
>> [email-masked] <mailto:[email-masked]>
>> for details
>> [email-masked] <mailto:[email-masked]>

---

From: Jim Reid <[email-masked]>
Date: Tue, 9 Jul 2019 16:05:36 +0100

> On 9 Jul 2019, at 15:50, John Bambenek <jcb=[email-masked]> wrote:
> 
> I'm not married to any name, I chose WHOIS for historical reasons. We can call it _hamsandwich if it builds consensus.

The concern here isn't what the label is called. Prepending a label won't work with absurdly long domain names because the maximum length of a domain name will be exceeded. That gives bad actors another way of not complying. Not that they would ever provide accurate contact data anyway.

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Jul 2019 11:07:15 -0400

Hi John,

> information into DNS records, what venue would you suggest?

I think that the protocol aspects of this are the least difficult ones. If this is fundamentally the data governance issue that I think it is, I think it would make a lot more sense to align exactly with what is happening in RDAP, treating self-publication as a new profile and DNS as a possible transport. If there's data to publish, thinking about transport afterwards seems far more sensible than inventing a transport and hoping that the data will follow.

RDAP profiles are not being discussed in the IETF. I think this is a feature.

> You could say the same for SPF.

There's an operational incentive to publish SPF records: the need for recipients to accept legitimate mail that is being sent. I don't know what the operational incentive is to publish "whois" data in zone files.

Joe

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 10:07:40 -0500

This is true with DKIM today which uses a label.

---

From: Bjarni Rúnar Einarsson <[email-masked]>
Date: Tue, 09 Jul 2019 15:07:48 -0000

Hi :-)

John Bambenek <[email-masked]> wrote:
> Why? GDPR applies to IP addresses, that doesn't impact DNS yet.

You appear to have confused IP with P(I)I: personally identifying
information.

All whois data is PII, in the case where people register
individual details, as opposed to organizational roles. I think
you may need to do a bit more research on this topic, you seem to
have misunderstood a thing or two.

> I'm genuinely curious of something. The most I've engaged in
> this debate about WHOIS records and what is or is useful in
> fighting abuse, the opinions of those who actually fight abuse
> for a living are discarded a priori.

I also have done this for a living. I expect everyone on this
list has, to a certain degree.

I guess what I'm saying is, I probably wouldn't buy what you're
selling.

Further, I agree with others that it's not our job to standardize
and encourage the kind of large scale self-doxxing such products
would undeniably benefit from. That would be to throw the
average-Joe under the bus, for the benefit of the minority who
decide to invest in such tools (whether they are actually
effective or not).

So this is me changing my mind, I don't think potential
automation use-cases justify this.

Cheers,
 - Bjarni

- --

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 10:09:41 -0500

Below

> I think that the protocol aspects of this are the least difficult ones. If this is fundamentally the data governance issue that I think it is, I think it would make a lot more sense to align exactl…
No more data governance than there is already in publishing records in
DNS today.
> There's an operational incentive to publish SPF records: the need for recipients to accept legitimate mail that is being sent. I don't know what the operational incentive is to publish "whois" data…
Once a critical mass of adoption happens, then a similar incentive...
the need for recipients to accept legitimate mail, for one.

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 10:14:11 -0500

> have misunderstood a thing or two.

One, IP addresses in some cases are PII (see here:
https://eugdprcompliant.com/personal-data/).

Two, in some cases whois data is NOT PII (i.e. role based accounts,
which are allowed here).

You could set contact info to "Mail Administrator" and
"[email-masked]" and that's fine here.

> decide to invest in such tools (whether they are actually
If you put personal information, that's your choice. If you put
role-based info, that's your choice. Same as what you post on twitter,
facebook, or whatever. This enables the choice to "self-dox" (something
I think is an odd formulation.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Jul 2019 11:21:51 -0400

As far as I can tell, you are deflecting my serious concerns rather than responding to them.   I’m asking you to describe an actual situation where the information you want us to publish would (a) be published and (b) actually work as a means of notifying some real person of something, or prosecuting some real crime.  I’m going to respond to what you’ve said to point out that it’s not serious, but I encourage you not to debate these points with me.  If your goal is actually to publish this draft, the right thing to do is come up with some good arguments why the IETF should publish it, not to get into a debate over details with me.

You respond:
> I most certainly can and do use no information and false information for making policy decisions. In fact, so do you and everyone here, every day. Would you give you credit card information over the phone when receiving a call with no caller ID?

Caller ID is always presumptively forged.  If you actually care about not being phished, you should never under any circumstances provide your credit card information over the phone if you didn’t initiate the phone call.   You shouldn’t even do it then, since telephone conversations aren’t encrypted end-to-end.

> You're making an assumption that people SHOULDN'T ever give contact information. That's not true. Every business puts their contact information their website. They WANT to be contact. Individuals often will do the same. On twitter, journalists routinely put their phone numbers.
> 
This isn’t actually true.  People who want anonymous contact do in fact publish information that people can use to contact them anonymously, which may be a phone number.   It’s also a straw man.  I’m not saying people shouldn’t ever give contact information.  I’m saying that people shouldn’t be held hostage in such a way that they are forced to _publish_ personal information in order to get services.
> As far as pretext for "investigating people", as long as I break no laws, I can't investigate anyone for anything I want at any time I want for any reason I want. So can you. But that's not the question here. Voluntary interconnection is. I can deny people access to my resource for any reason I want.
> 
Repressive regimes often use pretexts to justify their repressive activities.   It is to this that I am referring when I talk about this as an attack surface.  Maybe you never engage in improper policing, but we can’t assume that this is true everywhere where DNS is used.
> You'd want me (or others) to let you know about compromises, for one. DMARC does this already, in a sense. I get email reports about potential abuse of my domain and spoofing emails. To do this, it needs an email. I get something. But wide-spread adoption is the risk, I don't make any illusions of that.

There is no way in the world that I would ever publish my email address as a way to get notifications of compromise.  Not merely for privacy reasons, but because the spam rate on that email address would be astronomical, and so I’d never see them.

> I can provide lots of use cases and provide others who will attest to the same. Victim notification, correlation of domains and resources, investigations, generating reputational data…
> 
These are nearly all examples of ways this information will be used against me.  If you think victim notification is a good use case, can you describe in detail how that would work?
> There is no protocol, communication, human endeavor where this will be every true as far as "not used against me". DNS records is entirely voluntary now. You control what you put or don't put in there, no one is changing that. But using it against you or not, someone could use the fact you are running an IIS web server against you.
> 
It’s true that whenever I communicate with anyone, I create a risk for myself.  So doesn’t it make sense that I would want to control with whom I communicate, rather than broadcasting?

> Exactly what ethical standard do you claim is violated here? And if the answer is that you have some unfettered right to access my network resources, that is simply false.

That’s an interesting response, which suggests that you have a use case in mind.  The use case you have in mind is that you will deny service to people who do not publish this information.  This is exactly the attack surface I was describing earlier, and you’ve just said that you intend to use this attack.

Of course it’s your right to deny service to people who don’t identify themselves to you.  If you want to do that, the way you do that is by establishing a business relationship with them and refusing service to people with whom you have no business relationship.  It is not by creating a huge database of personal information accessible to everyone, and demanding that they publish their information in  this database.

---

From: Bjarni Rúnar Einarsson <[email-masked]>
Date: Tue, 09 Jul 2019 15:24:37 -0000

Hello,

John Bambenek <jcb=[email-masked]>
> "[email-masked]" and that's fine here.

This does not eliminate the GDPR concerns when people fail to do
this.

> role-based info, that's your choice.

You can't have it both ways. Elsewhere in this thread you suggest
that people will be coerced into providing this data, because
otherwise their e-mail won't get delivered. Sorry, but nope.

Thanks for all the fish,
 - Bjarni

- --

---

From: Jim Reid <[email-masked]>
Date: Tue, 9 Jul 2019 16:27:04 +0100

> > Why? GDPR applies to IP addresses that, doesn't impact DNS yet.

GDPR applies to *any* data which identifies a living European citizen.

If you think it only applies to IP addresses you are very badly mistaken. GDPR will also apply to anything in the DNS which happens to identify a living European citizen.

---

From: Steve Crocker <[email-masked]>
Date: Tue, 9 Jul 2019 11:38:15 -0400

> Folks,

Let me share a somewhat broader perspective.  I was chair of the ICANN
board for several years.  During that period, I attempted, without success,
to reset the dialog related to whois.  After I stepped off the board in
late 2017, I decided to take another run at the problem.  I've been working
q

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 10:41:39 -0500

Not intended to debate, per se.

On 7/9/19 10:21 AM, Ted Lemon wrote:
> As far as I can tell, you are deflecting my serious concerns rather
> than responding to them.   I’m asking you to describe an actual
> situation where the information you want us to publish would (a) be
> published and (b) /actually work/ as a means of notifying some real
> person of something, or prosecuting some real crime.  I’m going to
> respond to what you’ve said to point out that it’s not serious, but I
> encourage you not to debate these points with me.  If your goal is
> actually to publish this draft, the right thing to do is come up with
> some good arguments why the IETF should publish it, not to get into a
> debate over details with me.
>
> You respond:
>> I most certainly can and do use no information and false information
>> for making policy decisions. In fact, so do you and everyone here,
>> every day. Would you give you credit card information over the phone
>> when receiving a call with no caller ID?
>
> Caller ID is always presumptively forged.  If you actually care about
> not being phished, you should never under any circumstances provide
> your credit card information over the phone if you didn’t initiate the
> phone call.   You shouldn’t even do it then, since telephone
> conversations aren’t encrypted end-to-end.
I'd agree its preemptively forged. Then pick another example. If someone
came up to you on the street and demanded to see identification, you'd
say no. If they were wearing a police uniform and have a badge, you
might say yes (varies between jurisdictions).
> This isn’t actually true.  People who want anonymous contact do in
> fact publish information that people can use to contact them
> anonymously, which may be a phone number.   It’s also a straw man.
>  I’m not saying people shouldn’t ever give contact information.  I’m
> saying that people shouldn’t be held hostage in such a way that they
> are forced to _publish_ personal information in order to get services.
No one is holding anything hostage, I guess that's the thing I genuinely
don't get. Individuals are free to publish or communicate how they see
fit. I'm free to reject said communication. It's the other side of the
same coin. No one is forcing anything. If this proposal was universally
implemented, there still would be no force or hostage taking. On one
hand, I'm being told to show incentives, on the other told that such
incentives are coercive. I can't do both.
>> laws, I can't investigate anyone for anything I want at any time I
>> want for any reason I want. So can you. But that's not the question
>> here. Voluntary interconnection is. I can deny people access to my
>> resource for any reason I want.
>>
> Repressive regimes often use pretexts to justify their repressive
> activities.   It is to this that I am referring when I talk about this
> as an attack surface.  Maybe you never engage in improper policing,
> but we can’t assume that this is true everywhere where DNS is used.
I'm a private sector actor, improper policing is criminal. I can't
forsee, however, how a repressive regime could use a phone number in a
DNS record to commit human rights violations.
>> DMARC does this already, in a sense. I get email reports about
>> potential abuse of my domain and spoofing emails. To do this, it
>> needs an email. I get something. But wide-spread adoption is the
>> risk, I don't make any illusions of that.
>
> There is no way in the world that I would ever publish my email
> address as a way to get notifications of compromise.  Not merely for
> privacy reasons, but because the spam rate on that email address would
> be astronomical, and so I’d never see them.
Then don't, that's fine.
>> investigations, generating reputational data…
>>
> These are nearly all examples of ways this information will be used
> against me.  If you think victim notification is a good use case, can
> you describe in detail how that would work?

It's voluntary, if you don't want it, you won't get it. But there are
millions of websites compromised on the internet right now. We can only
clean them either if hosting providers just go in and do it (assuming
they have access), or somehow contact you in a low cost way and getting
you to do it. There exists no easy programmatic way to do this unless
the hosting providers want to get into that business, so the use case
doesn't really exist today.

That being said, the sticking point is "used against you". Anything you
do can be used against you online in deciding whether or not I want to
accept your packets. People block entire countries. That is their right
and how the internet was designed to work. I don't intend to deflect, I
intend to say I believe such a position runs counter to a fundamental
design principle of the internet.

I'd like information, for instance, to accurate and narrowly block bad
providers. In the absence of that data, all I have is provider
reputation. For instance, if you have a .pw or .tk TLD, you're just
blocked. You may be innocent, but if I can't specifically block, I have
to generally block, which means innocent people get dragged in. The
alternative is to not block and allow my constituents to more likely be
victims.

>> There is no protocol, communication, human endeavor where this will
>> be every true as far as "not used against me". DNS records is
>> entirely voluntary now. You control what you put or don't put in
>> there, no one is changing that. But using it against you or not,
>> someone could use the fact you are running an IIS web server against you.
>>
> It’s true that whenever I communicate with anyone, I create a risk for
> myself.  So doesn’t it make sense that I would want to control with
> whom I communicate, rather than broadcasting?
If you are e-mailing me, connecting to my webserver, etc, you want to
communicate with me... should I not have information with which to make
a decision to decide if that's ok? If the answer to this is no, then we
have an irreconcilable philosophical difference and that's ok, I just
disagree and there isn't much middle ground to be had there.
>> Exactly what ethical standard do you claim is violated here? And if
>> the answer is that you have some unfettered right to access my
>> network resources, that is simply false.
>
> That’s an interesting response, which suggests that you have a use
> case in mind.  The use case you have in mind is that you will deny
> service to people who do not publish this information.  This is
> exactly the attack surface I was describing earlier, and you’ve just
> said that you intend to use this attack.
More accurately, I will score it as part of one of many reputational
indicators if and only if a critical mass of adoption takes place for
the VERY small portion of the internet I have a say on. I'm not Google,
I have no power over even a rounding error of the overall network space.
>
> Of course it’s your right to deny service to people who don’t identify
> themselves to you.  If you want to do that, the way you do that is by
> establishing a business relationship with them and refusing service to
> people with whom you have no business relationship.  It is not by
> creating a huge database of personal information accessible to
> everyone, and demanding that they publish their information in  this
> database.

You assume I'm going to create a huge database, I am not. I would
envision doing something like if you send me email, try to connect, etc,
there is a DNS query for this information, much like there are queries
for DBLs, SPF et al, and score it in real time.

Or if doing abuse reporting, just programmatically look who an email and
then email whatever is given (assuming syntactically valid).

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Jul 2019 12:00:20 -0400

On Jul 9, 2019, at 11:41 AM, John Bambenek <jcb=[email-masked]> wrote:
> You assume I'm going to create a huge database, I am not. I would envision doing something like if you send me email, try to connect, etc, there is a DNS query for this information, much like there are queries for DBLs, SPF et al, and score it in real time.
> Or if doing abuse reporting, just programmatically look who an email and then email whatever is given (assuming syntactically valid).
> 

John, the DNS is the huge public database to which I am referring.  You don’t operate it.  You’re just proposing to require me to publish my private information in it in order to do business with you.

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 11:03:13 -0500

> This does not eliminate the GDPR concerns when people fail to do
How so?
> otherwise their e-mail won't get delivered. Sorry, but nope.

I cannot coerce anything. I represent nothing that represents even a
molecule of the network to coerce or enforce anything. I hope incentives
will be created, and those may be purely positive incentives (mails more
likely to be delivered, etc).

To put your argument in another way, I as someone who protects uses
should NOT have information with which I could potentially reliably
block malicious individuals could be another way to frame your position.
That's a position.

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 11:05:29 -0500

On 7/9/19 11:00 AM, Ted Lemon wrote:
> On Jul 9, 2019, at 11:41 AM, John Bambenek
>> envision doing something like if you send me email, try to connect,
>> etc, there is a DNS query for this information, much like there are
>> queries for DBLs, SPF et al, and score it in real time.
>>
>> Or if doing abuse reporting, just programmatically look who an email
>> and then email whatever is given (assuming syntactically valid).
>>
>
> John, the DNS is the huge public database to which I am referring.
>  You don’t operate it.  You’re just proposing to require me to publish
> my private information in it in order to do business with you.
>
I'm proposing a standard to publish certain information should you wish
to. There is nothing in this document to indicate anything is required.
In theory, I as a network operator could require some information in
order to allow you access to my network, that is the sole power I have
and this proposal doesn't change that.

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 11:08:40 -0500

> If you think it only applies to IP addresses you are very badly mistaken. GDPR will also apply to anything in the DNS which happens to identify a living European citizen.
You mistake my point, my point is that people publish IP addresses that
may refer to living European citizens and thus, is covered by GDPR. The
objections to WHOIS data in DNS apply just as much to IP addresses. So
if role-based info or self-disclosed personal info can't be in DNS
because GDPR, I'm curious as to why people think IP addresses can be?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Jul 2019 12:09:29 -0400

> likely to be delivered, etc).

This is why I keep asking you for a clear use case.   What you are describing here is a real problem.  The solution to that problem is not to publish everyone’s private information in a huge public database.

> block malicious individuals could be another way to frame your position.

Whether or not you should have this information has no bearing on whether it should be in a public database.  There are much better ways to solve this problem, which require no privacy violation at all.  Just as one example, if I establish mutual trust with everyone I’m corresponding with, then we can set up a mechanism whereby any mail from a source with which trust has not been established can be dropped automatically.   This does not require a public database with my personal identifying information.  It can probably even be done in such a way that you don’t have a map of who knows whom, although that’s a hard problem.  But even if it were done in such a way that it gave you, someone with whom I have a business relationship, private access to my contact graph, that would be much less bad than making all of my personal information public.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Jul 2019 12:12:41 -0400 (EDT)

On Tue, 9 Jul 2019, John Bambenek wrote:

>             You assume I'm going to create a huge database, I am not. I would envision doing something like if you send me
>             email, try to connect, etc, there is a DNS query for this information, much like there are queries for DBLs, SPF
>             et al, and score it in real time.
>
> John, the DNS is the huge public database to which I am referring.  You don’t operate it.  You’re just proposing to require me to
> publish my private information in it in order to do business with you.
> 
> I'm proposing a standard to publish certain information should you wish to. There is nothing in this document to indicate anything is
> required. In theory, I as a network operator could require some information in order to allow you access to my network, that is the sole
> power I have and this proposal doesn't change that.

Can you add a Human Rights Considerations section to your document as per https://tools.ietf.org/html/rfc8280 ?

Paul

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 11:17:39 -0500

On 7/9/19 11:09 AM, Ted Lemon wrote:
> On Jul 9, 2019, at 12:03 PM, John Bambenek
> This is why I keep asking you for a clear use case.   What you are
> describing here is a real problem.  The solution to that problem is
> not to publish everyone’s private information in a huge public database.
>
Everyone is not the scope. People who chose to is the scope. Heck,
"everyone" includes people who aren't domain operators also.

Use cases:

- Victim notification of compromised webpages or abuse reports.

- Use in reputational systems to better calibrate security policy to
trust "good" sources and mistrust "bad" sources.

- Aid in investigations, correlate malicious infrastructure, etc.

> Whether or not you should have this information has no bearing on
> whether it should be in a public database.  There are much better ways
> to solve this problem, which require no privacy violation at all.
>  Just as one example, if I establish mutual trust with everyone I’m
> corresponding with, then we can set up a mechanism whereby any mail
> from a source with which trust has not been established can be dropped
> automatically.   This does not require a public database with my
> personal identifying information.  It can probably even be done in
> such a way that you don’t have a map of who knows whom, although
> that’s a hard problem.  But even if it were done in such a way that it
> gave you, someone with whom I have a business relationship,
> /private/ access to my contact graph, that would be much less bad than
> making all of my personal information public.
>
It would be in a public database in one instance only:

Someone chooses to put it there.

Ok, if there is a better solution, I'm listening. I'm not hear to
mandate a path, I started a discussion. What technical mechanism can be
implemented that scales that can facilitate mutual trust with everyone
an organization corresponds with?

And again, this proposal doesn't require anything and it certainly
doesn't do a proposal for "all your personal information", there are
only four classes of OPTIONAL data: name, email, phone, address. And it
can be role-based information. You could presumably fill all four of
those out validly and expose NO personal information.

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 11:20:06 -0500

Yes, I can do that.

On 7/9/19 11:12 AM, Paul Wouters wrote:
>>             You assume I'm going to create a huge database, I am not.
>> I would envision doing something like if you send me
>>             email, try to connect, etc, there is a DNS query for this
>> information, much like there are queries for DBLs, SPF
>>             Or if doing abuse reporting, just programmatically look
>> who an email and then email whatever is given (assuming
>>             syntactically valid).
>>
>>
>>  You don’t operate it.  You’re just proposing to require me to
>> I'm proposing a standard to publish certain information should you
>> wish to. There is nothing in this document to indicate anything is
>> required. In theory, I as a network operator could require some
>> information in order to allow you access to my network, that is the sole
> Can you add a Human Rights Considerations section to your document as
> per https://tools.ietf.org/html/rfc8280 ?
>
> Paul

---

From: Steve Crocker <[email-masked]>
Date: Tue, 9 Jul 2019 12:26:52 -0400

Folks,

Let me share a somewhat broader perspective.  I was chair of the ICANN
board for several years.  During that period, I attempted, without success,
to reset the dialog related to whois.  After I stepped off the board in
late 2017, I decided to take another run at the problem.  I've been working
quietly with a small, excellent group to see if we can provide some useful
tools for assisting the community in thinking about the policy issues.  Our
first goal is to provide a policy framework for expressing the wide variety
of policies in this area, both existing and proposed.  We're not quite
ready to release this framework, but it's coming along and I hope to be
able to publish it shortly.  That said, I can share a few points.

   1.  "Whois" is a somewhat ill-fitting handle.  The policy problems
   extend beyond contact data to include quite few other types of data, some
   of which are inherently public such as the DNS records, some of which are
   inherently extremely sensitive such credit card numbers, and others which
   fall somewhere in between such as dates of registration and expiration.

   I'll also note that WHOIS arose in the days of the Arpanet, prior to the
   existence of the domain name system and prior to the Internet.  The admin
   and tech contacts referred to the people running the time-shared systems
   that were hosts on the Arpanet, and these contacts were published so they
   could reach each other.  Almost fifty years later and a millionfold
   expansion, it's not a surprise the original concepts are not a perfect fit.

   2. Of the various contacts that are usually published, only the
   registrant contact has any real meaning.  For most registrations, the admin
   and tech contacts have no agreed upon meaning.  By "an agreed upon meaning"
   I mean an explicit statement of the authority (what the contact may do) and
   responsibility (what the contact is supposed to do) so that both the
   contact and everyone who accesses the contact data would share the same
   understanding.

   One of the most important roles in the entire structure is the person
   who has the account with the registrar and therefore has direct, electronic
   control of all the data.  We use the term "account holder" for this role.
   It may or may not be the same as the registrant.

   Other contact data is occasionally published, e.g. billing contact,
   legal contact, etc.  While the meaning of these roles is alluded to in the
   name, there is usually nothing explicit about authority and responsibility.

   3. The policy issues related to all of this are quite tangled.  The
   registrar and the registrar are the primary parties involved.  The
   blazingly simple and obvious fact is that neither of these parties have any
   trouble with the accuracy or meaning of the data they share with
each other *that
   are related to the actual process of registration*.  The registrar is
   primarily concerned with getting paid and the registrant is primarily
   concerned with having his registration active.  The trouble comes from the
   many third parties who have developed practices and policies related to the
   registration data.  A full discussion of these multiple parties, their
   motivations and needs, and the wide variety of policy issues requires much
   more space and attention than is appropriate for this note and this thread,
   but a couple of specific points are relevant and worth emphasizing.

   4. It's important to separate (a) the definition of the data elements,
   (b) the policies governing who should have access to which data elements,
   and (c) the access mechanisms.  As I said in an earlier note, the proposal
   being discussed in this thread, viz to use DNS to publish contact data,
   speaks to only a small portion of the overall problem.  Because the
   proposed mechanism is DNS, the data will presumably be public and provided
   at the discretion of the registrant.   This is useful for some purposes,
   but it clearly does not address the larger policies issues of allowing
   different groups to have differing levels of access to various types of
   data.

   5. With respect to the role of the IETF, I agree the policy issues
   belong elsewhere.  That said, there is, I believe, a natural role for the
   IETF that matches one part of the current proposal.  All parties will
   benefit if there is a dictionary of the possible registration data
   elements.  As I suggested in point 1 above, the relevant data elements
   include more than just contact data.  And even with respect to contact
   data, a more precise definition of the various roles would be quite helpful.

   The distinction implied here is the separation of the definition of the
   data elements from the publication mechanism.

I would strongly support an effort within the IETF to create and maintain a
dictionary of registration data elements.  This would probably be in the
form of an IANA-maintained registry, with oversight from DNSOP.

Steve

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 9 Jul 2019 18:27:17 +0200 (CEST)

> Il 9 luglio 2019 16:36 John Bambenek <jcb=[email-masked]> ha scritto:
> 

You could try with ETSI... Seriously, the IETF in the past has already decided not to standardize certain technologies, as they could easily have been used to gain access to personal information and identify/track people on a mass scale, even with the blessing of law enforcement authorities and with the purpose of legitimate investigation activities. It would be weird now to work on a mechanism that could easily be used to coerce people to self-identify themselves in a global, public, automatically scrapable database to facilitate similar investigations.

--

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 11:42:23 -0500

I generally agree with this and have no problem deferring to an effort
to create a dictionary of registration data elements and agreed upon
definitions.

I gave serious thought to just making the current proposal have one
contact class, I kept several more for consistency with the legacy
system, but I'm not married to that.

On 7/9/19 11:26 AM, Steve Crocker wrote:
> board for several years.  During that period, I attempted, without
> success, to reset the dialog related to whois.  After I stepped off
> the board in late 2017, I decided to take another run at the problem. 
> I've been working quietly with a small, excellent group to see if we
> can provide some useful tools for assisting the community in thinking
> about the policy issues.  Our first goal is to provide a policy
> framework for expressing the wide variety of policies in this area,
> both existing and proposed.  We're not quite ready to release this
> framework, but it's coming along and I hope to be able to publish it
> shortly.  That said, I can share a few points.
>
>     extend beyond contact data to include quite few other types of
>     data, some of which are inherently public such as the DNS records,
>     some of which are inherently extremely sensitive such credit card
>     numbers, and others which fall somewhere in between such as dates
>     of registration and expiration.
>
>     I'll also note that WHOIS arose in the days of the Arpanet, prior
>     to the existence of the domain name system and prior to the
>     Internet.  The admin and tech contacts referred to the people
>     running the time-shared systems that were hosts on the Arpanet,
>     and these contacts were published so they could reach each other. 
>     Almost fifty years later and a millionfold expansion, it's not a
>     surprise the original concepts are not a perfect fit.
>
>     registrant contact has any real meaning.  For most registrations,
>     the admin and tech contacts have no agreed upon meaning.  By "an
>     agreed upon meaning" I mean an explicit statement of the authority
>     (what the contact may do) and responsibility (what the contact is
>     supposed to do) so that both the contact and everyone who accesses
>     the contact data would share the same understanding.
>
>     One of the most important roles in the entire structure is the
>     person who has the account with the registrar and therefore has
>     direct, electronic control of all the data.  We use the term
>     "account holder" for this role.  It may or may not be the same as
>     the registrant.
>
>     Other contact data is occasionally published, e.g. billing
>     contact, legal contact, etc.  While the meaning of these roles is
>     alluded to in the name, there is usually nothing explicit about
>     authority and responsibility.
>
>     blazingly simple and obvious fact is that neither of these parties
>     have any trouble with the accuracy or meaning of the data they
>     share with each other _that are related to the actual process of
>     registration_.  The registrar is primarily concerned with getting
>     paid and the registrant is primarily concerned with having his
>     registration active.  The trouble comes from the many third
>     parties who have developed practices and policies related to the
>     registration data.  A full discussion of these multiple parties,
>     their motivations and needs, and the wide variety of policy issues
>     requires much more space and attention than is appropriate for
>     this note and this thread, but a couple of specific points are
>     relevant and worth emphasizing.
>
>  4. It's important to separate (a) the definition of the data
>     elements, (b) the policies governing who should have access to
>     which data elements, and (c) the access mechanisms.  As I said in
>     an earlier note, the proposal being discussed in this thread, viz
>     to use DNS to publish contact data, speaks to only a small portion
>     of the overall problem.  Because the proposed mechanism is DNS,
>     the data will presumably be public and provided at the discretion
>     of the registrant.   This is useful for some purposes, but it
>     clearly does not address the larger policies issues of allowing
>     different groups to have differing levels of access to various
>     types of data.
>
>     belong elsewhere.  That said, there is, I believe, a natural role
>     for the IETF that matches one part of the current proposal.  All
>     parties will benefit if there is a dictionary of the possible
>     registration data elements.  As I suggested in point 1 above, the
>     relevant data elements include more than just contact data.  And
>     even with respect to contact data, a more precise definition of
>     the various roles would be quite helpful.
>
>     The distinction implied here is the separation of the definition
>     of the data elements from the publication mechanism.
>
> I would strongly support an effort within the IETF to create and
> maintain a dictionary of registration data elements.  This would
> probably be in the form of an IANA-maintained registry, with oversight
> from DNSOP.
>
> Steve
>
>

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 11:43:44 -0500

I'll look at ETSI.

But is the risk to self-identification as present when role-based
accounts could be used as opposed to PII? I guess I'm not understanding
the risks of people accidentally disclosing what they don't intend to.

---

From: Bjarni Rúnar Einarsson <[email-masked]>
Date: Tue, 09 Jul 2019 17:49:22 -0000

wrote:
> 
> But is the risk to self-identification as present when
> role-based accounts could be used as opposed to PII? I guess
> I'm not understanding the risks of people accidentally
> disclosing what they don't intend to.

The risk is this: until people have been burned by over-sharing
sensitive information, most are very ill informed about the fact
that sharing is risky at all.

People literally won't understand that listing their name and
phone number, to assert ownership of a domain, ALSO exposes that
data to any creative criminal who knows how to wield dig as part
of preparing their spear-phishing campaign (as a random example).
Or expose their current address to a vindictive ex.

Most people won't understand this until it's too late, until
they've been burned.

Many domain owners are barely technically literate, DNS is not
just used by medium and large organizations with dedicated IT
staff. Many domain owners do not have an "organizational role" to
list, even if that were the encouraged default option.

Understanding how your data puts you at risk requires both
thinking in an adversarial way, and requires understanding how
the technology works. Very few people have that combination of
skills, even within tech.

As a result, the only reasonable assumption is that any system
which encourages the collection (let alone the publication) of
personal data must be considered risky, even dangerous. We have
too many such systems as it is, we need to think very carefully
and need strong justification for creating more of them.

Another way to put it: if a system requires you think and
exercise care to stay safe, that means the system itself is by
default unsafe. Building unsafe systems is not good engineering
practice.

Cheers,
 - Bjarni

- --

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 13:04:13 -0500

> Most people won't understand this until it's too late, until

But are these the unsophisticated users the ones who are going to adopt
this? Can't this be mitigated by any number of forms of user education?
If we're talking about those who don't know about over-exposing
sensitive information, those are the ones exposing a great deal on
twitter, facebook, et al, or sending nudes over texts. We're talking
about putting an email address on a DNS record here. If you own a domain
in the first place, some level of knowledge should be presumed. If
you're running your own DNS server, odds are you know SOMETHING. And if
you are having the registrar (or whomever) host your DNS, then a popup
that says "are you sure?" could help here.

The risks of "over-sharing" are inherent in having a domain in the first
place, in my mind. Am I wrong in that position?

> default unsafe. Building unsafe systems is not good engineering
Devil's advocate, and my intent is not argumentative. All this is true
in having a domain (or a social media account, really). I only allow for
someone to optionally put in a name, email, address, and phone number
into DNS. If you have a domain, odds are you have a website if they are
the above class of person. A website allows you to literally publish
whatever you want. One could put their tax returns on their website.

If the standard is "Let's not let people put an email address in DNS
because some subset of people can't understand the risks", hasn't that
ship already sailed by letting them have a website (were odds are, they
are publishing contact info), an email account, or access to social media?

---

From: Peter DeVries <[email-masked]>
Date: Tue, 9 Jul 2019 14:16:11 -0400

> default unsafe. Building unsafe systems is not good engineering

If we adhere to this we should just stop engineering anything for any
purpose.  It's literally impossible to meet the bar of "good engineering"
in this definition.  A pencil requires you to think and exercise care not
to poke an eye out.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Jul 2019 14:21:03 -0400

On Jul 9, 2019, at 2:04 PM, John Bambenek <jcb=[email-masked]> wrote:
> Can't this be mitigated by any number of forms of user education?

The evidence is crystal clear on this point: no, it can’t.   It is not possible for a person who is informed on this topic to believe otherwise.

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 13:32:33 -0500

Then why do we allow them to have social media accounts, email accounts,
etc?

How many RFCs involve using passwords somewhere in them? We know users
pick bad passwords. We know users reuse passwords. And we know
credential theft and misuse is a big problem. Were these same
considerations given to those proposals? If not, why is THIS proposal
that involves basically phone numbers and email addresses getting this
scrutiny?

If this is the hangup, then why isn't there a PIA (or related) process
for every I-D and RFC? What formal process should I undergo to have this
evaluated? Or should there be one created?

On 7/9/19 1:21 PM, Ted Lemon wrote:
> On Jul 9, 2019, at 2:04 PM, John Bambenek
> The evidence is crystal clear on this point: no, it can’t.   It is not
> possible for a person who is informed on this topic to believe otherwise.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Jul 2019 14:37:27 -0400

On Jul 9, 2019, at 2:32 PM, John Bambenek <jcb=[email-masked]> wrote:
> Then why do we allow them to have social media accounts, email accounts, etc?
> 
We don’t.
> How many RFCs involve using passwords somewhere in them? We know users pick bad passwords. We know users reuse passwords. And we know credential theft and misuse is a big problem. Were these same considerations given to those proposals? If not, why is THIS proposal that involves basically phone numbers and email addresses getting this scrutiny?
> 
If someone were to propose using passwords in a new specification, I think it would see fairly significant pushback.
> If this is the hangup, then why isn't there a PIA (or related) process for every I-D and RFC? What formal process should I undergo to have this evaluated? Or should there be one created?
> 
There is.  There are several RFCs that you should read that talk about the problem.  You are expected to know about them.

e.g.: https://tools.ietf.org/html/rfc6973 <https://tools.ietf.org/html/rfc6973>
e.g.: https://tools.ietf.org/html/rfc8280 <https://tools.ietf.org/html/rfc8280>
e.g.: https://tools.ietf.org/html/rfc2804 <https://tools.ietf.org/html/rfc2804>
e.g.: https://tools.ietf.org/html/rfc7258 <https://tools.ietf.org/html/rfc7258>

I could go on, but these are the low-hanging fruit.

---

From: Jim Reid <[email-masked]>
Date: Tue, 9 Jul 2019 21:51:26 +0100

On 9 Jul 2019, at 17:43, John Bambenek <jcb=[email-masked]> wrote:
> 
> I guess I'm not understanding the risks of people accidentally disclosing what they don't intend to.

I suggest you learn more about GDPR. The penalties for non-compliance can hurt - up to 4% of global turnover.

Some CIOs are learning this the hard way. British Airways got fined $200M+ yesterday and Marriott’s been hit by a $100M+ fine today, both for data breaches which involved due diligence failures covered by GDPR.

Anyone proposing policies or protocols that involve Personal Data really need to take account of the GDPR implications of their proposals and the likely impact on those who will be affected.

Hey, what’s this got to do with dnsop? :-)

---

From: Jim Reid <[email-masked]>
Date: Tue, 9 Jul 2019 21:57:38 +0100

> On 9 Jul 2019, at 17:26, Steve Crocker <[email-masked]> wrote:
> 
> I would strongly support an effort within the IETF to create and maintain a dictionary of registration data elements.  This would probably be in the form of an IANA-maintained registry, with oversight from DNSOP.

Hmmm. That might be a better fit for regext where the EPP people gather since those data elements are more likely to figure in EPP transactions than in DNS traffic. I’m not sure dnsop is a suitable place to discuss stuff that goes in domain name registry databased and whois servers.

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 16:01:33 -0500

Below

—
John Bambenek

> I suggest you learn more about GDPR. The penalties for non-compliance can hurt - up to 4% of global turnover.

No DPA is going to fine me for publishing my email on my dns zone. Not the use of only first person pronouns. No one is talking about anything a third party will do. Only what domain registrants may do if they so choose. 

There is nothing in this I-D to require publishing anything. There is nothing in this I-D to require if someone publishes that its PII (can use role based accounts). 

Please read the I-D being proposed. 

The concern is that a standard structure of a DNS TXT record for WHOIS may inspire someone to “accidentally” publish their email in DNS, something they can coincidently do today because absolutely no new functionality is required to make this I-D happen.

The only thing being proposed here is a standard format be which to put contact info (even role based contact info) into a DNS TXT record in a standard format. 

> Some CIOs are learning this the hard way. British Airways got fined $200M+ yesterday and Marriott’s been hit by a $100M+ fine today, both for data breaches which involved due diligence failures cov…

These are third parties managing someone else’s data. 
> Hey, what’s this got to do with dnsop? :-)

Because the I-D at hand is about DNS TXT records.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 9 Jul 2019 14:21:42 -0700

On Tue, Jul 9, 2019 at 2:01 PM John Bambenek <jcb=
[email-masked]> wrote:

> >> On 9 Jul 2019, at 17:43, John Bambenek <jcb=
> No DPA is going to fine me for publishing my email on my dns zone. Not the
> use of only first person pronouns. No one is talking about anything a third
> party will do.

> Only what domain registrants may do if they so choose.
>

That is technically true, only in the cases where the registrant operates
their authoritative DNS server.

What is problematic, is if a registrant's data is published, where the
registrant uses a third party DNS hosting provider, and the registrant
makes a claim about that not being intentional. The starting point is a "he
said, she said" scenario where GDPR essentially reverses the presumption of
innocence on the data providers' part.

Protecting themselves against this kind of claim would require a
significant effort by DNS hosting providers, precisely because there would
be a liability issue.
The bar would probably be quite high, for proving that the publication was
done by the registrant, including some manner of proof regarding identity.
That is a hard problem.
For little to no perceived benefit, with a lot of development and support
(i.e. expense), I don't see this as likely to be taken up by DNS hosting
providers.

And without uptake by DNS hosting providers, there will not likely be any
significant uptake at all, IMHO. High relative risk, no reward.

>
> There is nothing in this I-D to require publishing anything. There is
> nothing in this I-D to require if someone publishes that its PII (can use
> role based accounts).
>

This line of argument resembles that of the NRA regarding gun use, in
promoting the interests of weapons manufacturers.
No offense intended, but maybe highlighting the real-world benefits rather
than minimizing the risks, would be a better approach.
I don't yet see any benefit for using DNS as the publication point,
particularly all the way down in the registrant's zones.

Brian

> The concern is that a standard structure of a DNS TXT record for WHOIS may
> inspire someone to “accidentally” publish their email in DNS, something
> they can coincidently do today because absolutely no new functionality is
> required to make this I-D happen.
>
> The only thing being proposed here is a standard format be which to put
> contact info (even role based contact info) into a DNS TXT record in a
> standard format.
>
> > Some CIOs are learning this the hard way. British Airways got fined
> $200M+ yesterday and Marriott’s been hit by a $100M+ fine today, both for
> data breaches which involved due diligence failures covered by GDPR.
>
> > Anyone proposing policies or protocols that involve Personal Data really
> need to take account of the GDPR implications of their proposals and the
> likely impact on those who will be affected.
> >

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 16:38:30 -0500

Below

—
John Bambenek

On Jul 9, 2019, at 16:21, Brian Dickson <[email-masked]> wrote:

> 
> 
>> On Tue, Jul 9, 2019 at 2:01 PM John Bambenek <jcb=[email-masked]> wrote:
>> 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 sales@bambenekconsulting..com for details
>> 
>> No DPA is going to fine me for publishing my email on my dns zone. Not the use of only first person pronouns. No one is talking about anything a third party will do.
>  
> That is technically true, only in the cases where the registrant operates their authoritative DNS server.
> 
> What is problematic, is if a registrant's data is published, where the registrant uses a third party DNS hosting provider, and the registrant makes a claim about that not being intentional. The starting point is a "he said, she said" scenario where GDPR essentially reverses the presumption of innocence on the data providers' part.

There is nuance there. For instance, on twitter, I could tweet my phone number. I may want to do that for any number of reasons, but in no way to twitter compel me to do it, require me to do it, or could it be an accident. 

This gets into an implementation question but anyone implementing this as a DNS operator on behalf of others would need to do something to prevent such circumstances. Namely, it can’t be a checkbox, must be free form and accept what the user wants as long a syntactically valid (ie phone number with just numbers). 

Having the third party autopopulate, yes, definitely GDPR issue. 

But the domain I am emailing from now uses a third-party CDN for DNS. I can publish these records and there is no way it could be an accident. 

> 
> Protecting themselves against this kind of claim would require a significant effort by DNS hosting providers, precisely because there would be a liability issue.
> The bar would probably be quite high, for proving that the publication was done by the registrant, including some manner of proof regarding identity. That is a hard problem.
> For little to no perceived benefit, with a lot of development and support (i.e. expense), I don't see this as likely to be taken up by DNS hosting providers.
> 
> And without uptake by DNS hosting providers, there will not likely be any significant uptake at all, IMHO. High relative risk, no reward.
> 

If I were betting, I would bet it won’t be widely adopted. Sure. I think it should be, and I think you overestimate the complexity of doing it legally (social media companies have figured this out). 

But without an actual standard there is nothing to implement and we’re all guessing at adoption. 

> This line of argument resembles that of the NRA regarding gun use, in promoting the interests of weapons manufacturers. 
> No offense intended, but maybe highlighting the real-world benefits rather than minimizing the risks, would be a better approach.
> I don't yet see any benefit for using DNS as the publication point, particularly all the way down in the registrant's zones. 
> 
> Brian
>  
>>

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 16:56:49 -0500

How would having an SRV record and an entirely different (currently undeveloped) service help the situation?

If its a question of query logs, the consequence of putting any service (smtp, web, slack) in the hands of a third-party is they need to provide that (if you pay them) or you don’t get it. Why should this service be special in that regard?

—
John Bambenek

---

From: George Michaelson <[email-masked]>
Date: Wed, 10 Jul 2019 08:26:48 +1000

> RDAP profiles are not being discussed in the IETF. I think this is a feature.

Wrong: https://tools.ietf.org/html/draft-harrison-regext-rdap-jcard-profile-00

(admittedly it's the profile for JCARD in RDAP, but in any case there
is a convergeance/profile/conformance discussion happening amongst the
RIR at least, regarding RDAP data. We're fully deployed)

-G

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 Jul 2019 20:10:14 -0400

On Mon, Jul 08, 2019 at 02:42:25PM -0700, Bill Woodcock wrote:

> > self-disclosure which mitigates the sticky issues of GDPR et al. Would
> > love to get feedback.
> 
> information.  It’s a little hard for me to imagine it being widely used
> for valid information, though that would of course be the ideal outcome.
> 

When locating contacts for domains with stale TLSA records, I find each of:

	1. postmaster@
	2. SOA RR 'mrname'
	3. WHOIS technical contact when published
	4. Contact data on the domain's website

to work a non-trivial fraction of the time.  Between them, most
domains turn out to be reachable.  The SOA 'mrname' is closest to
the subject of this thread, and while often unusable[1], is also
often enough the only working contact.

Perhaps the SOA 'mrname' could get more publicity as worthy of
proper upkeep.  If you want more info from the registrant, send a
query there.  For data kept by the registrar, we're often out of
luck these days.

-- 
	Viktor.

[1] Even when notionally the right address, the SOA 'mrname' is not
always read, and may (e.g. <[email-masked]>) simply bounce all messages
because the mailbox is over quota.  On the other hand some other
"provider" contact addresses work reliably.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 10 Jul 2019 00:13:26 +0000

> undeveloped) service help the situation?

whois and rdap servers are a dime a dozen. i can run one for all of my 
domains, and put it behind a rate limiter to make life harder for scrapers.

> If its a question of query logs, the consequence of putting any service
> (smtp, web, slack) in the hands of a third-party is they need to provide
> that (if you pay them) or you don’t get it. Why should this service be
> special in that regard?

it contains my PII.

-- 
Paul

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 19:29:56 -0500

Below. 

—
John Bambenek

> domains, and put it behind a rate limiter to make life harder for scrapers.

The reason scraping and rate-limiting make sense with registry operates servers is because scrapers want to query the whole portfolio. 

In this scenario, the attacker only queries your record once and has what he needs to move on to next domain. Any rate limit beyond 0 doesn’t protect you. 

And if you run DNS Auth, don’t have the ability to rate limit today?

>> that (if you pay them) or you don’t get it. Why should this service be

1) So can smtp, web, and most certainly slack. 
2) If you use role-based contacts, it is not PII by definition.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 9 Jul 2019 17:41:19 -0700

John Bambenek wrote on 2019-07-09 17:29:>
>> whois and rdap servers are a dime a dozen. i can run one for all
>> of my domains, and put it behind a rate limiter to make life
>> harder for scrapers.
>> 
> 
> The reason scraping and rate-limiting make sense with registry 
> operates servers is because scrapers want to query the whole 
> portfolio.

this is wrong. stop being obstreperous and deflective about this topic
for a few days if you want me to tell you why. i'm done otherwise.

> 
> In this scenario, the attacker only queries your record once and has 
> what he needs to move on to next domain. Any rate limit beyond 0 
> doesn’t protect you.

same.

> And if you run DNS Auth, don’t have the ability to rate limit today?

i think you mean "don't you have", and no, because as i said up-thread,
i can't ask my friendly secondaries to do custom name server settings
for those of my zones they handle.

-- 
P Vixie

---

From: John Bambenek <[email-masked]>
Date: Tue, 9 Jul 2019 20:07:42 -0500

—
John Bambenek

> for a few days if you want me to tell you why. i'm done otherwise.

How is it wrong? I’m not being deflective (or at least not trying to be). If I’m an attacker who wants lots of emails in whois, I’d hit up .com 140 million or so for each domain. In my proposal, you’d query the auth server for say bambenekconsulting.com once and have what you need. Why would an attacker query a whois record twice for the same domain?

Sincerely, I’m not being deflective I just don’t see rate limiting helping you in the proposed model. 

> for those of my zones they handle.

I meant if you run the authoritative (and secondary) NS for a domain you could. If you share that with a third party, obviously you are constrained by the rules of that third party.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Jul 2019 16:16:25 +1000

Take activedisplay.org.uk.  The DNS server for this zone has a broken
DNS COOKIE implementation (see the mismatch between the request cookie and
the response cookie).

COOKIE: 5dc8e2253d5f2702 
COOKIE: e0d5650141611e0110474b0003000000dce86501ad361e01

% dig ns1.activedisplay.org.uk @88.208.234.46 +qr

; <<>> DiG 9.15.1 <<>> ns1.activedisplay.org.uk @88.208.234.46 +qr
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18721
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5dc8e2253d5f2702
;; QUESTION SECTION:
;ns1.activedisplay.org.uk.	IN	A

;; QUERY SIZE: 65

;; Warning: Client COOKIE mismatch
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18721
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e0d5650141611e0110474b0003000000dce86501ad361e01 (bad)
;; QUESTION SECTION:
;ns1.activedisplay.org.uk.	IN	A

;; ANSWER SECTION:
ns1.activedisplay.org.uk. 86400	IN	A	88.208.234.46

;; AUTHORITY SECTION:
activedisplay.org.uk.	86400	IN	NS	ns1.activedisplay.org.uk.
activedisplay.org.uk.	86400	IN	NS	ns2.activedisplay.org.uk.

;; ADDITIONAL SECTION:
ns2.activedisplay.org.uk. 86400	IN	A	88.208.234.46

;; Query time: 332 msec
;; SERVER: 88.208.234.46#53(88.208.234.46)
;; WHEN: Wed Jul 10 15:31:53 AEST 2019
;; MSG SIZE  rcvd: 145

% 

Whois is useless

    Domain name:
        activedisplay.org.uk

    Data validation:
        Nominet was able to match the registrant's name and address against a 3rd party data source on 20-Jun-2015

    Registrar:
        Fasthosts Internet Ltd [Tag = LIVEDOMAINS]
        URL: http://www.fasthosts.co.uk

    Relevant dates:
        Registered on: 20-Jul-2011
        Expiry date:  20-Jul-2020
        Last updated:  20-Jun-2019

    Registration status:
        Registered until expiry date.

    Name servers:
        ns1.activedisplay.org.uk  88.208.234.46
        ns2.activedisplay.org.uk  88.208.234.46

    WHOIS lookup made at 06:50:41 10-Jul-2019

There is no web site.

The registrar’s web site is useless.

The SOA contact is a Compuserve email address which hasn’t yet bounced.
Time will tell.

Mark

> On 10 Jul 2019, at 1:07 am, Joe Abley <[email-masked]> wrote:
> 
> Hi John,
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: John Bambenek <[email-masked]>
Date: Wed, 10 Jul 2019 07:41:23 -0500

I’m not sure the point aside of illustrating if there is no response for the domain records by the auth server that there would also be no response for a _whois record. That’s true. 

1) Using _whois is completely optional, like SPF or any other record. 
2) I can’t envision much legitimate need to contact a domain owner for something that doesn’t exist (aside of domain renewal spam or trying to buy the domain). 

Am I missing something?

—
John Bambenek

---

From: Philip Homburg <[email-masked]>
Date: Wed, 10 Jul 2019 15:24:51 +0200

> Im not sure the point
> aside of illustrating if there is no response for the domain records
> by the auth server that there would also be no response for a _whois
> record. Thats true.
> 
> 1) Using _whois is completely optional, like SPF or any other
> record.  2) I cant envision much legitimate need to contact a domain
> owner for something that doesnt exist (aside of domain renewal spam
> or trying to buy the domain).
> 
> Am I missing something?

I read this discussion from the point of view of someone how is very happy
with the result of GDRP in this area.

With that in mind, it seems that this proposal doesn't address any technical
issues with whois.

Where whois allows for querying of contact information associated with a 
domain, this proposal does something similar.

Of course, whois has various technical issues, but it makes sense to first
try to solve those technical issues within the whois system. And only when 
it is clear that certain issues cannot be solved look for a different
protocol. (And I mean cannot be solved for technical reasons, but because 
of lack of consensus)

As far as I know, there is no issue with whois and the GDRP when it comes
to voluntarily publishing information in whois. This draft clearly 
advocates voluntary sharing of this information. 

As the Section 1 suggests, whois works.

So it seems to me that this draft does not solve a technical problem
(or at most a minor one, 'internationalization')

---

From: Jim Reid <[email-masked]>
Date: Wed, 10 Jul 2019 14:37:10 +0100

> On 10 Jul 2019, at 14:24, Philip Homburg <[email-masked]> wrote:
> 
> to voluntarily publishing information in whois.

Nope. It’s OK for you to publish your Personal Data. For anything else, you need to get informed consent first. And be able to prove that. And give the Data Subjects the ability to modify those data or get them deleted.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 10 Jul 2019 15:48:43 +0200

> Nope. Its OK for you to publish your Personal Data. For anything
> else, you need to get informed consent first. And be able to prove
> that. And give the Data Subjects the ability to modify those data
> or get them deleted.

When you register a domain, your registrar already has to have your informed
consent to process any PII you supply. And as far as I know,
registrars routinely ask for your name and credit card.

So all GDRP-related processes are already in place.

Looking at it from a technical point of view, whois has a referal mechanism.
So if GDRP compliance would be a big issue, then allowing the handful of
people who wish to publish anything in whois to run their own whois server
would also solve the issue.

---

From: John Bambenek <[email-masked]>
Date: Wed, 10 Jul 2019 08:49:21 -0500

The technical issue with whois is that its dark in many places and getting darker with minimal to no prospect of coming back (in a usable form). 

While GDPR applies only to EU natural persons because there is “no way” to distinguish between natural persons and legal persons and “no way” to distinguish EU from other countries, many have adopted applying strong redaction to all records. 

This proposal assumes the above remains true but it is an assumption. 

That said, no additional functionality is created with this proposal. Most, if not all, commercial auth DNS providers already support free form text fields so can support this with no additional work. The idea here was to develop something using services people already run with functionality that already exists. The only “new” here is a standard way to structure the information. 

—
John Bambenek

---

From: John Bambenek <[email-masked]>
Date: Wed, 10 Jul 2019 08:50:18 -0500

This is my understanding as well as the approach and legal assumption I used in creating this draft. 

—
John Bambenek

---

From: John Bambenek <[email-masked]>
Date: Wed, 10 Jul 2019 08:54:18 -0500

Subdelegation/federation of whois (or rdap) servers could solve the problem. Whois still would remain effectively unstructured and unparseable but that’s the status quo. It would require entities to set up another public facing service. 

That’s an approach, I can’t say its wrong. My philosophy here was to design something using services people already run with functionality that already exists. Since SPF, DKIM, DMARC, CAA already live in DNS, it seemed appropriate to put this there too. 

My thoughts here were to keep it simple, use existing stuff, and have it all be voluntary disclosure and allow role-based info. That’s not the only approach. It just seemed logical to me to tackle it that way. 

—
John Bambenek

---

From: Philip Homburg <[email-masked]>
Date: Wed, 10 Jul 2019 16:13:49 +0200

> The technical issue with
> whois is that its dark in many places and getting darker with
> minimal to no prospect of coming back (in a usable form).
> 
> While GDPR applies only to EU natural persons because there is no
> way to distinguish between natural persons and legal persons and
> no way to distinguish EU from other countries, many have adopted
> applying strong redaction to all records.

This doesn't make any sense to me.

Previously, information was published in whois without the consent (as
defined in the GDRP) of the subjects.

So obviously, registrars had to stop publishing that kind of information.

However that doesn't say anything about voluntarily providing that information.

Support for voluntary information has a cost to implement. It is possible
that registrars don't want to provide that feature because it would not
make them any money. Of course ICANN could require registrars to support
domain holders adding information in whois voluntarily. 

So I guess the argument then becomes that DNS TXT records have to be used
because it doesn't require additional investments in many cases. Maybe you
should list that argument in the draft. Because that means that as soon
as DNS TXT records are rejected, there is no basis anymore for the
the draft.

>From a technical point of view, having structured information in TXT
records is bad. Having large RRsets is also bad. So the obvious solution
would be to define a new resource type for this kind of information.
However, that defeats your argument that existing zone editiors can be used.

In the end you are reinventing whois to get around policy issues and the
lack of a business case.

---

From: Joe Abley <[email-masked]>
Date: Wed, 10 Jul 2019 12:09:07 -0400

On 10 Jul 2019, at 10:13, Philip Homburg <[email-masked]> wrote:

> make them any money.

It's also possible that registrants don't want registrars to provide that feature. In the past many registrars were able to charge extra for services that would effectively redact personal information from the data accessible via whois, services that had in some cases the additional costs of e-mail and phone redirection included with them. If we infer that the products wouldn't have been made available if nobody bought them, perhaps we can conclude that at least some registrants had a preference for privacy.

A mechanism for voluntary publication of private information by the data subjects that enjoyed standardisation might fail because there is no demand for it. This does not seem like an unlikely outcome to me. To be honest, I find it hard to imagine any registrant paying extra money or spending extra time publishing personal information to the general public voluntarily. It'd be like paying a restaurant extra to have a waiter spit in your food.

Climbing up a few thousand feet (and not replying to you directly, Philip) it's not clear to me that this discussion has revealed any real support for John's proposal. I have no standing to judge consensus here, in case that's not already abundantly obvious, but perhaps it'd be an idea to stop the circular, point-by-point rebuttals and simply concede that there's no appetite to proceed with this work here. Other venues have been suggested.

Joe

---

From: David Conrad <[email-masked]>
Date: Wed, 10 Jul 2019 13:14:54 -0700

Philip,

> With that in mind, it seems that this proposal doesn't address any technical

Maybe rate limiting by most (all?) whois servers?

Regards,
-drc

---

From: John Bambenek <[email-masked]>
Date: Wed, 10 Jul 2019 15:55:17 -0500

And the existing system is not consistently formatted, this would create
a parseable and consistent standard.

And would bypass GDPR concerns by registries.

On 7/10/19 3:14 PM, David Conrad wrote:
> Philip,
>
> On Jul 10, 2019, at 6:24 AM, Philip Homburg
> <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Michele Neylon - Blacknight <[email-masked]>
Date: Thu, 11 Jul 2019 09:59:51 +0000

All gTLD registries and registrars will be obliged to use RDAP from next month onwards.

At present all gTLD registries and registrars follow a consistent format for their whois output which is mandated under their respective contracts.

Regards

Michele

--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com/
https://blacknight.blog/
Intl. +353 (0) 59  9183072
Direct Dial: +353 (0)59 9183090
Personal blog: https://michele.blog/
Some thoughts: https://ceo.hosting/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845

From: DNSOP <[email-masked]> on behalf of John Bambenek <jcb=[email-masked]>
Date: Wednesday 10 July 2019 at 21:56
To: "[email-masked]" <[email-masked]>
Subject: Re: [DNSOP] Proposal: Whois over DNS

And the existing system is not consistently formatted, this would create a parseable and consistent standard.

On Jul 10, 2019, at 6:24 AM, Philip Homburg <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
-drc

DNSOP mailing list

[email-masked]<mailto:[email-masked]>

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Thu, 11 Jul 2019 12:11:04 +0200

And many ccTLDs will follow suit anyway :-)-O

el

On 11/07/2019 11:59, Michele Neylon - Blacknight wrote:
> At present all gTLD registries and registrars follow a consistent
> format for their whois output which is mandated under their respective
> contracts.
> 
> Regards
> 
> Michele
> 
> --
> Mr Michele Neylon

-- 
Dr. Eberhard W. Lisse          / Obstetrician & Gynaecologist (Saar)
[email-masked]            / *     |   Telephone: +264 81 124 6733 (cell)
PO Box 8421                  /
Bachbrecht, Namibia     ;____/

---

From: Michele Neylon - Blacknight <[email-masked]>
Date: Thu, 11 Jul 2019 13:21:32 +0000

It will have whatever contact data has been decided under ICANN policy and the registrar / registry’s own policies etc.,

As Dr Lisse pointed out, some ccTLDs will probably follow suit.

As with any network connected service there will be some rate limits, though unless you’re being abusive they shouldn’t impact you.

From: John Bambenek <[email-masked]>
Date: Thursday 11 July 2019 at 14:17
To: Michele Neylon <[email-masked]>
Subject: Re: [DNSOP] Proposal: Whois over DNS

And will that have contact data (I assume not). If it doesn’t have contact data will it be rate limited?
—
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 [email-masked]<mailto:[email-masked]> for details

On Jul 11, 2019, at 04:59, Michele Neylon - Blacknight <[email-masked]<mailto:[email-masked]>> wrote:
All gTLD registries and registrars will be obliged to use RDAP from next month onwards.

Regards

Michele

From: DNSOP <[email-masked]<mailto:[email-masked]>> on behalf of John Bambenek <jcb=[email-masked]<mailto:jcb=[email-masked]>>
Date: Wednesday 10 July 2019 at 21:56
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DNSOP] Proposal: Whois over DNS

Regards,
-drc

DNSOP mailing list