[gnso-rds-pdp-wg] The Whois roles are not well defined

[Steve Crocker]

Almost all of the discussion around whois has been based on implicit
acceptance of the roles of registrant, admin contact and tech contact as if
these had definite meaning.  They don't.

The person who actually controls the domain registration and the associated
parameters, i.e. name servers, etc. is the person who has access to the
account with the registrar.  I don't know if there is widely agreed upon
name of this role, so I'll call her the domain controller.  If this group
prefers a different name, I'll happily switch.

It's the domain controller who populates the registrant, admin and tech
fields.  Most of the time, the names and contact information that is put
into these fields is reasonably related to the common sense notion of what
these terms mean, but unless I have missed something, there is nothing in
either the rules or the operational practices that forces these to be
meaningful.  In the extreme, the controller can put in the names of people
who have NO relationship with the domain.  Viewed from this perspective,
rather than decrying the high error rates, it might be more appropriate to
be amazed at how well this system works.

When the whois system was first created, the net -- and we're talking about
the Arpanet, not the full blown Internet -- consisted of several dozen
time-shared computers, each of which support several dozen users.  The tech
contact was what we'd now call the system administrator (sysadmin) and the
admin contact was someone who had administrative authority over both the
operations and the users.  The list of contacts was intended to make it
easy for the relevant people in authority to get in touch with each other
when there was a problem.

Those terms have been transliterated to the domain name system and scaled
from hundreds to hundreds of millions.  Nothing really survives being
scaled up by a factor of a million without undergoing serious and
substantial reworking.

In my view, the extensive and overwrought discussion about who should have
access to the contact information, how to validate the information, and how
to reconcile all of this with privacy laws is troubled because there really
isn't a firm foundation at to what this contact information means.  The
operational questions for contact information is fundamentally what
obligation does the person designated in a particular role have when she's
contacted, who should be allowed to contact the person, and under what
circumstances.

There is, of course, one particular role that is well defined.  It's the
billing contact.  If the registrar sends a message to the billing contact
and says the bill hasn't been paid, the billing contact either takes care
of the problem or the registrar shuts down the account.

There is also a reasonably well defined sequence related to domain name
transfers.  Is there more that is well defined?

What are the implications of this line of reasoning?  Well, for starters,
what happens if we simply remove the admin and tech contacts?  If there is
an argument for continuing their existence, can we base it on operational
authorities and responsibilities?

Another, quite important but less obvious implication is to look at what
information is NOT there that should be.  The current ICANN contractual
model is based on registries and registrars but pays no attention to name
server operators.  It's quite common for the registrar to operate the name
servers for the registrant, but it is also quite common for the registrant
to either operate her own name servers or to use a third party.  There are
companies that specialize in providing this service, and they are an
important part of the ecosystem.

Why does it matter that name server operators are not explicitly visible in
the ICANN contractual model and registration data base?  Because the name
server operator sometimes needs to change the information in the registry
that's associated with the domain name.  There are two significant cases.
One is when the name server operator changes the set of name servers
associated with a domain name.  This doesn't happen frequently, and when it
does it usually affects a large fraction or all of the name server
operator's customers.  When that happens, the revised list of name servers
has to be communicated to the registry and be published in the parent zone.

Under the ICANN model, the only path for communicating with the registry is
via the registrar, and the only path implemented by registrars is via the
account holder, i.e. the person I called the controller.  This means when a
name server operator makes a change to its set of name servers, EACH of the
name server operator's customers has to process an email message from the
name server operator and make a manual change to the entry in her account.
This is time-consuming, labor intensive and error prone.

The other case is related to DNSSEC.  The signatures associated with DNSSEC
have expiration dates.  If the name service is being provided by a name
server operator, it will be the name server operator that will generate a
new key and create a new DS record on a regular schedule and .  This
requires putting the new DS record in the parent.  Again, since the only
path is through the registrar...

here are proposals for additional protocols to automate this process, but
these have some complexity due to the need to work around the clumsiness of
adhering to the limited business model.  It ought to be possible for the
domain controller to explicitly designate the name server operator and to
authorize the name server operator to send changes to the name server
records and/or the DS records whenever necessary.

For those of you who have read this far and are wondering whether this
really belongs in a discussion about RDS, the answer is yes,  The RDS is a
portion of the overall operation of the domain name system.  It provides
contact information for the essential functions of the system.  In the
ICANN system, the registrars are contracted parties and the name server
operators are not, but that does not address the need for a more orderly
operational relationship among these parties.

More to come.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180215/74674ee1/attachment.html>