Public, private, static and dedicated are independent address properties. Build a deployment map that also covers routing, firewalls, forward DNS, reverse DNS and TLS, and verify each setting with the party that controls it.
Address properties answer different questions
Public and private describe where an address is intended to be routed. Static and dynamic describe how an assignment behaves over time. Dedicated and shared describe how an address is used or allocated within a service. These are separate properties: a stable public address might serve many sites, and a private address can be assigned dynamically inside a controlled network.
Write the role of each address in the deployment: public entry point, internal database, management route or outbound connection. Then identify who assigns it and what can change. This prevents configuration work from depending on an assumption such as dedicated means permanently fixed or public means the service is reachable. Reachability also depends on routing, firewalls and the application's listener.
Private addressing still needs routing and access control
RFC 1918 reserves the IPv4 ranges 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 for private networks. Their addresses are not globally unique public destinations. A network may translate private addresses for outgoing connections or connect private networks through explicit routes. An inbound service behind translation needs a deliberate publication method; changing a DNS record alone does not create that route.
IPv6 has its own address types and scopes, including link-local addressing and globally routable unicast addresses. Review it separately rather than assuming an IPv4 firewall or translation rule covers IPv6. A private address is not an authentication mechanism, and a public IPv6 address is not a reason to expose every service. Test access from each relevant network and restrict administration at the appropriate boundary.
Stable names and stable addresses are related
DHCP allocates address configuration through a protocol and can use leases. A dynamically assigned address may remain unchanged for some time; that does not make its permanence a contractual guarantee. When an application depends on a stable address, verify the provider's assignment and change policy instead of inferring it from yesterday's connection.
Dynamic DNS can update a name after an address changes, but clients may still cache the previous answer. It also cannot overcome an unreachable listener, a missing inbound route or carrier-grade address translation. Use it when the network permits the connection and the application tolerates update delays. For a hosted deployment, document the intended address lifecycle before building allowlists or external integrations around it.
| Property | What to confirm | Common mistaken assumption |
|---|---|---|
| Public or private | Routing scope and access path | An address alone makes a service reachable |
| Static or dynamic | Assignment and change policy | An unchanged lease is permanent |
| Dedicated or shared | Allocation and allowed use | A dedicated address provides anonymous identity |
| IPv4 or IPv6 | Both routing and firewall configurations | One protocol's settings cover the other |
Forward DNS and reverse DNS have different owners
Forward DNS maps names to data such as A and AAAA address records. Reverse DNS uses an address-related namespace and PTR records to associate an address with a name. The organisation controlling the forward DNS zone is not necessarily the organisation controlling reverse DNS for the address range. Obtain the right configuration path before promising a reverse name.
Check the record through the appropriate resolver and record the result. For a PTR intended to identify a host, also check whether the corresponding forward record points to the expected address. Reverse DNS can support operational identification and some mail-system checks, but it does not authenticate an application or guarantee message delivery. Mail sending also needs its own domain, reputation and authentication review.
A dedicated address is not required for every HTTPS site
HTTP host routing and the TLS Server Name Indication extension allow supported clients and servers to select a site or certificate by name. Several HTTPS sites can therefore use an address without requiring one public address per domain. The actual hosting configuration and required clients determine whether that arrangement is suitable.
Choose an extra address only when a documented requirement calls for one, such as a supported network separation or an external system that expects a distinct endpoint. An address does not provide immunity from reputation problems or identify the person operating a service. Keep certificates, hostname routing and address allocation as separate checks. Verify the served certificate through the hostname users will actually visit.
Use a deployment map before changing records
Create a small map containing each hostname, address record, listener, firewall path and responsible party. Include administration, backups and any outbound allowlists. Check whether the SwissOctet configuration lists the address option you need and ask about reverse DNS control before relying on it. Do not present catalogue options as a live assignment that has already been provisioned.
During a move, prepare the destination application and TLS settings before directing users there. Account for DNS caches and maintain a workable recovery path. Verify forward resolution, actual application reachability and the expected reverse name separately. The map makes failures easier to locate because a wrong record, a closed port and a mismatched certificate are different problems with different owners.
Your practical checklist.
- Map address role, assignment and ownership.
- Check IPv4 and IPv6 separately.
- Verify inbound routing before relying on DNS.
- Identify who controls PTR records.
- Test the hostname, certificate and application together.
The details that matter.
Does a dedicated IP make a service anonymous?+
No. It describes an allocation or use arrangement, not an identity or privacy guarantee. Accounts, traffic and application data have separate implications.
Can I set PTR records from my domain's DNS panel?+
Only if it also controls the relevant reverse zone. The address provider commonly controls that zone or supplies a separate request process.
Does each HTTPS domain need its own address?+
Not necessarily. Supported clients and servers can use name-based routing and TLS SNI. Verify the actual hosting and client requirements.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- RFC 1918: Address Allocation for Private Internets www.rfc-editor.org
- RFC 2131: Dynamic Host Configuration Protocol www.rfc-editor.org
- RFC 1035: DNS implementation and specification www.rfc-editor.org
- RFC 4291: IPv6 Addressing Architecture www.rfc-editor.org
- RFC 6066: TLS extensions, including Server Name Indication www.rfc-editor.org
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.