[gnso-rds-pdp-wg] Why the thin data is necessary

[TXVB]

Thank you Andrew for your well thought out and presented points. I agree with you, as someone who's worked in the trenches and often needs to track down domain owners to deal with malware, etc. sometimes I have to reach out to the domain owner as a last resort.

-Thanks
Mike

-------- Original Message --------
Subject: [gnso-rds-pdp-wg] Why the thin data is necessary
Local Time: June 6, 2017 1:22 PM
UTC Time: June 6, 2017 6:22 PM
From: ajs at anvilwalrusden.com
To: gnso-rds-pdp-wg at icann.org

Hi,

On the call today there were arguments being made about why certain
fields should not be publicly accessible. In effect, what we are now
arguing about, in talking about what should be considered "thin data",
is the definition of the set of data to which unauthenticated access
should be permitted. (Let us please not get distracted by what is
actually required by the RAA or anything like that just now, since the
outcome of this policy discussion might change that.)

There were several arguments put forth about whether the created on,
updated on, and expiry dates should be included. Similarly, people
discussed whether the domain status values should be included. I
believe they must be.

The Internet is unlike many other technologies because of its radical
decentralization. That is not some sort of political choice, but
instead a fundamental part of the design of the Internet: it's a
network of networks (of networks…) formed by voluntary interoperation
among the participants. Participants in the Internet interoperate
without setting up formal contractual arrangements between all the
participating parties. This feature is part of what has made the
Internet so successful compared to other telecommunications systems,
because the barrier to entry is really low. But that design comes at a cost.

The cost is that there's not always a party to speak to, with whom one
has a pre-existing relationship. If communications break down between
two telephone customers, they know whom to call: the phone company.
The phone company also has contractual (or sometimes treaty)
relationships to other phone companies.

The Internet doesn't work that way. If you and I are communicating
over the Internet, there is no guarantee of direct contractual
relationships all the way along the transit path: that's what open
peering policies ensure. The way we make this work in fact is by
placing the responsibility for troubleshooting out at the edges. And
because of that, when I need to troubleshoot my site I need to have
tools with which to do that.

In domain-based communications (such as email, IP telephony, websites,
money transfer, and thousands of other applications), when I encounter
a problem with the communication I need to answer whether the problem
is in _my_ network operation, or in the other end. Important data to
rule out "the other end" is in the thin RDS data.

Obviously, the nameserver and DNSSEC information in the RDS will allow
me to tell whether what is in the global DNS is what ought to be
there. For instance, if the RDS has one value for the name servers,
but the DNS returns something else, there is a problem.

Less obvious but just as important are the status values. If a name
is on Hold or is pendingTransfer or something like that, it can tell
me that something is up. A name that doesn't appear in the DNS but
has a full complement of name servers in the RDS, for example, might
be on hold; and I can't tell that without seeing the status values.

In the same way, the dates in the RDS allow a troubleshooter to
understand what might be wrong when things are broken. If a name is
set to expire in a day and you're getting a parking page on the
website, you have a clue about what is going on. Most of the examples
cited in
https://whoapi.com/blog/1582/5-all-time-domain-expirations-in-internets-history/
were trivial to understand for help desks that could see that a name
that should have existed for some time was just hours old, because the
created_on date was available. And if you start having trouble and
see a domain was updated about the same time the trouble started, you
have a pretty good clue that the problem is most likely at the target
domain, and not in your own network.

As for the question of why the global Internet infrastructure needs to
help with this, the answer is that _that's what the infrastructure is
for_. We have registrars and registries in order to co-ordinate these
assignments and make those assignments available, in support of the
distributed administration and operation of the Internet. If the
infrastructure isn't providing this kind of information in order to
help administrators of various Internet administrators, then it isn't
doing its job.

The Internet is a distributed system. If you want to make distributed
systems work, you have to allow the operators to have enough
information to do their jobs independently of one another. So,
regardless of where one lands on whether any of this data is personal
data, it makes no difference. If you want the domain name system to
continue to work reliably, you have to publish this data.
Centralization and locking the data up for just registrars simply
won't scale.

Best regards,

A

--
Andrew Sullivan
ajs at anvilwalrusden.com
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170607/3c3d563b/attachment.html>