# Re-resolve Service Fabric endpoints after the listener rejects a stale identity

> How should an internal client respond when a reused address no longer belongs to its intended Service Fabric service?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-482-re-resolve-service-fabric-endpoints-after-the-listener-rejects-a-stale-identity/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:23:54+00:00
- Modified: 2026-09-10T02:08:05+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

How should an internal client respond when a reused address no longer belongs to its intended Service Fabric service?

## Potentially affected

ASP.NET Core Service Fabric services using dynamic endpoints in a trusted, non-hostile-tenant environment.

## DSE recommendation

DSE recommends checking the listener's identity validation and the client's endpoint refresh behavior together.

## Article

## Source facts

Service Fabric’s ASP.NET Core integration middleware adds a unique identifier to the registered service address and checks it on requests. A mismatch returns HTTP 410 Gone. Clients should then resolve the service endpoint again. This cooperative protection is intended for a trusted environment; it does not authenticate a service securely against a hostile tenant. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-communication-aspnetcore).

## Applicability

Focus this review on internal clients caching dynamically assigned endpoints. Distinguish an address that is reachable from an address that still represents the intended service. Do not extend this mechanism into a claim that tenant authentication, authorization or transport security has been established.

## DSE recommendation

DSE recommends checking the listener’s identity validation and the client’s endpoint refresh behavior together. Have the application owner trace where a resolved address is cached and what happens after an identity rejection. Keep this error path separate from ordinary application failures: the proposed response is to refresh the destination, not repeatedly submit the same request to an unchanged cached address.

## Verification

In an isolated integration test, exercise a stale endpoint and inspect the listener response. Confirm that the client performs a fresh resolution after the documented rejection and subsequently addresses the intended service. Retain the old and refreshed endpoint identities without collecting sensitive request payloads. Test the application’s separate authentication controls through their own acceptance criteria; passing this routing test is not a substitute.

## Official references

[Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-communication-aspnetcore). Source retrieved September 9, 2026.

## Primary reference

- Name: Service communication with the ASP.NET Core - Azure Service Fabric | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-communication-aspnetcore
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Re-resolve Service Fabric endpoints after the listener rejects a stale identity,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-482-re-resolve-service-fabric-endpoints-after-the-listener-rejects-a-stale-identity/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.