‘Experts can move forward together without ministerial instructions.’
‘SQL also took time, which was later called ‘Structured Query Language.’
‘EU countries work on NIS2 security regulations.’

The data technical RDAP protocol should stabilize

The Registration Data Access Protocol (RDAP) was created as a replacement of the WHOIS (port 43) protocol.
RDAP was developed by the technical community in the Internet Engineering Task Force (IETF).

How US/EU countries can make RDAP output publicly readable too

Technical and textual modeling of forms:
https://rdap.hostingtool.nl/modeling_domain/
https://rdap.hostingtool.nl/modeling_email/

How registry menus can be transparent, eg on https://regmenu.sidn.nl

Modeling of a policies and procedures screen including laws and regulations:
https://rdap.hostingtool.nl/modeling_menu/

How ‘Who Is’ rules can be formulated to comply with the EU’s NIS2 Security Directive

About restrictions

1. issue: Which country applies for jurisdiction and how can holdership be verified?
   suggestion: The country of the real domain user is leading for country-specific Domain Services;
2. A domain can be transferred to another holder and also under the registration conditions for its TLD, if
   1. prescribed by law;
   2. determined in a living will;
   3. agreed by the holder if a natural person;
   4. agreed by the holder if listed in the Commercial Register;
   5. decided by the domain’s registry;
   6. decided by the real holder’s country-specific Domain Service; or
   7. based on court decision;
3. A purchase deed may also state that associated domains are transferred immediately upon delivery;
4. Upon the death of a personal holder, the heirs become responsible for his domain(s) and/or hosting. If not privacy-sensitive, continuation is permitted unless otherwise specified in a will;
5. Liabilities for a legal entity’s estate include hosting and associated domains;
6. For a control cycle, the period of registration or renewal of a domain does not exceed one year;
7. Charging a small or substantial fee by a registry, as well as a registrar, for updating data, such as immediately after a domain transfer that has already been charged, hinders data maintenance and is therefore not billable;
8. A change of a registry, registrar or reseller’s own data is also not hindered by a fee;
9. Using RDAP data to act maliciously or as a disproportionate revenue model is not allowed.

About duties

1. A domain’s registrant, or the person who ordered the registration, is primarily responsible for the domain’s contact and registrant information;
2. A registry, a registrar and a reseller are primarily responsible for own trade and personal information;
3. Reverse DNS lookup also called reverse DNS resolution (rDNS), of the domain name associated with an IP address, is transparent;
4. The domain name in a server name determines who can be contacted, for security and possible liability, especially with a server that is not managed by the hosting provider;
5. With regard to data not directly maintained by them, a registry, registrar and reseller have responsibilities according to their capabilities;
6. When contacting a person, the requested attention must be in proportion to the reported case;
7. A request from a third party regarding data is treated seriously, with the requested handling not excessively consuming resources;
8. After a change in the domain holder’s details, the registry informs the domain’s administrative contact with all relevant holder details;
9. IP block holder data requires flexibility similar to a domain’s RDAP;
10. The registry provides a readable and informative RDAP query screen for auditing and public insight;
11. Any directive is preceded by a breakdown of responsibilities and modeling that can be programmed directly.

About data

1. For RDAP file management, the respective Commercial Register generates and supports web_ids;
2. Querying the Commercial Register works in US English;
3. Interface fields can and must be functionally readable as well as work technically.
   Note: the EU term ‘Essential Provider’ makes it really complicated;
4. RDAP data exchange is in, future proof, variable-width ‘UTF-8’ character encoding;
5. IPv6, the Internet Protocol version 6, is supported;
6. To protect the customer, the trade name, otherwise the personal name if public, is in the url address bar;
7. Under GDPR privacy regulations, RDAP deletion means full deletion;
8. The registry is clear about privacy protected field values with derived fields such as ‘registrant_shielding’;
9. The ‘admin’ and ‘tech’ information would benefit from a ’emergency_contact’ field. It is up for discussion.

- SIDN's Whois zone shows an incorrect 'expiration_date' due to the lack of a Whois protocol 'deletion_date' field;
- SIDN's Whois is not sufficient in Zulu time by showing 00:00:00;
- SIDN's Whois via Python does not contain the holder name for an active 'business use' domain;
- SIDN's RDAP does not inform about the 'redemption period' if 'pending delete' exists;
- SIDN's RDAP shows the 'expiration' date and time impossibly after the 'deletion' date and time;
- SIDN's RDAP damages 'expiration' because it is not as precise in years after 'registration' (in Zulu date-time);
- ICANN's RDAP in generic TLD zones could use a requirement for 'deletion' once 'expiration' has passed;
- ICANN's Whois/RDAP lookups could use a responsibility-based field ordering, like mine;
- ICANN's Whois/RDAP lookups could use some explanatory guidance, like mine;
- Domains in the final stage can be found on https://www.catchtiger.com/nl/domeinnaam-veilingen/ and for gTLD on https://www.expireddomains.net/expired-domains/.

Just a .com gTLD domain during the recovery grace period:

status:
+0: redemption period -> Note: correct information

events:
+0:
++eventAction: registration
++eventDate: 2022-09-20T09:52:07Z
+1:
++eventAction: expiration -> Note: at ICANN no date and time of deletion
++eventDate: 2024-09-20T09:52:07Z
+2:
++eventAction: last changed
++eventDate: 2024-09-22T04:07:20Z
+3:
++eventAction: last update of RDAP database
++eventDate: 2024-09-26T13:03:54Z

---------------------------------

Just a .com gTLD domain during the deletion phase:

status:
+0: client transfer prohibited
+1: pending delete -> Note: correct information

events:
+0:
++eventAction: registration
++eventDate: 2022-07-20T11:03:12Z
+1:
++eventAction: expiration -> Note: at ICANN no date and time of deletion
++eventDate: 2024-07-20T11:03:12Z
+2:
++eventAction: last changed
++eventDate: 2024-09-21T11:03:10Z
+3:
++eventAction: last update of RDAP database
++eventDate: 2024-09-27T10:41:09Z

---------------------------------

Just a .nl ccTLD domain during the recovery grace and deletion period:

status:
+0: pending delete -> Note: 'redemption period' misses

events:
+0:
++eventAction: registration
++eventDate: 2023-09-13T04:31:05Z
+1:
++eventAction: last changed
++eventDate: 2024-09-12T02:31:06Z
+2:
++eventAction: expiration
++eventDate: 2024-10-22T02:31:06Z -> Note: inaccurate date and time of in fact scheduled deletion
+3:
++eventAction: deletion
++eventDate: 2024-09-12T02:31:05Z -> Note: inaccurate date and time of in fact expiration in the past
+4:
++eventAction: last update of RDAP database
++eventDate: 2024-10-14T15:39:07Z

---------------------------------

Just a .fr ccTLD domain during the recovery grace and deletion period:

status:
+0: client hold
+1: pending delete -> Note: correct information
+2: redemption period -> Note: correct information

events:
+0:
++eventAction: registration
++eventDate: 2017-08-16T01:11:38Z
+1:
++eventAction: expiration
++eventDate: 2024-08-16T01:11:38Z
+2:
++eventAction: last changed -> Note: 'last update of RDAP database' misses
++eventDate: 2024-09-22T12:31:23.217123Z
+3:
++eventAction: deletion
++eventDate: 2024-09-22T12:31:23.217123Z -> Note: wrong impossible information

-----------------------------------

Just a .frl geoTLD domain during the recovery grace and deletion period:

status:
+0: pending delete -> Note: correct information
+1: server hold
+2: server transfer prohibited
+3: redemption period -> Note: This correct information can help SIDN.

events:
+0:
++eventAction: registration
++eventDate: 2023-12-05T12:35:41.0Z
+1:
++eventAction: expiration
++eventDate: 2024-12-05T23:59:59.0Z -> Note: 'deletion' date-time would help.
+2:
++eventAction: last update of RDAP database
++eventDate: 2024-12-07T00:29:07.0Z
+3:
++eventAction: last changed
++eventDate: 2024-12-04T20:25:13.0Z

About visibility

1. The Registrar ‘Abuse’ fields are visible and located in a Registrar information block;
2. The route security ‘DNSSEC’ yes / no field is located in a name server information block;
3. To check off, the registrant ‘organization’ field and value are shown;
4. To check off, the registrant ‘full_name’ (=> presented_name) field and value are shown.

About insights

1. For segregation of duties, a domain holder is primarily responsible for his domain data;
2. Legitimate business operations require an existing and commercially visible name of the actual user.;
3. The Registrar ‘Abuse’ information provides a contact option for a third party.

About emailing

1. Mail delivery to a RDAP contact may not be delayed by forwarding manually;
2. Forwarding can be authorized. SPF ‘~all’ setup combines with forwarding using SRS.
   See also my https://webhostingtech.nl/monitoring-email/solve-exim-issues/

About costs

1. Registration is billable for a new domain / other Registrar combination, and renewal;
2. For identification, the data infrastructure is subject to indirect costs;
3. For Registrar identification, updating data is subject to indirect costs.

My key points for working RDAP

1. RDAP lookup is intended for both technical and functional purposes;
2. A correct domain registrant and contacts need periodical verification;
3. Regulations can work after narrowing down physical scenarios first;
4. Authorization for legal requests would work through the country-specific registers;
5. Country-specific registers are better able to handle incorrect registrations than a registry;
6. Sovereign countries can do without the central gateway, accreditation authority and identity providers;
7. Technical specification, standardization of cost handling and legal regulation may provide high availability and reliability;
8. In RDAP, domain business purposes can be transparent without any individual privacy concerns;
9. Legal coordination on country level first of all requires an adequate data structure;
10. US/EU lawyers can work together to technically cover country-specific needs;
11. Similar to user level, technical personnel often deal passively with necessary actions;
12. Technology-infused delivery of legal preparation isn’t too hard to achieve;
13. When duties can be separated, separation can help, eg four eyes principle;
14. RDAP tools that actually work require to-do lists for all expertise;
15. A model to verify hosting is not a real model if it includes a person doing this.

About hiding domain information
https://en.wikipedia.org/wiki/Domains_by_Proxy

List of ICANN-accredited registrars
https://www.icann.org/en/accredited-registrars

Whois Data Reminder Policy (WDRP) for compliance
https://www.icann.org/resources/pages/registrars/consensus-policies/wdrp-en

Querying databases that store the registered users or assignees of an Internet resource
https://en.wikipedia.org/wiki/WHOIS

Current iteration of the WHOIS protocol drafted by the Internet Society
https://datatracker.ietf.org/doc/html/rfc3912

Political points

1. issue: Registrars are pressed for tracing further data in legal matters.
   suggestion: Opt, through a web ID that validates, for reference to country-level data;
2. issue: Registries make verification work. A registry can decide on a domain registrant name.
   Periodic verification is technically possible after entering a web ID.
   Strict verification, without any interpretation, is case sensitive and includes dots.
   Registrant, registrant name, registrar, registrar name, reseller and reseller name are relevant.
   Note: Eg Google Search provides a ‘google-site-verification’ value to put in the DNS settings.
   suggestion: Opt for technical specification so that countries can realize data retrieval;
3. issue: There are so-called ‘thick’ and ‘thin’ Whois servers, with one or two queries.
   suggestion: If performance demands, choose one type of Whois server;
4. issue: The DNSSEC field (suite of security extensions to the DNS) needs proper explanation.
   suggestion: Field definition and its explanation meeting all needs are to-do and to address;
5. issue: Traffic from an Internet Service Provider can be blocked, for example by Microsoft.
   suggestion: New legislation to require justification would help.

Legal points

1. issue: A possible change of the domain’s registrant name must also be justified.
   suggestion: US/EU lawyers agree how to define legal name change of the registrant;
2. issue: Use of the web ID to be introduced, should be restricted.
   suggestion: US/EU lawyers agree how to define use of a fake web ID as forgery;
3. issue: Search results are still published for a canceled domain.
   suggestion: US/EU lawyers agree to publish if active and the last transaction is up to one year old;
4. issue: A customer may register / renew through a registry for longer than one year.
   suggestion: US/EU lawyers agree to register / renew for one year for realistic registration;
5. issue: A registry can now decide unilaterally in a dispute with a registrar.
   issue: Country-specific registers can evolve into professional dispute resolution.
   suggestion: US/EU lawyers try to improve handling of disputes;
6. issue: A registrant, registrar and registry do refuse to act on a spelling mistake.
   suggestion: US/EU lawyers introduce a legal limitation in case of misspelling.
   Eg the Dutch ‘Vereniging Van Registrars’ exists when spelled as ‘Vereniging van Registrars’;
7. issue: Checking Whois for financial statements has not yet been analyzed as legal.
   issue: Segregation of duties of the contacts and answer time require attention too.
   suggestion: US/EU lawyers update the analyzed six legal gTLD Whois purposes;
8. issue: Primary responsibility and/or physical capability need a clear segregation of duties.
   need: A top-level domain zone (the end part of a web domain) is approved by ICANN.
   need. A domain zone is assigned by the ICANN to a domain registry to manage domains.
   need: A domain registry owns and has to take care of domains in their zone.
   need: A domain registrar takes care of domain reservations and IP address routing.
   need: A domain reseller may be responsible for the processing of the holder’s data.
   need: A web domain under a (second-level) top-level domain is unique worldwide and can be freely chosen under certain rules.
   need: A domain registrant holds a domain from a registry.
   need: A registry assigns a domain to a registrant and cancels it if necessary.
   need: Primary responsibility limits to registrant (/ reseller) level of physical capability.
   need: Support attaches a report by a third party to a customer account.
   need: The administratively responsible desk answers a request, and forwards it if necessary.
   need: A technical contact responds to resolve a reported malfunction.
   need: A domain registrant’s liability for harmful content and actions is limited, based on separated responsibilities of the contributing parties.
   suggestion: US/EU lawyers work towards basic explanations in short sentences;
9. issue: Privacy for admin-c is not a problem by using a specific functional email address.
   suggestion: US/EU lawyers agree on admin_email for legal matters, change of registrant;
10. issue: A reseller may have agreements such as to protect customer data.
    suggestion: US/EU lawyers write generic reseller conditions (see eg the .nl zone);
11. issue: Court decisions deal with issues related to ownership aspects of web domains.
    need: A domain is kept out of liquidation if another intended registrant paid for it.
    need: Domains are included in business ownership transfers.
    suggestion: US/EU lawyers introduce specific web domain regulation;
12. issue: A web domain may contain confidential information from the previous registrant.
    suggestion: US/EU lawyers define moved data, similar to letter secrecy;
13. issue: Country-specific registers need to start validating domain ownership.
    issue: A registrar can mask with an existing name such as ‘Privacy Protected by Hostnet’.
    issue: The EU puts pressure on companies that cannot take all responsibility for failures.
    issue: The registrant and his country-specific register can perform checks and adjustments.
    need: The country-specific register provides a domain overview of a company behind its login.
    need: The country-specific register provides a Whois check of a company behind its login.
    need: The country has a duty of care with regard to the correctness of the registered data.
    suggestion: US/EU lawyers formulate a country’s legal basis for a web domain overview.

Fields and values

1. issue: Web browsers may check on annual verification (such as for HTTPS).
   suggestion: A new ‘domain_event_verification_retrieved’ field would be informative when a year passes;
2. issue: A web ID works effectively to verify a registrant and one of the registrant’s names.
   E.g. ‘icann.org’ of ICANN (incorporated, mutual-benefit nonprofit corporation ‘iCANN’).
   E.g. ‘ca.gov’ in Whois for ‘.gov’ of organization ‘State of California’.
   With the many spelling mistakes, acceptance of auditing is still a long way off.
   suggestion: Specify a web ID format, such as the IBAN bank account code.
   Registrars and domains (registrant and reseller) fields with a 34 character code, may have a two letter (ISO) country code, two digits for internal validation, ‘COMM’ and up to 26 characters within a country, such as ‘NL88COMM01234567890123456789012345’, in uppercase;
3. issue: Protected field values need proper communication.
   issue: A field ‘shielding’ cannot be a field in the address table that is not about where used.
   suggestion: Each zone shows its zone specific Protected field content.
   registrant_shielding: ‘name,email,tel,address’
   admin_shielding: ‘name,tel,address’
   tech_shieldind: ‘name,tel,address’;
4. issue: The required IT continuity requires a tech2 contact, I suppose a emergency contact.
   issue: The tech-c field is blurred with multiple values.
   suggestion: A new entity field emergency-c.

Country-level

1. issue: Country-level web IDs are required to retrieve the registrant.
   Country Commercial Registers can meet an important need.
   Whether or not data is displayed is country-specific.
   Lawyers can negotiate carefully at country level (not the EU).
   Shared sovereignty, as in the EU, would slow down negotiation.
   suggestion: Country-level politicians agree on implementation of web IDs;
2. issue: Country-level registers need to guarantee web IDs.
   Note: The Sarbanes-Oxley Act also took time for countries to adopt.
   suggestion: Country-level registers adopt a generic data structure;
3. issue: A country-level register, such as KVK in NL, charges for solid lookups.
   suggestion: Verification in a country-level register should become free of charge;
4. issue: Country-level registers may charge for enabling web IDs.
   suggestion: Verification costs for a country-level register must be indirect.

Application design

1. issue: A regional server / application for Whois must function without centralization.
   At table level the contact data already have their specific table structure.
   At XML level, the large number of fields, such as ‘registrant_contact_id’, is not a problem.
   A registry doesn’t need to immediately convert field names, without standardization.
   Search based on the web ID must be able to retrieve from / via each country-level register.
   Unicode works to handle all kinds of character sets worldwide.
   A Whois tool such as https://www.ip2whois.com/ is not convenient enough to use.
   Data sharing with registrars for the .nl zone might conflict with GDPR:
   https://github.com/timboormans/SIDN-XML-WHOIS – Retrieval is therefore further limited.
   My data sharing with RDAP: https://github.com/janwillemstegink/rdap_view_model
   suggestion: An application based on HTML / PHP / Python / XML / Docker / Azure;
2. issue: The UK is not a valid domicile anymore to hold a .eu domain as former EU country.
   suggestion: Such a change requires simple validation to check and maintain;
3. issue: Registries may charge for a web ID enabled Whois application.
   suggestion: Costs of a regional server / application must be indirect.

Cost handling

1. issue: Economies of Scale cost advantages are achieved in both period and variable costs.
   suggestion: A variable cost advantage is reduced, even to zero;
2. issue: Legal updating at a registry can be a variable cost component equal to zero.
   suggestion: Include updating details in annual costs and no longer pass on variable costs;
3. issue: A registry looks over and manages its registrar’s information. Charging looks illegal.
   suggestion: Include updating registrar details in period costs for a registrar;
4. issue: Volume discount and direct debit discount for ‘.nl’ are called ‘expenses’ by SIDN.
   issue: Incentive programs for ‘.nl’ at SIDN up to 0.40 euro off the domain fee are significant.
   E.g. 8% volume discount from 100,000x and 2.5% direct debit discount at SIDN.
   suggestion: Registries do not discount anything other than a fair volume discount;
5. issue: Customers unnecessarily commit for two or three years.
   suggestion: Customers simply register and automatically renew for one year.