...@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 disa
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 th
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
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 does
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 stupi
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 gener
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 f
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, 12:29
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 (in
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 o
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