This article explains how users can allow DNS reply packets through the SRX device with no existing session for the DNS request.

This article is scenario based when we have an SRX cluster in an active/passive design and DNS traffic is being dropped during certain failure scenarios.

In some scenarios, traffic flow may be asymmetric due to the way the network is designed. In such scenarios, the DNS request can pass through firewall 1 and the DNS reply packet may arrive on firewall 2.

The DNS reply packet arriving on firewall 2 will be dropped as there is no existing session for the DNS request on that firewall.

In the scenario chosen in this article, we see the DNS reply packets being dropped on the SRX firewall because there is no existing matching session for the DNS request.

In some scenarios, traffic flow may be asymmetric due to the way the network is designed. In such scenarios, the DNS request can pass through firewall 1 and the DNS reply packet may arrive on firewall 2.

In normal working conditions, SRX will create a session as soon as it sees the DNS request packet and forwards the packet out. It then waits for the DNS reply packet for that session. Once the DNS reply packet is received, a match is made with the DNS request session that was created earlier, the DNS reply packet is forwarded and the session closed.

In this whole process, the DNS ALG (Application Layer Gateway) is involved, which keeps track of the DNS request and reply packet. As soon as the DNS reply packet is received for an existing DNS request session and the SRX firewall forwards the DNS reply packet, the DNS ALG will close the session immediately without waiting for the protocol service timeout settings.

In the scenario where we see asymmetric routing, the DNS request is on Firewall 1 and the DNS reply is coming on Firewall 2. This can create problems and the DNS reply packets can be dropped by Firewall 2 as there is no existing session for the DNS request on that firewall. In this condition, it does not matter whether the DNS ALG is enabled or disabled on Firewall 2. Irrespective of whether the DNS ALG is enabled or disabled, we can experience packet drop for the DNS reply packets.

In such scenario, we can provide a solution/recommendation by configuring the command " set security flow allow-dns-reply " on both Firewall 1 and Firewall 2 devices to simply pass the DNS reply packets without the existing DNS request session.

We recommend to add this command on both the devices because if there is a asymmetric traffic in the network, there are chances that both firewalls may experience the above scenario and adding the command on both the Firewalls can help to resolve the problem.

Detail Description of the command:

Allow an incoming Domain Name Service (DNS) reply packet without a matched request. By default, if an incoming UDP first-packet has dst-port 53, the device checks the DNS message packet header to verify that the query bit (QR) is 0, which denotes a query message. If the QR bit is 1, which denotes a response message, the device drops the packet, does not create a session, and increments the illegal packet flow counter for the interface. Using the allow-dns-reply statement directs the device to skip the check.

2020/07/27: Article reviewed for accuracy; J-Series reference removed from platforms since it is EOL