...@gmail.com<mailto:nmaxpier...@gmail.com>
Sent: Sunday, January 20, 2019 2:46 AM
To: Crist Clark mailto:cjc+bind-us...@pumpky.net>>
Cc: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: [社外から受信](送信者確認)Re: EDNS Compliance
I just reconfigured our SRX and everything seems to
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
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 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
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
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
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
On Fri, Jan 18, 2019 at 12:07 PM Ben Croswell
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.
>
This can be
Good point as I did not think in terms of an IPS checking for that as well.
In our case the firewall in question is acting as a simple packet filter so
based on what you state, I should be able to allow for larger packet sizes
for DNS queries and hopefully that will resolve our issues.
Thank you
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,
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
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 Hi List,
>
> I am trying to ensure
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
13 matches
Mail list logo
