[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access

[Alexander Jäger]

+1

> Am 31.05.2017 um 15:07 schrieb John Bambenek via gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org>:
> 
> And creation date is used by security as a hugely valuable indicator of suspiciousness. Domain gets registered and starts sending mail immediately? Obviously spam or malicious. Criminals immediately operationalize their domains. Normal people don't. If we want to weigh the harms, I think having that date prevents a lot more problems than the ones you mention that can largely be solved by a mediocre spam filter. 
> 
> Sent from my iPhone
> 
> On May 31, 2017, at 01:33, Rob Golding <rob.golding at astutium.com> wrote:
> 
>>> Revoking that data can't stop brute force transfer attempts,
>> 
>> If the status is Transfer Prohibited, then yes it does, as they are automatically failed by the registry when the gaining registrar sends them.
>> 
>> It's not about whether a domain needs a status, but whether that status should be "open to the public" rather than restricted to those who need it (registrant via their registrar, authenticated users for specific use cases, etc)
>> 
>>> Registrars sell domains in precisely 1 year blocks
>>> of time.
>> 
>> one-or-more periods of years for most gTLDs, with 2,1,5 being the most common at my registrar (in that order)
>> 
>> Creation date I left off, although it's easy to work out from the changes to the zone files
>> 
>> Creation date does (in conjunction with the other data) get abused - I've had over 30 "contacts" from people trying to sell me seo, websites, stationary since registering a variation spelling of a domain on the 19th May (to help those who keep missing out the final "S" when sending an email to me from getting bounces) - 11pm on Monday from an Asian callcentre using a UK voip number (now reported to the TPS) being one of the most intrusive this week.
>> 
>> Whilst I can't stop the free pens, adwords vouchers, brochures for radiator valves and other tat coming through the letterbox based on a domain registration, I've even seen _registrars_ doing it :(
>> 
>> I didn't forget, but excluded Updated date - in my experience it's wrong at least as much as it's correct -  and my opinion is that data you can't trust does more harm than good
>> 
>> From 2 of my domains:
>> 1. Updated Date: 2017-04-11T23:15:07.0Z
>> is correct, as that is when I renewed it
>> 
>> 2. Updated Date: 2016-01-09T22:25:53Z
>> is not correct as I changed the nameservers in Dec
>> 
>> To me it looks like it only changes the "updated date" when the _dates_ on a domain change, not on other types of updates.
>> 
>>> I actually like the idea of revoking all nameserver data. I like that
>>> idea the more and more I think about it.
>> 
>> NS information is redundant in "whois", and depending on which whois server/system you ask, regularly incorrect - there are a variety of reasons for this, including but not limited to:
>> * registrars don't tidy up
>> * registries aren't realtime
>> * 3rd-party systems cache the data
>> * end-users dont know the difference between whois (service) and "whois" being in the name of a website
>> and so on
>> I've seen domains where Directi WHOIS has said one thing, a Whois website has said another and the actual nameservers were different to both of those on the domain at the registry (plus the actual issue I was diagnosing was that the zone slaved the nameservers off to yet different ns, which is why the A record the client thought should be returned wasn't the IP they were seeing)
>> 
>> Use the right tools for the job, and in the case of DNS that's *NOT* whois - we'd be doing a global service to the internet by taking them out of it.
>> 
>>> SOA data is almost always garbage. 95% of the time I find it useless.
>> 
>> With DNS Zones being mostly automated by hosting control panels, it's "variable" as to what goes in there, and SOAs rarely get updated once created beyond the serial changing, so sadly yes, it's of limited use now
>> 
>> Rob
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> 
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg