RE: Why are there no GeoDNS solutions anywhere in sight?
The first hit on Google for "dns geolocation" results in http://backreference.org/2010/02/01/geolocation-aware-dns-with-bind/, or the first hit for "dns geolocation patch" leads you to http://www.caraytech.com/geodns/ -Original Message- From: Constantine A. Murenin [mailto:muren...@gmail.com] Sent: March-20-13 11:28 PM To: North American Network Operators' Group Subject: Why are there no GeoDNS solutions anywhere in sight? Dear NANOG@, Not every operator has the ability to setup their own anycast. Not every operator is big enough to be paying 25 USD/month for a managed GeoDNS solution, just to get their hands on GeoDNS. (Hey, for 25$/mo, I might as well have an extra POP or two!) Why so many years after the concept has been introduced and has been found useful, can one not setup GeoDNS in under 5 minutes on one's own infrastructure, or use GeoDNS from any of the plentiful free or complementary DNS solutions that are offered by providers like he.net, xname.org, linode.com and others? I'm an NSD3 user and have a POP in Europe and NA, and, frankly, the easiest (and only) solution I see right now is, on both servers, running two copies of `nsd` on distinct sockets, and redirecting incoming DNS traffic through a firewall based on IPv4 /8 address allocation (RIPE and AfriNIC -- to an `nsd` instance with zone files with an `A` record of a POP in Europe; ARIN, APNIC, LACNIC and the rest of /8 allocations -- an `A` record for NA), with zone replication managed through git. Yeap, it's rough, and quite ugly, and unmaintainable, and will give optimal results only in 80 to 95 per cent of actual cases, and will not benefit from the extra webapp redundancy one otherwise might have had, but what other alternatives could be configured in 5 or 15 minutes? Any plans to make DNS itself GeoDNS-friendly? When editing a zone file in `emacs`, why can one not say that one has 3 web servers -- Europe, NA, Asia -- and have the dns infrastructure and/or the web-browser figure out the rest? Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy. It should be possible to say that you have a server in Fremont, CA and Toronto, ON or Beauharnois, QC, and automatically have all East Coast users go to Toronto, and West Coast to Fremont. Why is there no way to do any of this? Cheers, Constantine.
RE: IPv6 Default Allocation - What size allocation are you giving out
To paraphrase a post on this list a while ago (my apologies for lack of reference). There are two kinds of waste: - the first kind of waste is providing 'too many' subnets for someone; - the second kind of waste is leaving the space unallocated forever. If we choose the first option and somehow burn through the 35 trillion /48's out of the first /3 we're drawing from (ie, almost 5000 /48's for every person on the planet) then we can always reconsider how to be more conservative with the remaining 88% of unallocated IPv6 space. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Faisal Imtiaz Sent: October-09-14 12:45 AM To: Mark Andrews Cc: NANOG Subject: Re: IPv6 Default Allocation - What size allocation are you giving out == > > >Only short sighted ISP's hand out /56's to residential customers. > > > > I am curious as to why you say it is short sighted? what is the > > technical or otherwise any other reasoning for such statement ? > > 256 is *not* a big number of subnets. By restricting the number of subnets > residences get you restrict what >developers will design for. Subnets don't > need to be scares resource. ISP's that default to /56 are making them a > >scares resource. === So, this is more of a 'opinion' / 'feel' (with all due respect) comment, and not something which has a (presently) compelling technical reasoning behind it ? Regards Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - > From: "Mark Andrews" > To: "Faisal Imtiaz" > Cc: "Sam Silvester" , "NANOG" > > Sent: Thursday, October 9, 2014 12:40:07 AM > Subject: Re: IPv6 Default Allocation - What size allocation are you > giving out > > > In message > <482678376.131852.1412829159356.javamail.zim...@snappytelecom.net>, > Faisal Imtiaz writes: > > > A /60, /56, /52 or /48 allows the client to run multiple SLAAC > > > subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa > > > zone delegated on a nibble boundary. > > > > Understood... > > > > > There is plenty of address space even handing out /48's to everyone. > > > > Also Understood. > > > > >Only short sighted ISP's hand out /56's to residential customers. > > > > I am curious as to why you say it is short sighted? what is the > > technical or otherwise any other reasoning for such statement ? > > 256 is *not* a big number of subnets. By restricting the number of > subnets residences get you restrict what developers will design for. > Subnets don't need to be scares resource. ISP's that default to > /56 are making them a scares resource. > > Mark > > > Faisal Imtiaz > > Snappy Internet & Telecom > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >
RE: Prefix hijack by INDOSAT AS4795 / AS4761
We just received a similar alert from bgpmon - part of 108.168.0.0/17 is being advertised as /20's - although we're still listed as the origin. We are 40788. 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy Sent: March-26-15 10:08 AM To: nanog@nanog.org Subject: Prefix hijack by INDOSAT AS4795 / AS4761 On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing more specifics on one of our prefixes. Anyone else seeing similar or is it just us? 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 -- Randy
RE: Prefix hijack by INDOSAT AS4795 / AS4761
+1 The summary below aligns with our analysis as well. We've reached out to AS18978 to determine the status of the leak but at this time we're not seeing any operational impact. -Original Message- From: Andree Toonk [mailto:andree+na...@toonk.nl] Sent: March-26-15 11:54 AM To: Peter Rocca Cc: nanog@nanog.org Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 Hi List, this morning our BGPmon system picked up many new more specific announcements by a variety of Origin ASns, the interesting part is that the majority of them were classified as BGP Man In The middle attacks (MITM). A typical alert would look like: Possible BGP MITM attack (Code: 21) Your prefix: 23.20.0.0/15: Prefix Description: acxiom-online.com --- Amazon EC2 IAD prefix Update time: 2015-03-26 11:27 (UTC) Detected by #peers: 24 Detected prefix: 23.21.112.0/20 Announced by: AS14618 (AMAZON-AES - Amazon.com, Inc.,US) Upstream AS: AS3257 (TINET-BACKBONE Tinet SpA,DE) ASpath: 4608 24130 7545 6939 40633 18978 3257 14618 All alerts have the following part of the AS Path is common: 40633 1897 We're still looking into the details of this particular cases, but based on past experience it's likely that it is not in fact 14618 AWS, that originated this more specific (in this example), but most likely 18978 (or 40633), which leaked it to AS40633 Los Angeles Internet exchange, where others picked it up and propagated it to their customers. In the past we've seen similar issues caused by BGP traffic optimizers. These devices introduce new more specifics (try to keep the ASpath in tact) for Traffic engineering purposes, and then folks leak those. A good write up of a previous example can be found here: http://www.bgpmon.net/accidentally-stealing-the-internet/ A quick scan show that this affected over 5000 prefixes and about 145 Autonomous systems. All of these appear to be more specific prefixes (which is the scary part). Cheers, Andree PS. It appears this is not related to INDOSAT, they just happen to be one of the peers that picked this up. .-- My secret spy satellite informs me that at 2015-03-26 7:43 AM Peter Rocca wrote: > We just received a similar alert from bgpmon - part of 108.168.0.0/17 is > being advertised as /20's - although we're still listed as the origin. We are > 40788. > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy > Sent: March-26-15 10:08 AM > To: nanog@nanog.org > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more specifics on one of our prefixes. Anyone else seeing similar or > is it just us? > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 >
Cogeco Contact...?
Can someone from the Cogeco NOC please contact me off-list at roccap2...@yahoo.com? I have tried ipservi...@cogeco.net and 1-905-333-7055 without luck. Thank you.
RE: Cogeco Contact...?
Thanks all, success. -Original Message- From: Peter Rocca [mailto:ro...@start.ca] Sent: March 24, 2010 8:20 PM To: nanog@nanog.org Subject: Cogeco Contact...? Can someone from the Cogeco NOC please contact me off-list at roccap2...@yahoo.com? I have tried ipservi...@cogeco.net and 1-905-333-7055 without luck. Thank you.
