Pingback Permitted From (PPF)

Introduction Linkback protocols allow one site to notify another that a source resource links to a target resource. In typical deployments, the receiver verifies the linkback by fetching the claimed source URI and checking that it contains a link to the target URI. This receiver-side verification step creates a sender authorization problem. Without an authorization layer, any host can send a linkback claiming any source URI. A receiver that attempts to verify such a linkback will make an HTTP request to the claimed source URI, even if the party sending the linkback has no authority over that source domain. This creates two related problems:

unauthorized linkbacks, where a sender causes linkbacks to be created for source resources it does not control; and
reflected fetches, where many receivers are induced to fetch resources from a victim domain.

PPF addresses this by moving the first authorization check into DNS. The owner of the source domain publishes a policy at a well-known DNS owner name. Receivers and linkback proxies query that policy and determine whether the sender's IP address is authorized before attempting source-resource verification. PPF is deliberately narrow. It answers only this question:

Is this sender authorized by the source domain to send linkbacks for source URIs on that domain?

A positive PPF result does not mean that the linkback is true, desirable, non-abusive, or safe to display. Receivers still need to verify that the source resource links to the target resource and apply their ordinary moderation, abuse, and policy controls. This document defines:

the PPF DNS owner name;
the PPF TXT record format;
PPF mechanisms;
the PPF evaluation algorithm;
PPF result names;
generic protocol-binding requirements; and
the generic model for PPF linkback proxy operation.

This document does not define a complete binding for any particular linkback protocol. Protocol bindings define how source URIs, target URIs, sender IP addresses, responses, status resources, and proxy metadata are represented in a specific protocol.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terms:

Source URI: The URI of the resource that is claimed to contain a link.
Target URI: The URI of the resource that is claimed to be linked to by the source resource.
Linkback: A protocol message from a sender to a receiver claiming that a source URI links to a target URI. This document uses "linkback" as the generic term for such messages and the protocols that carry them.
Sender: The host or service transmitting a linkback to a receiver or linkback proxy.
Receiver: The host or service receiving a linkback for a target URI.
Linkback proxy: A service that receives linkbacks, evaluates PPF, performs source-resource verification or filtering, caches the result, and forwards or reports the result to a receiver using a protocol binding.
Protected receiver: A receiver that relies on a linkback proxy to perform PPF evaluation, source fetching, or source verification on its behalf.
Source domain: The DNS domain name derived from the host component of the source URI.
Sender IP address: The IP address evaluated against the PPF policy. The protocol binding or local trusted-proxy configuration defines how this address is determined.
PPF record: A DNS TXT record whose first token is v=ppf1, using ASCII case-insensitive comparison, at the DNS owner name _pingback.<source-domain>.
Policy: The authorization rule set expressed by a PPF record.
Mechanism: A policy term that can authorize a sender IP address.
Strict mode: Receiver or proxy behavior in which source-resource verification proceeds only when PPF evaluation returns pass.
Permissive mode: Receiver or proxy behavior in which a linkback can proceed to ordinary source-resource verification when no usable PPF policy is found.
Protocol binding: A specification that defines how PPF applies to a particular linkback protocol.

Design Considerations

Relationship to SPF PPF is intentionally modeled on the Sender Policy Framework (SPF) . 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.

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.

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.

PPF DNS Owner Name For a source URI, the receiver or linkback proxy extracts the host component as specified by the URI scheme and converts it to a DNS domain name. For http and https URIs, this is the URI host component as defined by . If the source URI has an IP address literal as its host, or its host cannot otherwise be converted to a DNS domain name, no source domain exists and PPF evaluation returns none. The PPF policy is published as a TXT RRset at: ]]> For example, the PPF policy for source URI https://blog.example.com/post is queried at: The _pingback label is the well-known DNS owner-name prefix for PPF policies. The policy authorizes senders of linkbacks for the source domain. Internationalized domain names MUST be converted to A-label form using the IDNA lookup protocol ; the term A-label is defined by . PPF record generators SHOULD publish DNS owner names in A-label form. Receivers and linkback proxies MUST perform DNS lookups using the DNS wire representation of the resulting domain name.

Record Format A PPF policy is expressed in a DNS TXT record. A TXT RR can contain one or more character strings. When parsing a candidate PPF TXT RR, the receiver or linkback proxy MUST concatenate all character strings in that RR in order, without inserting separators. A TXT RR is a PPF record only when its concatenated content is exactly v=ppf1 or begins with v=ppf1 followed by one or more SP characters, using ASCII case-insensitive comparison. Other TXT records at the same owner name, including records for other PPF versions, MUST be ignored by this version of PPF. There MUST NOT be more than one PPF record at a PPF DNS owner name. If more than one TXT RR at the owner name has v=ppf1 as its first token, the policy evaluation result is permerror.

ABNF The following ABNF uses the notation of . IPv4address and IPv6address are imported from . domain-name is an ASCII DNS domain name in presentation form; internationalized names MUST use A-labels . 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.

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.

Evaluation Results PPF evaluation returns one of the following results. These result names deliberately mirror SPF where the same concepts apply.

pass: A valid PPF policy exists and a mechanism authorizes the sender IP address.
fail: A valid PPF policy exists, but no mechanism authorizes the sender IP address, or the policy is none.
none: No usable PPF policy was found for the source domain. This includes a source URI without a DNS source domain, NXDOMAIN, NODATA, and the absence of any TXT RR whose first token is v=ppf1 at the expected owner name.
permerror: A PPF policy exists but cannot be used because it is malformed, ambiguous, contains invalid syntax, contains an unsupported mechanism, exceeds a lookup or include-depth limit, or otherwise violates this specification.
temperror: A temporary error occurred while attempting to retrieve or evaluate the policy, such as a DNS timeout or SERVFAIL.

The none evaluation result is distinct from the none policy mechanism. A policy of v=ppf1 none is a usable policy that explicitly authorizes no senders; it therefore evaluates to fail, not none. Protocol bindings define how these results are mapped to protocol-specific responses. In strict mode, any result other than pass prevents source-resource fetching; the protocol binding defines whether the request is rejected, deferred, or otherwise represented. In permissive mode, none, permerror, and temperror can be treated as absence of PPF authorization and the receiver or proxy can proceed according to the underlying protocol's ordinary behavior. A receiver or linkback proxy MAY apply local policy that is stricter than the selected protocol binding, including rejecting temperror in otherwise permissive deployments.

Verification Algorithm Given a linkback, the receiver or linkback proxy obtains the following inputs from the protocol binding and local trusted-proxy configuration:

source URI;
target URI;
sender IP address; and
enforcement mode.

PPF evaluates only the source URI and sender IP address. The target URI is part of the linkback protocol and is not used by the base PPF algorithm. The receiver or linkback proxy performs the following steps:

Extract the host component from the source URI.
Convert the host component to a DNS domain name. Internationalized domain names MUST be converted to A-label form. If the host is an IP address literal or cannot otherwise be converted to a DNS domain name, return none.
Query the TXT RRset at _pingback.<source-domain>.
If the lookup returns NXDOMAIN or NODATA for the owner name, return none.
If the lookup fails because of a temporary DNS error, return temperror.
From the returned TXT RRset, select records whose concatenated content is exactly v=ppf1 or begins with v=ppf1 followed by one or more SP characters, using ASCII case-insensitive comparison.
If no PPF records are present, return none.
If more than one PPF record is present, return permerror.
Parse the selected PPF record. If parsing fails, return permerror.
Evaluate mechanisms from left to right.
If a mechanism matches, return pass.
If no mechanism matches, return fail.

Receivers and linkback proxies MUST NOT fetch the claimed source URI as part of PPF evaluation. Source-resource fetching belongs to the linkback protocol's ordinary verification step and occurs only after PPF processing permits it.

DNS Processing Rules

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.

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.

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.

Mechanism Evaluation

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.

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.

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.

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.

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.

Enforcement Modes PPF defines two enforcement modes. Protocol bindings MUST specify the default enforcement mode for that protocol. Receivers and linkback proxies MAY apply a stricter local policy than the binding default.

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.

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.

Protocol Binding Requirements This document defines the PPF DNS policy format, evaluation algorithm, result vocabulary, and generic proxy-processing model. It does not define a complete binding for any particular linkback protocol. A protocol binding that uses PPF MUST define:

how the source URI is identified;
how the target URI is identified;
how the receiver or linkback proxy determines the sender IP address;
whether the binding uses strict mode or permissive mode by default;
how each PPF evaluation result is represented to the sender;
whether asynchronous processing is supported;
whether a capability signal is required to use asynchronous or extended response behavior;
how protected receivers advertise proxy endpoints, if proxied operation is supported;
how proxy metadata is carried from a linkback proxy to a protected receiver, if proxied operation is supported; and
how a protected receiver authenticates the proxy, if proxied operation is supported.

A binding MUST preserve the PPF ordering requirement: PPF evaluation occurs before any receiver-initiated or proxy-initiated fetch of the claimed source URI. A binding MAY define additional protocol-specific error codes, response formats, status resources, metadata fields, or endpoint-discovery rules.

Linkback Proxy Operation A linkback proxy is a service that receives linkbacks on behalf of protected receivers, performs PPF and source-resource verification, caches the results, and then contacts the protected receiver using a protocol binding. The purpose of this model is to allow a CDN, hosting provider, reverse proxy, or dedicated linkback service to absorb the DNS and HTTP risk of linkback processing before a request reaches the protected receiver. This section defines the protocol-independent proxy model. Protocol bindings define how the model is represented for particular linkback protocols. A linkback proxy SHOULD operate in strict mode by default. Permissive operation can be useful for staged deployment or diagnostics, but it weakens the protection the proxy is intended to provide.

Proxy Processing Model A linkback proxy receiving a linkback request performs the following steps:

Extract the source URI and target URI according to the relevant protocol binding.
Determine the sender IP address from the client connection and trusted local configuration.
Apply syntax, target-routing, duplicate, rate-limit, and other local checks that do not require fetching the claimed source URI.
Evaluate PPF for the source URI and sender IP address.
If PPF and local policy do not permit source fetching, reject, defer, or record the result according to the protocol binding.
If PPF permits source fetching, fetch the claimed source URI.
Verify that the fetched source resource links to the target URI.
Apply any remaining abuse, reputation, and receiver policy checks.
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.
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.

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.

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.

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.

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.

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.

Sender Behavior Senders and proxies using PPF with linkback protocols SHOULD:

avoid retry storms;
respect protocol-specific retry and status guidance;
implement exponential backoff after temporary protocol or transport failures; and
avoid repeatedly sending linkbacks to receivers that persistently reject or fail requests.

A sender MUST NOT treat PPF pass as evidence that a receiver will accept or display the linkback. PPF authorizes the sender; it does not grant any right to appear on the receiver's site.

Security Considerations

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.

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.

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.

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.

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.

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.

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.

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.

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.

Privacy Considerations

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.

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.

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.

IANA Considerations

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 :

RR Type	_NODE NAME	Reference
TXT	_pingback	RFC-to-be

Examples

Self-Hosted Site A site that sends linkbacks from the same addresses used by its source host publishes:

Static Site with External Linkback Service A site that uses a third-party linkback service publishes:

Multiple Authorized Sources A site that sends from its own host and from a managed service publishes:

Domain That Sends No Linkbacks A domain that does not send linkbacks publishes: This explicitly declares that no sender is authorized to send linkbacks for source URIs on that domain.

Site Using a Linkback Proxy A site using a linkback proxy publishes: The site advertises linkback endpoints hosted by the proxy and configures the origin receiver to reject direct linkback requests.

Operational Considerations

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 . 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.

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.

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.

Acknowledgments PPF borrows the DNS-based authorization pattern from SPF while adapting it to linkback protocols.