---
title: "IP/hostnames"
slug: "iphostnames-v6-5"
description: "Learn how to define hosts using IP addresses and hostnames, ensuring proper DNS configuration and avoiding common pitfalls in your network setup."
updated: 2025-12-18T20:48:06Z
published: 2025-12-18T20:48:06Z
canonical: "support.appgate.com/iphostnames-v6-5"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.appgate.com/llms.txt
> Use this file to discover all available pages before exploring further.

# IP/hostnames

The simplest (and traditional) way of defining hosts when creating an Action is to use IP addresses or hostnames.

## Using IP addresses

IP addresses can be used directly.

### Supported formats

| Host definition | Use for |
| --- | --- |
| 1.0.0.26 | Single entries |
| 1.0.0.26, 1.0.0.30 | Multiple entries |
| 1.0.0.0/28 | Subnets |
| 1.0.0.0/28, 1.0.0.128/28 | Multiple subnets |

## Hostnames (DNS)

Hostnames can be used directly or with specific prefixes which dictate exactly how they will be handled by the Appgate SDP system. These will be resolved by some internal [DNS server(s) via the Gateways](/v1/docs/dns-and-name-resolution-2) which are normally [configured on the Site](/v1/docs/dns-resolving) where the internal DNS server(s) resides. Typically Clients will use the same DNS server(s) as the Gateways. Even though shortnames might work (because of the way Windows handles DNS domains), you should not use shortnames when defining hosts.

Clients have their DNS configured in one of 3 ways and in the following order:

- by a specific [DNS Policy](/v1/docs/configure-policies) assigned to the user.
- automagically from within the [DNS resolver](/v1/docs/dns-resolving) using a hidden Policy.
- by the [Identity Provider](/v1/docs/general-settings) that the user authenticates against (old way).

> [!NOTE]
> **NOTE**
> 
> In the last two cases, remember to include an Entitlement to allow the Client access to the specified DNS server(s).

Hostnames are resolved in one of two ways - using the [DNS resolver](/v1/docs/dns-and-name-resolution) or the DNS Forwarder depending on the prefix used.

The DNS Forwarder:

- Does not support overlapping domains so any domains belonging to one Site must have the same depth. For example, a configuration with https://application.web.my.co and https://web.my.co is not supported, but https://application.web.my.co and https://binary.web.my.co is supported.
- Different domains resolving to same IPs (shared hosting, CDNs etc) are treated as same. In this case *.domain based cannot provide separation based on the hostname as they work based on the resolved IPs.

### Supported syntax

| host definition | Resolved by | Result |
| --- | --- | --- |
| myserver1.my_co.com | DNS Resolver | Resolves to the IP addresses of myserver1.my_co.com |
| myserver1.my_co.com, myserver2.my_co.com | DNS Resolver | Resolves the IP addresses of myserver1.my_co.com and myserver2.my_co.com |
| dns://myserver1.my_co.com | DNS Resolver | Resolves to the IP addresses of myserver1.my_co.com |
| dns://myserver1.my_co.com, dns://myserver2.my_co.com | DNS Resolver | Resolves the IP addresses of myserver1.my_co.com and myserver2.my_co.com |
| http://myserver1.my_co.com | DNS Resolver | Resolves to the IP addresses of myserver1.my_co.com - see URL access below |
| https://myserver1.my_co.com | DNS Resolver | Resolves to the IP addresses of myserver1.my_co.com - see URL access below |
| *.my_co.com [*.domain.commy_co.com] | DNS Forwarder | Resolves the IP addresses of myserver1.my_co.com, myserver2.my_co.com, myserver3.my_co.com, etc |
| *.my_co1.com [*.my_co1.com], *.my_co2.com [domain://my_co2.com] | DNS Forwarder | Resolves the IP addresses of myserver1.my_co1.com, myserver1.my_co2.com, myserver2.my_co2.com, etc |

* You should always use dns:// if you can - especially in the case of a single host. It is possible to create security issues using *.domain as it will return (and allow access to) all subnets/hosts within the defined domain.

When trying to configure access to a SaaS provider, DNS synchronization issues can occur if you use the [DNS resolver](/v1/docs/dns-and-name-resolution). This can be avoided if instead you use the DNS forwarder.

Appgate SDP (Software Defined Perimeter) is a security solution that provides secure access to resources based on user identity and context, leveraging a zero trust security model.

A Policy is a set of rules that govern access control and permissions for users and devices within the Appgate ZTNA system. Policies determine what resources users can access based on their entitlements.

A defined access right or permission granted to users or devices, allowing them to access specific resources or functionalities within the Appgate ZTNA system.