The 2 servers that pass the check are behind an old Cisco FWSM so I know it at least works. Hopefully that code carried over to the ASA and won't give us any problems but if it does, I have the option of moving these servers directly to the internet and I can configure iptables for any filtering we need.
As far as any option in the SRX, I do not see any configuration options to disable the version check for EDNS as you suggested. I have a couple of posts on Juniper forms/mailing lists to see if I get anyone familiar with these options but for the moment we are just using the SRX as a packet filter with no ALGs so we may be out of luck. Regards, Max Regards, Max On Fri, Jan 18, 2019 at 3:07 PM Mark Andrews <ma...@isc.org> wrote: > I can’t remember if Cisco ASA has a similar issue. Checkpoint does have > similar > issues (EDNS version != 0 and EDNS flags) last time I checked. Checkpoint > were > thinking of changing the defaults. You just need to turn off the setting > on the > Juniper. It really shouldn’t be on by default as it doesn’t do anything > useful. > > > On 19 Jan 2019, at 7:52 am, N. Max Pierson <nmaxpier...@gmail.com> > wrote: > > > > I was just trying to figure out how I could log this but since the > logging would only probably show if something didn't match udp 53 on the > server IP it probably wouldn't match the block-any catch-all log I > configured. I will certainly bring this up to our Juniper rep but in the > meantime, I have a spare Cisco ASA I am going to migrate these subnets to > and see if that fixes the timeouts we are experiencing. > > > > Mark, thank you for your explanation. And if anyone knows someone at > Juniper you may want to mention this to them as if they do not fix it > before flag day, a lot of queries will be broken. > > > > Regards, > > Max > > > > On Fri, Jan 18, 2019 at 2:42 PM Mark Andrews <ma...@isc.org> wrote: > > This is the signature of a Juniper firewall which drops EDNS version != > 0 and > > packet with a NSID option present. Dropping EDNS version != 0 just > breaks > > future interoperability and as already impacted of EDNS development as > the > > RFC 6891 would have included a EDNS version bump except for these stupid > > firewalls dropping EDNS version != 0. NSID is used to identify a server > > in a anycast cluster and the information is not returned unless the > operator > > has configured the server to return it. There is no need for a firewall > to > > drop queries with these properties. > > > > Please file a bug report with Juniper. > > > > Mark > > > > > On 19 Jan 2019, at 4:02 am, 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 > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > >
_______________________________________________ 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