🇹🇫 .tf — French Southern Territories

The .tf is a country-code top-level domain (ccTLD) operated by AFNIC (Association Française pour le Nommage Internet en Coopération). This article documents the technical, operational, and contractual requirements for the TLD, along with special considerations for registry, registrar, and domain management.

General Information

Domain Lifecycle

Grace periods

Launch Phases & Availability

Domain Characteristics

Contacts & Roles

Nameservers & DNS

Transfer Policy

WHOIS & RDAP

Dispute Resolution

Contact Attributes

AFNIC models every contact as either a natural person (PP — personne physique) or a legal entity (PM — personne morale), and that choice decides which of the remaining attributes apply.

Two things set the AFNIC TLDs apart from most ccTLDs:

• the attributes are required on every contact role — registrant, administrative, and technical — not on the registrant alone;
• the roles do not have to agree. A PP registrant with a PM technical contact is a normal .tf registration.

Natural person (PP)

AFNIC_REACHABLE_STATUS is only sent to the registry when AFNIC_REACHABLE_MEDIA is set alongside it — a status on its own is dropped, because AFNIC carries the confirmation as an attribute of the channel.

Legal entity (PM)

The five identifiers apply to the company and other legal statuses. An entity may supply several; AFNIC accepts them together.

Associations

An association identifies itself through its WALDEC number, or through its publication in the Journal Officiel — one of the two is mandatory, and a create that carries neither is rejected before it reaches the registry.

Supply either AFNIC_PM_ASSOC_WALDEC, or AFNIC_PM_ASSOC_PUBL_DATE together with AFNIC_PM_ASSOC_PUBL_PAGE. When a WALDEC number is present it is what gets sent, and the publication attributes are ignored. AFNIC_PM_ASSOC_DECL and AFNIC_PM_ASSOC_PUBL_ANNOUNCE only add detail to the publication route; neither satisfies the requirement on its own.

{
  "type": "policy-validation-error",
  "title": "Policy Validation Error",
  "status": 422,
  "code": "ERROR_POLICY_VALIDATION",
  "detail": "PM association requires AFNIC_PM_ASSOC_WALDEC or (AFNIC_PM_ASSOC_PUBL_DATE + AFNIC_PM_ASSOC_PUBL_PAGE)"
}

Registry-managed attributes

AFNIC_RESTRICTED_PUBLICATION is read back from AFNIC when a contact is imported or read; it is not sent on a contact create, so setting it on an attribute set has no effect.

Example attribute sets

A natural person:

curl "$OPUSDNS_API_BASE/v1/contacts/attribute-sets" \
  --request POST \
  --header "X-Api-Key: $OPUSDNS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "label": "TF registrant - individual",
    "tld": "tf",
    "attributes": {
      "AFNIC_CONTACT_TYPE": "PP",
      "AFNIC_PP_FIRST_NAME": "Pierre"
    }
  }'

An association identified by its Journal Officiel publication:

curl "$OPUSDNS_API_BASE/v1/contacts/attribute-sets" \
  --request POST \
  --header "X-Api-Key: $OPUSDNS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "label": "TF registrant - association",
    "tld": "tf",
    "attributes": {
      "AFNIC_CONTACT_TYPE": "PM",
      "AFNIC_PM_LEGAL_STATUS": "association",
      "AFNIC_PM_ASSOC_PUBL_DATE": "2015-03-14T00:00:00Z",
      "AFNIC_PM_ASSOC_PUBL_PAGE": 118
    }
  }'

⚠️ Reusing one contact for every role? AFNIC_CONTACT_TYPE is required on the administrative and technical contacts too, not only the registrant. A create that carries it on the registrant alone is rejected before it reaches the registry:

{
  "type": "policy-validation-error",
  "title": "Policy Validation Error",
  "status": 422,
  "code": "ERROR_POLICY_VALIDATION",
  "errors": [
    {
      "detail": "Attribute 'AFNIC_CONTACT_TYPE' is required for admin contacts",
      "pointer": "contacts.admin[0].attributes.AFNIC_CONTACT_TYPE"
    }
  ],
  "detail": "Policy validation failed"
}

json

These constraints are machine-readable: each possible_attributes entry returned by GET /v1/tlds/tf carries its own type, values, required, contact_roles, and conditions fields. Build forms from the specification rather than hard-coding the PP/PM split.

Contact handles

AFNIC assigns contact handles itself — a handle cannot be chosen when creating a contact, and an existing AFNIC handle cannot be adopted through the API.

Transfers and registrant changes

The registrant is not part of a .tf transfer request: an inbound transfer keeps the registrant the domain already has at the registry. The administrative and technical contacts are supplied with the transfer as usual.

To move a domain to a different holder, transfer it first and then change the registrant with a domain update — .tf supports a registrant change through PATCH /v1/domains/{domain_reference}.