Pingback Permitted From (PPF)

3.1. Relationship to SPF

PPF is intentionally modeled on the Sender Policy Framework (SPF) [RFC7208]. The two protocols address structurally identical problems: a sender claims to be acting on behalf of a domain, and a receiver must determine whether the domain authorizes that sender before performing potentially expensive or dangerous follow-up work. SPF gates message acceptance; PPF gates source-resource fetching.¶

This document deliberately reuses SPF's design choices wherever the underlying problem is the same:¶

• DNS as the policy publication layer, exploiting existing global caching and operational practice;¶

• a TXT record at a well-known prefix relative to the domain being authorized;¶

• a small, fixed mechanism vocabulary evaluated left-to-right with first-match semantics;¶

• include as a delegation primitive, with the SPF-style requirement that the included policy must return pass for the include to match;¶

• a DNS-work limit inspired by SPF's limit of ten DNS-interactive terms, together with an explicit maximum include depth of 5; and¶

• a result vocabulary with the same names and meanings (pass, fail, none, permerror, temperror).¶

PPF omits SPF features that do not apply to linkbacks. There is no mx mechanism, because linkback senders are not mail exchangers. There are no qualifiers (+, -, ~, ?) and no soft-fail or neutral states. PPF handles gradual deployment through receiver enforcement modes rather than per-mechanism qualifiers, so a binary pass/fail policy is simpler to reason about. There is no redirect modifier because include is sufficient for the deployment patterns observed for linkbacks.¶

Implementers familiar with SPF should find PPF immediately recognizable. Where this document is silent on a corner case that SPF addresses, SPF's behavior is generally a reasonable starting point, though only the text in this document is normative.¶

3.2. Choice of DNS Owner Name Prefix

The DNS owner name prefix for PPF policies is _pingback, despite this document being protocol-neutral. Three alternatives were considered.¶

_ppf is the most precise label and aligns with the protocol name. It was rejected because PPF policies are published primarily by web site operators using common DNS management interfaces. An operator inspecting a TXT record named _ppf has no contextual cue for what it controls; a record named _pingback is self-describing for an audience that recognizes Pingback as a category of web traffic.¶

_linkback is more accurate as a category term but has limited operational recognition. Pingback is by a wide margin the most widely deployed linkback protocol, and operators searching for relevant documentation are more likely to find it under "pingback".¶

_pingback was therefore retained. The label refers to the category of web traffic the policy authorizes, not to a specific protocol. A single PPF record at _pingback.<domain> authorizes senders for any linkback protocol that has a binding for PPF, including Pingback 1.0, Webmention, and future protocols. Protocol bindings MUST NOT define alternative DNS owner names for PPF policies.¶

3.3. Use of Explicit none Policies

A PPF record containing only v=ppf1 is syntactically valid and authorizes no senders. The Record Format section nonetheless recommends that generators emit v=ppf1 none rather than the bare version tag.¶

The reasoning parallels the choice of DNS owner name prefix. PPF records are read and written by site operators using DNS management tools. An operator encountering a record that contains only v=ppf1 has no obvious indication of whether the policy is incomplete, mistakenly truncated, or deliberately empty. A record reading v=ppf1 none makes the same intent visible at a glance, with a keyword whose meaning is self-evident.¶

The keyword none was preferred over alternatives such as an explicit fail keyword or an SPF-style deny-all qualifier. PPF defines fail as an evaluation result, not a policy keyword; using the same name for both would force operators to learn the result vocabulary in order to write a basic policy. none reads as the declaration "none authorized", which matches the operator's perspective rather than the implementer's.¶

5.1. ABNF

The following ABNF uses the notation of [RFC5234].¶

ppf-record  = version [1*SP policy]
version     = "v=ppf1"
policy      = "none" / mechanisms
mechanisms  = mechanism *(1*SP mechanism)
mechanism   = "a" /
              "a:" domain-name /
              "ip4:" ip4-network /
              "ip6:" ip6-network /
              "include:" domain-name

domain-name = label *("." label) ["."]
label       = let-dig [*61(let-dig-hyp) let-dig]
let-dig     = ALPHA / DIGIT
let-dig-hyp = let-dig / "-"

ip4-network = IPv4address ["/" 1*2DIGIT]
ip6-network = IPv6address ["/" 1*3DIGIT]

IPv4address and IPv6address are imported from [RFC3986]. domain-name is an ASCII DNS domain name in presentation form; internationalized names MUST use A-labels [RFC5890]. Each label MUST be between 1 and 63 octets. The wire-format domain name, including the root label, MUST NOT exceed 255 octets. Implementations MUST validate IP addresses, prefix lengths, and DNS names before evaluating mechanisms.¶

Record generators MUST emit the version tag and mechanism names in lowercase. Receivers and linkback proxies MUST compare the version tag and mechanism names case-insensitively for ASCII letters. Domain names are compared using DNS case-insensitive comparison.¶

A record containing only v=ppf1 is valid and is equivalent to v=ppf1 none. Generators SHOULD emit v=ppf1 none rather than the bare version tag.¶

The none policy MUST NOT appear with any other mechanism. A record such as v=ppf1 none ip4:192.0.2.1 is invalid and evaluates to permerror.¶

5.2. Mechanisms

Mechanisms are evaluated from left to right. The first matching mechanism determines that the sender is authorized. If no mechanism matches, the result is fail.¶

a

Authorizes IP addresses resolved from the host component of the source URI. For an IPv4 sender, this mechanism performs an A lookup; for an IPv6 sender, it performs an AAAA lookup.¶

a:<hostname>

Authorizes IP addresses resolved from the specified hostname. For an IPv4 sender, this mechanism performs an A lookup; for an IPv6 sender, it performs an AAAA lookup.¶

ip4:<addr-or-cidr>

Authorizes an IPv4 address or IPv4 CIDR range.¶

ip6:<addr-or-cidr>

Authorizes an IPv6 address or IPv6 CIDR range.¶

include:<domain>

Evaluates the PPF policy at _pingback.<domain>. The include mechanism matches only if the included policy evaluates to pass for the sender IP address.¶

none

Explicitly authorizes no senders. A policy of none evaluates to fail for every sender IP address.¶

The a mechanism is convenient for self-hosted sites whose web-serving addresses are also valid linkback-sending addresses. It is not appropriate for sites using origin-hiding CDNs, split-horizon DNS, or managed outbound infrastructure unless the operator intends those resolved addresses to be authorized senders.¶

8.1. TXT Record Selection

A TXT RRset MAY contain records used for unrelated purposes or other PPF versions. Receivers and linkback proxies MUST ignore TXT records whose first token is not exactly v=ppf1, using ASCII case-insensitive comparison.¶

A TXT RR containing multiple character strings is parsed as the concatenation of those character strings, in order, without inserted whitespace. This matches the DNS TXT representation and avoids ambiguity introduced by DNS presentation formats.¶

If more than one TXT RR at the PPF owner name has v=ppf1 as its first token, the policy is ambiguous and evaluation returns permerror.¶

8.2. CNAME Handling

Receivers and linkback proxies MAY follow CNAME aliases encountered while resolving PPF owner names or mechanism hostnames, subject to ordinary DNS resolver behavior and the DNS lookup limits in this document. DNS lookups caused by CNAME chasing count toward the DNS lookup limit.¶

If CNAME processing results in a loop or resolver error, evaluation returns temperror or permerror according to the resolver error.¶

8.3. DNS Lookup Limits

To limit resource consumption, PPF evaluation MUST NOT perform more than 10 DNS queries after the initial TXT query for _pingback.<source-domain>. Every subsequent query caused by evaluation counts toward this limit, including included-policy TXT queries, A or AAAA queries, and queries caused by CNAME processing.¶

Include depth MUST NOT exceed 5. The top-level policy is depth 0. A policy reached by one include is depth 1.¶

If the lookup limit or include-depth limit is exceeded, evaluation returns permerror.¶

9.1. a

For an IPv4 sender, the a mechanism resolves the source domain using an A lookup. For an IPv6 sender, it resolves the source domain using an AAAA lookup. If the sender IP address is equal to any returned address, the mechanism matches.¶

If all required DNS lookups complete successfully but return no usable addresses, the mechanism does not match.¶

If a temporary DNS error occurs while evaluating the mechanism, evaluation returns temperror.¶

9.2. a:<hostname>

For an IPv4 sender, the a:<hostname> mechanism resolves the specified hostname using an A lookup. For an IPv6 sender, it resolves the hostname using an AAAA lookup. If the sender IP address is equal to any returned address, the mechanism matches.¶

The hostname MUST be a valid DNS name. If it is not valid, evaluation returns permerror.¶

9.3. ip4:<addr-or-cidr>

The ip4 mechanism matches when the sender IP address is an IPv4 address within the specified IPv4 address or CIDR range.¶

The prefix length, if present, MUST be between 0 and 32 inclusive. An invalid IPv4 address or prefix length makes the policy invalid and evaluation returns permerror.¶

IPv4-mapped IPv6 addresses MUST NOT be treated as IPv4 addresses for ip4 matching unless the protocol binding explicitly normalizes them before invoking PPF. Bindings that can receive IPv4-mapped IPv6 peer addresses SHOULD normalize them to IPv4 before PPF evaluation when that reflects the actual network peer.¶

9.4. ip6:<addr-or-cidr>

The ip6 mechanism matches when the sender IP address is an IPv6 address within the specified IPv6 address or CIDR range.¶

The prefix length, if present, MUST be between 0 and 128 inclusive. An invalid IPv6 address or prefix length makes the policy invalid and evaluation returns permerror.¶

9.5. include:<domain>

The include mechanism evaluates the PPF policy at _pingback.<domain> using the original sender IP address.¶

If the included policy returns pass, the include mechanism matches.¶

If the included policy returns fail, the include mechanism does not match and mechanism evaluation continues with the next mechanism in the including policy.¶

If the included policy returns temperror or permerror, evaluation of the including policy returns that result.¶

If the included policy returns none, evaluation of the including policy returns permerror. This mirrors SPF include behavior: include is a request to evaluate another policy for a pass result, not a textual inclusion mechanism.¶

Include processing is subject to the DNS lookup and include-depth limits defined in this document. Implementations MUST detect include loops. If an include loop is detected, evaluation returns permerror.¶

10.1. Strict Mode

In strict mode, a receiver or linkback proxy proceeds to source-resource verification only when PPF evaluation returns pass.¶

For every other result, the receiver or linkback proxy MUST NOT fetch the claimed source URI. The protocol binding defines whether the request is rejected, deferred, or otherwise represented.¶

Strict mode provides the strongest protection against reflected fetches because linkbacks without a pass result never cause source-resource fetches.¶

10.2. Permissive Mode

In permissive mode, a receiver or linkback proxy proceeds to source-resource verification when PPF evaluation returns pass. It MAY also proceed when evaluation returns none, permerror, or temperror.¶

If evaluation returns fail, the receiver or linkback proxy MUST reject the linkback before fetching the claimed source URI.¶

Permissive mode is intended for transition periods and backward-compatible deployments. It allows existing linkback ecosystems to continue functioning while domains gradually publish PPF policies.¶

12.1. Proxy Processing Model

A linkback proxy receiving a linkback request performs the following steps:¶

1. Extract the source URI and target URI according to the relevant protocol binding.¶

2. Determine the sender IP address from the client connection and trusted local configuration.¶

3. Apply syntax, target-routing, duplicate, rate-limit, and other local checks that do not require fetching the claimed source URI.¶

4. Evaluate PPF for the source URI and sender IP address.¶

5. If PPF and local policy do not permit source fetching, reject, defer, or record the result according to the protocol binding.¶

6. If PPF permits source fetching, fetch the claimed source URI.¶

7. Verify that the fetched source resource links to the target URI.¶

8. Apply any remaining abuse, reputation, and receiver policy checks.¶

9. Cache the fetched source representation, canonical source URI, validation result, PPF result, sender IP address, verification time, and any other metadata needed by the protected receiver.¶

10. Contact the protected receiver using the relevant protocol binding.¶

A linkback proxy MUST NOT fetch the claimed source URI after PPF evaluation returns fail.¶

In strict mode, a linkback proxy MUST NOT fetch the claimed source URI unless PPF evaluation returns pass.¶

In permissive mode, a linkback proxy MAY fetch the claimed source URI after none, permerror, or temperror according to the protocol binding and local policy.¶

12.2. Proxy-to-Receiver Metadata

A protocol binding for proxied operation SHOULD define how the proxy communicates the following metadata to the protected receiver:¶

• original sender IP address;¶

• submitted source URI;¶

• canonical source URI after redirects, if different;¶

• target URI;¶

• PPF evaluation result;¶

• source-verification result;¶

• verification timestamp;¶

• cached source representation or a cache URL;¶

• proxy identity; and¶

• any policy or abuse result the protected receiver needs in order to process the linkback.¶

The metadata format is protocol-specific. This document does not define HTTP fields, JSON members, XML-RPC extensions, form parameters, signatures, or other protocol-specific serialization.¶

12.3. Cache URLs and Cached Representations

When a proxy provides a cache URL or cached source representation to a protected receiver, the cache object MUST correspond to the source representation used by the proxy when it performed source verification.¶

Cache URLs MUST be unguessable or access-controlled. A protected receiver MUST authenticate the proxy before dereferencing a proxy-provided cache URL.¶

The proxy SHOULD make cached representations available long enough for the protected receiver to complete linkback processing. The protocol binding or deployment profile can define specific lifetimes.¶

A protected receiver MUST NOT fetch the submitted source URI directly. If it requires the source representation, it MUST use the proxy-provided cached representation or cache URL, or reject the linkback. A receiver that can rely on authenticated proxy-provided validation metadata without reading the source representation MAY do so.¶

12.4. Proxy Authentication

A protected receiver MUST authenticate the linkback proxy before relying on proxy-provided metadata, validation results, or cache URLs.¶

This document does not define a single proxy-authentication mechanism. Deployments can use IP allowlists, shared secrets, request signatures, mutual TLS, private network paths, or equivalent mechanisms. Protocol bindings or deployment profiles can define a specific authentication method.¶

A protected receiver that is configured to require a linkback proxy MUST reject direct linkback requests that bypass the configured proxy.¶

12.5. Endpoint Advertisement

A protected receiver using a linkback proxy advertises a proxy endpoint rather than its origin endpoint. The way this is done is protocol-specific and MUST be defined by the protocol binding.¶

Clients normally do not need to know whether the advertised endpoint is an origin receiver or a proxy.¶

12.6. Proxy as Sender

A proxy that sends linkbacks on behalf of source domains is a sender for PPF purposes. The source domain's PPF policy needs to authorize the proxy's sending addresses.¶

A proxy that receives linkbacks on behalf of protected receivers is not automatically authorized to send linkbacks for arbitrary source domains. Authorization is always determined from the source domain's PPF policy and the sender IP address evaluated for the linkback.¶

14.1. Reflected Fetches

PPF is designed to prevent unauthorized senders from causing receivers or linkback proxies to fetch claimed source URIs. Authorization is obtained from DNS before fetching the source resource. In strict mode, linkbacks that do not pass PPF evaluation do not cause source-resource fetching.¶

Permissive mode weakens this protection for domains without usable PPF policies. It is intended for transition and compatibility.¶

14.2. DNS Tarpitting and Resource Exhaustion

PPF introduces DNS lookups into the linkback path. Attackers can use slow or unresponsive authoritative name servers to consume receiver or proxy resources. Receivers and linkback proxies SHOULD enforce resolver timeouts, use caching, limit concurrency, and process linkbacks asynchronously where appropriate.¶

The DNS lookup and include-depth limits in this document are mandatory resource-exhaustion controls.¶

14.3. HTTP Tarpitting

PPF reduces unauthorized source-resource fetching, but it does not remove the need to protect the subsequent source verification step. Authorized senders can still link to resources that respond slowly, redirect repeatedly, or attempt other HTTP-level resource exhaustion attacks. Receivers and proxies SHOULD enforce timeouts, redirect limits, content-size limits, and content-type policies when verifying source resources.¶

14.4. Server-Side Request Forgery

Receivers and proxies that fetch source URIs need SSRF protections independent of PPF. A PPF-authorized sender might submit a source URI that redirects to private or internal address space, changes DNS answers between authorization and fetch, or serves malicious content.¶

Receivers and proxies SHOULD reject or carefully control fetches to loopback, link-local, private, and otherwise restricted address ranges unless explicitly configured to permit them. Receivers and proxies SHOULD resolve and re-check addresses after redirects and immediately before connecting.¶

14.5. DNS Rebinding

PPF authorization and source-resource fetching are separate operations. A source hostname can resolve differently during PPF evaluation and later HTTP fetching. Receivers and proxies MUST NOT assume that an a mechanism match implies that fetching the source URI is safe. SSRF protections apply regardless of PPF result.¶

14.6. Origin IP Exposure

Sites using CDNs or DDoS-protection services often proxy inbound traffic but not outbound verification fetches. A receiver that performs direct source-resource fetching can expose its origin IP address through outbound connections.¶

Sites requiring origin hiding MUST use proxied operation or disable linkback receiving. An origin receiver configured to require a linkback proxy MUST reject linkback requests that bypass the configured proxy.¶

14.7. DNSSEC

PPF does not require DNSSEC. Deployments that use validating resolvers can obtain stronger protection against DNS spoofing. If DNSSEC validation returns a Bogus result for a PPF lookup, receivers and proxies SHOULD treat the lookup as temperror unless local policy dictates stricter handling.¶

14.8. Abuse and Spam

PPF does not prevent spam or abuse from authorized senders. A valid PPF pass only means that the source domain authorizes the sender IP address for linkbacks. Receivers still need moderation, reputation systems, rate limits, and content filtering.¶

14.9. Policy Delegation

The include mechanism delegates authorization decisions to another domain. A source domain that uses include depends on the included domain's DNS security and operational practices. Compromise or misconfiguration of the included domain can authorize unintended senders.¶

15.1. DNS Query Metadata

PPF lookups reveal that a receiver or proxy is processing a linkback claiming to originate from a source domain. This metadata can be visible to recursive resolvers, authoritative DNS operators, and network observers.¶

Caching reduces query volume but does not eliminate metadata exposure. Receivers and proxies concerned about DNS privacy should consider encrypted DNS transport to their recursive resolver, local caching resolvers, and query minimization where available.¶

15.2. Proxy Trust

Linkback proxies can observe linkback metadata, source-resource content fetched for verification, timing patterns, and relationships among participating sites. Sites using proxied operation should treat linkback proxies as trusted infrastructure providers.¶

15.3. Cache URLs

Cache URLs can reveal source content and linkback-processing state. Cache URLs need to be unguessable or access-controlled, and protected receivers need to authenticate the proxy before using them.¶

16.1. Underscored and Globally Scoped DNS Node Name

IANA is requested to register the following entry in the "Underscored and Globally Scoped DNS Node Names" registry established by [RFC8552]:¶

17.1. Self-Hosted Site

A site that sends linkbacks from the same addresses used by its source host publishes:¶

_pingback.example.com. IN TXT "v=ppf1 a"

17.2. Static Site with External Linkback Service

A site that uses a third-party linkback service publishes:¶

_pingback.blog.example.com. IN TXT "v=ppf1 a:linkback.example.net"

17.3. Multiple Authorized Sources

A site that sends from its own host and from a managed service publishes:¶

_pingback.news.example.com. IN TXT (
  "v=ppf1 a ip4:192.0.2.0/24 "
  "include:linkback.example.net"
)

17.4. Domain That Sends No Linkbacks

A domain that does not send linkbacks publishes:¶

_pingback.docs.example.com. IN TXT "v=ppf1 none"

This explicitly declares that no sender is authorized to send linkbacks for source URIs on that domain.¶

17.5. Site Using a Linkback Proxy

A site using a linkback proxy publishes:¶

_pingback.example.org. IN TXT "v=ppf1 include:linkback.example.net"

The site advertises linkback endpoints hosted by the proxy and configures the origin receiver to reject direct linkback requests.¶

18.1. Caching

Receivers and proxies SHOULD cache positive PPF results according to DNS TTLs. They MAY cache fail, none, permerror, and temperror results for short periods to protect themselves from repeated expensive lookups, subject to local policy and the considerations in [RFC2308].¶

Caches need to account for the sender IP address, source domain, and relevant DNS answers. A cached authorization result for one sender IP address MUST NOT be reused for a different sender IP address unless the cached policy evaluation proves that the different address is covered by the same matching mechanism.¶

18.2. Managed Hosting Providers

Managed hosting providers can publish PPF records for customer domains or provide DNS guidance for customers. A provider that sends linkbacks on behalf of customers can publish a provider-level PPF policy and instruct customers to include it.¶

Providers that operate linkback proxies for protected receivers can publish provider-level endpoint guidance and origin-protection guidance in the protocol bindings they support.¶

Providers that do not support outbound linkbacks can publish v=ppf1 none for hosted domains where they control DNS and where doing so reflects customer intent.¶

18.3. Transition

Permissive mode allows gradual deployment. Receivers and proxies can start by checking PPF records and rejecting only explicit fail results. As publication becomes common, receivers and proxies can move selected protocols, domains, or local policies to strict mode.¶

20.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/rfc/rfc5234>.

[RFC5890]

Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/rfc/rfc5890>.

[RFC5891]

Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/rfc/rfc5891>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

20.2. Informative References

[RFC2308]

Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/rfc/rfc2308>.

[RFC7208]

Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/rfc/rfc7208>.

[RFC8552]

Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/rfc/rfc8552>.