DNSEC DNS udp response blocked on 61k R80.10

[Denis_Gozdzik]

Hey Community,

Maybe you had the same problem.

Yesterday DNS guys asked me to check abnormal behavior of DNS queries. They want to use packets up to 4096 bytes according some new rfc standards and they thought it's blocked because they do not get a response.

My first thought was about the default inspection settings, but this inspection is inactive (DNS Maximum Request Length).

Then with help of fw ctl zdebug + drop I found that returning traffic is blocked. And I found that aggresive aging is enabled for domain-udp object. So when there is no returning traffic within 15 seconds, session is dropped. That's ok.

;[vs_1];[tid_3];[fw4_3];fw_log_drop_ex: Packet proto=17 x.x.x.x:53 -> x.x.x.x:46661 dropped by fw_handle_first_packet Reason: Rulebase drop - rule 1267;

I have created a specific object with increased timeout and aggresive aging disabled.

I have then inserted this object into the rule, deleted old object default domain-udp and what I see? I still see drops because of quick aging and I see attempts in the log hitting the old object (domain-udp), which is not present in the rule already. What else, when I search the logs for this p[articular service object(udp-53-no_aggresive_agg) i see hits on domain-udp as well!

Is this related to CoreXL?

[Andre_K]

Hi Dennis,

I had the same exact issue with DNSSEC. I spend over a year with support troubleshooting this issue. Build an entire lab to simulate the behavior, eventually support provided a hotfix to test which resolved the issue. This hotfix was then included in R76SP.50 JHF take 72 (General stability fixes).

[Andre_K]

The root cause of the issue is as follows:

The issue occurs when a server replies with a packet that gets fragmented and the connection is created from an accept template.

This is the observed flow:

First connection handled by the firewall - creates a template -Second connection is created from a template -Reply packet returns fragmented (large PDU) - and -Sim (SecureXL enforcing module) decides to send the packet to F2F -When in the firewall packet is dropped on clean up rule as the firewall at this point is not yet aware of the connection

Later investigation showed that SecureXL could not find the connection as well.

This was due to cached RSS decision is used and the packet is being redistributed to the wrong RX queue and to another PPAK core that is not aware of the connection.

This  lead to the CI not being found, forwarded to the firewall where it is not found and dropped by the clean up rule.

[Denis_Gozdzik]

Thanks a lot, this is exactly what we found.

I totally forgot to update this post. We are going to install the fix, but firstly we need to uninstall the private fix we have for different bug.