DNS

Publish one TXT record to verify who can proceed with sign-in.
This record is the KPF authentication framework (Kie.la Policy Framework).
Its syntax follows the SPF mail framework (Sender Policy Framework).

Register the application in Console → Applications first.

Fields

What to type in the DNS panel.

Field Value
Type TXT
Name kpf.<uuid>.<domain> — or kpf.<uuid> when the zone is added for you.
Value v=kpf1 env:dev|prod name:AppName include:… ip4:… ip6:… ptr:…

Tokens in the TXT value

Token What to write
v=kpf1 Always this exact token, so the record is recognized as KPF.
env:dev / env:prod Required. env:dev while you integrate; env:prod when real users sign in.
name: Required. Application name, exact spelling and case (name:MyShop).
include: Required, at least one. Hostname of the sign-in prompt — the host of the application URL.
ip4: At least one ip4: or ip6:. Public IPv4 of that server. A range is allowed (ip4:203.0.113.0/24).
ip6: Public IPv6 of that server, if it has one. A range is allowed.
ptr: Hostname from reverse DNS, required in production.

What Kie.la checks at login

env:dev and env:prod

The TXT record must include a mandatory env: token.

TTL

Maximum TTL of 360 in development (env:dev). In production (env:prod), minimum TTL 43200 (12 h).

Reverse DNS (PTR) in production

At sign-in, Kie.la checks that your application server's public IP has a reverse DNS (PTR) record pointing to a hostname matching the PTR record in your KPF. Ask your hoster or network team to publish PTR for each public IP of the sign-in prompt.

When DNS is not required

Local or IP authentication domains (localhost, a raw IPv4) skip DNS checks at login.

Reserved for development on a machine that is not a public hostname.

Related