Re: Quick name and shame -- Apologies but...
You might try the mailop mailing list. A few MS staff lurk there and might be able to shed some light. -A On Fri, Dec 30, 2016 at 1:48 PM, wrote: > > For years, YEARS, Microsoft's OUTLOOK.COM has flooded us with this > sort of dictionary spamming on a daily basis. > > Is there anyone at MS who cares? > > Surely it's not that difficult to notice someone is blasting stuff > like this from your servers every single day for years? Or are your > servers just an out of control free-for-all? Do you even know who is > using them? > > If you need another few zillion records like this for motivation just > ask. > > 2016-12-30T16:34:29.342803-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus1 > relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] > 2016-12-30T16:34:29.593566-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus2 > relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] > 2016-12-30T16:34:29.844258-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus3 > relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] > 2016-12-30T16:34:30.094905-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus4 > relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] > 2016-12-30T16:35:23.984284-05:00 pcls5 sendmail[7053]: NOUSER: ehansen1 > relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] > 2016-12-30T16:35:24.235025-05:00 pcls5 sendmail[7053]: NOUSER: ehansen10 > relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] > 2016-12-30T16:35:24.485697-05:00 pcls5 sendmail[7053]: NOUSER: ehansen5 > relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] > 2016-12-30T16:35:24.736408-05:00 pcls5 sendmail[7053]: NOUSER: ehansen2 > relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] > 2016-12-30T16:35:24.987137-05:00 pcls5 sendmail[7053]: NOUSER: ehansen3 > relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] > 2016-12-30T16:36:01.134355-05:00 pcls5 sendmail[7889]: NOUSER: efd5 > relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] > 2016-12-30T16:36:01.385161-05:00 pcls5 sendmail[7889]: NOUSER: efd6 > relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] > 2016-12-30T16:36:01.635940-05:00 pcls5 sendmail[7889]: NOUSER: efd7 > relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] > 2016-12-30T16:36:01.886771-05:00 pcls5 sendmail[7889]: NOUSER: efd8 > relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] > 2016-12-30T16:36:02.137626-05:00 pcls5 sendmail[7889]: NOUSER: efd9 > relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] > 2016-12-30T16:41:25.012620-05:00 pcls5 sendmail[15054]: NOUSER: josephl6 > relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] > 2016-12-30T16:41:25.263296-05:00 pcls5 sendmail[15054]: NOUSER: josephl4 > relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] > 2016-12-30T16:41:25.514058-05:00 pcls5 sendmail[15054]: NOUSER: josephl7 > relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] > 2016-12-30T16:41:25.764786-05:00 pcls5 sendmail[15054]: NOUSER: josephl8 > relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] > 2016-12-30T16:41:26.015469-05:00 pcls5 sendmail[15054]: NOUSER: josephl5 > relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] > > > -- > -Barry Shein > > Software Tool & Die| b...@theworld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo*
Quick name and shame -- Apologies but...
For years, YEARS, Microsoft's OUTLOOK.COM has flooded us with this sort of dictionary spamming on a daily basis. Is there anyone at MS who cares? Surely it's not that difficult to notice someone is blasting stuff like this from your servers every single day for years? Or are your servers just an out of control free-for-all? Do you even know who is using them? If you need another few zillion records like this for motivation just ask. 2016-12-30T16:34:29.342803-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus1 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:34:29.593566-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus2 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:34:29.844258-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus3 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:34:30.094905-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus4 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:35:23.984284-05:00 pcls5 sendmail[7053]: NOUSER: ehansen1 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.235025-05:00 pcls5 sendmail[7053]: NOUSER: ehansen10 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.485697-05:00 pcls5 sendmail[7053]: NOUSER: ehansen5 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.736408-05:00 pcls5 sendmail[7053]: NOUSER: ehansen2 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.987137-05:00 pcls5 sendmail[7053]: NOUSER: ehansen3 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:36:01.134355-05:00 pcls5 sendmail[7889]: NOUSER: efd5 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:01.385161-05:00 pcls5 sendmail[7889]: NOUSER: efd6 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:01.635940-05:00 pcls5 sendmail[7889]: NOUSER: efd7 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:01.886771-05:00 pcls5 sendmail[7889]: NOUSER: efd8 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:02.137626-05:00 pcls5 sendmail[7889]: NOUSER: efd9 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:41:25.012620-05:00 pcls5 sendmail[15054]: NOUSER: josephl6 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:25.263296-05:00 pcls5 sendmail[15054]: NOUSER: josephl4 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:25.514058-05:00 pcls5 sendmail[15054]: NOUSER: josephl7 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:25.764786-05:00 pcls5 sendmail[15054]: NOUSER: josephl8 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:26.015469-05:00 pcls5 sendmail[15054]: NOUSER: josephl5 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: Recent NTP pool traffic increase
On 12/30/16 11:26 AM, Emille Blanc wrote: > Ah, but who do you trust? Trump, Putin, or Xi's clock? > > That said, we use a Stratum2 clock for our AS, which syncs using GPS > at $dayjob. So... I guess we trust Trump's clock. > > Perhaps there's a market for a device that takes GPS, GLONASS, and > Beidou, and references the three for sanity checks in the event of > $unforseen_circumstance. Assuming such a thing were possible - > admittedly I know little about GLONASS, and even less about Beidou. Why are you trying to re-invent a properly configured S2 NTP server? H -- > "Perhaps some kind of death clock?" > > -Original Message- From: NANOG > [mailto:nanog-bounces+emille=abccommunications@nanog.org] On > Behalf Of Allan Liska Sent: December-30-16 11:09 AM To: Majdi S. > Abbas; Laurent Dumont Cc: nanog@nanog.org Subject: Re: Recent NTP > pool traffic increase > > > On 12/30/2016 at 1:20 PM, "Majdi S. Abbas" wrote:On Thu, Dec 22, > 2016 at 11:31:08PM -0500, Laurent Dumont wrote: >> What I mostly meant is that there should be a regulated, > industry-wide >> effort in order to provide a stable and active pool program. With > the >> current models, a protocol that is widely used by commercial >> devices > is >> being supported by the time and effort of volunteers around the > world. > > Who's authoritative for time? Even the national labs aren't -- UTC is > figured well after the fact. > > In the United States that would the United States Naval Observatory > (USNO) Master Clock (http://tycho.usno.navy.mil/). You can read > more about it here: > http://motherboard.vice.com/read/demetrios-matsakis-and-the-master-clock > > allan > > -- Harlan Stenn http://networktimefoundation.org - be a member!
SYN Floods from Verizon in the Midwest-Chicago area?
Wondering if anyone noticed issues with customers coming from Verizon's handoff in Chicago - 204.255.168.61? We have couple of customers with Verizon that seem to have been flooding us with SYN's. It seems Verizon has acknowledged this, but as we are not customers of VZN, we have no information about this. The SYN floods stopped around 10:20 PST on 12/29. Had enough impact to cause a minor outage. Thanks, Bobin Joseph
Re: Recent NTP pool traffic increase
On Fri, Dec 30, 2016 at 02:08:50PM -0500, Allan Liska wrote: > In the United States that would the United States Naval Observatory > (USNO) Master Clock (http://tycho.usno.navy.mil/). You can read more > about it here: > http://motherboard.vice.com/read/demetrios-matsakis-and-the-master-clock One of the things I have learned as a time hobbyist is that if something involves time, and you think there is a simple answer, you are probably wrong. :) USNO is our military time keeper -- NIST keeps time for civil purposes, and while they coordinate to stay in reasonably close proximity, even they don't agree. Even better, the GPS clocks are run by (and corrections distributed) by the Air Force, not the Navy. And they have made mistakes in recent memory. From an international perspective, BIPM is responsible for UTC, but it is only figured well after the fact. We distribute "UTC" via NTP, but it's not true UTC since that is not figured in real time, it's much, much coarser, and everyone's local views differ anyway. For an idea just how many components there are, take a look at BIPM's Circular T: ftp://ftp2.bipm.org/pub/tai//Circular-T/cirthtm/cirt.347.html But back to the point...while UTC is an international time scale, individual national labs and institutions keep their own views of it, and correct periodically...then they distribute these timescales, and in some fashion we attempt to get a coarse version of it onto the Internet in real time. There is no one authority responsible for this, and you may take time from any one (or more) of them that you choose. And for this reason, there is no single authority for time distribution on the Internet -- because there is none for the world as a whole, either. We /can/ have an authoritative system for something like host naming, where it's comparatively easy to produce a single authoritative source. Timing is not nearly such a simple subject. Cheers, --msa
RE: Recent NTP pool traffic increase
On Fri, December 30, 2016 14:26, Emille Blanc wrote: > Ah, but who do you trust? Trump, Putin, or Xi's clock? > > > That said, we use a Stratum2 clock for our AS, which syncs using GPS at > $dayjob. So... I guess we trust Trump's clock. > > > Perhaps there's a market for a device that takes GPS, GLONASS, and > Beidou, and references the three for sanity checks in the event of > $unforseen_circumstance. Assuming such a thing were possible - admittedly > I know little about GLONASS, and even less about Beidou. I was casually (yes, really) looking around at some GNSS modules available the other day, and readily found quite affordable ones that can receive at least 2 at a time, of those systems. GPS and GLONASS being the most complete, so probably the best bang-for-the-buck. I'm only an armchair time-nut, so I can't really speak to their precision and such, so this is very much a FWIW post. > > -Original Message- > From: NANOG [mailto:nanog-bounces+emille=abccommunications@nanog.org] > On Behalf Of Allan Liska > Sent: December-30-16 11:09 AM > To: Majdi S. Abbas; Laurent Dumont > Cc: nanog@nanog.org > Subject: Re: Recent NTP pool traffic increase > > > > On 12/30/2016 at 1:20 PM, "Majdi S. Abbas" wrote:On Thu, Dec 22, 2016 > at 11:31:08PM -0500, Laurent Dumont wrote: >> What I mostly meant is that there should be a regulated, >> > industry-wide >> effort in order to provide a stable and active pool program. With > the >> current models, a protocol that is widely used by commercial devices > is >> being supported by the time and effort of volunteers around the > world. > > Who's authoritative for time? Even the national labs aren't -- > UTC is figured well after the fact. > > > In the United States that would the United States Naval Observatory > (USNO) Master Clock (http://tycho.usno.navy.mil/). You can read more > about it here: > http://motherboard.vice.com/read/demetrios-matsakis-and-the-master-clock > > > allan > > > -- Jeff
RE: Recent NTP pool traffic increase
On 12/30/2016 at 2:26 PM, "Emille Blanc" wrote:Ah, but who do you trust? Trump, Putin, or Xi's clock? That said, we use a Stratum2 clock for our AS, which syncs using GPS at $dayjob. So... I guess we trust Trump's clock. Perhaps there's a market for a device that takes GPS, GLONASS, and Beidou, and references the three for sanity checks in the event of $unforseen_circumstance. Assuming such a thing were possible - admittedly I know little about GLONASS, and even less about Beidou. "Perhaps some kind of death clock?" Personally, when it goes online, I plan on trusting the "Jeff Bezos" clock :) http://www.1yearclock.net/ allan
RE: Recent NTP pool traffic increase
Ah, but who do you trust? Trump, Putin, or Xi's clock? That said, we use a Stratum2 clock for our AS, which syncs using GPS at $dayjob. So... I guess we trust Trump's clock. Perhaps there's a market for a device that takes GPS, GLONASS, and Beidou, and references the three for sanity checks in the event of $unforseen_circumstance. Assuming such a thing were possible - admittedly I know little about GLONASS, and even less about Beidou. "Perhaps some kind of death clock?" -Original Message- From: NANOG [mailto:nanog-bounces+emille=abccommunications@nanog.org] On Behalf Of Allan Liska Sent: December-30-16 11:09 AM To: Majdi S. Abbas; Laurent Dumont Cc: nanog@nanog.org Subject: Re: Recent NTP pool traffic increase On 12/30/2016 at 1:20 PM, "Majdi S. Abbas" wrote:On Thu, Dec 22, 2016 at 11:31:08PM -0500, Laurent Dumont wrote: > What I mostly meant is that there should be a regulated, industry-wide > effort in order to provide a stable and active pool program. With the > current models, a protocol that is widely used by commercial devices is > being supported by the time and effort of volunteers around the world. Who's authoritative for time? Even the national labs aren't -- UTC is figured well after the fact. In the United States that would the United States Naval Observatory (USNO) Master Clock (http://tycho.usno.navy.mil/). You can read more about it here: http://motherboard.vice.com/read/demetrios-matsakis-and-the-master-clock allan
Re: Recent NTP pool traffic increase
On 12/30/2016 at 1:20 PM, "Majdi S. Abbas" wrote:On Thu, Dec 22, 2016 at 11:31:08PM -0500, Laurent Dumont wrote: > What I mostly meant is that there should be a regulated, industry-wide > effort in order to provide a stable and active pool program. With the > current models, a protocol that is widely used by commercial devices is > being supported by the time and effort of volunteers around the world. Who's authoritative for time? Even the national labs aren't -- UTC is figured well after the fact. In the United States that would the United States Naval Observatory (USNO) Master Clock (http://tycho.usno.navy.mil/). You can read more about it here: http://motherboard.vice.com/read/demetrios-matsakis-and-the-master-clock allan
Re: Recent NTP pool traffic increase
On Thu, Dec 22, 2016 at 11:31:08PM -0500, Laurent Dumont wrote: > What I mostly meant is that there should be a regulated, industry-wide > effort in order to provide a stable and active pool program. With the > current models, a protocol that is widely used by commercial devices is > being supported by the time and effort of volunteers around the world. Who's authoritative for time? Even the national labs aren't -- UTC is figured well after the fact. Thing about the pool is -- you may use it, you don't have to. You're welcome to provide your own services, including to your customers. There has to be one sole DNS -- there isn't one sole source of time. --msa
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 31 Dec, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 626822 Prefixes after maximum aggregation (per Origin AS): 221601 Deaggregation factor: 2.83 Unique aggregates announced (without unneeded subnets): 304431 Total ASes present in the Internet Routing Table: 55506 Prefixes per ASN: 11.29 Origin-only ASes present in the Internet Routing Table: 36264 Origin ASes announcing only one prefix: 15201 Transit ASes present in the Internet Routing Table:6538 Transit-only ASes present in the Internet Routing Table:169 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 38 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table:52 Unregistered ASNs in the Routing Table: 17 Number of 32-bit ASNs allocated by the RIRs: 16714 Number of 32-bit ASNs visible in the Routing Table: 12704 Prefixes from 32-bit ASNs in the Routing Table: 52166 Number of bogon 32-bit ASNs visible in the Routing Table: 656 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:376 Number of addresses announced to Internet: 2834970340 Equivalent to 168 /8s, 250 /16s and 54 /24s Percentage of available address space announced: 76.6 Percentage of allocated address space announced: 76.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 207813 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 156571 Total APNIC prefixes after maximum aggregation: 43183 APNIC Deaggregation factor:3.63 Prefixes being announced from the APNIC address blocks: 171063 Unique aggregates announced from the APNIC address blocks:70682 APNIC Region origin ASes present in the Internet Routing Table:5188 APNIC Prefixes per ASN: 32.97 APNIC Region origin ASes announcing only one prefix: 1132 APNIC Region transit ASes present in the Internet Routing Table:939 Average APNIC Region AS path length visible:4.4 Max APNIC Region AS path length visible: 38 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2579 Number of APNIC addresses announced to Internet: 761702276 Equivalent to 45 /8s, 102 /16s and 167 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:188253 Total ARIN prefixes after maximum aggregation:89318 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 195160 Unique aggregates announced from the ARIN address blocks: 89620 ARIN Region origin ASes present in the Internet Routing Table:16071 ARIN Prefixes per ASN:12.14 ARIN Region origin
Re: Recent NTP pool traffic increase
On Tue, Dec 20, 2016 at 10:27:18PM -0500, Laurent Dumont wrote: > To be honest, the fact that NTP is still something managed by volunteers and > not a regulated entity (a bit like DNS) is mind boggling. I don't see why. Look back on 30-ish years of domain registration, I think that it was far more responsibly, ethically, and professionally managed when it was handled by volunteers. ---rsk
