Re: improved NANOG filtering

[shawn wilson]

AFAIK (IDK how either) this hasn't been a big issue in the past few years.
Is it really worth worrying about? I notified the MARC admin and it was
removed there within a few hours too - a dozen easily tracked messages in a
few hours and a few hours after that, it's done (or more like, filteres).

Not sure how much actually happens on the backend to keep this list as
clean as it appears. But if everyone on that end of things decided to grab
a beer at the same time and we have to suffer a little for a badly timed
cold one every few years, I'm good with the status quo.
On Oct 26, 2015 10:58 PM, "Barry Shein"  wrote:

>
> What's needed is 20 (pick a number) trusted volunteer admins with the
> mailman password whose only capacity is to (make a list: put the list
> into moderation mode, disable an acct).
>
> Obviously it would be nice if the software could help with this
> (limited privileges, logging) but it could be done just on trust with
> a small group.
>
> Another list to announce between them ("got it!") would be useful
> also.
>
> --
> -Barry Shein
>
> The World  | b...@theworld.com   |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR,
> Canada
> Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
>

BGP hold timer on IX LAN

[marcel.durega...@yahoo.fr]

Hello,

As all of us know BGP was designed for scalability, thus slow 
convergence. But it was also when CPU was slow :-).


What do you think about the standard eBGP hold timer of 180sec ? 
Conservative ?


I'm asking because we see more and more peering partners which force the 
hold timer to a lower value, and when BGP negotiate the timer, the 
lowest hold timer is the winner.


Shall we all decide that for global faster convergence we should ALL 
decrease the hold timer ? Or those guys which are lowering their (and 
our) timers on IX LAN play a dangerous game ?



See a example of our peering router at AMS-IX (hold from 30s to 180s):


..
BGP neighbor is 193.239.116.13x,  remote AS 12x54, external link
  Last read 00:00:42, last write 00:00:13, hold time is 180, keepalive 
 interval is 60 seconds


BGP neighbor is 193.239.116.13x,  remote AS 31x77, external link
  Last read 00:00:09, last write 00:00:03, hold time is 90, keepalive 
interval is 30 seconds


BGP neighbor is 193.239.116.13x,  remote AS 4x562, external link
  Last read 00:00:30, last write 00:00:07, hold time is 180, keepalive 
interval is 60 seconds


BGP neighbor is 193.239.116.14x,  remote AS 4x350, external link
  Last read 00:00:01, last write 00:00:01, hold time is 30, keepalive 
interval is 10 seconds


BGP neighbor is 193.239.116.14x,  remote AS 341x1, external link
  Last read 00:00:09, last write 00:00:27, hold time is 180, keepalive 
interval is 60 seconds


BGP neighbor is 193.239.116.14x,  remote AS 2x028, external link
  Last read 00:00:00, last write 00:00:21, hold time is 180, keepalive 
interval is 60 seconds


BGP neighbor is 193.239.116.15x,  remote AS 41x52, external link
  Last read 00:00:27, last write 00:00:11, hold time is 90, keepalive 
interval is 30 seconds


BGP neighbor is 193.239.116.18x,  remote AS 1x041, external link
  Last read 00:00:20, last write 00:00:14, hold time is 90, keepalive 
interval is 30 seconds


BGP neighbor is 193.239.116.18x,  remote AS 162x8, external link
  Last read 00:00:28, last write 00:00:06, hold time is 180, keepalive 
interval is 60 seconds


BGP neighbor is 193.239.116.20x,  remote AS 47x86, external link
  Last read 00:00:59, last write 00:00:21, hold time is 180, keepalive 
interval is 60 seconds


BGP neighbor is 193.239.116.21x,  remote AS x3350, external link
  Last read 00:00:02, last write 00:00:01, hold time is 30, keepalive 
interval is 10 seconds


BGP neighbor is 193.239.116.24x,  remote AS x5133, external link
  Last read 00:00:24, last write 00:00:03, hold time is 90, keepalive 
interval is 30 seconds


.


I've somehow basically anonymized ip and AS just in case I'm not allowed 
to publish those details.



Best Regards,
-Marcel

Re: BGP hold timer on IX LAN

[Nikolay Shopik]

BFD is your friend. Yes it's require both parties to understand it but it much 
better than 30sec hold time. BIRD already have support for BFD

> On 27 окт. 2015 г., at 10:31, "marcel.durega...@yahoo.fr" 
>  wrote:
> 
> Hello,
> 
> As all of us know BGP was designed for scalability, thus slow convergence. 
> But it was also when CPU was slow :-).
> 
> What do you think about the standard eBGP hold timer of 180sec ? Conservative 
> ?
> 
> I'm asking because we see more and more peering partners which force the hold 
> timer to a lower value, and when BGP negotiate the timer, the lowest hold 
> timer is the winner.
> 
> Shall we all decide that for global faster convergence we should ALL decrease 
> the hold timer ? Or those guys which are lowering their (and our) timers on 
> IX LAN play a dangerous game ?
> 
> 
> See a example of our peering router at AMS-IX (hold from 30s to 180s):
> 
> 
> ..
> BGP neighbor is 193.239.116.13x,  remote AS 12x54, external link
>  Last read 00:00:42, last write 00:00:13, hold time is 180, keepalive  
> interval is 60 seconds
> 
> BGP neighbor is 193.239.116.13x,  remote AS 31x77, external link
>  Last read 00:00:09, last write 00:00:03, hold time is 90, keepalive interval 
> is 30 seconds
> 
> BGP neighbor is 193.239.116.13x,  remote AS 4x562, external link
>  Last read 00:00:30, last write 00:00:07, hold time is 180, keepalive 
> interval is 60 seconds
> 
> BGP neighbor is 193.239.116.14x,  remote AS 4x350, external link
>  Last read 00:00:01, last write 00:00:01, hold time is 30, keepalive interval 
> is 10 seconds
> 
> BGP neighbor is 193.239.116.14x,  remote AS 341x1, external link
>  Last read 00:00:09, last write 00:00:27, hold time is 180, keepalive 
> interval is 60 seconds
> 
> BGP neighbor is 193.239.116.14x,  remote AS 2x028, external link
>  Last read 00:00:00, last write 00:00:21, hold time is 180, keepalive 
> interval is 60 seconds
> 
> BGP neighbor is 193.239.116.15x,  remote AS 41x52, external link
>  Last read 00:00:27, last write 00:00:11, hold time is 90, keepalive interval 
> is 30 seconds
> 
> BGP neighbor is 193.239.116.18x,  remote AS 1x041, external link
>  Last read 00:00:20, last write 00:00:14, hold time is 90, keepalive interval 
> is 30 seconds
> 
> BGP neighbor is 193.239.116.18x,  remote AS 162x8, external link
>  Last read 00:00:28, last write 00:00:06, hold time is 180, keepalive 
> interval is 60 seconds
> 
> BGP neighbor is 193.239.116.20x,  remote AS 47x86, external link
>  Last read 00:00:59, last write 00:00:21, hold time is 180, keepalive 
> interval is 60 seconds
> 
> BGP neighbor is 193.239.116.21x,  remote AS x3350, external link
>  Last read 00:00:02, last write 00:00:01, hold time is 30, keepalive interval 
> is 10 seconds
> 
> BGP neighbor is 193.239.116.24x,  remote AS x5133, external link
>  Last read 00:00:24, last write 00:00:03, hold time is 90, keepalive interval 
> is 30 seconds
> 
> .
> 
> 
> I've somehow basically anonymized ip and AS just in case I'm not allowed to 
> publish those details.
> 
> 
> Best Regards,
> -Marcel

Re: BGP hold timer on IX LAN

[Nick Hilliard]

On 27/10/2015 08:31, marcel.durega...@yahoo.fr wrote:
> I'm asking because we see more and more peering partners which force the
> hold timer to a lower value, and when BGP negotiate the timer, the lowest
> hold timer is the winner.

You need to be careful with this.  On larger IXPs, there will be a wide
variety of kit with different capabilities, which will usually work well in
most circumstances, but which may not have enough cpu power to handle edge
cases like e.g. ixp maintenance or flaps when you get large amounts of bgp
activity.  A low bgp timer might be fine for, say an asr9k or an mx960 with
the latest RE/RSP, but would be actively harmful if one of your peers is
using an mx80 or a sup720.

Nick

Re: BGP hold timer on IX LAN

[Colin Johnston]

low bgp timers usually done to allow faster hsrp failover result

colin

Sent from my iPhone

> On 27 Oct 2015, at 08:20, Nick Hilliard  wrote:
> 
>> On 27/10/2015 08:31, marcel.durega...@yahoo.fr wrote:
>> I'm asking because we see more and more peering partners which force the
>> hold timer to a lower value, and when BGP negotiate the timer, the lowest
>> hold timer is the winner.
> 
> You need to be careful with this.  On larger IXPs, there will be a wide
> variety of kit with different capabilities, which will usually work well in
> most circumstances, but which may not have enough cpu power to handle edge
> cases like e.g. ixp maintenance or flaps when you get large amounts of bgp
> activity.  A low bgp timer might be fine for, say an asr9k or an mx960 with
> the latest RE/RSP, but would be actively harmful if one of your peers is
> using an mx80 or a sup720.
> 
> Nick
> 
> 

Re: *tap tap* is this thing on?

[Rich Kulawiec]

On Mon, Oct 26, 2015 at 02:48:59PM -0600, Brielle Bruns wrote:
> I get it that it is hard for large providers to be proactive about
> things going on due to the sheer size of their networks, but come
> on. That excuse only works for so long.

1. It's not hard.  It's far easier for large providers than small ones,
although many of them flat-out lie and claim the opposite.

2. Whatever happened to "never build what you can't control?"  If you
can't stop your operation from emitting abuse, you should shut it down.
Immediately.  That's what professionals do.

3. Large providers pretend to be "leaders", but are among the worst in
terms of actually leading by example.  Just try getting a response from
them via postmaster@ or abuse@.  Of course these large operations should
individually answer *every* message to those addresses promptly, 24x7,
and initiate immediate investigation/remediation on *every* complaint.
That's baseline operational competence 101, and given their enormous
financial and personnel resources, it would require only a tiny amount
of resources.  But they don't -- and everyone else pays the price for it.

---rsk

[Discussion] MTU mismatch and impact of data-plane traffic

[Mohamed Kamal]

Suppose you have the below network topology, where PE is connected to 
P1, P1 is connected to P2 and P2 is connected to GW, all through 1G links.


[PE]-15001500-[P1]-16001600-[P2]-15001600-[GW] 



The numbers represent the MTU values configured in the following order; 
PE's egress interface to P1, P1 ingress interface, P1 egress interface, 
P2 ingress, P2 egress and eventually GW ingress.


Q1: What do you think would be the impact in terms of data-plane traffic 
(HTTP/s browsing, Video streaming etc), traversing this network, in the 
direction from the Internet and going to the PE router?


My answer is:

If there is a client running Win7 on a machine trying to access a web 
server out there, the TCP MSS would be adjusted to around 1260-1460 
bytes depending on the Operating System's MTU value. Hypothetically, the 
first packet from the web server destined to the client would be 
1460-bytes and will reach the ingress interface of the GW.


The GW would receive it in the input_buffer of the ingress interface, 
strip off the Ethernet header, and move it to the output buffer of the 
egress interface whose MTU is 1600. Since the largest MSS is 1460, and 
there is always a one-to-one mapping between segments received from the 
TCP module and the packets constructed in the IP module, I believe that 
the largest IP packet would be 1480. GW would cram the Ethernet frame 
with the 1480-bytes of IP payload data and send it to the P2, which 
would in the other end, pass it on its way.


Q2: However, what about larger MSS sizes? example; above 1500? and 
larges chunks of payload from a connectionless protocols that don't 
exchange MSS? UDP for example? or Google's QUIC (which is HTTP over UDP)?


--
Mohamed Kamal

Re: Uptick in spam

[A . L . M . Buxey]

Hi,

> not even close to more discussing than from the original spam.  Not even
> close.

data volume wise, the discussion of spam is easily beating the volume of spam
(which some people had issue with) as the SPAM emails were very small with just 
a 
URL - the discusions about it is now spread into around 6 threads with many 
pages of text
in some messages.

alan

Re: AW: Uptick in spam

[Ian Smith]

On Mon, Oct 26, 2015 at 9:40 PM, Octavio Alvarez 
 wrote:

> On 26/10/15 11:38, Jürgen Jaritsch wrote:
> 
>
But it is originating all from different IP addresses. Who knows if this
> is an attack to get *@jdlabs.fr blocked from NANOG and is just getting
> its goal accomplished.



This is the part that's been bugging me.  Doesn't the NANOG server
implement SPF checking on inbound list mail?  jdlabs.fr doesn't appear to
have an SPF record published.  It seems to me that these messages should
have been dropped during the connection.

Ian Smith

Fiber in\near Hoopeston, IL

[Mike Hammett]

Can we talk about something not SPAM for a minute? 

Looking for fiber in or near Hoopeston, IL that's not the incumbent. Frontier 
is the ILEC and it looks like New Wave is the MSO, but New Wave doesn't appear 
to go to Chicago. 

I know of networks near 57 and 65 and also McLeod's route to the south. Any 
other ideas for networks in that area? I'm assuming there aren't any others, 
but figured I'd ping here before going with the incumbent. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 

Re: AW: Uptick in spam

[Rich Kulawiec]

On Tue, Oct 27, 2015 at 08:09:00AM -0400, Ian Smith wrote:
> This is the part that's been bugging me.  Doesn't the NANOG server
> implement SPF checking on inbound list mail?

Don't know, but it doesn't matter: SPF has zero anti-spam value.
(I know.  I've studied this in ridiculous detail using a very large
corpus of spam/nonspam messages over a very long period of time.)
There are much better methods available.

---rsk

Re: Why is NANOG not being blacklisted like any other provider that sent 500 spam messages in 3 days?

[David Cantrell]

On Mon, Oct 26, 2015 at 03:53:07PM -0700, Stephen Satchell wrote:

> Also, if you think what happened was a spam flood, you are very lucky. 

Ironically - but alas also predictably - I have received far more list
traffic griping and moaning about this than I actually got from the spam
run.

-- 
David Cantrell | top google result for "internet beard fetish club"

Seven o'clock in the morning is something that
happens to those less fortunate than me

Re: Uptick in spam

[Jutta Zalud]

Am 27.10.2015 13:09, schrieb Ian Smith:
> On Mon, Oct 26, 2015 at 9:40 PM, Octavio Alvarez 
>  wrote:
> 
>> On 26/10/15 11:38, Jürgen Jaritsch wrote:
>> 
>>
> But it is originating all from different IP addresses. Who knows if this
>> is an attack to get *@jdlabs.fr blocked from NANOG and is just getting
>> its goal accomplished.
> 
> 
> 
> This is the part that's been bugging me.  Doesn't the NANOG server
> implement SPF checking on inbound list mail?  jdlabs.fr doesn't appear to
> have an SPF record published.  It seems to me that these messages should
> have been dropped during the connection.

If it does (which I don't know), it will probably check the SPF record
of the delivering mailserver, which was not *.jdlabs.fr as far as I can
see from the mailheaders.

Jutta Zalud

Re: Uptick in spam

[Ian Smith]

But that's not how SPF works.  In SPF, the domain of the envelope header
sender address is checked against that domain's sender policy.  Since
jdlabs.fr has no policy specified, a strict SPF policy at the NANOG server
would have prevented this small issue.

As for the utility of SPF, well.  It's not comprehensive, no one I know
would say that it is.  But it's a bit of a stretch to say that has zero
value.  It would have prevented this latest bit of fun, which seems to have
people upset, so there's *some* value.

-Ian


On Tue, Oct 27, 2015 at 8:40 AM, Jutta Zalud  wrote:

> Am 27.10.2015 13:09, schrieb Ian Smith:
> 
> If it does (which I don't know), it will probably check the SPF record
> of the delivering mailserver, which was not *.jdlabs.fr as far as I can
> see from the mailheaders.
>
> Jutta Zalud
>

Re: Uptick in spam

[Rich Kulawiec]

On Tue, Oct 27, 2015 at 09:08:00AM -0400, Ian Smith wrote:
> But it's a bit of a stretch to say that [SPF] has zero value.

No, it's not a stretch at all.  It's a statistical reality.  And a single
isolated case does not alter that.

You're welcome to set up your own network of spamtraps and mailboxes,
ingest a sizable corpus of messages, and analyze it.  If you do so,
and if you take care to ensure that the composition of that traffic
is appropriate (that is, not skewed by network, domain, ASN, TLD,
etc.), and you accumulate samples over a period of many years,
you'll find the same thing.

This wasn't always true, incidentally.  In the early days of SPF,
it did have some value, because -- by far -- the most prolific
early adopters of SPF were spammers.

---rsk

Re: Uptick in spam

[Ian Smith]

I'm not making any argument about the relation of SPF compliance to message
quality or spam/ham ratio.  You are no doubt correct that at this point in
the game SPF doesn't matter with respect to message quality in a larger
context, because these days messages that are not SPF compliant will simply
never arrive, and therefore aren't sent.

I'm saying that SPF helps prevent envelope header forgery, which is what it
was designed to do.  The fact that NANOG isn't checking SPF (and it isn't,
I tested) was exploited and resulted in a lot of spam to the list.  This
wasn't caught by receiving servers (like Gmail's, for example) because they
checked mail.nanog.org against the nanog.org spf record, which checked out.

You can argue that envelope header forgery is irrelevant, and that corner
cases don't matter.  But I think this latest incident provides a good
counterexample that it does matter.  And it's easy to fix, so why not fix
it?

-Ian

Re: Uptick in spam

[Connor Wilkins]

On 2015-10-27 13:08, Ian Smith wrote:
But that's not how SPF works.  In SPF, the domain of the envelope 
header

sender address is checked against that domain's sender policy.  Since
jdlabs.fr has no policy specified, a strict SPF policy at the NANOG 
server

would have prevented this small issue.


No sane system rejects email based on the lack of a SPF policy.

If the domain had a policy ending in "-all" and the spam wasn't coming 
from a source allowed by the policy then it should be marked as failing, 
held for moderator review, or rejected.


--
“Simply stated, we have a new formula for Coke.” --- Roberto C. 
Goizueta, Company Chairman, Coca-Cola

Re: Uptick in spam

[Colin Johnston]

hosted gmail did catch some of the spam but not all , into auto junk filter due 
to some of the weblinks were spammy

Colin

> On 27 Oct 2015, at 14:18, Ian Smith  wrote:
> 
> I'm not making any argument about the relation of SPF compliance to message
> quality or spam/ham ratio.  You are no doubt correct that at this point in
> the game SPF doesn't matter with respect to message quality in a larger
> context, because these days messages that are not SPF compliant will simply
> never arrive, and therefore aren't sent.
> 
> I'm saying that SPF helps prevent envelope header forgery, which is what it
> was designed to do.  The fact that NANOG isn't checking SPF (and it isn't,
> I tested) was exploited and resulted in a lot of spam to the list.  This
> wasn't caught by receiving servers (like Gmail's, for example) because they
> checked mail.nanog.org against the nanog.org spf record, which checked out.
> 
> You can argue that envelope header forgery is irrelevant, and that corner
> cases don't matter.  But I think this latest incident provides a good
> counterexample that it does matter.  And it's easy to fix, so why not fix
> it?
> 
> -Ian

Re: Uptick in spam

[anthony kasza]

22 emails later (only counting this thread)...

Can someone with the proper privileges confirm they have the spam under
control? I think any solution would be acceptable at this point. If you all
would like to debate the pros/cons of different spam filtering theories
after the spam has subsided, I don't mind but let's safeguard the
infrastructure before we start using it again.

-AK
On Oct 27, 2015 7:20 AM, "Ian Smith"  wrote:

> I'm not making any argument about the relation of SPF compliance to message
> quality or spam/ham ratio.  You are no doubt correct that at this point in
> the game SPF doesn't matter with respect to message quality in a larger
> context, because these days messages that are not SPF compliant will simply
> never arrive, and therefore aren't sent.
>
> I'm saying that SPF helps prevent envelope header forgery, which is what it
> was designed to do.  The fact that NANOG isn't checking SPF (and it isn't,
> I tested) was exploited and resulted in a lot of spam to the list.  This
> wasn't caught by receiving servers (like Gmail's, for example) because they
> checked mail.nanog.org against the nanog.org spf record, which checked
> out.
>
> You can argue that envelope header forgery is irrelevant, and that corner
> cases don't matter.  But I think this latest incident provides a good
> counterexample that it does matter.  And it's easy to fix, so why not fix
> it?
>
> -Ian
>

Re: [Discussion] MTU mismatch and impact of data-plane traffic

[Mikael Abrahamsson]

On Tue, 27 Oct 2015, Mohamed Kamal wrote:

Suppose you have the below network topology, where PE is connected to P1, P1 
is connected to P2 and P2 is connected to GW, all through 1G links.


[PE]-15001500-[P1]-16001600-[P2]-15001600-[GW] 

The numbers represent the MTU values configured in the following order; PE's 
egress interface to P1, P1 ingress interface, P1 egress interface, P2 
ingress, P2 egress and eventually GW ingress.


Q1: What do you think would be the impact in terms of data-plane traffic 
(HTTP/s browsing, Video streaming etc), traversing this network, in the 
direction from the Internet and going to the PE router?


My answer is:

If there is a client running Win7 on a machine trying to access a web server 
out there, the TCP MSS would be adjusted to around 1260-1460 bytes depending 
on the Operating System's MTU value. Hypothetically, the first packet from 
the web server destined to the client would be 1460-bytes and will reach the 
ingress interface of the GW.


Where is the Win7 machine located in the above topology? If the end system 
uses 1500 as MTU, you won't notice the above misconfiguration because no 
packet will ever be bigger than 1500 (IP) so the mismatched MTU won't 
matter. Routers do not assemble packets (generally).


Q2: However, what about larger MSS sizes? example; above 1500? and 
larges chunks of payload from a connectionless protocols that don't 
exchange MSS? UDP for example? or Google's QUIC (which is HTTP over 
UDP)?


As soon as you try to send larger than 1500 byte packets in the above 
configuration you will star to drop packets (if MTU and MRU is the same). 
For instance, if the Internet is on the right and GW has 1600 to the 
outside, then you'll get a packet that is 1600 bytes that P2 will silently 
drop due to 1500 MRU.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Uptick in spam

[Rich Kulawiec]

On Tue, Oct 27, 2015 at 10:18:11AM -0400, Ian Smith wrote:
> I'm not making any argument about the relation of SPF compliance to message
> quality or spam/ham ratio.  You are no doubt correct that at this point in
> the game SPF doesn't matter with respect to message quality in a larger
> context, because these days messages that are not SPF compliant will simply
> never arrive, and therefore aren't sent.

No, what I'm trying to explain to you is that the presence or absence
of SPF records, and the content of those records, has no bearing on
whether not messages emitted are spam or nonspam.  I have millions
of messages that passed all SPF checks and are clearly spam; I have
millions of messages that failed (or had none) and are clearly not spam.
I have analyzed this data in ridiculous detail using a variety of
statistical/pattern recognition techniques, and the bottom line
vis-a-vis SPF is that it simply doesn't matter.

It would be nice if it did; it would be nice if the fatuous claim
made at SPF's introduction ("Spam as a technical problem is solved
by SPF") were true.  But it's not.  It's worthless.

> I'm saying that SPF helps prevent envelope header forgery, which is what it
> was designed to do.

When trying to stop spam, forgery (header and otherwise) is largely
unimportant.  These are separate-but-related problems, and it is a
fundamental tactical error to conflate them.

> The fact that NANOG isn't checking SPF (and it isn't,
> I tested) was exploited and resulted in a lot of spam to the list. 

No, the fact that NANOG's mailing list mechanisms (the MTA, Mailman,
etc.) aren't defended by *other* methods is the problem.  There are much
better ways to accomplish the goal than screwing around with SPF.

> You can argue that envelope header forgery is irrelevant, and that corner
> cases don't matter.  But I think this latest incident provides a good
> counterexample that it does matter. 

It's an unimportant and isolated incident.  I have a bazillion of 
those too.  But using those, instead of looking at overall statistical
trends, is a very poor way to craft mail system defenses.  The correct
strategy is to begin with those measures that:

- have the lowest FP rate
- have the lowest FN rate
- take the least bandwidth
- take the least memory
- take the least CPU
- are as close as possible to the source of abuse
- rely the least on external resources
- are simplest to understand
- are simplest to implement
- are easiest to monitor and evaluate
- are easiest to maintain and modify
- are the least susceptible to gaming
- are the least susceptible to "flavor-of-the-moment" issues

and then work down the list from there.  This yields architectures
that are effective, predictable, and accurate.  Not perfect: there
is no such thing; but certainly robust enough for production use.

---rsk

Re: more FUSSPs, Uptick in spam

[John Levine]

>You can argue that envelope header forgery is irrelevant, and that corner
>cases don't matter.  But I think this latest incident provides a good
>counterexample that it does matter.  And it's easy to fix, so why not fix
>it?

Why do you think that the envelope addresses in the spam bore any
relation to the address in the From header?  The from comments (the
so-called friendly name) were randomized, and they came from
compromised servers all over the world, so I'd expect the envelope
addresses to be similarly random.

SPF has some value for some heavily forged domains, but that's about it.

R's,
John

DNSSEC broken for login.microsoftonline.com

[Bruce Curtis]

FYI our DNS requests to resolve login.microsoftonline.com are failing because 
of a DNSSEC error.

http://dnssec-debugger.verisignlabs.com/login.microsoftonline.com

http://dnsviz.net/d/login.microsoftonline.com/dnssec/



ns1 domain]$ drill -DT  login.microsoftonline.com
Warning: No trusted keys were given. Will not be able to verify authenticity!
;; Domain: .
;; Signature ok but no chain to a trusted key or ds record
[S] . 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
. 172800 IN DNSKEY 256 3 8 ;{id = 62530 (zsk), size = 1024b}
Checking if signing key is trusted:
New key: .  172800  IN  DNSKEY  256 3 8 
AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
 ;{id = 62530 (zsk), size = 1024b}
[S] com. 86400 IN DS 30909 8 2 
e2d3c916f6deeac73294e8268fb5885044a833fc5459588f4a9184cfc41a5766 
;; Domain: com.
;; Signature ok but no chain to a trusted key or ds record
[S] com. 86400 IN DNSKEY 256 3 8 ;{id = 51797 (zsk), size = 1024b}
com. 86400 IN DNSKEY 257 3 8 ;{id = 30909 (ksk), size = 2048b}
[S] Existence denied: microsoftonline.com. DS
;; No ds record for delegation
;; Domain: microsoftonline.com.
;; No DNSKEY record found for microsoftonline.com.
;; No DS for login.microsoftonline.com.;; No ds record for delegation
;; Domain: login.microsoftonline.com.
;; No DNSKEY record found for login.microsoftonline.com.
[U] No data found for: login.microsoftonline.com. type A
;;[S] self sig OK; [B] bogus; [T] trusted
[ns1 domain]$ 





[ns1 domain]$ drill -DT  medicare.gov
Warning: No trusted keys were given. Will not be able to verify authenticity!
;; Domain: .
;; Signature ok but no chain to a trusted key or ds record
[S] . 172800 IN DNSKEY 256 3 8 ;{id = 62530 (zsk), size = 1024b}
. 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: .  172800  IN  DNSKEY  256 3 8 
AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
 ;{id = 62530 (zsk), size = 1024b}
[S] gov. 86400 IN DS 7698 8 1 6f109b46a80cea9613dc86d5a3e065520505aafe 
gov. 86400 IN DS 7698 8 2 
6bc949e638442ead0bdaf0935763c8d003760384ff15ebbd5ce86bb5559561f0 
;; Domain: gov.
;; Signature ok but no chain to a trusted key or ds record
[S] gov. 86400 IN DNSKEY 256 3 8 ;{id = 13175 (zsk), size = 1024b}
gov. 86400 IN DNSKEY 257 3 8 ;{id = 7698 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: gov.   86400   IN  DNSKEY  256 3 8 
AQPCY4NZARQ0HDzGismy6sZdJ17o2+yzmZSkw6d9PeeJ8NCnw9atj4PGHO50LX1Hy0n4YimUcDEXHu+sI4MBaeTkHY3ilsC2kpWGGOFW2fkXn6XNvvPVRjwk04hDsEFphOXPPdoXWjXtQiTVYkFpgUbxJYo24/JxM5JuC4v0+qDmLQ==
 ;{id = 13175 (zsk), size = 1024b}
[S] medicare.gov. 3600 IN DS 16500 7 1 ea88786ecaa04e66322e4405b1c1a55e31485281 
medicare.gov. 3600 IN DS 16500 7 2 
43a0e12df89bb342c15229495cd2bc18dddce0d9fb315aeb5b06b0d849b9a3ee 
;; Domain: medicare.gov.
;; Signature ok but no chain to a trusted key or ds record
[S] medicare.gov. 7200 IN DNSKEY 256 3 7 ;{id = 58988 (zsk), size = 1024b}
medicare.gov. 7200 IN DNSKEY 256 3 7 ;{id = 41714 (zsk), size = 1024b}
medicare.gov. 7200 IN DNSKEY 257 3 7 ;{id = 16500 (ksk), size = 2048b}
[S] medicare.gov.   20  IN  A   23.213.71.152
;;[S] self sig OK; [B] bogus; [T] trusted

---
Bruce Curtis bruce.cur...@ndsu.edu
Certified NetAnalyst II701-231-8527
North Dakota State University

Re: more FUSSPs, Uptick in spam

[Ian Smith]

I was assuming that messages to the list were already filtered by sender,
so non-list or randomized senders would have been rejected by mailman.

-Ian

Re: Uptick in spam

[Peter Beckman]

On Tue, 27 Oct 2015, Rich Kulawiec wrote:


It would be nice if it did; it would be nice if the fatuous claim
made at SPF's introduction ("Spam as a technical problem is solved
by SPF") were true.  But it's not.  It's worthless.


I disagree. Since implementing SPF, there have been no joe-jobs on my
accounts, and attempting to pretend to be me via email is difficult where
SPF is implemented.

I never read or understood that SPF was created to solve the spam problem.
It was to give owners of domains a way to say "If you got an email from us
from these IPs/hosts, then it is probably from us."

It gave domain owners a standardized programmatic way to say to email
recipients when to accept or reject email from their domains.

SPF is not worthless.

However, SPF IS worthless at preventing spam.

And while SPF *could* have been implemented by the owner of the
email/domain that sent all of the spam to the NANOG list and *if* the mail
server for NANOG respected SPF then the emails would have been dropped, it
seems one or both is not the case.

---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: DNSSEC broken for login.microsoftonline.com

[Tony Finch]

Bruce Curtis  wrote:
>
> FYI our DNS requests to resolve login.microsoftonline.com are failing
> because of a DNSSEC error.

There's no DS record for microsoftonline.com so you shouldn't have any
DNSSEC problems with it - my servers can resolve it OK. DNSvis doesn't
show any problems. The only thing which might cause trouble is the
SERVFAIL responses to DNSKEY queries flagged by the Verisign DNSSEC
debugger.

> http://dnssec-debugger.verisignlabs.com/login.microsoftonline.com
>
> http://dnsviz.net/d/login.microsoftonline.com/dnssec/

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fitzroy, Sole: Cyclonic, mainly southwesterly, 5 to 7, occasionally gale 8 in
west Fitzroy. Very rough or high, becoming rough in Sole. Rain or thundery
showers. Moderate or poor, occasionally good.

Re: Is anyone tracking the "Fw: New Message" joe-job spammer?

[Mike Conlen]

I've seen this attack on a private list I'm on as well. It wasn't clear if the 
subscribed address was being spoofed or if the user had an infected computer. 

--
Mike Conlen

> On Oct 26, 2015, at 13:27, Patrick W. Gilmore  wrote:
> 
> I have 521 messages that match:
>To:nanog*
>Subject:new message
> 
> In the last week. Obviously that includes things like Jay’s message below, 
> but still a lot more than 100.
> 
> It also hit outages@, and probably other places.
> 
> Of course, I’m very upset about that. After 500+ tries, they did not spoof my 
> name once!!! Guess I’m not important enough. 
> 
> -- 
> TTFN,
> patrick
> 
>> On Oct 25, 2015, at 12:11 PM, Jay Ashworth  wrote:
>> 
>> Cause if so I got about 100 examples from last night I can send you if
>> you think they'll help.  :-)
>> 
>> Cheers,
>> -- jra
>> 
>> -- 
>> Jay R. Ashworth  Baylink   
>> j...@baylink.com
>> Designer The Things I Think   RFC 
>> 2100
>> Ashworth & Associates   http://www.bcp38.info  2000 Land Rover 
>> DII
>> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 
>> 1274
> 

Re: DNSSEC broken for login.microsoftonline.com

[Bruce Curtis]

> On Oct 27, 2015, at 2:38 PM, Avdija Ahmedhodžić  wrote:
> 
> Also, ns2.bdm.microsoftonline.com is offline for about 12 hours

  The problems started yesterday, more than 12 hours ago.

Thanks.

> 
>> On 27 Oct 2015, at 18:35, Tony Finch  wrote:
>> 
>> Bruce Curtis  wrote:
>>> 
>>> FYI our DNS requests to resolve login.microsoftonline.com are failing
>>> because of a DNSSEC error.
>> 
>> There's no DS record for microsoftonline.com so you shouldn't have any
>> DNSSEC problems with it - my servers can resolve it OK. DNSvis doesn't
>> show any problems. The only thing which might cause trouble is the
>> SERVFAIL responses to DNSKEY queries flagged by the Verisign DNSSEC
>> debugger.
>> 
>>> http://dnssec-debugger.verisignlabs.com/login.microsoftonline.com
>>> 
>>> http://dnsviz.net/d/login.microsoftonline.com/dnssec/
>> 
>> Tony.
>> -- 
>> f.anthony.n.finchhttp://dotat.at/
>> Fitzroy, Sole: Cyclonic, mainly southwesterly, 5 to 7, occasionally gale 8 in
>> west Fitzroy. Very rough or high, becoming rough in Sole. Rain or thundery
>> showers. Moderate or poor, occasionally good.
> 

---
Bruce Curtis bruce.cur...@ndsu.edu
Certified NetAnalyst II701-231-8527
North Dakota State University

Re: DNSSEC broken for login.microsoftonline.com

[Bruce Curtis]

> On Oct 27, 2015, at 12:35 PM, Tony Finch  wrote:
> 
> Bruce Curtis  wrote:
>> 
>> FYI our DNS requests to resolve login.microsoftonline.com are failing
>> because of a DNSSEC error.
> 
> There's no DS record for microsoftonline.com so you shouldn't have any
> DNSSEC problems with it - my servers can resolve it OK. DNSvis doesn't
> show any problems. The only thing which might cause trouble is the
> SERVFAIL responses to DNSKEY queries flagged by the Verisign DNSSEC
> debugger.


  DNSvis did list 4 errors earlier.  

  4 recursive DNS servers here still fail to resolve login.microsoftonline.com.

  I turned DNSSEC validation off on one and it then resolved correctly.

dnssec-validation no;

  Thanks for the info.  Our customers have reported that it does resolve at the 
Google public DNS servers also.

> http://dnssec-debugger.verisignlabs.com/login.microsoftonline.com
>> 
>> http://dnsviz.net/d/login.microsoftonline.com/dnssec/
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Fitzroy, Sole: Cyclonic, mainly southwesterly, 5 to 7, occasionally gale 8 in
> west Fitzroy. Very rough or high, becoming rough in Sole. Rain or thundery
> showers. Moderate or poor, occasionally good.

---
Bruce Curtis bruce.cur...@ndsu.edu
Certified NetAnalyst II701-231-8527
North Dakota State University

Re: spam smackdown?

[John Springer]

On Mon, 26 Oct 2015, Patrick W. Gilmore wrote:

Otherwise, everyone should thank the unpaid 
volunteers for their gracious and excellent work day after day, year 
after year. Or just STFU.



Thank you Communications Committee. What he said.

John Springer

Re: AW: Uptick in spam

[Geoffrey Keating]

Rich Kulawiec  writes:

> On Tue, Oct 27, 2015 at 08:09:00AM -0400, Ian Smith wrote:
> > This is the part that's been bugging me.  Doesn't the NANOG server
> > implement SPF checking on inbound list mail?
> 
> Don't know, but it doesn't matter: SPF has zero anti-spam value.
> (I know.  I've studied this in ridiculous detail using a very large
> corpus of spam/nonspam messages over a very long period of time.)
> There are much better methods available.

My experience is that it dramatically cuts down on the number of spam
bounce messages coming back to the SPF-protected domain.  It may be
that spammers don't bother sending out spam 'from' SPF-protected
domains (that they don't own) but still send the same amount of spam;
so it's not an effective antispam technique but it is a good domain
reputation preservation technique.

... and thus a suitable topic for NANOG, I guess, rather than a mail
abuse list, because it's best use is for domains that send no mail and
recieve no mail and don't want anything to do with mail and stil get
spam complaints.

[NANOG-announce] NANOG 66 - San Diego - Call for Presentations is Open!

[Tony Tauber]

Greetings NANOG Folks,

The last two NANOG meetings (San Francisco and Montreal) set records for
attendance and we hope and expect the trend of strong attendance numbers to
continue for the NANOG 66 meeting February 8-10, 2016 in San Diego, CA
which will be hosted by IIX, Inc.


The detailed NANOG66 Call For Presentations
 has more info but
below is some information that might be useful for quick digestion.

Cheers,

Tony Tauber
Chair, NANOG Program Committee
===

Timeline for submission and proposal review


   1.

   Submitter enters Abstract (and draft slides if possible) in Program
   Committee Site .
   1.

  Any time following Call for Presentations and before deadline for
  Abstracts
  2.

   PC performs initial review and assigns a “Shepherd” to help develop the
   submission.
   1.

  Within about 2-3 weeks
  3.

   Submitter develops draft slides (minimally showing proposed outline and
   level of detail).
   1.

  Please submit initial draft slides before published deadline for
  slides
  2.

  Panels and Track submissions should provide topic list and
  intended/confirmed participants
  4.

   PC reviews slides and iteratively works with Submitter to help develop
   topic.
   5.

   PC accepts or declines submission
   6.

   Agenda assembled and posted
   7.

   Submitters notified


If you think you have an interesting topic but want some feedback or
assistance working it into a presentation, please email the Program
Committee , and a representative on the Program
Committee will give you the feedback needed to work it into a presentation.
Otherwise, don't delay in submitting your talk, keynote, track, or panel
proposal to the Program Committee Site
.  We look forward to reviewing your submission.


Key Dates For NANOG 66

Event/Deadline

Date

Registration for NANOG 66 Opens

Monday, 10/26/2015

CFP Opens for NANOG 66

Monday, 10/26/2015

CFP Deadline #1: Presentation Abstracts Due

Monday, 11/30/2015

CFP Topic List  and NANOG Highlights Page Posted

Friday, 12/18/2015

CFP Deadline #2: Presentation Slides Due

Monday, 1/4/2016

Meeting Agenda Published

Monday, 1/11/2016

Speaker FINAL presentations to Program Committee Site


Wednesday, 2/3/2016

On-site Registration

Sunday, 2/7/2016

Lightning Talk Submissions Open (Abstracts Only)

Sunday, 2/7/2016

Further Presentation Guidelines can be found under "Present at a NANOG"
 and some general advice is
available in Tips on Giving a Talk
.
___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: DNSSEC broken for login.microsoftonline.com

[Bruce Curtis]

> On Oct 27, 2015, at 3:37 PM, Bruce Curtis  wrote:
> 
> 
>> On Oct 27, 2015, at 12:35 PM, Tony Finch  wrote:
>> 
>> Bruce Curtis  wrote:
>>> 
>>> FYI our DNS requests to resolve login.microsoftonline.com are failing
>>> because of a DNSSEC error.
>> 
>> There's no DS record for microsoftonline.com so you shouldn't have any
>> DNSSEC problems with it - my servers can resolve it OK. DNSvis doesn't
>> show any problems. The only thing which might cause trouble is the
>> SERVFAIL responses to DNSKEY queries flagged by the Verisign DNSSEC
>> debugger.
> 
> 
>  DNSvis did list 4 errors earlier.  
> 
>  4 recursive DNS servers here still fail to resolve login.microsoftonline.com.
> 
>  I turned DNSSEC validation off on one and it then resolved correctly.
> 
>   dnssec-validation no;
> 
>  Thanks for the info.  Our customers have reported that it does resolve at 
> the Google public DNS servers also.


  Drill run on one of our name servers shows that the error is

Existence denied: microsoftonline.com


[ns1 domain]$ drill -k /tmp/rootkey -DT  login.microsoftonline.com
;; Number of trusted keys: 2
;; Domain: .
[T] . 172800 IN DNSKEY 256 3 8 ;{id = 62530 (zsk), size = 1024b}
. 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: .  172800  IN  DNSKEY  256 3 8 
AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
 ;{id = 62530 (zsk), size = 1024b}
Trusted key: .  143619  IN  DNSKEY  256 3 8 
AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
 ;{id = 62530 (zsk), size = 1024b}
Key is now trusted!
Trusted key: .  143619  IN  DNSKEY  257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
 ;{id = 19036 (ksk), size = 2048b}
Trusted key: .  172800  IN  DNSKEY  256 3 8 
AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
 ;{id = 62530 (zsk), size = 1024b}
Key is now trusted!
Trusted key: .  172800  IN  DNSKEY  257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
 ;{id = 19036 (ksk), size = 2048b}
[T] com. 86400 IN DS 30909 8 2 
e2d3c916f6deeac73294e8268fb5885044a833fc5459588f4a9184cfc41a5766 
;; Domain: com.
[T] com. 86400 IN DNSKEY 256 3 8 ;{id = 51797 (zsk), size = 1024b}
com. 86400 IN DNSKEY 257 3 8 ;{id = 30909 (ksk), size = 2048b}
[T] Existence denied: microsoftonline.com. DS
;; No ds record for delegation
;; Domain: microsoftonline.com.
;; No DNSKEY record found for microsoftonline.com.
;; No DS for login.microsoftonline.com.;; No ds record for delegation
;; Domain: login.microsoftonline.com.
;; No DNSKEY record found for login.microsoftonline.com.
[U] No data found for: login.microsoftonline.com. type A
;;[S] self sig OK; [B] bogus; [T] trusted


> 
>> http://dnssec-debugger.verisignlabs.com/login.microsoftonline.com
>>> 
>>> http://dnsviz.net/d/login.microsoftonline.com/dnssec/
>> 
>> Tony.
>> -- 
>> f.anthony.n.finchhttp://dotat.at/
>> Fitzroy, Sole: Cyclonic, mainly southwesterly, 5 to 7, occasionally gale 8 in
>> west Fitzroy. Very rough or high, becoming rough in Sole. Rain or thundery
>> showers. Moderate or poor, occasionally good.
> 
> ---
> Bruce Curtis bruce.cur...@ndsu.edu
> Certified NetAnalyst II701-231-8527
> North Dakota State University
> 

---
Bruce Curtis bruce.cur...@ndsu.edu
Certified NetAnalyst II701-231-8527
North Dakota State University

Re: AW: Uptick in spam

[Peter Beckman]

Wouldn't that be interesting -- you can't join NANOG unless your email
domain publishes an SPF record with a -all rule.

That would raise the bar AND prevent the kind of thing that happened this
weekend.

On Tue, 27 Oct 2015, Geoffrey Keating wrote:


... and thus a suitable topic for NANOG, I guess, rather than a mail
abuse list, because it's best use is for domains that send no mail and
recieve no mail and don't want anything to do with mail and stil get
spam complaints.



---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: AW: Uptick in spam

[Hunter Fuller]

The trouble is that this is not the NAMSOG (North American Mail Server
Operators Group). ;)

On Tue, Oct 27, 2015 at 4:59 PM, Peter Beckman  wrote:

> Wouldn't that be interesting -- you can't join NANOG unless your email
> domain publishes an SPF record with a -all rule.
>
> That would raise the bar AND prevent the kind of thing that happened this
> weekend.
>
> On Tue, 27 Oct 2015, Geoffrey Keating wrote:
>
> ... and thus a suitable topic for NANOG, I guess, rather than a mail
>> abuse list, because it's best use is for domains that send no mail and
>> recieve no mail and don't want anything to do with mail and stil get
>> spam complaints.
>>
>>
> ---
> Peter Beckman  Internet Guy
> beck...@angryox.com
> http://www.angryox.com/
> ---
>

algeria

[Randy Bush]

any gossip of a cable issue to algier?

randy

Re: algeria

[Jake Mertel]

Not finding much but did run into this, posted within the past hour
(according to Google)

http://www.alhurra.com/content/algeria-internet/284810.html

Excerpt from Google translate "Internet service in Algeria fell to 80
percent because of damage caused, which hit the main cable that connects
between Algeria and Europe, the Algerian economy to incur significant
losses outweigh million dollars a day."


--
Regards,

Jake Mertel
Ubiquity Hosting



*Web: *https://www.ubiquityhosting.com
*Phone (direct): *1-480-478-1510
*Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054


On Tue, Oct 27, 2015 at 3:35 PM, Randy Bush  wrote:

> any gossip of a cable issue to algier?
>
> randy
>

Re: algeria

[Randy Bush]

> http://www.alhurra.com/content/algeria-internet/284810.html

thanks, jake

randy

Re: AW: Uptick in spam

[John Levine]

In article  you write:
>Wouldn't that be interesting -- you can't join NANOG unless your email
>domain publishes an SPF record with a -all rule.
>
>That would raise the bar AND prevent the kind of thing that happened this
>weekend.

That's OK.  It'd take about 15 minutes for the other 90% of us to
migrate over to the new list for people who actually want to get work
done.

R's,
John

Re: AW: Uptick in spam

[Valdis . Kletnieks]

On Tue, 27 Oct 2015 17:59:29 -0400, Peter Beckman said:
> Wouldn't that be interesting -- you can't join NANOG unless your email
> domain publishes an SPF record with a -all rule.
>
> That would raise the bar AND prevent the kind of thing that happened this
> weekend.

And make a number of long-time contributors have to change their e-mail
provider just to participate.

Hint: There's now 4 people listed in the To/From/CC for this mail, of which
2 don't have a -all SPF record published.

Oh. And there's this in the DNS as well:

nanog.org.  600 IN  TXT "v=spf1 include:_spf.google.com 
ip4:50.31.151.74 ip6:2001:1838:2001:8::10 ip4:50.31.151.73 
ip6:2001:1838:2001:8::9 ~all"

Did you *really* want to go there?


pgpKlyBGig_Ft.pgp
Description: PGP signature

Re: DNSSEC broken for login.microsoftonline.com

[Bruce Curtis]

Actually login.microsoftonline.com is resolving but the CNAME it points to, 
login.microsoftonline.com.nsatc.net is not resolving because of a DNSSEC issue.


[ns1 ~]$ drill -k /tmp/rootkey -DT  login.microsoftonline.com.nsatc.net CNAME
;; Number of trusted keys: 2
;; Domain: .
[T] . 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
. 172800 IN DNSKEY 256 3 8 ;{id = 62530 (zsk), size = 1024b}
Checking if signing key is trusted:
New key: .  172800  IN  DNSKEY  256 3 8 
AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
 ;{id = 62530 (zsk), size = 1024b}
Trusted key: .  143619  IN  DNSKEY  256 3 8 
AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
 ;{id = 62530 (zsk), size = 1024b}
Key is now trusted!
Trusted key: .  143619  IN  DNSKEY  257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
 ;{id = 19036 (ksk), size = 2048b}
Trusted key: .  172800  IN  DNSKEY  257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
 ;{id = 19036 (ksk), size = 2048b}
Trusted key: .  172800  IN  DNSKEY  256 3 8 
AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
 ;{id = 62530 (zsk), size = 1024b}
Key is now trusted!
[T] net. 86400 IN DS 35886 8 2 
7862b27f5f516ebe19680444d4ce5e762981931842c465f00236401d8bd973ee 
;; Domain: net.
[T] net. 86400 IN DNSKEY 257 3 8 ;{id = 35886 (ksk), size = 2048b}
net. 86400 IN DNSKEY 256 3 8 ;{id = 37703 (zsk), size = 1024b}
;; No DS for nsatc.net.;; No ds record for delegation
[B] ;; Error verifying denial of existence for name nsatc.net.NS: No DNSSEC 
signature(s)



cemacmini:~ curtis$ drill -k /tmp/rootkey -DT  
login.microsoftonline.com.nsatc.net CNAME
;; Number of trusted keys: 2
;; Domain: .
[T] . 172800 IN DNSKEY 256 3 8 ;{id = 62530 (zsk), size = 1024b}
. 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: .  172800  IN  DNSKEY  256 3 8 
AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
 ;{id = 62530 (zsk), size = 1024b}
Trusted key: .  29585   IN  DNSKEY  256 3 8 
AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
 ;{id = 62530 (zsk), size = 1024b}
Key is now trusted!
Trusted key: .  29585   IN  DNSKEY  257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
 ;{id = 19036 (ksk), size = 2048b}
Trusted key: .  172800  IN  DNSKEY  256 3 8 
AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
 ;{id = 62530 (zsk), size = 1024b}
Key is now trusted!
Trusted key: .  172800  IN  DNSKEY  257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
 ;{id = 19036 (ksk), size = 2048b}
[T] net. 86400 IN DS 35886 8 2 
7862b27f5f516ebe19680444d4ce5e762981931842c465f00236401d8bd973ee 
;; Domain: net.
[T] net. 86400 IN DNSKEY 257 3 8 ;{id = 35886 (ksk), size = 2048b}
net. 86400 IN DNSKEY 256 3 8 ;{id = 37703 (zsk), size = 1024b}
[B] Error verifying denial of existence for nsatc.net. DS: General LDNS error
;; No ds record for delegation
;; Domain: nsatc.net.
;; No DNSKEY record found for nsatc.net.
;; No DS for c

Re: DNSSEC broken for login.microsoftonline.com

[Avdija Ahmedhodžić]

Also, ns2.bdm.microsoftonline.com is offline for about 12 hours

> On 27 Oct 2015, at 18:35, Tony Finch  wrote:
> 
> Bruce Curtis  wrote:
>> 
>> FYI our DNS requests to resolve login.microsoftonline.com are failing
>> because of a DNSSEC error.
> 
> There's no DS record for microsoftonline.com so you shouldn't have any
> DNSSEC problems with it - my servers can resolve it OK. DNSvis doesn't
> show any problems. The only thing which might cause trouble is the
> SERVFAIL responses to DNSKEY queries flagged by the Verisign DNSSEC
> debugger.
> 
>> http://dnssec-debugger.verisignlabs.com/login.microsoftonline.com
>> 
>> http://dnsviz.net/d/login.microsoftonline.com/dnssec/
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Fitzroy, Sole: Cyclonic, mainly southwesterly, 5 to 7, occasionally gale 8 in
> west Fitzroy. Very rough or high, becoming rough in Sole. Rain or thundery
> showers. Moderate or poor, occasionally good.