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 <nmaxpier...@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.crosw...@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 <nmaxpier...@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@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@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@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@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@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@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@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@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users