URL redirects and direct DNS pointing explained
When someone types a web address into a browser, several systems work together before a page appears. The domain name must be translated into an IP address, the browser must contact a web server, and that server may then send the visitor somewhere else. These steps can look similar from the outside, yet they serve different purposes.
The difference between URL redirect and direct DNS pointing matters when moving a website, connecting a domain to a hosting provider, setting up a campaign address, or replacing a temporary parked page. Choosing the wrong method can create broken links, certificate warnings, email problems, or an address that behaves differently from what visitors expect.
A direct DNS record tells the internet where a domain should be found. A redirect is an instruction delivered after a visitor has reached a web server, telling the browser to request another address. One operates at the domain-name resolution level; the other operates at the web and HTTP level.
This distinction is useful for Australian organisations working with local agencies, overseas hosting platforms, government portals, or small-business websites. A café in Fremantle, a trades business in Parramatta, and a community group in regional Queensland may all use the same domain tools, while needing very different outcomes.
How DNS pointing and redirects work
The Domain Name System acts like a distributed directory. An A record maps a hostname to an IPv4 address, while an AAAA record maps it to an IPv6 address. A CNAME record maps one hostname to another hostname, which is common for services such as content delivery networks, hosted shops, and website builders.
Suppose example.com.au has an A record pointing to a hosting server. A visitor enters the domain, DNS provides the server address, and the browser connects to that destination. If the server is configured to serve the site for that hostname, the visitor remains at example.com.au and sees the requested content.
A URL redirect happens later. The browser reaches a server, receives an HTTP response such as 301 or 302, and then makes a new request for another URL. The address bar changes from the old address to the destination. Redirects can send visitors from an old domain to a new domain, from HTTP to HTTPS, or from an outdated page to a current one.
DNS cannot usually redirect a visitor from /old-page to /new-page. DNS deals with hostnames such as www.example.com.au; it does not understand paths, query strings, page titles, or most URL-level rules. That is why a forwarding service, web server configuration, or application setting is needed for page-by-page redirection.
When direct DNS pointing is the better choice
Direct DNS pointing is generally appropriate when the domain should display a website hosted elsewhere while retaining the same visible address. A business might register its domain through one provider, keep email with another, and point the website records to a third-party platform. The domain registrar and web host do not have to be the same company.
This arrangement is often called DNS connection, domain mapping, or pointing the nameservers. If the platform supplies specific A or CNAME values, those records are entered at the authoritative DNS provider. The host then recognises the domain and serves the matching website. The visitor does not see a forwarding address.
Direct records are also useful when several subdomains have separate functions. www might point to a website builder, shop to an online store, and mail to an email service. An Australian retailer operating from Adelaide could use this structure while keeping customer email on Microsoft 365 and its online catalogue on a specialist commerce platform.
Care is needed with the root or apex domain, because some DNS providers handle CNAME records there differently. A platform may ask for an A record, an ALIAS, an ANAME, or nameserver delegation. The instructions should be followed precisely rather than adding multiple competing records. An accidental duplicate A record can make a site appear intermittently available as different resolvers select different destinations.
When a URL redirect makes more sense
A redirect is the practical option when the original address should lead visitors to a different address. This is common after rebranding, changing a domain extension, consolidating duplicate pages, or promoting a short campaign URL. For example, oldbusiness.com.au can permanently send visitors to newbusiness.com.au, while links printed on signs and invoices continue to work.
A 301 redirect usually signals a permanent move to browsers and search engines. A 302 redirect is generally used for a temporary change, such as a short-term campaign or maintenance arrangement. Misusing a temporary status for a permanent migration can weaken search signals and leave old pages indexed longer than expected.
Redirects can preserve useful paths when configured carefully. A rule may send /services to the equivalent page on a new website, rather than dropping every visitor at the homepage. Query strings may also matter for advertising measurement. A marketing team in Melbourne should test whether tracking parameters survive the redirect before relying on campaign reports.
A parked domain page is a different situation from an active redirect. A placeholder supplied by a registrar or hosting company may simply display a welcome message, provider attribution, copyright notice, and privacy link. It may have no working business, product, or service behind it. If the domain owner wants visitors to reach a real site, the domain needs either valid DNS pointing to that site or a configured forwarding rule; leaving the parked page in place will not create a functioning web presence.
Comparing the two approaches
The right choice depends on whether the domain itself should host the content or whether visitors should be sent somewhere else. DNS pointing keeps the requested hostname in the browser, assuming the destination server is set up to accept it. A redirect exposes the new destination and requires an additional browser request.
The distinction is particularly important for email. Changing website records does not automatically move mail, and changing nameservers can remove existing MX, SPF, DKIM, and DMARC records if they are not recreated. A Brisbane organisation migrating its website should document its email records before editing DNS, because a successful web launch is of little value if staff mailboxes stop receiving messages.
| Issue | Direct DNS pointing | URL redirect |
|---|---|---|
| What it changes | Where a hostname resolves | Where a browser requests content |
| Address bar | Usually stays the same | Changes to the destination URL |
| Page paths | Managed by the destination server | Can be redirected individually |
| Typical status | No HTTP redirect is required | Usually 301, 302, 307, or 308 |
| Best for | Connecting a domain to hosting | Moving visitors between addresses |
| HTTPS needs | Certificate for the connected domain | Certificates for the redirecting and destination domains may be needed |
| Email effect | Depends on records changed | Usually separate from mail DNS |
| SEO migration | Preserves the original hostname | Transfers visitors and signals to a new URL when configured correctly |
| Common risk | Incorrect or conflicting records | Redirect loops, chains, or lost paths |
DNS changes are cached according to their time to live, or TTL. A low TTL can make later changes visible sooner, but it does not guarantee instant global updating. Visitors in Sydney, Perth, and Hobart may temporarily receive different answers because internet service providers and public resolvers refresh cached information at different times.
Australia’s geography makes this variation noticeable, especially for small operators testing a launch from multiple networks. A change that appears complete on an office connection may still show the previous destination on a mobile network or at a customer’s home. Testing with several resolvers and allowing time for propagation is safer than repeatedly editing records.
Security, performance, and search considerations
HTTPS must be planned for both methods. With direct DNS pointing, the destination host needs a valid certificate covering the domain visitors use, including www if that hostname is active. A redirect from an old HTTPS domain still needs a valid certificate because the browser establishes a secure connection before it can receive the redirect.
Redirect chains should be kept short. Sending an old URL to an intermediate URL and then to a final URL adds delay and increases the chance of a loop. A clean migration normally sends each important old address directly to its matching final address. Canonical tags, internal links, XML sitemaps, and advertising destinations should then be updated to use the final URLs.
DNS changes also affect performance and resilience. A provider may use a content delivery network, health checks, or geographically distributed infrastructure behind a single hostname. In other cases, a basic A record points directly to one server. The best option depends on the website’s traffic, security requirements, and tolerance for outages rather than on whether one provider is familiar.
Accessibility and public access deserve attention during a domain change. An organisation that moves a public information site should test keyboard navigation, readable error pages, document links, and mobile layouts after the DNS or redirect work. Projects concerned with barriers in digital government can review resources from accessibility advocates while checking that an address change does not strand people using older devices or assistive technology.
A practical setup and testing process
Start by recording the current DNS zone, including A, AAAA, CNAME, MX, TXT, and any verification records. Identify which service controls authoritative nameservers and which provider supplies the website. This prevents a common mistake: editing records in a registrar dashboard that is not actually authoritative for the domain.
Next, decide whether the visible address should remain unchanged. If the answer is yes, obtain the hosting provider’s exact DNS instructions and configure the required records. If the answer is no, set up a redirect at a service capable of handling the old domain and its HTTPS certificate. For a full migration, map important old pages to relevant new pages rather than relying on a single blanket rule.
Allow for DNS caching, then test from more than one connection. Check the root domain, www version, HTTPS version, common page paths, and any subdomains. Use browser developer tools or command-line utilities such as dig and curl to inspect DNS answers, response codes, redirect destinations, and certificate details.
Review email separately after every nameserver or DNS-zone change. Confirm that MX records still point to the mail provider and that SPF, DKIM, and DMARC remain present. A local club in Canberra or a family business on the Sunshine Coast may have only one person monitoring this work, so keeping a dated backup of the original records is a simple safeguard.
A successful test should show a clear final state: the intended content loads, the address bar behaves as planned, secure connections work, old links resolve appropriately, and email remains operational. If a parked provider page still appears, check whether the domain is pointing to the new host, whether the host has added the domain to the account, and whether cached DNS is masking the change.
Use the distinction between DNS resolution and HTTP forwarding to choose the setup before making edits. Document the records, redirect rules, certificates, and email dependencies, then test the result from Australian networks and on mobile devices. A careful configuration can turn an unused placeholder domain into a reliable address without disrupting existing visitors or communications.