EDNS Compliance

[Ben Croswell]

It more complicated than just packet size. I have seen FWs with IPS rules
that were dropping the packets because the rule stated 0 was the only edns
version and anything else was an attack.

I would check the FW logs to find the log of the drop and work back from
there.

On Fri, Jan 18, 2019, 12:29 PM N. Max Pierson <nmaxpierson at gmail.com wrote:

> Thanks to the response Ben. After looking at the results, it seems we do
> have a different firewall between the 4 servers and they have IPs out of
> the same subnet for 2 of them which are failing. So this lets me know it is
> firewall related and now I can check that.
>
> Do you know what type of rule (in general, not anything specific) needs to
> be added to allow for larger EDNS packets? Is it as simple as allowing the
> maximum size for payload specified in the RFC (
> https://tools.ietf.org/html/rfc6891#section-6.2.5) which is 4096 bytes?
>
> Regards,
> Max
>
> On Fri, Jan 18, 2019 at 11:07 AM Ben Croswell <ben.croswell at gmail.com>
> wrote:
>
>> As long as all 4 DNS servers are running the same version, my first
>> suggestion would be to check firewalls for dropped packets.
>>
>> Some FW/IPS drop packets with edns versions other 0 because they see it
>> as an attack.
>>
>> On Fri, Jan 18, 2019, 12:02 PM N. Max Pierson <nmaxpierson at gmail.com
>> wrote:
>>
>>> Hi List,
>>>
>>> I am trying to ensure our Bind servers comply with EDNS for the upcoming
>>> Flag Day (https://dnsflagday.net/). I am somewhat ignorant to EDNS but
>>> from what I have read, the information is somewhat conflicting as some
>>> documentation states EDNS is not a record that you configure in your zone
>>> file then other sites refer to some sort of OPT record you can configure.
>>> So my first question is which of the documentation is correct from what I
>>> have read? Is it DNS server functionality that supports EDNS or do you also
>>> have to configure something in the zone files?
>>>
>>> Also, I have 4 (well 5 counting the master that isn't queryable)
>>> nameservers with multiple domains served on them. When I run one of my
>>> primary domains through the ISC EDNS tool, it comes back as 2 out of the 4
>>> are failing EDNS queries.They are all on the same version of Bind
>>> (9.8.2rc1) and they are all slaves of the master so they should all have
>>> the same records. Can anyone please explain what I need to do to resolve
>>> the timeouts listed on the ISC testing tool?
>>>
>>> Here is what the tool says ...
>>>
>>>
>>> venyu.com. @208.79.48.30 (ns4.venyu.com.): dns=ok edns=ok
>>> *edns1=timeout* edns at 512=ok ednsopt=ok *edns1opt=timeout* do=ok
>>> ednsflags=ok docookie=ok edns512tcp=ok *optlist=timeout*
>>>
>>> venyu.com. @69.2.33.250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
>>> edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>>> edns512tcp=ok optlist=ok
>>> venyu.com. @2604:d800:12::250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
>>> edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>>> edns512tcp=ok optlist=ok
>>>
>>> venyu.com. @69.2.63.250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
>>> edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>>> edns512tcp=ok optlist=ok
>>> venyu.com. @2604:d800:13::250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
>>> edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>>> edns512tcp=ok optlist=ok
>>>
>>> venyu.com. @208.79.48.26 (ns2.venyu.com.): dns=ok edns=ok
>>> *edns1=timeout* edns at 512=ok ednsopt=ok *edns1opt=timeout* do=ok
>>> ednsflags=ok docookie=ok edns512tcp=ok *optlist=timeout*
>>>
>>>
>>> TIA!!
>>>
>>> Regards,
>>>
>>> Max
>>> _______________________________________________
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>>> unsubscribe from this list
>>>
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190118/1c5d58e1/attachment-0001.html>