Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

DNS Request Filtering for Disallowed Website Domains

Overview of DNS Request Filtering

Starting in Junos OS Release 18.3R1, you can configure DNS filtering to identify DNS requests for disallowed website domains. Starting in Junos OS Release 19.3R2, you can configure DNS filtering if you are running Next Gen Services with the MX-SPC3 services card. Next Gen Services are supported on MX240, MX480 and MX960 routers. For DNS request types A, AAAA, MX, CNAME, TXT, SRV, and ANY, you configure the action to take for a DNS request for a disallowed domain. You can either:

  • Block access to the website by sending a DNS response that contains the IP address or fully qualified domain name (FQDN) of a DNS sinkhole server. This ensures that when the client attempts to send traffic to the disallowed domain, the traffic instead goes to the sinkhole server (see Figure 1).

  • Log the request and allow access.

Starting in Junos OS release 21.1R1, you can also configure the following actions for a DNS request for a disallowed domain:

  • Alert
  • Accept
  • Drop
  • Drop-no-log

For other DNS request types for a disallowed domain, the request is logged and access is allowed.

The actions that the sinkhole server takes are not controlled by the DNS request filtering feature; you are responsible for configuring the sinkhole server actions. For example, the sinkhole server could send a message to the requestor that the domain is not reachable and prevent access to the disallowed domain.

Figure 1: DNS Request for Disallowed DomainDNS Request for Disallowed Domain

Benefits

DNS filtering redirects DNS requests for disallowed website domains to sinkhole servers, while preventing anyone operating the system from seeing the list of disallowed domains. This is because the disallowed domain names are in an encrypted format.

Disallowed Domain Filter Database File

DNS request filtering requires a disallowed domain filter database .txt file, which identifies each disallowed domain name, the action to take on a DNS request for the disallowed domain, and the IP address or fully qualified domain name (FQDN) of a DNS sinkhole server.

DNS Filter Profile

You configure a DNS filter profile to specify which disallowed domain filter database file to use. You can also specify the interfaces on which DNS request filtering is performed, limit the filtering to requests for specific DNS servers, and limit the filtering to requests from specific source IP address prefixes.

How to Configure DNS Request Filtering

To filter DNS requests for disallowed website domains, perform the following:

How to Configure a Domain Filter Database

Create one or more domain filter database files that include an entry for each disallowed domain. Each entry specifies what to do with a DNS request for a disallowed website domain.

To configure a domain filter database file:

  1. Create the name for the file. The database file name can have a maximum length of 64 characters and must have a .txt extension.
  2. Add a file header with a format such as 20170314_01:domain,sinkhole_ip,v6_sinkhole,sinkhole_fqdn,id,action.
  3. Add an entry in the file for each disallowed domain. You can include a maximum of 10,000 domain entries. Each entry in the database file has the following items:

    hashed-domain-name,IPv4 sinkhole address, IPv6 sinkhole address, sinkhole FQDN, ID, action

    where:

    • hashed-domain-name is a hashed value of the disallowed domain name (64 hexadecimal characters). The hash method and hash key that you use to produce the hashed domain value are needed when you configure DNS filtering with the Junos OS CLI.

    • IPv4 sinkhole address is the address of the DNS sinkhole server for IPv4 DNS requests.

    • IPv6 sinkhole address is the address of the DNS sinkhole server for IPv6 DNS requests.

    • sinkhole FQDN is the fully qualified domain name of the DNS sinkhole server.

    • ID is a 32-bit number that uniquely associates the entry with the hashed domain name.

    • action is the action to apply to a DNS request that matches the disallowed domain name. If you enter :

      • replace, the MX Series router sends the client a DNS response with the IP address or FQDN of the DNS sinkhole server. If you enter report, the DNS request is logged and then sent to the DNS server.
      • report, the DNS request is logged and then sent to the DNS server.
      • alert, the DNS request is logged and the request is sent to the DNS server.
      • accept, the DNS request is logged and the request is sent to the DNS server.
      • drop, the DNS request is dropped and the request is logged .DNS request is not sent to the DNS server.
      • drop-no-log, the DNS request is dropped and no syslog is generated. DNS request is not sent to the DNS server.
  4. In the last line of the file, include the file hash, which you calculate by using the same key and hash method that you used to produce the hashed domain names.
  5. Save the database files on the Routing Engine in the /var/db/url-filterd directory.
  6. Validate the domain filter database file.
  7. If you make any changes to the database file, apply the changes.

How to Configure a DNS Filter Profile

A DNS filter profile includes general settings for filtering DNS requests for disallowed website domains, and includes up to 32 templates. The template settings apply to DNS requests on specific uplink and downlink logical interfaces or routing instances, or to DNS requests from specific source IP address prefixes, and override the corresponding settings at the DNS profile level. You can configure up to eight DNS filter profiles.

To configure a DNS filter profile:

  1. Configure the name for a DNS filter profile:

    The maximum number of profiles is 8.

  2. Configure the interval for logging per-client statistics for DNS filtering. The range is 0 through 60 minutes and the default is 5 minutes.
  3. Configure general DNS filtering settings for the profile. These values are used if a DNS request does not match a specific template.
    1. Specify the name of the domain filter database to use when filtering DNS requests.
    2. (Optional) To limit DNS filtering to DNS requests that are destined for specific DNS servers, specify up to three IP addresses (IPv4 or IPv6).
    3. Specify the format for the hash key.
    4. Specify the hash key that you used to create the hashed domain name in the domain filter database file.
    5. Specify the hash method that was used to create the hashed domain name in the domain filter database file.

      The only supported hash method is hmac-sha2-256.

    6. Configure the interval for logging statistics for DNS requests and for sinkhole actions performed for each customer IP address. The range is 1 through 60 minutes and the default is 5 minutes.
    7. Configure the time to live while sending the DNS response after taking the DNS sinkhole action. The range is 0 through 86,400 seconds and the default is 1800.
    8. Configure the level of subdomains that are searched for a match. The range is 0 through 10. A value of 0 indicates that subdomains are not searched.

      For example, if you set the wildcarding-level to 4 and the database file includes an entry for example.com, the following comparisons are made for a DNS request that arrives with the domain 198.51.100.0.example.com:

      • 198.51.100.0.example.com: no match

      • 51.100.0.example.com: no match for one level down

      • 100.0.example.com: no match for two levels down

      • 0.example.com: no match for three levels down

      • example.com: match for four levels down

  4. Configure a template. You can configure a maximum of 8 templates in a profile. Each template identifies filter settings for DNS requests on specific uplink and downlink logical interfaces or routing instances, or for DNS requests from specific source IP address prefixes.
    1. Configure the name for the template.
    2. (Optional) Specify the client-facing logical interfaces (uplink) to which the DNS filtering is applied.
    3. (Optional) Specify the server-facing logical interfaces (downlink) to which the DNS filtering is applied.
    4. (Optional) Specify the routing instance for the client-facing logical interface to which the DNS filtering is applied.
    5. (Optional) Specify the routing instance for the server-facing logical interface to which DNS filtering is applied.
      Note:

      If you configure the client and server interfaces or the client and server routing instances, implicit filters are installed on the interfaces or routing instances to direct DNS traffic to the services PIC for DNS filtering. If you configure neither the client and server interfaces nor the routing instances, you must provide a way to direct DNS traffic to the services PIC (for example, via routes).

    6. Specify the name of the domain filter database to use when filtering DNS requests.
    7. (Optional) To limit DNS filtering to DNS requests that are destined for specific DNS servers, specify up to three IP addresses (IPv4 or IPv6).
    8. Specify the hash method that was used to create the hashed domain name in the domain filter database file.

      The only supported hash method is hmac-sha2-256.

    9. Specify the hash key that was used to create the hashed domain name in the domain filter database file.
    10. Configure the interval for logging statistics for DNS requests and for sinkhole actions performed for each customer IP address. The range is 1 through 60 minutes and the default is 5 minutes.
    11. Configure the time to live while sending the DNS response after taking the DNS sinkhole action. The range is 0 through 86,400 seconds and the default is 1800.
    12. Configure the level of subdomains that are searched for a match. The range is 0 through 10. A value of 0 indicates that subdomains are not searched.

      For example, if you set the wildcarding-level to 4 and the database file includes an entry for example.com, the following comparisons are made for a DNS request that arrives with the domain 198.51.100.0.example.com:

      • 198.51.100.0.example.com: no match

      • 51.100.0.example.com: no match for one level down

      • 100.0.example.com: no match for two levels down

      • 0.example.com: no match for three levels down

      • example.com: match for four levels down

    13. (Optional) Specify the response error code for SRV and TXT query types.

      (Optional) Specify the response error code for SRV and TXT query types.

    14. Configure a term for the template. You can configure a maximum of 64 terms in a template.
    15. (Optional) Specify the source IP address prefixes of DNS requests you want to filter. You can configure a maximum of 64 prefixes in a term.
    16. Specify that the sinkhole action identified in the domain filter database is performed on disallowed DNS requests.

How to Configure a Service Set for DNS Filtering

Associate the DNS filter profile with a next-hop service set and enable logging for DNS filtering. The service interface can be an ms- or vms- interface Next Gen Services with MX-SPC3 services card), or it can be an aggregated multiservices (AMS) interface.

Multitenant Support for DNS Filtering

Overview

Starting in Junos OS Release 21.1R1, you can configure custom domain feeds per customer or IP subgroup. You can :

  • Configure domain names and actions for multiple tenants such that domain feeds can be managed on a per tenant basis.
  • Configure hierarchical domain feed management per profile, per dns-filter-template or per dns-filter-term.
  • Exempt domain feeds at the IP, subnet, or CIDR level.

To implement the mutiltenant support for DNS filtering, creating the domain filter database file under template or profile level is disabled. You need not specify a file at the template or profile level. Starting in Junos OS 21.1R1, by default, a global file with a fixed name, nsf_multi_tenant_dn_custom_file.txt (plain text format) or dnsf_multi_tenant_dn_custom_file_hashed.txt (encrypted file) is available.

Each entry in the database file has the following items:

hashed-domain-name, IPv4 sinkhole address, IPv6 sinkhole address, sinkhole FQDN, ID, action, feed-name.

The file hash is calculated and appended to the list of domain name entries in the file. The file hash is calculated using a global key and method ,which is validated with the file hash computed using the hash key configured at the [edit services web-filter] hierarchy. The file validation is successful only if the calculated file-hash matches the file hash present in the file.

Each entry in nsf_multi_tenant_dn_custom_file.txt file consists of an additional field called feed-name. This feed-name s used as an indicator to group set of domain-names and map them to a tenant (profile, template, term, or IP address).

When the DNS packets are received from a particular SRC IP address, the corresponding feed-name is fetched and lookup happens against the domain-names mapped with the feed-name associated with the term. If the feed-name is not provisioned for that IP address, then it falls back to the feed-name configured at the template-level and lookup happens against the domain-names mapped with the feed-name associated with the template. If the feed-name is not configured at template, then the lookup is against the domain-names mapped against the feed-name associated with the profile.

Configuring Multi-tenant Support for DNS Filtering

  1. Configure the web filter.
  2. Enable multi-tenant support
  3. Configure the global file hash key and hash method.
    Note:

    When multi-tenant-hashis configured, it indicates that the global dns feed file consists of only encrypted feeds. When multi-tenant-hash s not configured it indicates that the global dns feed file has feeds in plain text format.

  4. Configure the name for a DNS filter profile and map the domain feed at the profile level. The feed name indicator configured at the profile level is applied to all the templates and terms under the profile that do not have the feed name indicator configured.
  5. Configure general DNS filtering settings for the profile. These values are used if a DNS request does not match a specific template.
    1. (Optional) To limit DNS filtering to DNS requests that are destined for specific DNS servers, specify up to three IP addresses (IPv4 or IPv6).
    2. Configure the interval for logging statistics for DNS requests and for sinkhole actions performed for each customer IP address. The range is 1 through 60 minutes and the default is 5 minutes.
    3. Configure the time to live (TTL) to send the DNS response after taking the DNS sinkhole action. The range is 0 through 86,400 seconds and the default is 1800.
    4. Configure the level of subdomains that are searched for a match. The range is 0 through 10. A value of 0 indicates that subdomains are not searched.
    5. (Optional) Specify the response error code for the TXT query type.
  6. Configure a template. You can configure a maximum of 8 templates in a profile. Each template identifies filter settings for DNS requests on specific uplink and downlink logical interfaces or routing instances, or for DNS requests from specific source IP address prefixes.
    1. Configure the name for the template.
    2. Configure the feed name. With multitenant format, you can no longer add a file name under profile or template. The feed name specified under profile has lesser precedence compared to the one configured under the template.
    3. (Optional) Specify the client-facing logical interfaces (uplink) to which the DNS filtering is applied.
    4. (Optional) Specify the server-facing logical interfaces (downlink) to which the DNS filtering is applied.
    5. (Optional) Specify the routing instance for the client-facing logical interface to which the DNS filtering is applied.
    6. (Optional) Specify the routing instance for the server-facing logical interface to which DNS filtering is applied.
      Note:

      If you configure the client and server interfaces or the client and server routing instances, implicit filters are installed on the interfaces or routing instances to direct DNS traffic to the services PIC for DNS filtering. If you configure neither the client and server interfaces nor the routing instances, you must provide a way to direct DNS traffic to the services PIC (for example, through routes).
    7. Configure the interval for logging statistics for DNS requests and for sinkhole actions performed for each customer IP address. The range is 1 through 60 minutes and the default is 5 minutes.
    8. Configure the time to live while sending the DNS response after taking the DNS sinkhole action. The range is 0 through 86,400 seconds and the default is 1800.
    9. Configure the level of subdomains that are searched for a match. The range is 0 through 10. A value of 0 indicates that subdomains are not searched.
    10. Configure a term for the template. You can configure a maximum of 64 terms in a template.
    11. Configure the feed name. The feed name configured at the term takes higher precedence over the one configured under the template. However, if the sinkhole domain is matching the only domain mentioned in the feed name under template, the action specified for that entry is implemented.
    12. (Optional) Specify the source IP address prefixes of DNS requests you want to filter. You can configure a maximum of 64 prefixes in a term.
    13. Configure that the sinkhole action identified in the domain filter database is performed on disallowed DNS requests.
  7. Associate the DNS filter profile with a next-hop service set and enable logging for DNS filtering. The service interface can be a multiservices (ms) or virtual multi service (vms) interface (Next Gen Services with MX-SPC3 services card), or it can be an aggregated multiservices (AMS) interface.
  8. If you are running Next Gen Services on the MX-SPC3 services card, configure the vms interface to get the FPC and PIC information in the syslog.

Example: Configuring Multitenant Support for DNS Filtering

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
19.3R2
Starting in Junos OS Release 19.3R2, you can configure DNS filtering if you are running Next Gen Services with the MX-SPC3 services card. Next Gen Services are supported on MX240, MX480 and MX960 routers.