I just reconfigured our SRX and everything seems to be working now. I wasn’t aware that some alg’s were enabled by default so thank you for pointing that out.
Regards, Max -- Sent via mobile > On Jan 18, 2019, at 9:22 PM, Crist Clark <cjc+bind-us...@pumpky.net> wrote: > > In SRX speak: > > # set security alg dns disable > > To verify status of DNS and other ALGs: > > show security alg status > > The DNS ALG is one of those enabled by default and must be explicitly > disabled to turn it off. > > >> On Fri, Jan 18, 2019 at 1:14 PM N. Max Pierson <nmaxpier...@gmail.com> wrote: >> 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
_______________________________________________ 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
