This article describes an issue that may occur when using domain names in security policies on the SRX. It explains the possible cause of this issue and shows a simple workaround.
When defining security policies on the SRX, address-book entries are used to specify source-address and destination-address fields of the policy. One of the possible options to define a value of the address-book entries is to use domain names (FQDN). The SRX will resolve these names using configured DNS servers, and the relevant security policies will be then enforced.
In some scenarios, however, this doesn’t happen.
To illustrate the symptoms, consider the following security policy, where a domain name is used for the destination-address field:
policies {
from-zone trust to-zone untrust {
policy AccessJuniperWebsite {
match {
source-address LAN; # Defined below as a simple IP prefix
destination-address Juniper-Website; # Defined below as a domain name
application junos-http;
}
then {
permit;
}
}
}
}
security-zone trust {
address-book {
address LAN 172.16.0.0/16;
}
...
}
security-zone untrust {
address-book {
address Juniper-Website {
dns-name www.juniper.net;
}
}
...
}
When the problem occurs, there are two ways to identify it.
First, the DNS cache will not include the resolved IP address. (Note: applicable only for Junos OS 12.1X44 and higher):
root@srx> show security dns-cache DNS Name: www.juniper.net DNS entry number: 1
Second, the relevant security policy will not have a resolved source-address and/or destination-address part. In the example there is no Destination addresses part:
root@srx> show security policies detail policy-name AccessJuniperWebsite
Policy: AccessJuniperWebsite, action-type: permit, State: enabled, Index: 4, Scope Policy: 0
Policy Type: Configured
Sequence number: 1
From zone: trust, To zone: untrust
Source addresses:
LAN: 172.16.0.0/16
Application: junos-http
IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
Source port range: [0-0]
Destination port range: [80-80]
Per policy TCP Options: SYN check: No, SEQ check: No
As a result, the security policy becomes non-operational.
Note: At the same time, the configured DNS servers are reachable and fully operational. In the above example, it is possible to ping www.juniper.net successfully from the SRX.
This may be caused by the method that the SRX uses to select a routing-instance for reaching configured DNS servers.
The exact method depends on the specific Junos OS release. Therefore, it is possible that the customer starts facing the issue after upgrading Junos, even if the same configuration has worked before.
In the next section the methods used in different Junos releases are described.
Note: This applies only when resolving domain names used in address-book entries. This does not apply for domain name resolution performed by other SRX modules.
In order to resolve the address-book entries, the SRX uses the configured DNS servers. In most common cases, these servers are reachable via the default routing-instance (inet.0). However, this is not always the case.
Starting with Junos OS 11.4R6, the SRX allows DNS servers to be reachable via routing-instances other than default (Note: they still have to be a part of the root logical-system). The SRX automatically detects the routing-instance (VR) for each configured DNS server. The detection method depends on Junos release:
In Junos 11.4R6, 12.1R5 and 12.1X44-D10, the SRX first checks the default VR (inet.0) by performing a route lookup for the DNS server in question. If the route lookup fails, the SRX goes through the other configured VRs (in the root logical-system), in lexicographical order of their names. The first VR in which the route lookup succeeds is chosen for this DNS server.
In Junos 11.4R8, 12.1R7 12.1X44-D15 and 12.1X45, the above mechanism was re-implemented with significant optimizations of resources usage. However, along with the optimizations, the new implementation also introduced a major behavior change: the default VR (inet.0) is no longer checked first. Instead, the SRX directly goes through all the configured VRs (in the root logical-system) – including the default VR – in lexicographical order of their names, where the name of the default VR is “default”. As before, the first VR in which the route lookup succeeds is chosen for the DNS server in question.
This can cause an issue. Consider the following scenario:
DNS servers are reachable via the default VR (inet.0).
Additionally, the following VR is configured:
UntrustVR {
instance-type virtual-router;
interface ge-0/0/1.0;
routing-options {
static {
route 0.0.0.0/0 next-hop 88.221.191.254;
}
}
}
The second described method will check the UntrustVR first, because the name “UntrustVR” lexicographically comes BEFORE the name “default” (capital letters come before small letters).
The route lookup will succeed, because the default route defined in the UntrustVR will match. As a result, the SRX will choose the UntrustVR to reach DNS servers. But as mentioned, the DNS servers are not reachable via the UntrustVR (they are reachable via inet.0), therefore DNS queries will fail. All the security policies that refer to address-book entries with domain names will become non-operational.
Note that with the first described method this would not happen, since the SRX would check the default VR first. Therefore, it is possible that the customer had all the policies working while running (for example) Junos OS 11.4R6,and he hit the above issue after upgrading to one of the Junos releases with the second described implementation.
There is an easy workaround for this issue. If the routing-instance “UntrustVR” is renamed to “untrustVR” (i.e. replace the capital ‘U’ with a small ‘u’), the new name will come AFTER the name “default” lexicographically, because ‘u’ comes after ‘d’. So the default VR will be checked first, and the issue will be resolved.
Note: On Junos 12.1X44 and higher, it may be necessary to clear the DNS cache, so that the change will take effect. Use the following CLI command:
clear security dns-cache
Finally, based on field experience, in Junos OS 11.4R10, 12.1X44-D25, 12.1X45-D20 and 12.1X46, Juniper decided to revert to the old behavior (while leaving the optimizations). Starting with these releases, the default VR (inet.0) is again checked first. Only if the route lookup fails in inet.0, the SRX goes through the rest of the configured VRs.