[gnso-rds-pdp-wg] Some reg'n data I think necessary (was Re: GNSO Next-Gen RDS PDP Working Group teleconference)

[Rob Golding]

> • Every domain on the Internet must have name servers in order to
> function.

By 'function' I guess you mean "be used in conjunction with DNS to 
perform some use beyond simply 'registration'" :)

A domain is "happy" with not having nameservers, and that config is 
perfectly valid and quite common

> The RDS ought to contain those name servers

Yes.

> so that, in the
> event of technical problems, other operators can detect whether there
> is a gap between what the registry contains and what the authoritative
> servers contain.

Nice theory, but in practice no-one really does that.

> • Many domans are signed, and in a signed domain that delegates the
> delegation will have a DS record.  The RDS ought to contain the DS
> record for the same reason the RDS ought to contain the name servers.

Yes.

> In signed domains today, this may be even more important than the NS
> records, given the frequency of DNSSEC misconfiguration

If someone chooses to effectively 'dos' themselves by the use of DNSSEC 
it's not our job to stop them ;)

> • Every name server has someone responsible for its operation.  The RDS
> ought to contain contact information for a given domain or the name
> server or (preferably) both, so that in the event of serious
> malfunction such that interoperation is impossible there is some
> mechanism for out-of-band contact in order to rectify the problem.

Why ? If a 'service provider' has an issue with their nameservers why is 
that of any concern to anyone else
  - their customers' will have appropriate contact information already, 
why should it in RDS ?

> • In shared registration systems, it is usually (always?) the case
> that registrations are not single-occasion, but instead are
> registration at a point in time for some term.  It is therefore
> necessary, for troubleshooting interoperation, to know when a name's
> registration is expiring and also when it was last updated (to
> troubleshoot recent problems that might be related to changes).

Whilst potentially convenient, it certainly isn't "necessary" - plenty 
of tlds operate just fine without making expiry information "public", 
and others don't expire at all.
eurid/.eu for example only provides the generic following:
Domain: astutium.eu
Registrant:        NOT DISCLOSED!
Onsite(s):        NOT DISCLOSED!
Registrar:        Name: Astutium Ltd         Website: www.astutium.com
Name servers:        ns2.astutium.com        ns1.astutium.com

Of course the registry and registrar (and thus the registrant) need to 
know expiry dates as part of their 'business'.

> • In any registry using EPP, every domain has an authInfo associated
> with it

It's not a requirement of EPP, neither is it the only transfer method 
for registries that do use EPP (Nominet for example uses EPP and does 
not use/need/have authInfo)

Because of the potential misuse (we see many fraudulent attempts at 
transfers aka theft every-day) that's certainly not something that 
should ever be "public" and regsitry dependant isn't even something the 
registrar can supply, so is outside the scope even of RDS data 
"collected"

> • In gTLDs, most (all?  I know there have been exceptions in the past,
> because I made the entries in the relevant database) registrations are
> registered through a registrar

Yes.

> There are two reasons to be able to
> learn the registrar of a name.  It is necessary for other Internet
> parties to be able to learn the registrar in order to deal with
> registration problems

Maybe. The 'appropriate parties' should know who they dealt with (which 
is very often a reseller than a registrar directly) - although I do see 
the benefit-in-practice and for 'reminder' purposes and where domains 
are moved as part of de-accreditation etc.

> It is necessary for other registrars
> to be able to learn the existing registrar in order to facilitate
> registrant-demanded transfers.

As you note, this is actually not necessary in the gtld world, as the 
gaining registrar on a transfer does not need to knwo anything about the 
losing registrar _expect_ currently for com/net/jobs due to the registry 
not handling contact details [ which is another working group]

> • Every registration is a registration by someone.

Yes

> Some registrations
> are the source of abuse against other networks,

Never. Domains cant "abuse other networks".
A 'service' can abuse, which may (or may not) somehow be related to a 
domain registration, but the domain itself is not capable of doing any 
abuse at all

> • In gTLDs, most (all?) include some cost that accrues to the 
> registrant
> in exchange for the registration.

tlds may have a cost, and sometimes it's to the registrant (it is at 
least "on behalf of" the registrant)

> The identities of the parties responsible for keeping
> the data up to date and for paying the registration are required in
> order to ensure continued operation by the same party at the time of
> expiry of a registration term.

Which only needs to be known by the registrar (for maintaining the 
registration) and the registry ( in case the registrar somehow fails ) 
and not a reason to make any of the data "public"

> I agree.  AFAICT, the above list covers what is normally accessible in
> the whois output of contracted thick registries today, and indicates
> places where anonymous access seems optional.

Rob
--
Rob Golding   rob.golding at astutium.com
Astutium Ltd, Number One Poultry, London. EC2R 8JR

* domains * hosting * vps * servers * cloud * backups *