[gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)

[Greg Aaron]

Dear Rob:

How does showing a domain's status fields "increase the 'criminal activity' regarding a domain name"?  How does showing a domain's create and expiration dates "increase abuse/malicious activity"?

As someone who's studied the criminal use of domains for many years, I have never seen or heard of any evidence of that.  In fact, domain status and date information is important to people who investigate abuse or many want to make judgements about the trustworthiness of a domain.

Best,
--Greg


-----Original Message-----
From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Rob Golding
Sent: Wednesday, December 7, 2016 8:42 PM
To: gnso-rds-pdp-wg at icann.org
Subject: Re: [gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)

>> the domain name,
>> the sponsoring registrar name
>> and ID,

are not controversial to me

>> the domain's status(es) ,
> One could argue that this data should not be included because most of 
> it is not directly relevant to whether a domain name ought to be 
> working.  (For instance, whether an update is pending is not 
> necessarily relevant to whether a name ought to resolve on the 
> Internet right now.)  Moreover, one could argue that at least some 
> status values radiate information about what a registrant may have 
> done, and also potentially supports attempts to game the registration 
> system to obtain a domain name contrary to the interests of the 
> previous registrant.

Showing the status certainly increases the "criminal activity" regarding a domain name, and is a good reason not to include it.

>> created- [date]
>> updated- [date]
>> expiration date[s]

Lots of pros and cons for the dates - showing them increases abuse/malicious activity, allows for more social engineering, but they are useful.

The downside is (as a Registar) we have more than once had phone calls along the lines of

Caller: "Hi, I unlocked my domain yesterday and got the epp code, but I forgot to write it down and dont have the email with me today, can you just read it out please"
Us: "Who are you ?"
Caller: "I'm (blah) working with (reads out name of registrant from whois)" // "I'm (name of registrant)"
Us: "The account holder can get the details if needed from the client system"
Caller: then usually tries some other tactic else hangs up or gets abusive - often tries to play the greed card "i'll take all my bisiness away and i know lots of your other customers"
Us: *click*


>> nameservers.

And their IP addresses if self-referencing

> Moreover, in principle if the
> registry and DNS are in harmony this data is already public, so there 
> is no harm in including it in another public repository.

The 'harm' being :
duplication = bad
duplication = discrepancies
duplication = mistakes
as a general rule

> It is hard for me to come up with an argument why this should not be 
> public except for the case where someone thinks the RDDS is a bad idea 
> in general.

The argument is that we're now getting RDS to deviate from "accurate" 
into "they might be the nameservers, but they might not, and even if they they were 30 minutes ago, they might not be anymore, I'm RDS not a shovel" responses.

Do the NS and IP data help troubleshoot ? As they're neither authoritive nor necessarily reliable I doubt it, unless you dont know how to actually get the authoritive data, in which case what exactly are you able to troubleshoot ?

Other data elements _currently_ required
- I suggest we make this a new "group" as they're not "domain data" and they're not "registrant data"


Registry Domain ID:
Registrar Abuse Contact Email:
Registrar Abuse Contact Phone:
Reseller:
DNSSEC:


Rob
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg