Dedicated Server IP Addresses: What to Verify Before You Rent

A dedicated server can have the right CPU, storage, and bandwidth and still be awkward to deploy because its IP setup does not match the workload. You may receive one IPv4 address when several services need separate addresses, discover that reverse DNS requires a support ticket, or learn during migration that an address cannot move to the replacement server.

These are rental questions, not details to leave until application deployment. Before ordering, establish which addresses you receive, how IPv6 is delivered, who controls reverse DNS, whether additional addresses are available, and what happens to those addresses when the server is replaced or canceled.

Start With the Services That Need Addresses

Do not begin by asking how many IP addresses a provider includes. First identify what actually needs an address and why.

A conventional web server may need only one public IPv4 address plus IPv6. Several HTTPS sites can share the same address, so assigning one IPv4 address per domain is normally unnecessary. A virtualization host, VPN gateway, mail system, DNS service, customer hosting platform, or application with external allowlists may have different requirements.

Make a short inventory before comparing plans:

• public services that must accept inbound connections;
• services that require a stable outbound source address;
• external systems that will allowlist the server;
• applications that need dedicated addresses for operational reasons;
• IPv6 requirements;
• reverse DNS requirements;
• addresses needed temporarily during migration or parallel operation.

Separate technical requirements from convenience. Additional public IPv4 addresses may carry recurring fees or require justification, while many workloads can share an address without affecting normal operation.

This inventory belongs beside the CPU, memory, storage, and network requirements described in the dedicated server selection guide. Network addressing can constrain a deployment even when the hardware is otherwise suitable.

Verify Exactly What the Rental Includes

Provider pages may describe networking as “1 IPv4,” “IPv4 included,” “IPv6 available,” or similar shorthand. That is not enough information for a production deployment.

For the exact server and location you plan to rent, determine:

• how many public IPv4 addresses are included;
• whether IPv6 is included and how it is assigned;
• whether addresses are static for the life of the rental;
• whether additional IPv4 addresses can be ordered;
• whether additional addresses have setup or recurring charges;
• whether the provider requires justification for extra addresses;
• whether addresses are configured directly on the server or routed to it;
• whether private addressing is available for communication between servers;
• who controls reverse DNS;
• whether addresses can move between servers within the provider’s network.

Check the actual product terms rather than assuming that two plans from the same provider use the same address policy. Availability and routing options can differ by product family and location.

Understand How the Addresses Reach the Server

An address assigned to a dedicated server is not always configured in the same way. The provider may place the server on a subnet, route individual addresses or prefixes toward it, or require a specific gateway arrangement.

This distinction becomes important when you add addresses, run virtual machines, build a firewall, or move an existing configuration from another provider.

Before deployment, obtain the information required to reproduce the intended network configuration:

• assigned IPv4 address or addresses;
• prefix or netmask information;
• default gateway;
• IPv6 prefix and gateway behavior;
• provider-specific routing requirements;
• any restrictions on using assigned addresses inside virtual machines or containers;
• private-network configuration, if ordered.

Do not copy the network configuration from the old server and substitute a new address. Providers can use different routing models even when both servers appear to have ordinary public IPv4 connectivity.

During initial deployment, confirm the configured addresses and routes before changing firewall rules. The dedicated server handover checklist treats network verification as an acceptance test because a working SSH session proves only one path through the configuration.

Decide Whether You Need Additional IPv4 Addresses

More IPv4 addresses do not automatically make a dedicated server more capable. Order them when a real service requirement calls for them.

One common reason is virtualization. A host may need addresses for individual virtual machines when those guests must be directly reachable from public networks. Another is network separation for services that cannot share the same addressing model. Some applications also need a stable dedicated source address because external partners identify traffic by IP.

Before paying for additional addresses, ask whether the requirement could instead be handled by:

• name-based virtual hosting;
• a reverse proxy;
• port mapping;
• a private network;
• IPv6;
• an application-level routing layer.

These are not universal replacements. They simply prevent address count from becoming a proxy for architecture.

If additional IPv4 space is genuinely required, verify availability before ordering the server. Do not assume you can add the required number later. Also check whether the provider assigns individual addresses, a routed block, or another configuration, because that affects how you configure the host and any guests behind it.

Treat IPv6 as a Separate Deployment Path

“IPv6 included” should lead to several more questions.

Find out whether the provider supplies one address or a prefix, how the prefix is routed, what gateway configuration is required, and whether reverse DNS can be managed for IPv6 addresses. If the workload will publish both A and AAAA records, test both protocol paths independently.

Dual-stack operation introduces behavior that an IPv4-only test will not reveal. RFC 6724 defines default address-selection rules for IPv6 and dual-stack communication, including how systems select among available source and destination addresses.

In practical terms, publishing an AAAA record means clients may attempt to use IPv6. A service that works perfectly over IPv4 can therefore appear broken to some users if IPv6 is advertised but the server, firewall, application, or return route is configured incorrectly.

Before publishing production AAAA records:

1. confirm the intended IPv6 address and routing;
2. verify host firewall rules for IPv6 rather than assuming IPv4 rules cover both stacks;
3. confirm that the application listens on the intended IPv6 socket;
4. test inbound connectivity from an external IPv6 network;
5. test required outbound connections over IPv6;
6. verify monitoring over IPv6 if the protocol is part of the production service.

Do not enable IPv6 in DNS merely because the server has an IPv6 address. Publish it when the complete service path works.

Check Reverse DNS Before You Need It

Forward DNS maps a hostname to an address. Reverse DNS performs the opposite lookup. For IPv4, reverse mappings use the in-addr.arpa hierarchy; IPv6 uses ip6.arpa. The mapping itself is represented with a PTR record.

With rented dedicated servers, the provider or upstream address holder normally controls the address space from which your server IP is assigned. As a result, creating a PTR record may not work through the same DNS control panel you use for your domain.

Before renting, determine how the provider handles reverse DNS:

• Can you set PTR records in the customer portal?
• Does changing a PTR require a support request?
• Can you configure PTR records for both IPv4 and IPv6?
• Are there restrictions on the hostname you can use?
• How are PTR records handled for additional addresses?
• What happens to reverse DNS when an address is replaced?

RIPE NCC documentation describes reverse DNS as the mapping from an IP address to a designated domain name and explains the delegation model behind IPv4 and IPv6 reverse zones. For a renter, the operational consequence is simple: confirm who has authority to make the change before the application depends on it.

Forward and reverse records should tell a coherent story

For a static server hostname, a common configuration is to have the PTR point to a hostname whose forward A or AAAA record resolves back to the address. RFC 8501 discusses matching forward and reverse records as an operational practice for static addresses and names.

This is particularly worth checking when the server will send mail or interact with systems that inspect reverse DNS. Do not assume that configuring a hostname inside Linux changes public reverse DNS. They are separate configurations controlled through different systems.

Control the Outbound Source Address

Multiple addresses on one server create another issue: which address does an outbound connection use?

The answer depends on the operating system, routes, protocol, and application behavior. Address-selection rules can choose a source automatically when the application has not explicitly selected one.

This matters when a third-party service has allowlisted a specific source address. An application can accept traffic on the expected IP while outbound API calls leave through another address.

After configuring multiple addresses, test the outbound path for every service that depends on source-IP identity. Examples include:

• database connections protected by network allowlists;
• partner APIs;
• payment or identity services;
• VPN peers;
• outbound mail;
• backup destinations with source restrictions.

If a fixed source is required, configure the application or routing policy deliberately rather than assuming the operating system will always choose the address you expect.

Plan for IP Changes During Migration

An IP address can become one of the hardest dependencies to find during a migration.

DNS records are obvious. Less obvious dependencies include firewall allowlists, SaaS dashboards, payment gateways, database access lists, VPN configurations, monitoring platforms, webhook restrictions, license systems, and partner networks.

Before moving to another dedicated server, search the running environment and operational documentation for every place where the old address appears.

The dedicated server migration checklist recommends inventorying DNS, fixed source addresses, VPNs, private links, and external systems restricted by IP before cutover. Do that work before the old server is scheduled for cancellation.

If keeping the same public address would materially simplify recovery or migration, ask the provider whether address reassignment between its servers is supported. Do not design the migration around that assumption until the provider confirms it for the relevant products and locations.

Know What Happens When the Server Is Replaced

Physical server replacement creates a similar question. If the machine fails and the provider supplies another server, will the existing addresses be routed to the replacement, or will you receive new ones?

The answer affects recovery time.

A new IP can require DNS changes, firewall updates, external allowlist changes, monitoring changes, VPN reconfiguration, and coordination with third parties. Some of those changes may take longer than provisioning the replacement hardware.

Add IP continuity to the same pre-rental review you use for hardware replacement. The dedicated server SLA checklist separates physical replacement from complete service recovery; address reassignment is one of the dependencies that can sit between those two events.

If the provider cannot guarantee address portability, document how the workload will recover with new addresses.

Verify the Network Before Production

Once the server is provisioned, test the addressing assumptions while changing the configuration is still cheap.

1. Compare the assigned IPv4 and IPv6 resources with the order.
2. Record the provider’s gateway and routing instructions.
3. Verify inbound and outbound IPv4 connectivity.
4. Verify IPv6 independently if it will be used.
5. Check that required applications listen on the intended addresses.
6. Test firewall policy on both protocol families.
7. Confirm the outbound source address used by services with allowlists.
8. Configure and query required PTR records.
9. Test external monitoring against the addresses clients will use.
10. Record the process for adding, replacing, or reassigning addresses later.

Keep this information with the server’s operational record. Addresses, prefixes, gateways, reverse DNS names, provider procedures, and external dependencies are recovery data. They should not exist only inside the server they describe.

Use the Address Policy as Part of the Rental Decision

Before ordering, you should be able to state how many public addresses the workload needs, whether IPv6 will be used, who manages reverse DNS, and what external systems depend on a stable source address. You should also know whether additional addresses can be added and what happens to the existing allocation during migration or hardware replacement.

For a simple web server, the answers may be straightforward: one public IPv4 address, working IPv6, and manageable reverse DNS may be enough. A virtualization host, mail system, or service tied to third-party allowlists needs more preparation.

Choose the server only after its addressing model fits the deployment and recovery plan. Changing CPU or adding storage can be inconvenient; discovering that a production dependency is tied to an address you cannot keep can be much harder to unwind.