On Wed, Jan 23, 2019 at 1:06 PM Art Stephens wrote:
> I know this might be off topic but hopefully not too far off.
> I heard rumors that there are ISPs out there running IPv6 only
> networks where the clients can still get to the IPv4 world without the
> $30,000 plus dollar expense of buying a
> On 24 Jan 2019, at 4:45 pm, Christopher Morrow
> wrote:
>
>
>
> On Thu, Jan 24, 2019 at 12:35 AM Mark Andrews wrote:
> And if you don’t want to go to the web site you can still see the content here
>
> https://github.com/dns-violations/dnsflagday
>
>
> I think part of my snark was
On Wed, Jan 23, 2019 at 10:16 AM Filip Hruska wrote:
> This experiment should be continued.
> It's the only way to get people to patch stuff.
Agreed. But be gentle. Wait a couple months between repeats to give
folks a generous amount of time to patch their gear. If you create the
emergency that
On Thu, Jan 24, 2019 at 12:35 AM Mark Andrews wrote:
> And if you don’t want to go to the web site you can still see the content
> here
>
> https://github.com/dns-violations/dnsflagday
>
>
I think part of my snark was lost as snark here...
So, we're asking 'everyone' to do 'something' on behalf
And if you don’t want to go to the web site you can still see the content here
https://github.com/dns-violations/dnsflagday
> On 24 Jan 2019, at 4:32 pm, Mark Andrews wrote:
>
> Also as a lot of you use F5 servers here is information about DNS flag day
> fixes.
>
>
Also as a lot of you use F5 servers here is information about DNS flag day
fixes.
https://support.f5.com/csp/article/K07808381?sf206085287=1
> On 24 Jan 2019, at 3:51 pm, Christopher Morrow
> wrote:
>
>
>
> On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote:
> Well you can go to
On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote:
> Well you can go to https://ednscomp.isc.org and click on "Test Your
> Servers Here”
> which is what https://dnsflagday.net calls behind the scenes. You will
> just need
> to interpret the results as they apply to DNS flag day. If you don’t
Well you can go to https://ednscomp.isc.org and click on "Test Your Servers
Here”
which is what https://dnsflagday.net calls behind the scenes. You will just
need
to interpret the results as they apply to DNS flag day. If you don’t want to go
there you can go to https://gitlab.isc.org and down
On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote:
> Quoting from the web site at https://dnsflagday.net/
>
>
huh, from the 'dns illuminati' eh"
DNS hosted by gandi.net? resolves to 3 /32's on 3 adjacent /24's.. in
github's ip space, routed by fastly.com ...
I'm sure glad the whois data for
On 23/Jan/19 21:01, James Jun wrote:
> Agreed; Please resume the experiment. We're all operators here, and we MUST
> have confidence
> that BGP speakers on our network are compliant with protocol specification.
> Experiments like
> this are opportunities for a real-life validation of how
On Thu, Jan 24, 2019 at 3:23 AM Paul S. wrote:
> As others have noted, the right target to be angry at is your
> equipment vendor.
...whose name I'd personally be quite delighted to finally hear.
Is it just the same FRR that got a patch someone failed to apply, or
this time the issue is more
I’ve been complaining for YEARS about lack of EDNS compliance.
If you run really old Windows DNS servers you are broken.
If you run a firewall in front of your DNS server you may be broken.
If you are QWEST you are broken.
Mark
> On 24 Jan 2019, at 11:10 am, Brian Kantor wrote:
>
> Quoting
Replying to throw in my support behind continuing the experiment as well.
Assurance that my gear will NOT fall over under adversarial situations
is paramount, thank you for the research that you're doing to ensure that.
Ben, you may wish to re-evaluate how "rock solid" [1] your networking
Quoting from the web site at https://dnsflagday.net/
What is happening?
The current DNS is unnecessarily slow and suffers from inability
to deploy new features. To remediate these problems, vendors of
DNS software and also big public DNS providers are going to
remove certain
> On Jan 23, 2019, at 10:16 , Filip Hruska wrote:
>
> This experiment should be continued.
>
> It's the only way to get people to patch stuff.
> And if all it takes to break things is a single announcement, than that's
> something that should be definitely fixed.
>
> Blacklisting an ASN is
On Wed, Jan 23, 2019 at 1:08 PM Art Stephens wrote:
> I know this might be off topic but hopefully not too far off.
> I heard rumors that there are ISPs out there running IPv6 only
> networks where the clients can still get to the IPv4 world without the
> $30,000 plus dollar expense of buying a
On 1/23/19 4:06 PM, Art Stephens wrote:
I know this might be off topic but hopefully not too far off.
I heard rumors that there are ISPs out there running IPv6 only
networks where the clients can still get to the IPv4 world without the
$30,000 plus dollar expense of buying a NAT64 appliance to
I know this might be off topic but hopefully not too far off.
I heard rumors that there are ISPs out there running IPv6 only
networks where the clients can still get to the IPv4 world without the
$30,000 plus dollar expense of buying a NAT64 appliance to service
4,000 plus customers.
Anyone have
On 23/01/2019 20:01, James Jun wrote:
> Kudos to researchers by the way, for sending courtesy announcements in
> advance, and testing
> against some common platforms available to them (Cisco, Quagga & BIRD) prior
> to the experiment.
On 18/12/2018 16:05, Italo Cunha wrote:
> We have
On Wed, Jan 23, 2019 at 06:45:50PM +, Nikolas Geyer wrote:
> Throwing my support behind continuing the experiment also. A singular
> complaint from a company advertising unallocated ASN and IPv4 resources (the
> irony) does not warrant cessation of the experiment.
Agreed; Please resume the
> On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper wrote:
>
>> Can you stop this?
>>
>> You caused again a massive prefix spike/flap, and as the internet is not
>> centered around NA (shock horror!) a number of operators in Asia and
>> Australia go effected by your “expirment” and had no idea what
Throwing my support behind continuing the experiment also. A singular complaint
from a company advertising unallocated ASN and IPv4 resources (the irony) does
not warrant cessation of the experiment.
The experiment is in compliance with the relevant RFCs, the affected “vendor”
has released
On 23/01/2019 18:19, Italo Cunha wrote:
> We have canceled this experiment permanently.
Sad to hear! :/
My impression if you continue is more users will get aware of bugs with
running BGP implementations. Not all follow announcement from $vendor
and will continue to run older broken code and
Sorry. Correction.
If it IS RFC compliant they should accept the attribute. If it is NOT, they
should drop (and maybe log it).
Steve
>Contact your hardware vendor. That is not acceptable behavior. If it is not
>RFC compliant they need to accept the attribute, if it's not RFC compliant
Agreed, do you think you will not see that attribute again now that the public
knows that you are vulnerable to this DoS method. Expect to see an attack
based on this method shortly. They just did you a favor by exposing your
vulnerability, you should take it as such. I would be putting in
Contact your hardware vendor. That is not acceptable behavior. If it is not
RFC compliant they need to accept the attribute, if it's not RFC compliant they
should gracefully ignore it. Now we all know that anyone using that gear is
vulnerable to a DoS attack. Won't be long until anyone else
This experiment should be continued.
It's the only way to get people to patch stuff.
And if all it takes to break things is a single announcement, than that's
something that should be definitely fixed.
Blacklisting an ASN is not a solution, that's ignorance.
Regards,
Filip Hruska
On 23
Töma Gavrichenkov wrote on 23/01/2019 18:00:
What if next time e.g. the bad guys would be doing this? Would you
urge them to also get a sandbox?
Send them a strongly worded memo.
If that doesn't work, threaten to send them a second.
Nick
On Wed, Jan 23, 2019 at 9:05 PM Aled Morris via NANOG wrote:
> I'd go further and say that as long as you're connected
> to the Internet, your equipment better be resilient when
> receiving packets with any combination of bits set,
> RFC compliant or not.
Well, here, when you receive this
On Wed, 23 Jan 2019 at 17:58, Naslund, Steve wrote:
> I hope you are as critical of your hardware vendor that cannot accept BGP4
> compliant attributes or have you just not updated your code? You can black
> hole anything you want but as long as the “Internet” is sending you an RFC
> compliant
> On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper wrote:
> You caused again a massive prefix spike/flap, and as the internet is not
> centered around NA (shock horror!) a number of operators in Asia and
> Australia go effected by your “expirment” and had no idea what was happening
> or why.
>
>
I hope you are as critical of your hardware vendor that cannot accept BGP4
compliant attributes or have you just not updated your code? You can black
hole anything you want but as long as the “Internet” is sending you an RFC
compliant BGP you better be able to handle it.
Steven Naslund
I would be very interested in hearing Ben's definition of something that is
"massive", if announcing or withdrawing a single /24 from the global
routing table constitutes, quote, "a massive prefix spike/flap".
Individual /24s are moved around all the time by fully automated systems.
On Wed, Jan
Dear Ben, all,
I'm not sure this experiment should be canceled. On the public Internet
we MUST assume BGP speakers are compliant with the BGP-4 protocol.
Broken BGP-4 speakers are what they are: broken. They must be fixed, or
the operator must accept the consequences.
"Get a sandbox like every
Ben, NANOG,
We have canceled this experiment permanently.
On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper wrote:
> Can you stop this?
>
> You caused again a massive prefix spike/flap, and as the internet is not
> centered around NA (shock horror!) a number of operators in Asia and
> Australia go
Looking for a contact/intro to Puerto Rico Power Company
https://aeepr.com/
Thank you
--
Mehmet
+1-424-298-1903
36 matches
Mail list logo
