FAQ's

HYAS Protect has a variety of different deployment methods to suit almost any organization. Learn more about which deployment methods here.

Yes. HYAS Protect fully supports Split-Horizon DNS through agent-based configurations. This allows the agent to determine whether it's on an internal or external network and route DNS queries accordingly.

To enable this feature, you define:

• A test domain that resolves only when on the internal network.

• An expected IP address (typically a private IP) returned by that domain.

• Your internal local resolvers and local domain suffixes.

When the test domain resolves to the expected IP, the agent uses the internal DNS resolvers for specified domains. If the test fails, HYAS Protect falls back to its secure cloud resolvers. This ensures seamless access to internal resources while maintaining external DNS protection.

For full configuration details, see: HYAS Agent Configuration Guide

Yes. HYAS Protect includes built-in Safe Search enforcement capabilities for major search engines, including Google, Bing, and DuckDuckGo.

When enabled, HYAS Protect automatically redirects search queries to use each platform’s "Safe Search" or "Strict" filtering mode. This feature helps prevent users from encountering inappropriate or unsafe content during web searches.

Safe Search enforcement is managed through agent-based deployments.

For details on enabling and customizing Safe Search, see here.

Yes. HYAS Protect allows you to define Local Resolution Settings that specify which domains should bypass HYAS resolvers and use your internal DNS infrastructure instead.

This includes:

• Local Domains: A list of domain suffixes (e.g., .corp, .internal) that the agent should resolve using internal DNS.

• Local Resolvers: The internal DNS servers (IP addresses) the agent should query for those domains.

These settings are especially useful in enterprise environments where internal applications or services rely on non-public DNS resolution. When combined with Split-Horizon DNS detection, HYAS Protect intelligently routes DNS queries based on network context.

For setup instructions, see: HYAS Agent Configuration Guide

Local DNS resolution is when your computer looks up internal domain names (like server01.local or hr.companyname.corp) using your organization’s internal DNS servers, instead of going out to the public internet.

This is common in business environments where you have:

• Internal servers and services not meant to be exposed to the internet.

• Custom domains that only exist inside your network.

• Tools and applications that rely on resolving internal hostnames.

Without properly configured local DNS, users may not be able to access internal resources like file shares, printers, or internal web apps.

What to Do if Internal Domains Aren’t Working with the HYAS Protect Agent

If you're using the HYAS Protect Agent and you can’t access internal or local domains, it's probably because the Agent is trying to resolve everything—including internal domains—using HYAS's external DNS resolvers.

To fix this, you'll need to tell the Agent which domains to resolve locally and which DNS servers to use.

Here’s how:

Step-by-Step: Configure Local DNS Resolution in HYAS Protect

1. Log in to the HYAS Protect Web UI
   Go to your organization’s portal and sign in.

2. Go to Agent Settings
   Navigate to:
   Organization Settings > Protect Agent > Settings

3. Configure Local Domains
   In the Local Domains section, add all internal domains that should not be resolved by HYAS (e.g., corp.local, internal.companyname.com, etc.).
   These domains will be excluded from normal HYAS resolution.

4. Set Up Local Resolvers
   In the Local Resolvers section, specify the internal DNS servers (IP addresses) that should handle lookups for the local domains you just defined.
   For example:

   • 10.0.0.2

   • 192.168.1.10

5. Important: You Must Do Both
   The Agent needs both the local domains and the resolvers defined.

   • If you only set domains and no resolvers → the Agent won’t know where to send the queries.

   • If you set resolvers but no domains → the Agent won’t know what queries to send to them.

Troubleshooting Tip

If internal resources still aren't accessible after setting this up:

• Double-check domain spelling (e.g., .local vs .com)

• Make sure the internal DNS servers are reachable from the device

• Ensure there’s no firewall blocking port 53 (DNS)

If your organization can resolve internal domains but not external ones, this is typically caused by firewall rules blocking outbound DNS traffic to HYAS Protect. HYAS Protect’s Anycast resolvers must be reachable for external domain resolution to function.

Ensure your firewall allows:

• UDP and TCP port 53 to HYAS Protect’s Anycast IPs: 68.220.41.83 and 68.220.41.134

Allowing these connections ensures that protected endpoints can resolve external domains properly while maintaining security policies.

The simplest way to identify why a query was blocked is to:

1. Open the DNS Log view from the left-hand menu.

2. Use the More Filters + option to search for the specific query.

3. In the results, check the Reason column for the high-level cause of the block.

4. Hover over the Reason to see detailed information, including the Rule, Category, or Block/Allow List that triggered it.

5. If the Reason is shown as HYAS Engine, review the Threats column for additional threat intelligence related to the block.

There are several possible reasons why this might occur. Start by clarifying the expected behavior:

• Do you expect the domain to be blocked because you manually added it to a Block List, assigned it to a blocked category, or created a Rule to block it?

• Or do you believe the HYAS Protect Decision Engine should have automatically blocked it based on threat intelligence?

In the first case, there are a few things you should check:

Category Blocking

1. Verify the Category Setting

   1. In the Policy Management UI, confirm that the category is configured to Block.

2. Check Policy Status

   • Ensure the policy’s Current Status is set to Enabled.

3. Validate the Domain’s Category

   • Use the Category Lookup tool to confirm that the domain or FQDN is actually classified under the category you expect.

4. Review Policy Application

   • Confirm that the policy applied to the relevant network asset (User Group or Source Network) includes the category you intend to block.

   • If the category is not blocked in that policy, update the policy settings accordingly.

   • If no explicit policy is applied, remember that the default policy will take effect, so ensure the default policy’s category settings align with your blocking expectations.

   • Note on Policy Precedence: If the network asset is part of another policy, that policy will override the default policy and determine whether the category is blocked or allowed.

   • Confirm that no Rules are in place that would override policy logic and allow traffic from the category you intended to block. Rules take precedence over policy settings.

Rule Blocking

1. Check Policy Status

   • Ensure the policy’s Current Status is set to Enabled.

2. Check Rule Status

   • Ensure that the Rule is set to Enabled.

3. Review Rule Application

   • If you have multiple rules under the policy, ensure that there isn’t a rule with a higher precedence that is overriding the block.

   • If no explicit policy is applied, remember that the default policy will take effect, so ensure the default policy’s category settings align with your blocking expectations.

   • Note on Policy Precedence: If the network asset is part of another policy, that policy will override the default policy and determine whether the category is blocked or allowed.

List Blocking

1. Check that the blocked status of indicator is set to Enabled.

2. Check that the indicator is on a block list, not an allow list.

3. Make sure that the indicator is in the correct list. For example, if an FQDN is on Domain list, it may not be blocked because HYAS Protect is looking for a domain, not a FQDN.

In the second scenario, where you expect the HYAS Protect Decision Engine to block a domain, several factors may explain why it was not blocked.

HYAS Protect evaluates domains based on a wide range of threat intelligence signals, including (but not limited to):

• Domain age

• Nameserver and registrar reputation

• Domain Generation Algorithm (DGA) characteristics

• Other indicators of attacker infrastructure

These signals are combined to determine whether a domain is safe or malicious. While no detection engine is 100% accurate, HYAS Protect is proven to be the most effective in the industry at identifying and blocking malicious domains.

If a domain you expected to be blocked is allowed, possible reasons include:

• Insufficient infrastructure intelligence — not enough data is currently available to classify the domain as malicious.

• Suspicious indicators without sufficient severity — the domain may have some risk factors, but not enough to exceed the blocking threshold.

• Synthetic or test domains — these are intentionally non-malicious and used for validation or demonstration, so they are not blocked.

• The domain is not actually malicious — it may not meet the criteria for blocking.

• False negatives — as with any security tool, some malicious domains may not be detected.

For anything other than synthetic domains, you can report suspicious domains to HYAS. Feedback helps us continuously refine and improve the Decision Engine.

Several factors could contribute to this behavior:

1. Policy Status

   • Ensure the policy is enabled.

2. Rule and Category Configuration

   • Confirm that any relevant Rules are enabled and that the category is set to Block within the policy.

3. Policy Assignment

   • Verify that the policy is assigned to the correct network assets (User Groups or Source Networks).

   • A policy with no assigned assets will not affect any traffic.

4. Policy Precedence

   • If you are modifying the default policy, remember that any other policies applied to the same assets will take precedence over the default policy and may override its settings.

5. Review Rule Application

   • If you have multiple rules under the policy, ensure that there isn’t a rule with a higher precedence that is overriding the expected behavior.

HYAS Protect blocks domains associated with malware, phishing, botnets, command-and-control servers, and other malicious activity. You can also block additional categories like adult content, ads, gambling, and custom blacklists.

False positives in HYAS Protect are rare due to our combination of infrastructure-based intelligence and rigorous threat validation processes. However, if a legitimate site is blocked:

• You can add the domain (or IP, hostname, etc.) to your allowlist using the List Management section of the HYAS Protect portal. Changes take effect in near real-time, notwithstanding local or resolver cacheing.

Learn how to create policies here.

Yes. Learn how to create and apply policies to source networks here.

Yes. With agent-based deployments, you can assign policies based on user groups, allowing tailored DNS protection for different teams or departments.

HYAS Protect includes a “Request Access from Block Page” feature, that when enabled (see Block Page UI), allows users to request access to blocked domains directly to their configured Admin.

To block a domain, you have a couple options:

Option #1: List Management

• Navigate to List Management from the left menu bar.

• Select “Domains”

• Select or create the list you would like to add the blocked domain to.

• Under the list, click the “+”

• Add the domain(s) to the list and select “Apply”

Option #2: Log View

• Click on the domain or FQDN in Log View.

• From the flyout panel, select the pick list under “List Management Status”

• Click “Add to Block List”

Changes to Policies, Categories or Lists may take up to 10 minutes to take effect.

There are a few options here:

Option 1: Add the domain to an Allow List via List Management.

Option 2: Locate the domain in Logs View. Right-click on the domain and select “Allow List” from the results.

UNKNOWN ATTACHMENT

Option 3: Locate the domain in Logs View. Click on it and from top left of the fly-out panel select List Management and then click on Add to Allow List.

UNKNOWN ATTACHMENT

Yes. By creating a policy via the Policy Engine, you may block an entire TLD.

Learn how to create user groups here.

Policy inheritance in HYAS Protect allows categories and domain lists created at an MSSP or parent organization level to be automatically applied to subordinate (child) organizations. This ensures consistent baseline protections across all managed tenants.

• Inherited policies are read-only at the child organization level; they cannot be modified or removed locally.

• Rules are never inherited and must always be defined at the local organization level.

When policy inheritance is enabled, the parent organization’s categories and lists are enforced automatically. However, the parent organization can allow child organizations to create local policies:

• If allowed, local policies can override inherited settings. For example, a child organization could block additional categories or domains, or allow certain ones if configured that way.

• If not allowed, only the inherited parent policies apply, and the child organization cannot modify them.

Whether a domain is blocked or allowed depends on this configuration:

• If inheritance is enabled and local overrides are permitted, the child’s policies may take precedence.

• If inheritance is enabled but local overrides are not permitted, the parent’s policy always applies.

• If inheritance is disabled, the child organization manages its own policies entirely.

API Keys are not visible through the UI. Your API Key was emailed to you upon the creation of your user account. If you’ve lost your API key or would like to request a new one, please navigate to http://support.hyas.com to request a new one.

Here

1. Open Settings

   • In the HYAS UI, click the gear icon in the top-right corner.

   • Select Manage User Accounts.

2. Find the User

   • If applicable, select the MSSP first.

   • Navigate to the correct Organization, then the Team.

   • Locate the row containing the user.

3. Create or Reset the API Key

   • On the right side of the user’s row, click Actions.

   • Choose Create API Key (or Reset API Key if they already have one).

4. Confirm Delivery

   • The user will automatically receive an email containing their new API key.

Instructions on managing Indicators can be found here.

1. Log into Microsoft Defender.

2. In the navigation page, select Settings > Endpoints > Indicators (under Rules)

3. Select the tab of the entity type you'd like to manage.

4. Select the indicator from the list and click the Delete button to remove the entity from the list.

Yes, HYAS Protect supports DoH (DNS over HTTPS)