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 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 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 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 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 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
>>> > > 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
>>> > >
