Help: How To Call A Domain Name From Another Domain Name In Asp.net

Short answer: make the request for a2.com land on the john.com app (or have a2.com front-end call john.com's API). If a2.com must show john.com's member pages without changing the browser address, either point a2.com at the john.com server and let the john app serve different content based on the Host header, or run a reverse proxy that forwards requests to john.com while preserving the Host header. If a2.com cannot be pointed to the same server, use an API on john.com that a lightweight a2.com front end calls.

Practical steps for the simplest, production-ready approach (domain mapping + host-aware routing):

• Add an A or CNAME record for a2.com to the john server IP (or have the member set it).
• Add a host name binding for a2.com in IIS (or your webserver) so the john app receives requests for that host.
• In the john app detect Request.Url.Host and load the correct member profile/template from the central tenant store. Issue a certificate for a2.com (SAN/wildcard or per-host cert) so HTTPS works.
• Watch cookies and sessions: separate cookie names or use an out-of-process session store to avoid cross-tenant collisions.

Example tenant lookup logic (ASP.NET):

string host = Request.Url.Host.ToLowerInvariant();
var tenant = TenantRepository.GetByHost(host);
if (tenant == null) { Response.StatusCode = 404; return; }
// use tenant settings to load data and templates for that domain

Alternatives and cautions:

• Reverse proxy (IIS ARR, Nginx) can be used if DNS changes aren’t possible; preserve Host header so the app can detect tenant.
• Exposing a JSON web API from john.com and building a2.com front-end that calls it avoids sharing infrastructure, but requires CORS and secure auth.
• Iframes and simple redirects will work technically but have UX, SEO, and same-origin limitations.

This expands on @Letscode and @tgreer: a browser redirect will change the address bar, and the underlying data still needs to be provided centrally. Common troubleshooting: test with hosts file before DNS changes, confirm IIS bindings and certificate, check logs for host header mismatches, and verify cookie/session behavior.