[dns-operations] Anyone on this list from Arbor Networks (or know a solid engineering contact)?

[Petr Špaček]

Let me add that firewall users who have enabled too strict filtering are 
going to be affected by https://dnsflagday.net/ , so some communication 
from firewall vendors to their customes might be desirable.

Petr Špaček  @  CZ.NIC


On 20.6.2018 10:56, Mark Andrews wrote:
> Unfortunately it is a knob that doesn’t really do any good for anyone.
> All it does is turn NXDOMAIN/NOERROR NODATA into SERVFAIL.  Foot, Gun,
> pull trigger.  DNS queries haven’t been mostly A records or even A and AAAA
> records for over a decade now.
> 
> Similarly firewalls that assume normal queries don’t have EDNS options or
> that currently reserved flag bits won’t be set or EDNS version will always
> be zero just make the DNS brittle.  They don’t actually do anything useful
> by dropping such queries.  EDNS servers handle all of these conditions.
> 
> All dropping these sorts of queries does is slow down your and other firewall
> vendors customer’s customer’s lookups as the recursive servers try different
> styles of queries and occasionally break DNSSEC when those servers back off
> too far because no response doesn’t currently mean “packet loss”.
> 
> The features need to be removed and/or clearly document the negative effects
> of enabling them.
> 
> If you don’t want to answer particular EDNS options remove them from the query
> and pass the rest of the request through.  That won’t break the client provided
> TSIG/SIG(0) is not in use. The server will just look like it doesn’t support the
> option.  Similarly for currently reserved flag bits in the DNS and EDNS headers.
> If they are worried about EDNS version != 0 then send back BADVERS with the
> supported version (0) set.
> 
> Mark
> 
>> On 19 Jun 2018, at 5:05 pm, Roland Dobbins <rdobbins at arbor.net> wrote:
>>
>>
>> On 19 Jun 2018, at 12:35, Viktor Dukhovni wrote:
>>
>>> due to a misconfigured Arbor Networks firewall,
>>
>> To clarify, Arbor Network doesn't produce firewalls, but rather intelligent DDoS mitigation systems, or IDMSes.
>>
>>> in which DNS filters were enabled that drop queries for all but the most common RR types.
>>
>> I'm unaware of any feature in Arbor products which by default does what's being described; operators of our IDMSes do have the ability to filter packets, including DNS queries, but they're typically operator-configurable.
>>
>> Please feel free to ping me directly so that we can understand the details better, and go from there.
>>
>> Thanks for reaching out, and to Barry for cc'ing me directly!
>>
>> -----------------------------------
>> Roland Dobbins <rdobbins at arbor.net>