gtlds
Methodology

Facts need
provenance.

The site treats data provenance as part of the product. Every field should be traceable to a source, a deterministic derivation, or clearly labeled editorial context.

01Source hierarchy

Use each authority for the fact it actually owns.

IANA Root Zone DatabaseTLD record, classification, sponsoring organisation, name servers, registry service links and delegation reports. IANA delegated TLD listCurrent membership of the delegated top-level namespace. IANA RDAP bootstrapProtocol bootstrap mapping from DNS namespaces to RDAP services. ICANN Registry AgreementsRegistry agreement status and explicit contractual attributes such as applicable specifications. IANA IDN Practices RepositoryRegistry-submitted IDN tables and related implementation material.
02Fact model

Four buckets. No blurry middle.

Sourced fact

Copied or normalized from an authoritative record, such as an IANA sponsoring organisation or an ICANN agreement status.

Deterministic derivation

Computed from source data with an explicit rule, such as “currently delegated” from current root membership or an IDN A-label/U-label transformation.

Editorial explanation

Plain-language context that explains a protocol or role without pretending to be registry-specific policy.

Unknown / not published

When a source does not provide the answer, the site says so. Absence of evidence is not converted into a confident field value.

03Normalization

Preserve source dimensions instead of flattening them.

A single friendly “type” field is tempting and dangerous. The normalized record keeps DNS/root classification, delegation state, ICANN agreement state, and agreement attributes separate so the interface can explain how they relate without silently rewriting them.

Displayed fieldAuthorityRule
delegatedIANA

Membership in the current delegated TLD set.

iana_typeIANA

Preserve the classification published for the root-zone record.

sponsoring_orgIANA

Do not replace with an ICANN operator field.

agreement_statusICANN

Stored independently from DNS delegation state.

brand / communityICANN

Only when the applicable agreement material explicitly supports the attribute.

dnssecRoot DNS

Derived from authoritative DS presence at the root.

04Validation

The importer should be harder to fool than the UI.

  1. 01
    Schema checks

    Required source fields, labels, URL shapes and expected enumerations are validated before output is accepted.

  2. 02
    Namespace checks

    Current delegation is validated against the authoritative delegated set rather than inferred from a registry agreement page.

  3. 03
    IDN checks

    A-label and U-label values must normalize and round-trip correctly before they become canonical routes or search keys.

  4. 04
    Diff checks

    Large or unexpected changes in counts, field coverage, source structure or classifications stop the update for review.

  5. 05
    Provenance checks

    Published factual fields must retain a source identifier or deterministic derivation rule.

05Freshness

A timestamp is only useful when it says what changed.

Source fetch time, source-record update time, and page build time are different concepts. The production dataset should preserve them separately. Page lastmod values should change only when the rendered record meaningfully changes.

Do not fake freshness.

A rebuild timestamp should never imply that an upstream registry record changed that day.

Open data reference Why the project exists