In Edge Computing deployment, an application service may be served by multiple Edge Application Servers typically deployed in different sites. These multiple Edge Application Servers that host service may use a single IP address (anycast address) or different IP addresses. To start such a service, the UE needs to know the IP address(es) of the Application Server(s) serving the service. The UE may do a discovery to get the IP address(es) of a suitable Edge Application Server (e.g. the closest one), so that the traffic can be locally routed to the Edge Application Server and service latency, traffic routing path and user service experience can be optimized. EAS discovery is the procedure by which a UE discovers the IP address(es) of a suitable Edge Application Server(s) using Domain Name System (DNS). EAS Re-discovery is the EAS Discovery procedure that takes place when the previously discovered Edge Application Server cannot be used or may have become non-optimal (e.g. at edge relocation). The DNS server to be used for EAS (re-)discovery may be deployed in different locations in the network as Central DNS (C-DNS) server or as Local DNS (L-DNS) resolver/server. In order to provide a translation of the FQDN of an EAS into the address of an EAS as topologically close as possible to the UE, the Domain Name System may use following information:

• The source IP address of the incoming DNS Query; and/or,
• an EDNS Client Subnet (ECS) option (as defined in RFC 7871).

EAS (re-)discovery procedures described in this specification should use the top level domains (TLDs) in the public namespace by default. If a private namespace is used, an Edge Computing Service Provider (ECSP) can provision DNS information in the EAS Deployment information via AF request with its Application Identifier, or DNN and NSSAI. Since private namespaces do not have a common root server or naming, the DNS information for each ECSP should be stored individually to prevent any overwriting of resolution entries. If the UE applications want to discover/access EAS by using the mechanisms defined in this TS, the UE shall support receiving DNS settings in PCO during PDU Session Establishment and PDU Session Modification, and the DNS Queries generated by the UE for these applications shall be sent to the DNS server/resolver (e.g. EASDF) indicated by the SMF. To ensure this, the application in the UE either requests the EDC functionality to send a DNS Query or, alternatively, uses the EDC functionality to get the configuration of the DNS Server (IP address and, conditionally, DNS security information of the EASDF/DNS Server/ Resolver; see TS 24.501 and TS 33.501) indicated by the SMF (see clauses 5.2.1 and 6.2.4) then resolves the FQDN by its own DNS mechanism. For EASDF, the DNS security information may be provided by EASDF to SMF. The DNS security information of the EASDF/Local DNS Server/Resolver may also be locally configured in the SMF. The case of EAS (Re-)discovery over Distributed Anchor connectivity model is described in clause 6.2.2. For Multiple PDU Sessions connectivity model, the description in clause 6.2.2 also applies to the PDU Session(s) with Local PSA. The case of EAS (Re-)discovery over Session Breakout connectivity model is described in clause 6.2.3.