On Tue, Mar 04, 2014 at 10:07:56PM -0500, Jay Ashworth wrote:
> Oh hell.
>
> Is this the *same* bug that just broke in Apple code last week?
I'd be surprised if Apple used GnuTLS, on licencing grounds...
> > widely used cryptographic code library. The bug in the GnuTLS library
On the other hand
For all it's worth, it might be Cox ignoring TTLs and enforcing their
own update times instead.
Wait 24-48 hours, and it should probably fix it all up.
I'm not seeing anything majorly broken with your system except the SOA
EXPIRE being ridiculously large.
On 3/5/2014 午後 01:40, Mark Keymer wr
Would an AT&T engineer who deals with uverse IPv6 please contact me off
list? I'm getting horrible throughput on your 6RD.
Thanks!
Andrew
Hi Everyone,
So I have a client who moved a domain specifically periodforgood.com to
a new VPS with our company.
DNS has been updated and the TTL time is 4 hours so things should all be
updated but something might still be wrong. Looking for help /
confirmation that things look good. And bet
Oh hell.
Is this the *same* bug that just broke in Apple code last week?
Cheers,
-- jra
- Forwarded Message -
> From: "PRIVACY Forum mailing list"
> To: privacy-l...@vortex.com
> Sent: Tuesday, March 4, 2014 3:17:43 PM
> Subject: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundr
Hello all,
Don't suppose there's any CenturyLink engineers/tech people on this list
that can look into a problem with their IPv6 6rd service?
Got multiple customers on CenturyLink (including myself), with IPv6
through their 6rd service since native isn't available yet. IPv6
assignments from
On 04/03/14 10:33, Ian McDonald wrote:
> Until the average user's cpe is only permitted to use the resolvers one
> has provided as the provider (or otherwise decided are OK), this is
> going to be a game of whackamole. So long as there's an 'I have a clue'
> opt out, it appears to be the way forwar
On 3/4/14, 11:52 AM, "Merike Kaeo" wrote:
CPE devices are just a huge cesspool. Any device that already
doesn't let you change username 'admin' is off to a bad start. We
have to get these supposedly 'plug it in and never touch it'
devices to be better at firmware upgrades.
* wbai...@satell
I don¹t know that they have a lot of motivation to support ³legacy² access
points. The home brew guys tend to magically ³find² ways to install
software on these POS CPE AP/Router combos, which I don¹t think is a
coincidence. The linksys types of the world want to sell more routers, not
make routers
On Mar 4, 2014, at 6:54 AM, valdis.kletni...@vt.edu wrote:
> On Tue, 04 Mar 2014 09:28:01 -0400, jim deleskie said:
>> Why want to swing such a big hammer. Even blocking those 2 IP's will
>> isolate your users, and fill your support queue's.
>>
>> Set up a DNS server locally to reply to those I
On Tue, Mar 4, 2014 at 12:33 PM, Ian McDonald wrote:
> Until the average user's cpe is only permitted to use the resolvers one
> has provided as the provider (or otherwise decided are OK), this is going
> to be a game of whackamole.
No. That is still just treating symptoms, and not the diseas
On Tue, Mar 4, 2014 at 12:33 PM, Ian McDonald wrote:
> Until the average user's cpe is only permitted to use the resolvers one has
> provided as the provider (or otherwise decided are OK), this is going to be a
> game of whackamole. So long as there's an 'I have a clue' opt out, it appears
> to
Until the average user's cpe is only permitted to use the resolvers one has
provided as the provider (or otherwise decided are OK), this is going to be a
game of whackamole. So long as there's an 'I have a clue' opt out, it appears
to be the way forward to resolve this issue. Shutting down one s
On 03/04/2014 05:28 AM, jim deleskie wrote:
> Why want to swing such a big hammer. Even blocking those 2 IP's will
> isolate your users, and fill your support queue's.
When the malicious DNS services get shutdown you will still have your
support queue's filled, anyway.
Doing it now will let you
- Original Message -
> From: "jim deleskie"
> Why swing such a big hammer. Even blocking those 2 IP's will
> isolate your users, and fill your support queue's.
>
> Set up a DNS server locally to reply to those IP's Your customers stay up
> and running and blissfully unaware.
>
> Log the
- Original Message -
> From: "Andrew Latham"
> > you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22",
> Jay is right, it is just the /32s at the moment... Dropping the /22s
> could cause other sites to be blocked.
>
> inetnum: 5.45.72.0 - 5.45.75.255
> netname: INFERNO-NL-
On Tue, 04 Mar 2014 09:28:01 -0400, jim deleskie said:
> Why want to swing such a big hammer. Even blocking those 2 IP's will
> isolate your users, and fill your support queue's.
>
> Set up a DNS server locally to reply to those IP's Your customers stay up
> and running and blissfully unaware.
>
I've been doing the suggestion below for many years using the IP
addresses that Cogent gives us. All I needed to do is get LOA from them
and submit it to my backup ISP. I've never had an issue with my Cogent
IP's *not* being advertised by my other ISP and I really don't think
there is very muc
Am 04.03.2014 05:19, schrieb William Herrin:
> Reasons why dynamic DNS fails to perform as expected include:
>
> * Web browser DNS pinning can result in a customer's web browser
> holding the old IP address indefinitely.
>
> * Host-level caching of looked up names which discards the TTL.
> Remembe
On Tue, Mar 4, 2014 at 7:27 AM, Davide Davini wrote:
> Andrew Latham wrote:
>> On Tue, Mar 4, 2014 at 5:46 AM, fmm wrote:
>>> On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth wrote:
>>>
http://arstechnica.com/security/2014/03/hackers-hijack-30-plus-wireless-routers-make-malicious-c
Why want to swing such a big hammer. Even blocking those 2 IP's will
isolate your users, and fill your support queue's.
Set up a DNS server locally to reply to those IP's Your customers stay up
and running and blissfully unaware.
Log the IP's hitting your DNS servers on those IP and have your s
Andrew Latham wrote:
> On Tue, Mar 4, 2014 at 5:46 AM, fmm wrote:
>> On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth wrote:
>>
>>>
>>> http://arstechnica.com/security/2014/03/hackers-hijack-30-plus-wireless-routers-make-malicious-changes/
>>>
>>> Is there any valid reason not to black hole t
On Tue, Mar 4, 2014 at 5:46 AM, fmm wrote:
> On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth wrote:
>
>>
>> http://arstechnica.com/security/2014/03/hackers-hijack-30-plus-wireless-routers-make-malicious-changes/
>>
>> Is there any valid reason not to black hole those /32s on the back bone?
>
On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth wrote:
http://arstechnica.com/security/2014/03/hackers-hijack-30-plus-wireless-routers-make-malicious-changes/
Is there any valid reason not to black hole those /32s on the back bone?
The telltale sign a router has been compromised is DNS
http://arstechnica.com/security/2014/03/hackers-hijack-30-plus-wireless-routers-make-malicious-changes/
Is there any valid reason not to black hole those /32s on the back bone?
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
25 matches
Mail list logo
