---
title: "IP/hostnames"
slug: "iphostnames-v6-6"
description: "Learn how to define hosts using IP addresses and hostnames in AppGate ZTNA, ensuring proper DNS configuration for secure access."
updated: 2026-02-23T18:45:54Z
published: 2026-02-23T18:45:54Z
canonical: "support.appgate.com/iphostnames-v6-6"
---

> ## 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 ZTNA system. These will be resolved by some internal [DNS server(s) via the Gateways](/v1/docs/dns-and-name-resolution-v6-6) which are normally [configured on the Site](/v1/docs/dns-resolving-v6-6) 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 three ways and in the following order:

- by a specific [DNS Policy](/v1/docs/configure-policies-v6-6) assigned to the user.
- automagically from within the [DNS resolver](/v1/docs/dns-resolving-v6-6) using a hidden Policy.
- by the [Identity Provider](/v1/docs/general-settings-v6-6) 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-v6-6) or the [DNS Forwarder depending](/v1/docs/dns-and-name-resolution-v6-6) on the prefix used.

The DNS Forwarder treats different domains resolving to the same IPs (shared hosting, CDNs etc) as the same. In this case, *.domain-based Entitlements 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 | DNS Forwarder | Resolves the IP addresses of myserver1.my_co.com, myserver2.my_co.com, myserver3.my_co.com, etc |
| dns://*.my_co1.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-v6-6). This can be avoided if instead you use the [DNS forwarder](/v1/docs/dns-and-name-resolution-v6-6).