GeoWebDNS and Service Location Resolution

1. Introduction

Many systems need to answer a user-centered routing question: “where should this request go?”

For a CDN asset, the answer may be “the closest healthy edge.” For a benefits application, the answer may be “the county agency with authority over this address.” For a clinic finder, the answer may be “the provider that serves this insurance plan and service area.” For a permit workflow, the answer may be “the city building department, unless the parcel is outside city limits, in which case the county.”

These are related problems, but they are not identical. Traditional DNS resolves names to network destinations. GeoDNS adds geographic or topological policy to that resolution. But service systems often need a second resolver that understands real-world geography, coverage areas, jurisdiction, business rules, and channels such as web, phone, in-person, or mail.

GeoWebDNS is the historical bridge between those two ideas. It applies DNS-like resolution thinking to real-world service lookup. This paper describes that resolver layer and its relationship to GeoDNS.

2. Definition

GeoDNS (noun): An operational DNS pattern in which an authoritative DNS service returns different answers based on the inferred location or topology of the querying client or resolver.

GeoWebDNS (proper noun): A location-aware service lookup model associated with the OpenPlans geowebdns project, in which a service namespace and geographic point are used to resolve the correct service URI or endpoint.

Service location resolution (noun): The process of mapping a request to the correct service destination based on a combination of:

1. Service intent - what the user is trying to do
2. User location - address, coordinates, or jurisdiction
3. Network context - resolver location, client subnet, region, latency
4. Authority and coverage - who serves that user at that place
5. Availability - hours, health, channel status, or capacity

The output of service location resolution is richer than a DNS answer. It can include:

• A network endpoint
• A provider or agency
• A physical office or virtual channel
• The rule or geography that justified the selection
• Ordered fallbacks

Formally:

ResolveService(intent, user_location, network_context, time) -> service_target[]

Where each service_target may contain:

{
  endpoint,
  provider,
  channel,
  office,
  authority_basis,
  coverage_basis,
  fallback_rank
}

3. Why DNS Alone Is Not Enough

3.1 Network Proximity Is Not Service Authority

DNS can answer “which endpoint is closest or healthiest?” It usually cannot answer “which organization has authority to serve this user?”

Those questions diverge often:

• The closest office may not be the office with jurisdiction
• The nearest hospital may not be in-network
• The lowest-latency API region may not be the legally correct data region
• The city nearest a parcel may not govern the parcel

GeoDNS is therefore necessary but incomplete. It can route traffic to the right ingress region while still leaving the application to choose the correct service authority.

3.2 Resolver Geography Is an Imperfect Proxy for User Geography

GeoDNS decisions are often based on the source IP of the recursive resolver rather than the end user. EDNS Client Subnet improves that approximation, but only when resolvers support it and when operators accept its privacy and caching tradeoffs.

This matters because modern clients may use:

• Centralized public resolvers
• Enterprise DNS forwarders
• VPNs
• Mobile carriers
• Browser-level secure DNS

As a result, “where the DNS query came from” is often only an estimate of where the user actually is.

3.3 Real Services Depend on Polygons, Hierarchies, and Rules

Real-world service routing usually depends on data that DNS does not model well:

• Service-area polygons
• Jurisdiction boundaries
• Catchment zones
• Eligibility rules
• Office hours
• Channel availability
• Capacity and queue state

DNS records are excellent for endpoint publication and traffic steering. They are poor containers for policy-rich service selection.

4. A Two-Layer Resolver Architecture

The clean architectural split is:

1. GeoDNS selects the best ingress or regional entry point.
2. GeoWebDNS-style lookup resolves the service namespace against the user’s location.
3. Service location resolution selects the correct provider, office, or channel for the request itself.

This is effectively a layered “Service DNS” architecture.

4.1 Layer 1: GeoDNS

Inputs:

• Hostname
• Resolver IP
• Optional EDNS Client Subnet
• Health and latency policy

Outputs:

• A / AAAA records
• Alias targets
• HTTPS / SVCB parameters
• A regional or edge origin

Typical decisions:

• Serve from us-west rather than us-east
• Send Europe to an EU deployment
• Fail over to a healthy secondary region
• Steer users to the nearest edge cache

4.2 Layer 2: GeoWebDNS-Style Lookup and Service Resolution

Inputs:

• Address or coordinates
• Service intent
• Optional user attributes
• Time and availability context

Outputs:

• Correct provider or agency
• Correct digital endpoint
• Correct office or service center
• Correct channel and fallbacks

Typical decisions:

• Which county benefits office serves this address
• Which clinic is in-network and in-area
• Which permit office has authority over this parcel
• Which store or warehouse should fulfill the order

This is the layer where GeoWebDNS is most useful as precedent. It reframes service discovery as a resolver problem: given a named service and a location, what is the correct destination?

4.3 Reference Query Flow

User request
  -> GeoDNS lookup
  -> Edge or regional application ingress
  -> Address normalization / geocoding
  -> Spatial and jurisdiction lookup
  -> Service registry query
  -> Availability and policy filtering
  -> Ranked service target list

The first half optimizes network delivery. The second half resolves the actual service destination.

5. DNS Mechanisms That Matter

5.1 A and AAAA with Geographic Policy

Most GeoDNS deployments still end in A or AAAA answers. The policy engine decides which address to return based on geography, latency, topology, or health. Commercial DNS platforms commonly expose this as geolocation, geoproximity, IP-based, or latency routing.

5.2 SRV and NAPTR

SRV records publish the host and port for a named service. NAPTR records support rewrite and discovery workflows. These records are useful when clients need a protocol-aware way to discover a service endpoint rather than a single host name.

5.3 SVCB and HTTPS

SVCB and HTTPS records make service binding richer. They can publish alternative endpoints and connection parameters before the client establishes a session. That makes them a good fit for modern application delivery, but they still describe network connection metadata rather than application-layer service authority.

5.4 EDNS Client Subnet

EDNS Client Subnet exists because authoritative DNS services often want a better view of end-user topology than the recursive resolver IP alone provides. It improves accuracy for tailored answers, but the tradeoff is additional privacy exposure and more complex caching behavior. For service location resolution, this reinforces a core point: DNS geography is approximate and should not be the only basis for business or jurisdictional decisions.

6. Data Model for Service Location Resolution

Service location resolution needs data structures that DNS itself does not define.

6.1 Core Entities

• Service - the thing the user is trying to obtain
• Provider - the organization offering it
• Endpoint - a URL, API, phone number, or facility
• Service area - the polygon, radius, or jurisdiction set where it applies
• Channel - web, mobile, phone, in-person, mail
• Rule - authority, eligibility, operating, or fallback logic

6.2 Spatial Resolution

The spatial core is usually a point-in-polygon or distance query.

WITH request AS (
  SELECT ST_SetSRID(ST_MakePoint(:lng, :lat), 4326) AS pt
)
SELECT s.name,
       p.name AS provider,
       e.channel,
       e.url,
       a.rule_basis
FROM request r
JOIN service_areas a
  ON ST_Contains(a.shape, r.pt)
JOIN services s
  ON s.id = a.service_id
JOIN providers p
  ON p.id = s.provider_id
LEFT JOIN endpoints e
  ON e.service_id = s.id
WHERE s.intent = :intent
ORDER BY a.authority_rank ASC, e.channel_rank ASC;

The important design choice is that authority rank usually sorts before distance. The correct answer is often “the right service area” rather than “the nearest point.”

6.3 OpenReferral, Juricode, and Service Lookup

OpenReferral provides a standard vocabulary for describing organizations, services, locations, contacts, and schedules. That makes it a strong interchange layer for service catalogs, but it does not by itself answer which listed service should serve a specific point.

Juricode complements that gap by resolving a point into its governing jurisdiction stack. In a civic service router, that creates a practical division of labor:

1. OpenReferral describes the service inventory
2. Juricode determines the authoritative jurisdictional context for the user’s location
3. GeoWebDNS-style lookup resolves the requested service namespace against that context, plus explicit service-area geometry and availability rules

That stack is especially useful when service lookup is not merely “nearest location” but “the correct service with authority over this user here.”

6.4 Output Shape

An application-facing result can be explicit about why a service was selected:

{
  "request": {
    "intent": "general_assistance",
    "address": "300 Hemlock St, Vacaville, CA 95688"
  },
  "dns_ingress": {
    "hostname": "benefits.example.org",
    "region": "us-west"
  },
  "service_target": {
    "provider": "Solano County Health and Social Services",
    "channel": "web",
    "endpoint": "https://benefits.solanocounty.example/apply",
    "authority_basis": "county jurisdiction",
    "coverage_basis": "service area polygon",
    "fallback_rank": 1
  }
}

That audit trail matters. A service router should be able to explain not only where it sent a user, but why.

7. Applications

7.1 Civic and Government Services

Public services are a strong fit because service delivery is often jurisdiction-bound. The system needs to know not just which endpoint is fast, but which agency actually governs the user.

Examples:

• Benefits enrollment
• Permit and licensing workflows
• Voting and election administration
• 311 and public service requests
• School assignment and district services

7.2 Healthcare and Social Services

Healthcare resolution often depends on overlapping spatial and policy constraints:

• Coverage area
• Plan network
• Specialty
• Referral rules
• Capacity

GeoDNS can land the user in the correct regional stack. Service location resolution determines which facility or telehealth channel should actually serve them.

7.3 Commerce, Logistics, and Fulfillment

Retail and logistics systems already solve variants of this problem:

• Which store fulfills buy-online-pickup-in-store
• Which warehouse ships a given order
• Which technician territory owns a service call

Again, low-latency ingress and correct fulfillment destination are related but distinct.

7.4 Multi-Region SaaS with Jurisdictional Rules

Some applications need both:

• GeoDNS for performance and failover
• Location-aware service rules for legal, contractual, or territorial correctness

Examples include tax engines, regulated data systems, region-locked media, and jurisdiction-aware civic platforms.

8. Operational Concerns

8.1 Privacy

GeoDNS uses inferred location. EDNS Client Subnet may expose a truncated client subnet. Application-level service routing may use exact addresses or coordinates. Those are different privacy surfaces and should be governed separately.

8.2 Caching and Freshness

DNS answers are cached by resolvers and clients. Service resolution data changes for different reasons:

• Boundary updates
• Office closures
• Health checks
• Hours and holiday schedules
• Policy and eligibility changes

The caching model should reflect those differences. A short DNS TTL does not solve stale service-area data, and vice versa.

8.3 Fallback Design

A robust resolver should define fallback order explicitly:

1. Authoritative in-area service
2. Secondary channel for the same provider
3. Adjacent service area or overflow provider
4. Generic statewide or national endpoint
5. Human escalation

Without an explicit fallback ladder, systems silently degrade into “nearest location” or “default endpoint,” which is often wrong.

8.4 Observability and Auditability

Routing decisions should be inspectable. Logs and traces should capture:

• DNS decision inputs
• Geocoding result
• Matching service areas
• Applied rules
• Final ranked results

For high-stakes domains such as healthcare, benefits, and public services, explainability is not optional.

9. Conclusion

GeoDNS, GeoWebDNS, and service location resolution solve adjacent layers of the same routing problem. GeoDNS answers: “which network ingress should handle this request?” GeoWebDNS asks: “given this named service and this place, what destination should it resolve to?” Service location resolution answers: “which provider, endpoint, office, or channel should actually serve this user?”

Systems that conflate those layers either overload DNS with application policy or force application stacks to rediscover network routing concerns. The cleaner design is layered:

• DNS for endpoint publication and traffic steering
• Spatial and policy-aware resolvers for real-world service selection

That is the difference between delivering a packet to the right region and delivering a person to the right service.

Appendix A. Standards and Related Systems

• DNS core - RFC 1034 and RFC 1035 define the conceptual and protocol foundations of DNS.
• GeoWebDNS - the OpenPlans geowebdns project is an early, explicit attempt to apply DNS-style resolution ideas to geographic service lookup.
• SRV records - RFC 2782 defines a way to publish the location of a named service in DNS.
• NAPTR and DDDS - RFC 3403 defines DNS as a DDDS database for rule-driven discovery.
• EDNS Client Subnet - RFC 7871 documents an EDNS0 option used to improve tailored DNS responses, with explicit privacy and caching tradeoffs.
• SVCB and HTTPS records - RFC 9460 defines richer service binding records for modern clients.
• Commercial GeoDNS - Amazon Route 53 geolocation and EDNS0 documentation provide concrete examples of how authoritative DNS products expose geographic routing policy.
• OpenReferral - the Human Services Data Specification provides a common structure for service, organization, and location records.
• Geocoding and geometry - the U.S. Census Geocoding Services API, PostGIS, and Juricode-style jurisdiction resolution are representative building blocks for application-layer service location resolution.

References

1. P. Mockapetris. Domain Names - Concepts and Facilities. RFC 1034, November 1987. https://www.rfc-editor.org/info/rfc1034
2. P. Mockapetris. Domain Names - Implementation and Specification. RFC 1035, November 1987. https://www.rfc-editor.org/info/rfc1035
3. OpenPlans. GeoWebDNS. GitHub repository. https://github.com/openplans/geowebdns
4. A. Gulbrandsen, P. Vixie, L. Esibov. A DNS RR for specifying the location of services (DNS SRV). RFC 2782, February 2000. https://www.rfc-editor.org/info/rfc2782
5. M. Mealling. Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database. RFC 3403, October 2002. https://www.rfc-editor.org/info/rfc3403
6. C. Contavalli, W. van der Gaast, D. Lawrence, W. Kumari. Client Subnet in DNS Queries. RFC 7871, May 2016. https://www.rfc-editor.org/info/rfc7871
7. B. Schwartz, M. Bishop, E. Nygren. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). RFC 9460, November 2023. https://www.rfc-editor.org/info/rfc9460
8. Amazon Web Services. Geolocation routing. Amazon Route 53 Developer Guide. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html
9. Amazon Web Services. How Amazon Route 53 uses EDNS0 to estimate the location of a user. Amazon Route 53 Developer Guide. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-edns0.html
10. Open Referral. What is the Human Services Data Specification (HSDS)? https://docs.openreferral.org/en/latest/hsds/what_is_hsds.html
11. U.S. Census Bureau. Geocoding Services API. https://geocoding.geo.census.gov/geocoder/Geocoding_Services_API.html
12. PostGIS Project. Official Manual. https://postgis.net/documentation/manual/