<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">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.<div><br></div><div>Regards,</div><div>Max<br>--<br><div dir="ltr">Sent via mobile</div><div dir="ltr"><br>On Jan 18, 2019, at 9:22 PM, Crist Clark <<a href="mailto:cjc+bind-users@pumpky.net">cjc+bind-users@pumpky.net</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div><div dir="auto">In SRX speak:</div></div><div dir="auto"><br></div><div dir="auto"> # set security alg dns disable</div><div dir="auto"><br></div><div dir="auto">To verify status of DNS and other ALGs:</div><div dir="auto"><br></div><div dir="auto"> show security alg status</div><div dir="auto"><br></div><div dir="auto">The DNS ALG is one of those enabled by default and must be explicitly disabled to turn it off.</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 18, 2019 at 1:14 PM N. Max Pierson <<a href="mailto:nmaxpierson@gmail.com">nmaxpierson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Max<br><div><br></div><div>Regards,</div><div>Max</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="m_6194271345379811231gmail_attr">On Fri, Jan 18, 2019 at 3:07 PM Mark Andrews <<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I can’t remember if Cisco ASA has a similar issue. Checkpoint does have similar<br>
issues (EDNS version != 0 and EDNS flags) last time I checked. Checkpoint were<br>
thinking of changing the defaults. You just need to turn off the setting on the<br>
Juniper. It really shouldn’t be on by default as it doesn’t do anything useful.<br>
<br>
> On 19 Jan 2019, at 7:52 am, N. Max Pierson <<a href="mailto:nmaxpierson@gmail.com" target="_blank">nmaxpierson@gmail.com</a>> wrote:<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> Regards,<br>
> Max<br>
> <br>
> On Fri, Jan 18, 2019 at 2:42 PM Mark Andrews <<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>> wrote:<br>
> This is the signature of a Juniper firewall which drops EDNS version != 0 and<br>
> packet with a NSID option present. Dropping EDNS version != 0 just breaks<br>
> future interoperability and as already impacted of EDNS development as the<br>
> RFC 6891 would have included a EDNS version bump except for these stupid<br>
> firewalls dropping EDNS version != 0. NSID is used to identify a server<br>
> in a anycast cluster and the information is not returned unless the operator<br>
> has configured the server to return it. There is no need for a firewall to<br>
> drop queries with these properties.<br>
> <br>
> Please file a bug report with Juniper.<br>
> <br>
> Mark<br>
> <br>
> > On 19 Jan 2019, at 4:02 am, N. Max Pierson <<a href="mailto:nmaxpierson@gmail.com" target="_blank">nmaxpierson@gmail.com</a>> wrote:<br>
> > <br>
> > Hi List,<br>
> > <br>
> > I am trying to ensure our Bind servers comply with EDNS for the upcoming Flag Day (<a href="https://dnsflagday.net/" rel="noreferrer" target="_blank">https://dnsflagday.net/</a>). 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?<br>
> > <br>
> > 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?<br>
> > <br>
> > Here is what the tool says ...<br>
> > <br>
> > <br>
> > <a href="http://venyu.com" rel="noreferrer" target="_blank">venyu.com</a>. @<a href="http://208.79.48.30" rel="noreferrer" target="_blank">208.79.48.30</a> (<a href="http://ns4.venyu.com">ns4.venyu.com</a>.): dns=ok edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=timeout <br>
> > <br>
> > <a href="http://venyu.com" rel="noreferrer" target="_blank">venyu.com</a>. @<a href="http://69.2.33.250" rel="noreferrer" target="_blank">69.2.33.250</a> (<a href="http://ns1.venyu.com">ns1.venyu.com</a>.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=ok <br>
> > <a href="http://venyu.com" rel="noreferrer" target="_blank">venyu.com</a>. @2604:d800:12::250 (<a href="http://ns1.venyu.com">ns1.venyu.com</a>.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=ok <br>
> > <br>
> > <a href="http://venyu.com" rel="noreferrer" target="_blank">venyu.com</a>. @<a href="http://69.2.63.250" rel="noreferrer" target="_blank">69.2.63.250</a> (<a href="http://ns3.venyu.com">ns3.venyu.com</a>.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=ok <br>
> > <a href="http://venyu.com" rel="noreferrer" target="_blank">venyu.com</a>. @2604:d800:13::250 (<a href="http://ns3.venyu.com">ns3.venyu.com</a>.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=ok <br>
> > <br>
> > <a href="http://venyu.com" rel="noreferrer" target="_blank">venyu.com</a>. @<a href="http://208.79.48.26" rel="noreferrer" target="_blank">208.79.48.26</a> (<a href="http://ns2.venyu.com">ns2.venyu.com</a>.): dns=ok edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=timeout <br>
> > <br>
> > <br>
> > <br>
> > TIA!!<br>
> > <br>
> > Regards,<br>
> > <br>
> > Max<br>
> > <br>
> > _______________________________________________<br>
> > Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
> > <br>
> > bind-users mailing list<br>
> > <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
> > <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
> <br>
> -- <br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: +61 2 9871 4742 INTERNET: <a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a><br>
> <br>
<br>
-- <br>
Mark Andrews, ISC<br>
1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
PHONE: +61 2 9871 4742 INTERNET: <a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a><br>
<br>
</blockquote></div>
_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div></div>
</div></blockquote></div></body></html>