1440024833.696698 CZdljELZjJSLLQpxj 10.251.27.165 5353 126.96.36.199 5353 udp DNS DNS_Conn_count_too_large
1440024920.764444 CgVrZf4IQ0Tc04EfQe 10.251.29.250 5353 188.8.131.52 5353 udp DNS DNS_Conn_count_too_large
1440024920.764923 C4oQOB2GRRhDHW1i4g fe80::6676:baff:feb5:772c 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large
1440024981.016577 CsCwiq3qk2Uxjhomjj fe80::1c8a:768d:e113:e39f 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large
1440024981.015551 CA1nbO23vgbca2PBYi 10.251.28.176 5353 184.108.40.206 5353 udp DNS DNS_Conn_count_too_large
1440025022.962007 C5kYaG3BckRrVOot89 10.251.26.99 5353 220.127.116.11 5353 udp DNS DNS_Conn_count_too_large
1440025022.962049 CrkZft38lJ0YqGqxsl fe80::2acf:e9ff:fe1a:9aed 5353 ff02::fb 5353 udp DNS DNS_Conn_count_too_large
for just UDP and port 5353 - multicast DNS
It might make sense to go ahead and merge this into master and see if it causes performance problems for anyone.
I think I concur. I will merge this into master with the limit at 25 and into 2.4.1 with the limit at 5 (so the only difference is that people in 2.4.1 will be able to redef it if they want to - but there will be no surprising change of how things work).
Merging this change actually triggers a few changes in our external test suite. Vlad, could you potentially take a short look if those seem to make sense?
Will do. Sorry for not checking that earlier.
Yes, these all seem reasonable. Several symptoms of this particular bug were fixed.
I updated the appropriate baselines in topic/vladg/bit-1460 in the bro-testing repo.
Several tests unrelated to DNS seem to be broken, but I believe that's due to BIT-1467. Also, the private test suite seems to be out of date with master, but I didn't see any DNS-related changes.