Summary

  • An unsigned discovery answer can send a client to a server that legitimately authenticates as itself. RFC 5178's service [AT] domain [AT] hostname name — where [AT] denotes the literal ASCII at-sign in the RFC syntax — asks the missing question: is that host authorized to provide this service for this domain?
  • The credential for that three-part name is an authorization instrument, not decorative metadata. Discovery, typed-name construction, credential issuance, GSS context establishment, application authorization and observed service outcome remain separate receipts.

The hostile server does not need to forge every layer. It can let discovery lie and authentication tell the truth.

Imagine a client looking for the root of an organisation's file namespace. An unprotected DNS SRV answer names a server controlled by an attacker. The server holds a valid credential for its own hostname. A host-based authentication check can therefore succeed exactly as designed: the machine proves that it is the machine named in the poisoned answer. What has not been proved is the proposition the user actually cares about — that this machine may speak for the organisation's file service.

RFC 5178 was designed around that gap. It adds neither a replacement DNS nor a magical trust bit. It changes the name presented to GSS-API so that the intended authority survives discovery. The resulting name contains the service, the domain being served and the concrete hostname selected from discovery. A server must authenticate a credential for the whole triple.

That extra field changes the question from “who owns this host name?” to “who authorized this host to provide this service for that domain?”

Discovery is a proposal, not an appointment

Service discovery is useful because it lets an administrator move a service among machines, publish replicas and change capacity without reconfiguring every client. The same indirection creates an authority problem. A discovery record proposes where a client should try. If the record is insecure, it cannot also be the final proof that the proposed target was entitled to answer.

Host-based service names bind a service to one host, commonly in a form such as service [AT] hostname. That is adequate when the host is already known through trusted configuration or when a separate policy establishes its role. It is weaker when the host itself came from an untrusted lookup. The client would be using the disputed statement — “this is the server” — to construct the identity that confirms the statement.

RFC 5178 keeps the intended resource domain outside that loop. Its syntax is:

service [AT] domain [AT] hostname

The three fields are not synonyms. The service says what function is requested. The domain states the administrative or resource scope for which that function is requested. The hostname identifies the concrete acceptor. The domain need not even be an Internet DNS domain, although DNS names are the expected form.

Possession of a credential for this name embodies authorization. That is the mechanism's power and its governance burden. Whoever creates nfs [AT] example.net [AT] nfs2.example.net has done more than serialize three strings. They have delegated to one machine the ability to authenticate as an NFS server for the example.net domain.

The credential issuer is therefore part of the service control plane.

A successful context makes a bounded claim

If a client constructs the intended typed name and establishes a GSS security context with an acceptor that proves the matching credential, the result is meaningful. The client has more than an arbitrary discovery target and more than an authenticated hostname. It has cryptographic evidence tied to the service-domain-host scope.

The result is still bounded.

It does not say the discovery record was authentic. It does not say the administrator intended the credential to remain valid today. It does not say the application authorized the requested operation, returned the correct file tree, enforced the right tenant boundary or completed a user's work. A stolen or mistakenly issued credential can satisfy the name while defeating the policy that motivated it.

This is why the operational record needs the whole chain: the domain the user intended; the discovery query and validation state; the returned candidates and selected host; the exact name type and input representation; the mechanism-canonical name; the credential issuer and lifetime; the GSS result; the application authorization decision; and an independent service observation.

Compressing those records into “Kerberos succeeded” or “GSS authenticated” throws away the most important scope.

The fallback is not merely compatibility

RFC 5178 recognised that a new name type could not be deployed by unilateral client preference. Some mechanisms cannot negotiate it. Some acceptors do not support it. LDAP installations may already expect host-based names and may lack domain-scoped acceptor credentials. Enabling the new form before servers and credentials are ready can break interoperability.

That does not make host-based fallback harmless. The standard requires initiators that fall back — and initiators that lack domain-based support altogether — to verify separately that the host-based identity is authorized to provide the service for the intended domain.

This requirement is easy to lose in an implementation toggle. A box labelled “use legacy naming” may restore connectivity while silently removing the authorization property that justified discovery. The right fallback receipt is not “retry succeeded”. It is “this exact host identity appears in a current, accountable authorization set for this service domain”.

Fail closed and fail open are too coarse as labels. A planned fallback can preserve service and authority. An unexamined fallback can preserve traffic by changing the question.

Printable equality is not identity equality

The internationalization sections expose a second boundary. RFC 5178 was written against the IDNA2003 model. Its ordinary import interface must accept ACE-encoded domain names. It also recommends a UTF-8 import function that accepts UTF-8 or ACE. Ordinary display emits ASCII or ACE; the UTF-8 display variant emits UTF-8 and must not emit ACE.

These are representation rules, not authority transformations.

GSS-API already distinguishes an imported internal name, a displayed string, a mechanism name and an exported name. RFC 2743 warns that displaying an imported name need not reproduce the original string, and the output name type need not match the identifier used for import. Name comparison belongs to GSS comparison and canonicalisation semantics, not to a byte comparison between two log lines.

The distinction became historically sharper because RFC 3490 was later obsoleted and IDNA2008 introduced A-label and U-label terminology. That later change does not retroactively rewrite RFC 5178. It does require an implementation to record which profile and conversion path produced the name it used. Two interfaces can show different strings for the same intended domain; two visually similar strings can also represent different security names.

An audit that saves only the prettiest Unicode rendering may be unable to reproduce the authenticated mechanism name. An audit that saves only ACE may conceal what the operator believed they approved. Preserve both, along with the typed name and mechanism result.

Kerberos keeps the three scopes distinct

RFC 5179 supplies the Kerberos V mapping. The service becomes the first principal component, the hostname the second and the domain the third. It recommends the Kerberos name type NT-SRV-HST-DOMAIN, value 12, although NT-UNKNOWN is permitted.

The realm is a separate decision. The specification says it corresponds to the domain treated as a hostname, and its security section insists that realm derivation proceed from the hostname rather than simply trusting the domain slot of the supplied string. The distinction prevents the asserted service scope from appointing its own authentication realm without the normal Kerberos mapping logic.

RFC 5179 also reflects its date. With Kerberos internationalization incomplete, it requires ACE-encoded internationalized domain names for the host and domain components. That rule is evidence of a compatibility boundary, not proof that every contemporary library exposes or compares those forms in the same way.

The useful engineering test is therefore not “can the library parse this string?” It is “which principal did the active mechanism derive, which realm did it consult, which credential answered, and did that resulting name match the application's domain-service policy?”

NFS shows what the separation buys

RFC 6641 later used the model for a global NFSv4 namespace. A client can query DNS SRV for root servers associated with an organisation. DNSSEC should be used where available. Domain-based service principals are an additional control: the administrator can arrange that only approved NFS root servers possess credentials for names such as nfs [AT] example.net [AT] nfs2.example.net.

This construction lets discovery remain replaceable. DNS proposes a member of the server set. The credential system states whether that member is authorized for the domain root. NFS then negotiates security and applies its own protocol rules. The mounted namespace and the data returned remain downstream observations.

No single layer has to impersonate the others. That is the design's strength.

It is also why a credential inventory matters as much as a DNS inventory. Removing a server from SRV without revoking its domain-service credential may stop ordinary discovery while leaving the machine able to authenticate if reached another way. Revoking the credential while leaving the SRV target produces a discoverable but unusable endpoint. The two actions are related, not interchangeable.

Authority is located in the issuance record

The symbol looks small: one extra domain component and one registered OID. The institutional change is larger. Authority no longer follows automatically from a discovered address or a host's ability to authenticate. It is localized in a credential whose scope can be inspected, issued and withdrawn.

That fits a wider Internet coordination principle. Shared syntax should be minimal and deterministic; local actors should retain control over the decisions that the syntax expresses. RFC 5178 defines enough common structure for a client and server to agree on the question. It does not create a central service-authority registry or claim that every application must adopt one deployment policy.

The clarity can feel inconvenient because it reveals who made the decision. If the wrong server authenticates the right triple, the failure is not “DNS did something strange”. Someone issued, copied, retained or failed to revoke an authorization-bearing credential. If a fallback accepts a host without domain approval, someone chose compatibility over the missing scope. The evidence becomes actionable because the layers stay separate.

The server's identity was never the whole question. RFC 5178 made the intended mandate part of the name.

Sources