[gnso-rds-pdp-wg] Some reg'n data I think necessary (was Re: GNSO Next-Gen RDS PDP Working Group teleconference)
Rob Golding
rob.golding at astutium.com
Mon Mar 21 03:37:01 UTC 2016
> • 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 *
More information about the gnso-rds-pdp-wg
mailing list