Re: IPv6 Firewalls
I guess this can be helpful to find not just firewalls but any IPv6-compliant product/service. http://www.ipv6-to-standard.org Regards, Jordi De: Joseph S D Yao [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 30 Jan 2007 17:36:58 -0500 Para: J. Oquendo [EMAIL PROTECTED] CC: nanog@merit.edu Asunto: Re: IPv6 Firewalls On Tue, Jan 30, 2007 at 09:43:52PM -0500, J. Oquendo wrote: ... A lot of vendor information on this, etc. can be summarized over at http://www.moonv6.org/ (or at least the hype of it) ... This is why I asked: at some point last year, those guys said NO firewalls were IPv6-ready yet. -- Joe Yao --- This message is not an official statement of OSIS Center policies. ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Cisco Security Advisory: SIP Packet Reloads IOS Devices Not Configured for SIP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: SIP Packet Reloads IOS Devices Not Configured for SIP Advisory ID: cisco-sa-20070131-sip http://www.cisco.com/warp/public/707/cisco-sa-20070131-sip.shtml Revision 1.0 For Public Release 2007 Jan 31 0900 UTC (GMT) - - Summary === Cisco devices running IOS which support voice and are not configured for Session Initiated Protocol (SIP) are vulnerable to a crash under yet to be determined conditions, but isolated to traffic destined to Port 5060. SIP is enabled by default on all Advanced images which support voice and do not contain the fix for CSCsb25337. There are no reports of this vulnerability on the devices which are properly configured for SIP processing. Workarounds exist to mitigate the effects of this problem. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20070131-sip.shtml Affected Products = IOS releases that include voice support after 12.3(14)T, 12.3(8)YC1, 12.3(8)YG and all of 12.4 are affected. Please see the fixed software table for a complete list of fixed and vulnerable trains. To determine if your device has SIP enabled, enter the commands 'show ip sockets' and 'show tcp brief all'. Below is an example of a router running code without the fix, and without the workaround enabled. The router in this example is vulnerable to this issue. IOS image in example: 7200-p-mz.124-3.bin Router#show ip sockets ProtoRemote Port Local Port In Out Stat TTY OutputIF 17 0.0.0.0 0 --any-- 5060 0 0 211 0 17 0.0.0.0 0 192.168.100.2 67 0 0 2211 0 17 0.0.0.0 0 192.168.100.2 2517 0 0 11 0 The first line with UDP Port 5060 shows that UDP SIP is enabled. Router#show tcp brief all TCB Local Address Foreign Address(state) 2051E680 *.5060 *.*LISTEN 2051E680 *.5060 *.*LISTEN The above lines with *.5060 show that TCP SIP is enabled. Vulnerable Products +-- The following is a list of products that support voice and could be affected by this vulnerability. * 815 * 871 * 876 * 877 * 878 * 1701 * 1711 * 1712 * 1721 * 1751 * 1751-V * 1760 * 1801 * 1802 * 1803 * 1811 * 1812 * 1841 * 2610XM-2611XM * 2620XM-2621XM * 2650XM-2651XM * 2691 * 2801 * 2811 * 2821 * 2851 * 3220 * 3250 * 3270 * 3725 * 3745 * 3825 * 3845 * 7200 * 7200-NPE-G2 * 7301 Products Confirmed Not Vulnerable + Devices which do not support voice are not affected by this issue. Devices which are properly configured for SIP processing are not affected by this issue. We have no reports of this vunerability on devices that are configured for SIP processing. We also have no reports of affected IOS-XR devices, CatOS devices, or any device which does not run IOS, but can not conclusively rule them out without further testing. This advisory will be updated with more information as it becomes available. Below is an example of a router not vulnerable to this issue. The router in this example is running the fixed release c7200-js-mz.124-5b.bin. Router#show tcp brief all Router#show ip sockets ProtoRemote Port Local Port In Out Stat TTY OutputIF 17 0.0.0.0 0 192.168.100.2 67 0 0 2211 0 No lines with UDP Port 5060 are shown and UDP SIP is not enabled. In this example UDP port 67 is used by DHCP is not related to this vulnerability. Details === SIP is a protocol designed for use in IP phone networks, and is widely used for Voice over Internet Protocol (VOIP) communications worldwide. Cisco devices running an affected image which supports voice services automatically enable SIP, which opens a listening port on UDP port 5060. TCP port 5060 is also opened, but does not appear to be related to the IOS crash detailed in this advisory. CSCsb25337 turns off the listening ports TCP and UDP 5060, and there have been no reports of this vulnerability in any images with this fix integrated. Impact == Successful exploitation of the vulnerability may result in a reload of the device. The issue may be repeatedly exploited, leading to an extended Denial Of Service (DOS) condition. Software Version and Fixes == When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release
Re: Best way to supply colo customer with specific provider
Steve Gibbard wrote: If you actually want to do this, you've got four choices: - Policy route, as mentioned below. - Get the customer their own connection to Cogent. - Have a border router that only talks to Cogent and doesn't receive full routes from your core, and connect the customer directly to that. - Do something involving route servers and switches outside your border routers, a-la-Equinix Direct. What about an MPLS VPN?
NANOG39 (Sheraton Centre Toronto)
NANOG 39 Meeting Attendees, Please note if you are staying in the Sheraton Centre Toronto and have a room reservation in the NANOG room block at the NANOG rate, you are entitled to receive complimentary in-room Internet access, complimentary access to the fitness center, and discounted valet parking on a space available basis. Charges for these services, if utilized, will be billed to a guest's folio and then rebated back on a daily basis or at the conclusion of one's stay. Again, in order to receive these benefits, your reservation *must* be under the NANOG room block at the NANOG group rate. See you there!
Re: Google wants to be your Internet
On Tue, Jan 30, 2007 at 08:19:12AM -, [EMAIL PROTECTED] wrote: IPv6 makes NAT obsolete because IPv6 firewalls can provide all the useful features of IPv4 NAT without any of the downsides. IPv6 firewalls? Where? Good ones? Why good ones. NAT is a basic IPv4 firewall. All IPv6 needs to obsolete NAT is a firewall that offers all the features of NAT without requiring the address translation. Then, instead of setting up a port translation for a particular incoming protocol, you simply open up that port without modifying the packets as they flow through. Suddenly, SIP works and incoming VoIP phonecalls work just like on the phone network. There is more to firewalls than NAT and packet filtering, no matter what the Cisco Pix people say. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: Google wants to be your Internet
On Tue, Jan 30, 2007 at 08:04:25PM -, Mark D. Kaye wrote: Hi, PIX/ASA Supports IPv6 Apparently, see below. Don't know anyone who has tested it yet though ;-) http://www.cisco.com/en/US/products/ps6120/products_configuration_guide_ chapter09186a0080636f44.html Note Failover does not support IPv6. The ipv6 address command does not support setting standby addresses for failover configurations. The failover interface ip command does not support using IPv6 addresses on the failover and Stateful Failover interfaces. The following inspection engines support IPv6: * FTP * HTTP * ICMP * SMTP * TCP * UDP as opposed to 23 separate application inspection engines listed in a table later on. Granted, some of those protocols don't exist on IPv6, but hardly 17 of 23. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
what the heck do i do now?
bear with me, this appears to be about DNS but it's actually about e-mail. maps.vix.com has been gone since 1999 or so. mail-abuse.org is the new thing. i've tried just about everything to get traffic toward the old domain name to stop... right now there's a DNAME but it made no real difference. i've taken the maps.vix.com domain away. i've set its NS to localhost. i've put long TTL's on both good and bad data. the traffic continues. clearly this is my pennance for starting MAPS, and i hear you giggling about it, but i need some advice. once upon a time, someone more insane than myself wanted to close an RBL and did so by replacing it with a wildcard entry. we all hated that since it caused a lot of mail to bounce. (all mail that would otherwise have been received by that RBL's subscribers, in fact.) it did however have the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this? oh and even though this isn't about bgp i can put some numbers in so that it will seem on-topic. out of 100K DNS queries received by a vix.com nameserver (which is about five minutes worth), here are the toptalkers for maps.vix.com. (and we all know by now that public shaming and notification won't work, i'm not sure why this is relevant, but it looks good, so here it is.) thoughts? 2208 68.216.187.10 2156 192.106.1.99 1348 213.239.240.162 1024 192.106.1.100 808 192.106.1.1 742 216.156.2.29 659 216.55.144.5 594 192.203.136.10 592 80.247.227.1 556 24.111.1.180 535 217.18.160.2 523 87.127.246.222 438 192.106.1.9 430 192.203.136.1 384 69.20.2.227 378 213.249.17.10 355 87.98.222.35 353 216.218.185.16 331 213.251.136.18 319 72.41.223.229 274 216.65.0.148 264 61.194.193.9 257 200.75.51.132 251 213.234.128.211 248 213.251.134.167 222 69.38.230.2 208 219.232.224.89 193 213.249.17.11 178 200.75.51.133 175 204.212.38.12 170 209.244.4.235 167 211.5.1.220 158 200.62.191.36 150 195.178.70.10 147 212.125.128.91 147 192.247.72.254 145 202.180.64.9 144 216.46.201.220 135 164.164.149.13 134 203.97.32.3 132 66.98.240.151 129 84.14.44.250 122 206.40.201.230 118 195.14.50.1 108 211.5.1.219 102 64.234.192.7 98 66.235.216.48 88 200.205.163.168 85 69.20.2.243 85 69.20.2.231 85 146.83.183.94 80 202.239.113.18 79 199.60.229.4 79 140.186.4.4 78 68.125.191.131 78 203.97.32.5 72 80.88.192.200 71 192.189.54.17 70 82.210.64.18 69 217.106.235.214 68 202.229.192.20 66 202.154.3.2 64 217.19.24.18 61 213.203.124.146 61 195.96.33.249 57 168.95.1.128 56 203.94.129.130 56 200.69.193.111 56 168.95.1.133 55 72.3.128.125 54 168.95.1.145 53 216.231.41.2 53 210.119.192.6 52 203.141.32.247 52 168.95.1.132 50 80.80.231.223 50 204.145.230.31 49 213.225.90.203 48 61.129.66.75 48 38.115.131.10 47 195.220.32.99 46 64.60.208.40 46 207.12.35.170 46 168.95.1.129 46 168.95.1.126 44 212.42.168.116 44 209.128.208.11 44 168.95.1.148 43 84.14.176.166 43 200.62.191.38 43 154.11.147.2 42 168.95.1.144 41 168.95.1.131 41 168.95.1.127 40 81.240.254.45 40 218.223.31.252 40 209.82.111.202 39 69.20.2.237 39 217.22.50.3 39 211.72.171.75 39 131.188.3.89 38 203.166.97.12 38 199.201.145.162 38 168.95.1.147 38 12.98.160.66 37 69.36.241.228 37 168.95.1.146 37 131.130.199.155 36 200.31.192.18 34 216.174.17.6 34 209.61.163.233 34 200.207.88.142 34 168.95.1.92 32 80.247.228.1 32 69.60.117.147 31 67.18.97.50 30 202.175.151.10 27 168.95.1.99 26 216.127.136.207 26 212.245.255.2 26 195.2.96.2 25 216.244.191.38 25 212.86.129.142 25 199.64.0.252 24 212.55.197.117 24 199.166.210.2 24 154.11.136.2 23 216.65.0.156 23 198.63.210.55 23 194.204.0.1 22 202.134.64.12 21 84.22.6.100 21 211.125.124.33 21 203.198.7.66 21 203.144.168.6 21 203.116.1.94 21 202.96.102.3 21 158.234.250.70 20 65.106.2.117 20 213.191.73.65 19 66.77.137.9 19 64.65.208.6 19 64.122.97.116 19 203.23.72.2 19 194.106.218.42 17 80.255.128.145 17 168.95.192.81 16 194.242.40.3 16 168.95.192.83 15 69.20.2.225 15 210.104.1.13 15 207.7.4.66 15 207.218.192.26 15 207.106.1.2 15 168.95.192.89 15 168.95.192.84 15 140.123.181.1 14 217.10.104.109 14 216.145.96.10 14 212.45.26.98 14 210.238.234.242 14 210.236.36.2 14 193.50.240.2 14 193.225.16.111 14 168.95.192.86 14 150.186.1.1 13 24.96.32.18 13 218.232.110.37 13 213.130.10.10 13 202.237.13.66 13 161.142.201.17 12 168.95.192.80 11 62.252.64.17 11 213.171.195.168 11 211.125.124.34 11 210.253.165.8 11 203.30.161.1 11 202.45.84.68 10 216.127.136.213 10 212.49.128.65 10 203.10.110.104 10 202.134.99.162 10 192.114.65.50 10 168.95.192.88 10 168.95.192.85 ...
Re: what the heck do i do now?
once upon a time, someone more insane than myself wanted to close an RBL and did so by replacing it with a wildcard entry. we all hated that since it caused a lot of mail to bounce. (all mail that would otherwise have been received by that RBL's subscribers, in fact.) it did however have the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this? one problem with this is that the pain is not felt by the misconfigured folk, but by distant innocents. randy
Re: what the heck do i do now?
Randy Bush wrote: once upon a time, someone more insane than myself wanted to close an RBL and did so by replacing it with a wildcard entry. we all hated that since it caused a lot of mail to bounce. (all mail that would otherwise have been received by that RBL's subscribers, in fact.) it did however have the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this? one problem with this is that the pain is not felt by the misconfigured folk, but by distant innocents. I don't necessarily agree with that. First off, if you set up your mail server to use maps.vix.com, you did it a LONG time ago, before scoring systems were all the rage. In all likelihood people are using this in a binary operation accept or don't based on this DNSBL entry's return code. Flipping that switch will completely break mail for the offending site, and (in all likelihood) they'll notice it pretty quick and stop. Or they won't, in which case, they're pretty much an unattended domain, and who really cares what happens to them anyway? I think that at some poing, Paul has a right to attempt to reclaim the sane use of his domain name, and considering how long the DNSBL in question has been out of commission, and people who use it should know that by now, the carrot needs to be traded in for a stick. Cheers, D -- Derek J. Balling Manager of Systems Administration Vassar College 124 Raymond Ave Box 0406 - Computer Center 217 Poughkeepsie, NY 12604 W: (845) 437-7231 C: (845) 249-9731 smime.p7s Description: S/MIME Cryptographic Signature
Re: what the heck do i do now?
... the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this? one problem with this is that the pain is not felt by the misconfigured folk, but by distant innocents. i am one of those who believes that e-mail is a shared benefit. so in my worldview, both the intended recipients and actual senders would feel pain. (bulk e-mail disproportionately benefits the sender, but i'm thinking 1x1 e-mail in this thought experiment.)
Re: what the heck do i do now?
One thing you might consider is putting together a script to harvest email addresses from whois records that correspond to the PTR for the querying IPs. Add to that list abuse, postmaster, webmaster, hostmaster, etc @ the poorly run domain. Then fire off a message explaining the situation and that you'll be adding a wildcard record on such and such date (preferably not 4/1). Script all of this and run it every couple of days until the date you gave and then follow through with the wildcard entry. This undoubtedly won't stop all of the whining but you can at least say you tried. volunteers are welcome to apply for that job. Perhaps you can get CNet or InfoWorld to pick it and write a story about the service and the impending change. that, conversely, would be fun. When it comes right down to it, you've got to do what you've got to do to recover your domain. You provided a service that many of us relied upon. The responsibility rests on our shoulders to keep up with the changing times. 7-8 years is more than enough time for even the laziest of mail admins to update their config. Think about how much bandwidth has been wasted over the years with these errant queries... about 1 billionth as much as has been wasted by RFC1918-sourced DNS queries sent to the root name servers OR RFC1918-domained DNS updates sent to AS112. therefore i treat it as a personal annoyance but NOT a waste in its own right.
Re: what the heck do i do now?
On Wed, 31 Jan 2007, Derek J. Balling wrote: I think that at some poing, Paul has a right to attempt to reclaim the sane use of his domain name, and considering how long the DNSBL in question has been out of commission, and people who use it should know that by now, the carrot needs to be traded in for a stick. 100% in agreement with everything Derek says. In the immediate term, it's *very* rude to just return false positives for everything, but maps.vix.com hasn't been a live DNSBL since 1999... -- Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Victorville, California PGP:0xE3AE35ED It's all fun and games until someone starts a bonfire in the living room.
Re: what the heck do i do now?
it caused a lot of mail to bounce. (all mail that would otherwise have been received by that RBL's subscribers, in fact.) it did however have the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this? I know the guy, in fact was talking to him on the phone earlier this afternoon and it wasn't as effective as you might hope. He may have had to abandon the domain. A probably not surprising number of people have decided that my abuse.net is a DNSBL, and nothing I've been able to do makes a serious dent. Look up the TXT record for any n.n.n.n.abuse.net where the n's are decimal numbers. 2208 68.216.187.10 This is Integrity On Line, which purports to be a filtered solution provider, which I presume means a big thick firewall that keeps out anything that might upset their subscribers. It might be illuminating to give them a call, express concern that a computer in their center is sending 400 unwanted messages a minute to you, and see if you can find anyone who has any idea how the mail servers are configured. I realize they're only a tiny percentage of your junk traffic, but their clue level is probably typical. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor More Wiener schnitzel, please, said Tom, revealingly.
Re: what the heck do i do now?
one problem with this is that the pain is not felt by the misconfigured folk, but by distant innocents. etc. One problem we have is that we tend to see the internet as a perfect simulation of a fair and just system, at least as a first goal. I don't know if that's possible or not. I don't know if anyone has actually explored the issue deeply. One problem is that there are many different notions of justice present globally. Probably thousands with significant real-world referents. -- -Barry Shein The World | [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: what the heck do i do now?
Paul Vixie wrote: bear with me, this appears to be about DNS but it's actually about e-mail. maps.vix.com has been gone since 1999 or so. mail-abuse.org is the new thing. i've tried just about everything to get traffic toward the old domain name to stop... right now there's a DNAME but it made no real difference. Paul, Not offering a solution but a bit of an explanation perhaps... From: http://cr.yp.to/ucspi-tcp/rblsmtpd.html If you do not supply any -r options, rblsmtpd tries an RBL source of rbl.maps.vix.com. This will be changed in subsequent versions. So checking the last released version: /ucspi-tcp-0.88# grep -hn maps.vix.com rblsmtpd.c 193: if (flagwantdefaultrbl) rbl(rbl.maps.vix.com); Looks like that could be a cause of some of your pain... Not everyone runs rblsmptd on their mailserver, but I know lots of large mail servers that run rblsmptd (qmail). The fact that the option is the default without being explicit means that at least some folks don't even know maps.vix.com zones are no longer present and the current failure case is not impacting them. -david ulevitch
Re: what the heck do i do now?
Thinking this out, out loud. Well, in black and white, anyway. Your vix.com name servers are authoritative for the zone. If a name server wants to do a lookup on maps.vix.com, it will get it from cache, or send a query to the listed IP address for one of the name servers. You said you had tried, e.g., putting up a maps.vix.com zone with a huge negative TTL - or did you say negative TTL? - but that would only work for multiple queries for the same value from the same name server. I don't see a clean way to poison even a large number of caches to forget about you completely. Does a large negative TTL on vix.com really not reduce the traffic much? But then that hurts you when you add a new record, if someone has been trying to get to that record. And there are name servers out there that ignore negative TTL. The only way for it not to arrive at the name server is for something in the way to block it. Perhaps a transparent filter, or perhaps the IP addresses of the name servers are your firewalls, which will block and pass the rest on to the real name servers behind them. Or maybe that's more work than it's worth. ;-) Is anything suffering besides your logs? -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: what the heck do i do now?
On Wed, 31 Jan 2007, Barry Shein wrote: :One problem we have is that we tend to see the internet as a perfect :simulation of a fair and just system, at least as a first goal. : :I don't know if that's possible or not. I don't know if anyone has :actually explored the issue deeply. One problem is that there are many :different notions of justice present globally. Probably thousands with :significant real-world referents. : : Ultimately, the problem is that the idealism which was more or less the rule a decade ago has taken a backseat to commercialism and what some see as practicality; and arguably, some consider such a reasonable excuse for lax maintenance (to the tune of if it's not hurting me/my customers, it's not a priority). Considering the time passed since maps went defunct, Paul is entirely justified in doing whatever is necessary to cluebat the offending networks, imho.
Re: what the heck do i do now?
Or just have everydns [or insert other free dns provider] handle your primary dns and let them handle the traffic, problem solved (for you atleast) :-) Personally I have no sympathy to people who are using outdated dnsbl's (especially from 1999), I would consider the wildcard if you want to actually solve the problem instead of dealing with it yourself or having to hand it off to someone else. You may also take that list of ips (with over 100 queries or so) and turn on the dnsbl with those ips added (they will only reject mail from each other but it might give some a clue). - Original Message - From: David Ulevitch [EMAIL PROTECTED] To: Paul Vixie [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: Wednesday, January 31, 2007 7:15 PM Subject: Re: what the heck do i do now? Paul Vixie wrote: bear with me, this appears to be about DNS but it's actually about e-mail. maps.vix.com has been gone since 1999 or so. mail-abuse.org is the new thing. i've tried just about everything to get traffic toward the old domain name to stop... right now there's a DNAME but it made no real difference. Paul, Not offering a solution but a bit of an explanation perhaps... From: http://cr.yp.to/ucspi-tcp/rblsmtpd.html If you do not supply any -r options, rblsmtpd tries an RBL source of rbl.maps.vix.com. This will be changed in subsequent versions. So checking the last released version: /ucspi-tcp-0.88# grep -hn maps.vix.com rblsmtpd.c 193: if (flagwantdefaultrbl) rbl(rbl.maps.vix.com); Looks like that could be a cause of some of your pain... Not everyone runs rblsmptd on their mailserver, but I know lots of large mail servers that run rblsmptd (qmail). The fact that the option is the default without being explicit means that at least some folks don't even know maps.vix.com zones are no longer present and the current failure case is not impacting them. -david ulevitch
Re: what the heck do i do now?
snip The only way for it not to arrive at the name server is for something in the way to block it. Perhaps a transparent filter, or perhaps the IP addresses of the name servers are your firewalls, which will block and pass the rest on to the real name servers behind them. The problem here is, most people that have experiences this problem, are significantly overwhelmed with traffic of people so much as trying to do a lookup, even if you firewall it you are still going to get an array of queries. In some cases, also, firewalling these queries makes it worse as servers will query multiple times, where as if you give a response with a large TTL they will go away. But then you have to have enough server power to handle these queries (and outbound bandwidth to match). I don't know how much of an impact there is in this case but I know of other people who've had this exact same problem and the traffic load of the attempted queries was immense. Cheers, Trent
Re: what the heck do i do now?
On Thu, 1 Feb 2007, Trent Lloyd wrote: snip The only way for it not to arrive at the name server is for something in the way to block it. Perhaps a transparent filter, or perhaps the IP addresses of the name servers are your firewalls, which will block and pass the rest on to the real name servers behind them. The problem here is, most people that have experiences this problem, are significantly overwhelmed with traffic of people so much as trying to do a lookup, even if you firewall it you are still going to get an array of queries. In some cases, also, firewalling these queries makes it worse as servers will query multiple times, where as if you give a response with a large TTL they will go away. But then you have to have enough server power to handle these queries (and outbound bandwidth to match). I don't know how much of an impact there is in this case but I know of other people who've had this exact same problem and the traffic load of the attempted queries was immense. We can discuss this forever. Paul can either maintain the service until he is sick of it, and hope they go away - or kick it. He waited long enough that even if we don't agree, hopefully non of us will have arguments with him. Depending on time investment issues, contacting some of the big hitters and seeing why they hit him may be interesting and may help stop a lot of these. Some generic emails to the hitters may also be an over-kill, but would satisfy some of the prettier souls among us. Gadi.
Re: what the heck do i do now?
On Wed, 31 Jan 2007, Brian Wallingford wrote: it's not a priority). Considering the time passed since maps went defunct, Paul is entirely justified in doing whatever is necessary to cluebat the offending networks, imho. here's the funny thing... what if the cluebat doesn't actualy change any delivery on the mailserver end? :) now THAT would be pretty funny. -Chris
RE: what the heck do i do now?
DNS forward all queries and replies to myspace, Im sure they'll enjoy that! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Vixie Sent: Wednesday, January 31, 2007 3:48 PM To: nanog@merit.edu Subject: Re: what the heck do i do now? ... the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this? one problem with this is that the pain is not felt by the misconfigured folk, but by distant innocents. i am one of those who believes that e-mail is a shared benefit. so in my worldview, both the intended recipients and actual senders would feel pain. (bulk e-mail disproportionately benefits the sender, but i'm thinking 1x1 e-mail in this thought experiment.)
Re: what the heck do i do now?
Brian Wallingford wrote: ... Considering the time passed since maps went defunct, Paul is entirely justified in doing whatever is necessary to cluebat the offending networks, imho. That's my opinion too. But I do have some domain name server addresses that get a lot of traffic due to historical misconfiguration by people who are likely too clueless to adjust it properly. And I tried some interesting experiments around providing wrong wildcard answers to queries that were received. And then, after getting some nasty complaints (including threats of legal action) from people who, for instance, didn't like that whenever their PC tried to use me as a resolver, they couldn't get to their favorite web sites any more and who weren't interested in removing me from their resolver list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their email firewall is checking your server, and someone dies as a result of the delay) So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts. Matthew Kaufman [EMAIL PROTECTED]
gmail admin anywhere?
Is there a gmail admin around? Could you give me a shout offlist? -mark -- Mark Jeftovic [EMAIL PROTECTED] Founder President, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(866) 273-2892
Re: what the heck do i do now?
list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their email firewall is checking your server, and someone dies as a result of the delay) So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts. Uhm. I don't follow? Once you've taken all reasonable measures to tell said hospital that you're no responsible, nor inclined, to forward their mail - and they continue to ignore your warnings - surely responsibility passes to the person who ignores the warnings? (Hospital Systems Engineer and/or IT Management? Or the person who relied on Email for a life-or-death application?) If theres no contract between you and said hospital, and you've taken reasonable steps to prevent a mishap, how is it your liability? Or is this where I get to say 'only in America' ?? To be more relevant to the original problem, I think Paul has every right to do what he wishes with the DNS entry, short of causing anyone else a Denial of Service. (Can't be said hes denying service to any of the clients involved, as they've had no 'service' from him since 1999, as stated...) Mark.
Re: what the heck do i do now?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 31, 2007, at 9:16 PM, Mark Foster wrote: list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their email firewall is checking your server, and someone dies as a result of the delay) So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts. Uhm. I don't follow? I my experience, people who tell stories like this really just need to get a better lawyer. I've had several lawyers contact us on things about this lame and have found that that the one sentence reply letter is often the most effective: Dear Sir: Kiss my what? Never hear from them again. Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFwV6ZElUlCLUT2d0RArP9AKC4JaEP5QJiB70SfrCWGkI9eTdxBwCcC+wA +DFKKXKMUqluFDF1DNCBJ0o= =sndk -END PGP SIGNATURE-
Re: what the heck do i do now?
On Thu, 1 Feb 2007, Paul Vixie wrote: One thing you might consider is putting together a script to harvest email addresses from whois records that correspond to the PTR for the querying IPs. Add to that list abuse, postmaster, webmaster, hostmaster, etc @ the poorly run domain. Then fire off a message explaining the situation and that you'll be adding a wildcard record on such and such date (preferably not 4/1). Script all of this and run it every couple of days until the date you gave and then follow through with the wildcard entry. This undoubtedly won't stop all of the whining but you can at least say you tried. volunteers are welcome to apply for that job. It's actually a trivial thing to do. Start with something like the geektools whois proxy. That'll handle getting the queries to the right RIR's whois server. Then all you need to do is parse the output for email addresses. For extra credit, you can look for common abuse addresses in the output and ignore other addresses in outputs where an abuse address is found. As for trying to make it stop, the two methods thought to be most successful are: 1) maps.vix.com.604800 IN NS . 2) maps.vix.com.604800 IN NS u1.vix.com. maps.vix.com.604800 IN NS u2.vix.com. maps.vix.com.604800 IN NS u3.vix.com. ... [as many as you like] u1.vix.com. 604800 IN A 192.0.2.1 u2.vix.com. 604800 IN A 192.0.2.2 u3.vix.com. 604800 IN A 192.0.2.3 ... [as many as you like] 1) just tells them there is no NS, go away. 2) gives them someone unreachable to try, which they'll do, and do, and do, wasting lots of retransmitted queries and the time it takes them to timeout. If you're lucky, the timeouts might be noticed as increased load and mail slowdown on the servers sending these queries. Either way, a properly functioning caching DNS should leave you alone for a while after caching the fact that there (is no NS for maps.vix.com||the NS's for maps.vix.com are unreachable/unresponsive). i.e. Either of these should mitigate the traffic far better than simply returning NXDOMAIN for every maps.vix.com dnsbl query. Successful here doesn't necessarily mean the traffic stopped but rather the traffic has been mitigated as much as is possible without actually getting people to fix their systems and stop querying the dead zone. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
WTH does Paul do now?
Why do I even bother? -- Forwarded message -- Date: Wed, 31 Jan 2007 23:08:22 -0500 From: Mail Delivery Subsystem [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Returned mail: see transcript for details The original message was received at Wed, 31 Jan 2007 23:08:18 -0500 from localhost.localdomain [127.0.0.1] - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 553 5.7.1 Service unavailable; Client host [69.28.69.2] blocked using reject-all.vix.com; reason / created) - Transcript of session follows - ... while talking to sa.vix.com.: RCPT To:[EMAIL PROTECTED] 553 5.7.1 Service unavailable; Client host [69.28.69.2] blocked using reject-all.vix.com; reason / created 550 5.1.1 [EMAIL PROTECTED]... User unknown
Re: what the heck do i do now?
As an, ahem, lawyer, I think what you do and how you do it matter a lot here. And it would be prudent to talk to someone who understood your facts and situation before doing some of the things discussed in this thread. (I won't be more specific for fear of sounding like I'm giving legal advice, YMMV, probably not admitted where you live, if this were advice it would trigger a bill, see generally disclaimers at http://www.law.tm/disclaimers.html .) Pulling a plug after reasonable/lots of warnings (did you miss anyone? how do you know for sure?) is on the safer end of the legal spectrum. Trying something that has the noble intention of directing cluebat to cranial density... well, that's different. It has the ability to be spun as malicious. Will the judge and jury get it? Who will pay for the lawyer who will explain it to them? What if it was a government computer that got hosed? Will this be civil or criminal liability? Bottom line is that in the absence of a promise -- explicit or implicit (!) -- to the contrary, you can usually turn off your gear and get on with your life (but would you want to if it was a hospital that got hosed? how would you feel in the morning?). The more your actions deviate from that, the more likely you are taking on some level of risk. In some scenarios it's an acceptable level, but it all depends. It is impossible to know with any confidence without knowing more details, but from the face of it, it is far from obvious to me that Mark Foster's lawyer got this wrong. (Meanwhile, this will make a great exam question some day.) On Wed, 31 Jan 2007, Chris Owen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 31, 2007, at 9:16 PM, Mark Foster wrote: list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their email firewall is checking your server, and someone dies as a result of the delay) So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts. Uhm. I don't follow? I my experience, people who tell stories like this really just need to get a better lawyer. I've had several lawyers contact us on things about this lame and have found that that the one sentence reply letter is often the most effective: Dear Sir: Kiss my what? Never hear from them again. Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFwV6ZElUlCLUT2d0RArP9AKC4JaEP5QJiB70SfrCWGkI9eTdxBwCcC+wA +DFKKXKMUqluFDF1DNCBJ0o= =sndk -END PGP SIGNATURE- -- http://www.icannwatch.org Personal Blog: http://www.discourse.net A. Michael Froomkin |Professor of Law| [EMAIL PROTECTED] U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm --It's warm here.--
Re: what the heck do i do now?
It is impossible to know with any confidence without knowing more details, but from the face of it, it is far from obvious to me that Mark Foster's lawyer got this wrong. (Meanwhile, this will make a great exam question some day.) I agree, except it wasn't my Laywer. You mean Matthew Kaufman. Note the number of quotede layers. I made the mistake of removing the quote-intro-line when I posted, apologies. On Wed, 31 Jan 2007, Chris Owen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 31, 2007, at 9:16 PM, Mark Foster wrote: list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their email firewall is checking your server, and someone dies as a result of the delay) So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts. Uhm. I don't follow? I my experience, people who tell stories like this really just need to get a better lawyer. I've had several lawyers contact us on things about this lame and have found that that the one sentence reply letter is often the most effective: Dear Sir: Kiss my what? Never hear from them again. Chris *snip*
Re: Best way to supply colo customer with specific provider
another way is tunnel them to a border router that interfaces with Cogent and deal with it at the border router. QinQ tunnel, GRE, IPSec, or whatever tunnel type you can support and will service the type of traffic your customer needs (L2 or L3). If you have multiple Cogent connections you might even be able to DMVPN to the relevant points. MPLS is another elegant way to handle it, but if you have MPLS infrastructure, you probably would have said so. --- Steve Gibbard [EMAIL PROTECTED] wrote: If you actually want to do this, you've got four choices: - Policy route, as mentioned below. - Get the customer their own connection to Cogent. - Have a border router that only talks to Cogent and doesn't receive full routes from your core, and connect the customer directly to that. - Do something involving route servers and switches outside your border routers, a-la-Equinix Direct. The policy routing idea will work, for some definition of work. I forget whether Cisco now has a fast (non-processor-switched) path for policy routed traffic; they didn't yet when somebody convinced me to try this many years ago. If nothing else, it will make a mess of configuration and troubleshooting. Getting the customer their own Cogent connection is likely the least trouble, but may not save you as much on the bandwidth cost as aggregating the customer's traffic into the rest of your traffic would. Connecting the customer to a Cogent-only border router works fine if you already have such a border router. If not, it may require significant reengineering. The route server suggestion is thrown out mainly as a conceptual exercise. It would require a lot of design work. All that said, if you're paying your engineers and operations people developed world salaries, and paying major well-connected city bandwidth rates, none of these suggestions should make your accountants or your customer's accountants happy. You'll be saving a bit on bandwidth costs while putting in large amounts of engineering time that at best will do nothing useful for your other customers. Any way you do this, you'll probably find that it costs you considerably more than it would to give the customer your standard product. -Steve On Tue, 30 Jan 2007, Rick Kunkel wrote: Hello all, Being relatively new to the colocation business, we run into a fair number of issues that we've never run into before. Got a new one today, and although I can think of kludgey ways to accomplish what he wants, I'd rather get some other ideas first... We just had our first customer that's requesting bandwidth exclusively through a particular provider of ours (Cogent) at less expensive pricing. The money people here are up for it, but obviously, they want to make sure that he's confined to that Cogent connection. So now of course we're attempting to figure out the best way to do this, and I figured that rather than reinventing the wheel, I'd check to see how others accomplish things like this. The way I can imagine doing it is by using route-maps to steer all of this customer's traffic out the Cogent pipe, and modifying our BGP announcements by AS prepending on whatever block or blocks we set aside to be Cogent-exclusive. Again though, this seems to me to lack a certain amount of, for lack of a better word, grace. Any other suggestions? Thanks, Rick Kunkel Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/
