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
> On 19 Jan 2019, at 6:58 am, Ben Croswell wrote:
>
> I would say we had one provider go as far as saying this whole flag day thing
> is a hoax. Not sure what option there is other than voting with your wallet
> and moving to a different provider.
You can go read the source code and see wher
On Fri, Jan 18, 2019 at 3:28 PM Ben Croswell wrote:
> I would imagine "its a hoax" is code for we dont want to bother
> remediating.
>
>
yah, I get their "Don't want to do it" position, but "It's a hoax" seems
like a poor selection from the possible excuses -- when flag day occurs it
will be clea
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
I would imagine "its a hoax" is code for we dont want to bother remediating.
On Fri, Jan 18, 2019, 3:20 PM Warren Kumari
>
> On Fri, Jan 18, 2019 at 2:58 PM Ben Croswell
> wrote:
>
>> I would say we had one provider go as far as saying this whole flag day
>> thing is a hoax.
>>
>
> That's a weir
On Fri, Jan 18, 2019 at 2:58 PM Ben Croswell wrote:
> I would say we had one provider go as far as saying this whole flag day
> thing is a hoax.
>
That's a weird stance / position. "The whole flag day thing is
[stupid|overblown|annoying|confusing|on a Friday]" are all positions I can
understand
I would say we had one provider go as far as saying this whole flag day
thing is a hoax. Not sure what option there is other than voting with your
wallet and moving to a different provider.
May even be worth looking at 2 providers. I see DNS provider redundancy as
being a huge priority after the D
On checking I find that any of our domains that use Network Solutions’
Worldnic.com nameservers are reporting failures when checked.
For example this result: https://ednscomp.isc.org/ednscomp/e30c6cf0ea
Other people online have posted about Network Solutions as they also saw
failures.
On call
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
> On Jan 18, 2019, at 9:18 AM, Ben Croswell wrote:
>
> I shouldn't have posted so closely to responding to the other user.
Oh, my mistake. How is this for a definitve statement?
BIND 9 was designed to be EDNS compliant from very beginning. All
currently-supported branches of BIND 9 are EDNS
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
I shouldn't have posted so closely to responding to the other user.
I am not running 9.8. I was replying to them about firewalls in regards to
their 9.8 issues.
Was just hoping for a statement of 9.x or greater supports the needed
badvers signaling etc.
On Fri, Jan 18, 2019, 12:15 PM Victoria Ri
> On Jan 18, 2019, at 9:09 AM, Ben Croswell wrote:
>
> Has ISC released minimum viable BIND version for flag day?
Most versions of BIND authoritative servers, going back years, are EDNS
compatible. Certainly ALL currently supported versions are compatible. I see
you are running 9.8, which has
Has ISC released minimum viable BIND version for flag day?
I looked around and couldn't find anything.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
htt
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
Is it supported to bootstrap inline signing using dnssec-signzone?
$ named-compilezone -f text -F raw -o example.raw example.com
example.text
$ dnssec-signzone -S -K /etc/bind/keys -O raw -3 ABCDEF -H 19 -A -o
example.com -f example.raw.signed example.text
and then load the two files (
22 matches
Mail list logo
