Re: IP to authoritative CIDR webservices
On Mon, Dec 14, 2009 at 11:13:28PM -0600, William Pitcock wrote: > Yes, but it has to be parsed, and RIRs have varying whois formats. ARIN > vs RIPE whois output, for example. This is very easy to parse, though not a "web service": ftp://ftp.ripe.net/pub/stats/ripencc/RIR-Statistics-Exchange-Format.txt james -- ``It's somewhere in the Red Hat district'' -- A network engineer's freudian slip when talking about Amsterdam's nightlife at RIPE 38.
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
* Steven Bellovin (s...@cs.columbia.edu) wrote: > > On Dec 14, 2009, at 11:47 PM, Joel Jaeggli wrote: > > Owen DeLong wrote: > > Stable outgoing connections for p2p apps, messaging, gaming platforms > > and foo website with java script based rpc mechanisms have similar > > properties. I don't sleep soundly at night becasuse the $49 buffalo > > router I bought off an endcap at frys uses iptables, I sleep soundly > > because I don't care. > > > Precisely. And if you want to get picky, remember that "availability" is part > of the standard definition of security. A firewall that doesn't let me play > Chocolate-Sucking Zombie Monsters is an attack on the availability of that > gmae, albeit from the purest of motives. > > No, I'm not saying that this is good. I am saying that in the real world, it > *will* happen. So what you are saying is that ease of use and service availability is priority one. Then what exactly are the responsibilities of the ISP and CPE manufacturer when it comes to security? CPEs with WiFi usually comes with the advice to change password etc. Is it ok to build an infrastructure relying on UPnP, write a disclaimer, and let the end user handle eventual problems? (I assume it is...) /jkm
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On 15/12/2009, at 11:19 PM, Joakim Aronius wrote: > So what you are saying is that ease of use and service availability is > priority one. Then what exactly are the responsibilities of the ISP and CPE > manufacturer when it comes to security? CPEs with WiFi usually comes with the > advice to change password etc. Is it ok to build an infrastructure relying on > UPnP, write a disclaimer, and let the end user handle eventual problems? (I > assume it is...) Hasn't essentially every ISP on the planet been doing that for years, only without the disclaimer? It's not like we're talking about creating UPnP from whole cloth. We're discussing a replacement of like-for-like, updating existing capabilities to support IPv6. - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
Re: IP to authoritative CIDR webservices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/15/2009 12:18 AM, William Pitcock wrote: >> http://asn.cymru.com/ > > Looks like their WHOIS server in verbose mode will do the trick for what > I want, as it provides predictable output. Thank you. For the record, the prefix you find here will be the prefix our BGP view (from peers around the globe) sees that IP announced as, which is not necessarily the same as the RIR allocated prefix. And you can find full details of all of the access methods for this service here: http://www.team-cymru.org/Services/ip-to-asn.html Please make note of the notice at the top of the page regarding use in software, applications, and devices - if we have advance notice we can make sure we're not going to accidentally block you or your users, but only if you get in touch with us first. :) Thanks, Tim Wilde - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twi...@cymru.com | +1-630-230-5433 | http://www.team-cymru.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksnoKMACgkQluRbRini9tg5dACePR1UW3eLF4LTQ3BkWIdy1B/+ E3IAnjTeU5TeJQkEHLKE7c+CceFyVPU+ =FmpZ -END PGP SIGNATURE-
DNS question, null MX records
I have a domain that exists solely to cname A records to another domain's websites. There is no MX server for that domain, there is no valid mail sent as from that domain. However when I hooked it up I immediately started getting bounces and spam traffic attemtping to connect to the cnamed A record, which has no inbound mail server (It's actually hitting the firewall in front of it). (The domain name is actually several years old and has been sitting without dns for a while) I found a reference to a null MX proposal, constructed so: example.comINMX 0 . Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. __ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.
RE: DNS question, null MX records
Hello, You could use: Local.example.com. IN A 127.0.0.1 Example.com.IN MX 10 local.example.com. This way systems shouldn't deliver it at your system. What you did mention is something we don't allow our customers to do (if I am correct). With kind regards, Mark Scholten -Original Message- From: Eric J Esslinger [mailto:eesslin...@fpu-tn.com] Sent: dinsdag 15 december 2009 16:18 To: 'nanog@nanog.org' Subject: DNS question, null MX records I have a domain that exists solely to cname A records to another domain's websites. There is no MX server for that domain, there is no valid mail sent as from that domain. However when I hooked it up I immediately started getting bounces and spam traffic attemtping to connect to the cnamed A record, which has no inbound mail server (It's actually hitting the firewall in front of it). (The domain name is actually several years old and has been sitting without dns for a while) I found a reference to a null MX proposal, constructed so: example.comINMX 0 . Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. __ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.
Re: DNS question, null MX records
* Eric J. Esslinger: > I found a reference to a null MX proposal, constructed so: > example.comINMX 0 . I think this is quite controversal. The best approach still seems to be an SMTP rejecter on a dedicated IP address. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: DNS question, null MX records
On Dec 15, 2009, at 10:17 AM, Eric J Esslinger wrote: > I have a domain that exists solely to cname A records to another domain's > websites. There is no MX server for that domain, there is no valid mail sent > as from that domain. However when I hooked it up I immediately started > getting bounces and spam traffic attemtping to connect to the cnamed A > record, which has no inbound mail server (It's actually hitting the firewall > in front of it). (The domain name is actually several years old and has been > sitting without dns for a while) > > I found a reference to a null MX proposal, constructed so: > example.comINMX 0 . > > Question: Is this a valid dns construct or did the proposal die? I don't want > to cause people problems but at the same time, I don't want any of this crap > to even attempt to deliver on this domain to any of my servers. It's valid. But if you think all spammers will respect it, you're in for a surprise. :( There is also a recommendation to point the MX at somewhere unroutable (192.2.x.x IIRC, but don't quote me on that). This will force the spammer / bot to try to connect to something that does not exist and use up sockets & resources, hopefully slowing it down. I've also heard that pointing the MX at localhost is useful, for reasons that should be obvious. The latter has the slight advantage of not making networks with a default route carry packets to the DFZ. I'm sure some will find errors with all three suggestions. I honestly don't know which is the best / worst. Personally I'd set up a tiny mail server that accepted connections & feed them to /dev/null, or maybe forwarded the whole feed to a spam trap or DCC or the like. -- TTFN, patrick
Re: DNS question, null MX records
On 12/15/2009 10:17 AM, Eric J Esslinger wrote: I found a reference to a null MX proposal, constructed so: example.comINMX 0 . Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. Pulling from my often mangled memory: This was proposed in a draft RFC that went nowhere. Parsing the Null MX record was implemented in at least one fairly popular MTA (Postfix?) The null MX record was published by whoever got (some of?) the Excite @Home domain(s) after that company flamed out. This results in the occasional post to various mailing lists by people wondering why they are queuing mail bound for said domain. So to the point of your question, it may reduce some SMTP connection attempts to you, but will not likely eliminate them. -- Dave
RE: DNS question, null MX records
I've had a couple of off-list comments already about using it as/donating it to a spam trap; That is a good idea and I actually thought of that. However, the address was formerly used for email addresses for our customers and for our business (some 10 years ago it was registered, but has not had any valid dns records set for roughly 6 years), and we still deal from time to time with mail being sent to old addresses on that domain for various reasons (several dns registrations, for example, we've had to help these people go through the fax change system because we don't want to go to the trouble of setting up to receive email on this domain again) So in any case, due to customer privacy concerns we feel we can't do that. Also I have set the spf -all on it, for those that look for these records to auot-reject email from the domain. __ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 -Original Message- From: Eric J Esslinger [mailto:eesslin...@fpu-tn.com] Sent: Tuesday, December 15, 2009 9:18 AM To: 'nanog@nanog.org' Subject: DNS question, null MX records I have a domain that exists solely to cname A records to another domain's websites. There is no MX server for that domain, there is no valid mail sent as from that domain. However when I hooked it up I immediately started getting bounces and spam traffic attemtping to connect to the cnamed A record, which has no inbound mail server (It's actually hitting the firewall in front of it). (The domain name is actually several years old and has been sitting without dns for a while) I found a reference to a null MX proposal, constructed so: example.comINMX 0 . Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. __ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. <>
Cyclops Down?
Is anyone else seeing cyclops down -- or is it just me? mtr -c10 -r 131.179.96.253 4. osh-2828-peer.onshore.net 0.0%101.3 1.3 1.2 1.6 0.1 5. ip65-47-181-105.z181-47-65.c 0.0%101.4 2.0 1.3 3.7 0.8 6. ge11-1-4d0.mcr2.chicago-il.u 0.0%102.1 1.7 1.4 2.1 0.3 7. ae1d0.mcr1.chicago-il.us.xo. 0.0%102.7 11.8 1.8 34.9 13.4 8. 216.156.0.161.ptr.us.xo.net 0.0%10 62.2 62.3 62.0 62.8 0.3 9. te-3-2-0.rar3.dallas-tx.us.x 0.0%10 61.1 61.8 61.0 64.2 1.0 10. 207.88.12.46.ptr.us.xo.net0.0%10 61.6 61.6 60.7 63.8 1.1 11. 207.88.12.158.ptr.us.xo.net 0.0%10 60.7 61.0 60.7 61.7 0.4 12. lax-px1--xo-ge.cenic.net 0.0%10 60.5 60.8 60.4 61.4 0.4 13. dc-lax-core1--lax-peer1-ge.c 0.0%10 61.5 61.5 61.1 62.1 0.4 14. dc-lax-agg1--lax-core1-ge.ce 0.0%10 61.1 61.6 60.8 63.5 0.9 15. dc-ucla--lax-agg1-ge-2.cenic 0.0%10 62.0 62.6 61.7 65.1 1.3 16. border-2--core-1-ge.backbone 0.0%10 62.4 62.4 61.8 63.4 0.5 17. core-1--mathsci-10ge.backbon 0.0%10 61.9 61.7 61.4 62.1 0.2 18. ??? 100.0100.0 0.0 0.0 0.0 0.0
Re: DNS question, null MX records
Eric J Esslinger wrote: > I have a domain that exists solely to cname A records to another domain's > websites. [...] > I found a reference to a null MX proposal, constructed so: > example.comINMX 0 . [...] > Question: Is this a valid dns construct or did the proposal die? It's "valid", but you will probably find people still try to spam to machines on the A records, and all of the other weird and wonderful things that spambots try to do to find a path that will deliver mail... If there is no time that mail should appear *from* this domain name then it's polite to set spf records as such - one of the few things spf is always useful for :-) like this : @ IN TXT "v=spf1 -all" ... all this means in practice though is that spammers who actually bother to check for this, will find someone else to masquerade. But you won't have to deal with the associated attempted bounce delivery connections... Best wishes Andy
Re: Is there anyone from ASPEWS on this list?
Bill Weiss wrote: Michelle Sullivan(matt...@sorbs.net)@Mon, Dec 14, 2009 at 11:32:48AM +0100: Then tell me where it says 3-5 hours and I'll correct the text. On http://www.au.sorbs.net/cgi-bin/support , I read: "This will route any created ticket to the robot handler which will process and delist the netblock (upto /24) within a few hours" That says the robot will delist (not schedule to delist) "within a few hours". Thank you, I wasn't aware, and it will be corrected (doesn't say 3-5hours still so I'd love to find that one). Michelle
Re: Cyclops Down?
Looks from from SATX (TWC/RoadRunner) Jorge On Tue, Dec 15, 2009 at 10:00 AM, sjk wrote: > Is anyone else seeing cyclops down -- or is it just me? > > mtr -c10 -r 131.179.96.253
Re: Is there anyone from ASPEWS on this list?
Kevin Stange wrote: On 12/14/2009 04:32 AM, Michelle Sullivan wrote: I'm a robot writing you on behalf of the SORBS' admins. The reason you're getting this automated response, is our desire to provide you with consistent and fast responses. I'm prepared to correctly analyze most of the cases appearing in the DUHL queue. This last sentence seems to be my point of contention here. I am trying to get a /18 removed from the DUHL and every time the robot tells me some arbitrary ranges I did not mention explicitly are being tested and/or not eligible for delisting. Since the ranges not eligible are configured the same as those that are, I can't figure this out. Replying to the robot resulted in no response for a month, so I ended up submitting a ticket via the ISP contact form directly, with all the information requested, but the first time, someone just pushed my request back to the robot and it refused ranges again. This sometimes happens, particularly if the request doesn't come with an ASN and/or no authoritative contact (ie: not from the email used in the whois records for that netblock). For what it's worth using the following syntax when sending to d...@support.sorbs.net can force the robot's view: BEGIN SORBS LIST / . . . / END SORBS LIST Will force the robot to only look at the networks within the tags (case is sensitive) Submitting ranges over /16 with this method will result in ticket rejection. rDNS will be scanned in all cases, rDNS is cached locally for a minimum of 48 hours, so if you are rejected because some rDNS appears dynamic, you will need to get a human to manually rescan or approve for delisting, or wait 48 hours for the cache to be ignored. The cache is web viewable and publicly accessible, please email me offlist to miche...@sorbs.net if you want to know where the cache is. I understand you get a lot of traffic to your ticket system, but I have to wonder whether a system which is so complex and large that it is near impossible to support and keep maintained accurately is actually still useful. I assume you love (to some degree) helping kill spammers, but maybe you need to solicit (screened) volunteers to expand your staffing? We do, and getting technically clueful people who are trustworthy seems to be an issue. We got hit by the 'trustworthy' aspect some time ago, and the clueful aspect is a regular problem. I am hoping that the buy out by GFI will provide some paid 24x7 staff, obviously I cannot comment about where that is going any further, but we all know things take time Currently I am working full time on processing tickets as well as other duties in relation to improving all systems, but I actually need to stop answering tickets completely to complete those other systems... Those other systems will allow approved entities to access the SORBS database directly (and not just for DUHL requests) this system was devised in 2003, initially developed in 2004 and promised in 2005 however with everything that has happened to me in the last 4 years it has been delayed, delayed and delayed yet again. Patience seems to be the key for all concerned as there is currently only one of me. Michelle
Customer issue connecting to TWTelecom
Can someone from TW Telecom contact me offlist? I have a customer having issues connecting to a TW Telecom hosted site. Scott Wolfe Cybera, Inc 615-301-2346 PGP.sig Description: PGP signature
Re: Cyclops Down?
Hi all, We're having an issue with an UPS here at UCLA where one of the Cyclops servers is connected to. It should be fixed very soon, will keep you posted.. Thanks, --Ricardo On Dec 15, 2009, at 8:00 AM, sjk wrote: Is anyone else seeing cyclops down -- or is it just me? mtr -c10 -r 131.179.96.253 4. osh-2828-peer.onshore.net 0.0%101.3 1.3 1.2 1.6 0.1 5. ip65-47-181-105.z181-47-65.c 0.0%101.4 2.0 1.3 3.7 0.8 6. ge11-1-4d0.mcr2.chicago-il.u 0.0%102.1 1.7 1.4 2.1 0.3 7. ae1d0.mcr1.chicago-il.us.xo. 0.0%102.7 11.8 1.8 34.9 13.4 8. 216.156.0.161.ptr.us.xo.net 0.0%10 62.2 62.3 62.0 62.8 0.3 9. te-3-2-0.rar3.dallas-tx.us.x 0.0%10 61.1 61.8 61.0 64.2 1.0 10. 207.88.12.46.ptr.us.xo.net0.0%10 61.6 61.6 60.7 63.8 1.1 11. 207.88.12.158.ptr.us.xo.net 0.0%10 60.7 61.0 60.7 61.7 0.4 12. lax-px1--xo-ge.cenic.net 0.0%10 60.5 60.8 60.4 61.4 0.4 13. dc-lax-core1--lax-peer1-ge.c 0.0%10 61.5 61.5 61.1 62.1 0.4 14. dc-lax-agg1--lax-core1-ge.ce 0.0%10 61.1 61.6 60.8 63.5 0.9 15. dc-ucla--lax-agg1-ge-2.cenic 0.0%10 62.0 62.6 61.7 65.1 1.3 16. border-2--core-1-ge.backbone 0.0%10 62.4 62.4 61.8 63.4 0.5 17. core-1--mathsci-10ge.backbon 0.0%10 61.9 61.7 61.4 62.1 0.2 18. ??? 100.0100.0 0.0 0.0 0.0 0.0
RE: DNS question, null MX records *summary of on list and off list replies*
A. Use a valid domain mapped to an unroutable or loopback instead of the . I've decided to use 127.0.0.1 B. Set spf -all, for those who bother to check that to stop inbound mail from your domain. Already had that in place C. Donate the spam to someone who would use it. I can't donate the existing incoming email due to privacy concerns, however, project honeypot uses subdomains (f...@bar.example.com) for it's spam traps and wants unused subdomains so it's traps will be 'clean to start'. I'll see if I can get that done. D. Expect some spammers to detect any MX strangeness you use and bypass it in favor of your A record. Understandable, and none of the referenced records in the DNS files accept mail from outside, connections are silently dropped at the firewall. This is just an attempt to cut the mess coming in because of the A record down in size. E. Set up an actual mail server routing all mail to /dev/null. I'd rather just drop the traffic rather than have another service to maintain/secure/update __ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 -Original Message- From: Eric J Esslinger [mailto:eesslin...@fpu-tn.com] Sent: Tuesday, December 15, 2009 9:18 AM To: 'nanog@nanog.org' Subject: DNS question, null MX records I have a domain that exists solely to cname A records to another domain's websites. There is no MX server for that domain, there is no valid mail sent as from that domain. However when I hooked it up I immediately started getting bounces and spam traffic attemtping to connect to the cnamed A record, which has no inbound mail server (It's actually hitting the firewall in front of it). (The domain name is actually several years old and has been sitting without dns for a while) I found a reference to a null MX proposal, constructed so: example.comINMX 0 . Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers. This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.
Re: Is there anyone from ASPEWS on this list?
On 12/15/2009 10:17 AM, Michelle Sullivan wrote: > Bill Weiss wrote: >> Michelle Sullivan(matt...@sorbs.net)@Mon, Dec 14, 2009 at 11:32:48AM >> +0100: >> >>> >>> Then tell me where it says 3-5 hours and I'll correct the text. >>> >> >> On http://www.au.sorbs.net/cgi-bin/support , I read: >> "This will route any created ticket to the robot handler which will >> process and delist the netblock (upto /24) within a few hours" >> >> That says the robot will delist (not schedule to delist) "within a few >> hours". >> >> > > Thank you, I wasn't aware, and it will be corrected (doesn't say > 3-5hours still so I'd love to find that one). > There is this text I see, which seems to disagree with the robot's behavior in my case (from the Dynamic IP FAQ): "The Regional Internet Registry (RIR) Point of Contact (PoC) can request a listing or delisting of any address in their space. The only time this will be refused is when the netblock information in the RIR or in the reverse DNS naming clearly indicates the addresses are dynamically assigned (e.g. 0.1.pool.example.com). " I'm sending my request from our PoC and it's not taking my word for it like is claimed here (since the reverse DNS certainly doesn't imply the ranges are dynamic). If you don't consider this part of the policy anymore, you might want to clear that up in the FAQ. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 signature.asc Description: OpenPGP digital signature
Re: Cyclops Down?
Cyclops is online now, apologies for the disruption. Best, --Ricardo On Dec 15, 2009, at 8:00 AM, sjk wrote: Is anyone else seeing cyclops down -- or is it just me? mtr -c10 -r 131.179.96.253 4. osh-2828-peer.onshore.net 0.0%101.3 1.3 1.2 1.6 0.1 5. ip65-47-181-105.z181-47-65.c 0.0%101.4 2.0 1.3 3.7 0.8 6. ge11-1-4d0.mcr2.chicago-il.u 0.0%102.1 1.7 1.4 2.1 0.3 7. ae1d0.mcr1.chicago-il.us.xo. 0.0%102.7 11.8 1.8 34.9 13.4 8. 216.156.0.161.ptr.us.xo.net 0.0%10 62.2 62.3 62.0 62.8 0.3 9. te-3-2-0.rar3.dallas-tx.us.x 0.0%10 61.1 61.8 61.0 64.2 1.0 10. 207.88.12.46.ptr.us.xo.net0.0%10 61.6 61.6 60.7 63.8 1.1 11. 207.88.12.158.ptr.us.xo.net 0.0%10 60.7 61.0 60.7 61.7 0.4 12. lax-px1--xo-ge.cenic.net 0.0%10 60.5 60.8 60.4 61.4 0.4 13. dc-lax-core1--lax-peer1-ge.c 0.0%10 61.5 61.5 61.1 62.1 0.4 14. dc-lax-agg1--lax-core1-ge.ce 0.0%10 61.1 61.6 60.8 63.5 0.9 15. dc-ucla--lax-agg1-ge-2.cenic 0.0%10 62.0 62.6 61.7 65.1 1.3 16. border-2--core-1-ge.backbone 0.0%10 62.4 62.4 61.8 63.4 0.5 17. core-1--mathsci-10ge.backbon 0.0%10 61.9 61.7 61.4 62.1 0.2 18. ??? 100.0100.0 0.0 0.0 0.0 0.0
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On Dec 15, 2009, at 4:49 AM, Joakim Aronius wrote: * Steven Bellovin (s...@cs.columbia.edu) wrote: On Dec 14, 2009, at 11:47 PM, Joel Jaeggli wrote: Owen DeLong wrote: Stable outgoing connections for p2p apps, messaging, gaming platforms and foo website with java script based rpc mechanisms have similar properties. I don't sleep soundly at night becasuse the $49 buffalo router I bought off an endcap at frys uses iptables, I sleep soundly because I don't care. Precisely. And if you want to get picky, remember that "availability" is part of the standard definition of security. A firewall that doesn't let me play Chocolate-Sucking Zombie Monsters is an attack on the availability of that gmae, albeit from the purest of motives. No, I'm not saying that this is good. I am saying that in the real world, it *will* happen. So what you are saying is that ease of use and service availability is priority one. Then what exactly are the responsibilities of the ISP and CPE manufacturer when it comes to security? CPEs with WiFi usually comes with the advice to change password etc. Is it ok to build an infrastructure relying on UPnP, write a disclaimer, and let the end user handle eventual problems? (I assume it is...) /jkm Personally, I think that CPE should come up relatively braindead except on the interior wired ethernet interfaces and require creating an SSID and suggesting creating a password (regardless of whether TKIM, WEP, WPA, etc, at least something) before enabling any wireless. It should require the user to create their own administrative password before being able to enable any other features on the box. If CPE manufacturers did this, it would remove a great many vulnerabilities in the world without making it particularly harder for the average end-user. Owen
Re: DNS question, null MX records
On Tue, 15 Dec 2009, Florian Weimer wrote: > * Eric J. Esslinger: > > > I found a reference to a null MX proposal, constructed so: > > example.comINMX 0 . > > I think this is quite controversal. My impression from discussions on various IETF lists is that most people think it is a good idea, it is already reasonably widely implemented, but no-one has the time and persistence to push a spec through to publication. Tony. -- f.anthony.n.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: DNS question, null MX records
I disagree. There was considerable concern with a misuse of a mechanism and its effect on various systems. That, from discussion on the IETF mailing list I was on when it was discussed there. There was no rough consensus that I could see. On Dec 15, 2009, at 2:09 PM, Tony Finch wrote: > On Tue, 15 Dec 2009, Florian Weimer wrote: >> * Eric J. Esslinger: >> >>> I found a reference to a null MX proposal, constructed so: >>> example.comINMX 0 . >> >> I think this is quite controversal. > > My impression from discussions on various IETF lists is that most people > think it is a good idea, it is already reasonably widely implemented, but > no-one has the time and persistence to push a spec through to publication. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. > MODERATE OR GOOD.
Cogent $1500 GigE
Dear List, I am getting a big push from Cogent on their full GigE for $1.50 per circuit. What are your experiences with Cogent in general? If on the fence, how would you use their service for this deal to make sense? Best Regards, Babak -- Babak Pasdar President & CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability (p) 212.461.3322 x3005 | (f) 212.584. | (w) www.BatBlue.com Receive Bat Blue's Daily Security Intelligence Report Bat Blue's AS: 25885 | BGP Policy | Peering Policy Bat Blue's Legal Notice Reducing IT Security Budget, Burden & Risk - Video | Article
Re: Cogent $1500 GigE
Babak Pasdar wrote: Dear List, I am getting a big push from Cogent on their full GigE for $1.50 per circuit. What are your experiences with Cogent in general? If on the fence, how would you use their service for this deal to make sense? $1.50 per meg. ;) I'd probably take it just because I could at that price. The downsides with Cogent is that they occasionally get into peering spats that might hurt you if you aren't multihomed, and no usable IPv6 (if that matters to you). I hadn't looked into it any further because I'm not located anywhere Cogent is to give it a serious look. ~Seth
Re: Cogent $1500 GigE
On Dec 15, 2009, at 3:53 PM, Seth Mattinen wrote: > Babak Pasdar wrote: >> Dear List, >> I am getting a big push from Cogent on their full GigE for $1.50 per >> circuit. What are your experiences with Cogent in general? If on the >> fence, how would you use their service for this deal to make sense? > > $1.50 per meg. ;) I'd probably take it just because I could at that price. > The downsides with Cogent is that they occasionally get into peering spats > that might hurt you if you aren't multihomed, and no usable IPv6 (if that > matters to you). I hadn't looked into it any further because I'm not located > anywhere Cogent is to give it a serious look. I'm pretty sure the system at $DAY_JOB is better at pushing bits near, but not quite over, the hard limit of a link than any other out there. And I am dead certain I could not get 1000 Mbps out of a GigE without serious packet loss. Even assuming 900 Mbps (good luck), you're at $1.66/Mbps. Most people do 50%, so that would be $3/Mbps. Still probably a good price for 500 Mbps. But how much OpEx do you have to spend to ensure that link stays below 1 Gbps 24/7/365? And if you only have 100 Mbps, though, it doesn't look so good. -- TTFN, patrick
Root zone DNSSEC deployment web site and technical status update
The root zone DNSSEC deployment team is pleased to announce a new web site with information about the project, http://www.root-dnssec.org. The site serves as a repository for documentation and information about deploying DNSSEC in the root zone, including technical status updates. The first status update is available on the site and is included below, as well. Additional documentation will be posted as it becomes available. Important announcements and future status updates will appear in the site's RSS feed, http://www.root-dnssec.org/rss. The design team welcomes your feedback: you can reach the entire team at roots...@icann.org. On behalf of the root zone DNSSEC deployment team, Matt Larson -- Status Update, December, 2009 This is the first of a series of technical status updates intended to inform a technical audience on the progress of deploying DNSSEC in the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at http://www.root-dnssec.org/. We'd like to hear from you. If you have feedback for us, please send it to roots...@icann.org. DOCUMENTATION This project involves the creation of a large volume of documentation, individual components of which will be released as they have completed internal review. The following documents are expected to be released as drafts before the end of December 2009: * Root Zone DNSSEC Deployment Plan * Root Zone Trust Anchor Publication DEPLOYMENT STATUS Several root server operators have started testing a lightweight packet capture tool designed to provide a full record of priming queries received over the period covering DNSSEC deployment in the root zone. We hope this data collection will be in full production on all root servers before the end of December, providing baseline data which will allow the reaction of the system as a whole to deployment events to be observed. On 2009-12-01, the first pre-production KSR exchange between ICANN and VeriSign and the signing of the root zone within VeriSign's production infrastructure commenced. The signing, validation, measurement and monitoring infrastructure will now be subject to full internal testing. PLANNED DEPLOYMENT SCHEDULE 2009-12-01: KSR exchange, root zone signing begins, internal to VeriSign and ICANN; generation of DURZ Week of 2010-01-11: L starts to serve DURZ Week of 2010-02-08: A starts to serve DURZ Week of 2010-03-01: M, I start to serve DURZ Week of 2010-03-22: D, K, E start to serve DURZ Week of 2010-04-12: B, H, C, G, F start to serve DURZ Week of 2010-05-03: J starts to serve DURZ 2010-07-01: Distribution of validatable, production, signed root zone; publication of root zone trust anchor. (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.)
Re: Cogent $1500 GigE
On 12/15/2009 09:53 PM, Seth Mattinen wrote: Babak Pasdar wrote: Dear List, I am getting a big push from Cogent on their full GigE for $1.50 per circuit. What are your experiences with Cogent in general? If on the fence, how would you use their service for this deal to make sense? $1.50 per meg. ;) I'd probably take it just because I could at that price. The downsides with Cogent is that they occasionally get into peering spats that might hurt you if you aren't multihomed, and no usable IPv6 (if that matters to you). I hadn't looked into it any further because I'm not located anywhere Cogent is to give it a serious look. ~Seth Hi Seth/List, Maybe I'm to harsh, but I just don't think of them as a full-transit. That makes it a lot easier to make a decision about adding them. We need atleast 2 full-transits and then possible add them to get the price down on a good part of the traffic. On the IPv6-side they have IPv6 in Amsterdam (where we are fairly close), but they don't even have full-transit in the 'normal' situation (think: HE). We do have peering with HE, so that's atleast something. But I don't yet know what else they are missing. That's how I see them. Have a nice day.
Need to contact someone with Verisign
Hi, Long story short I am a customer of 1and1.com for the domain adappsolutions.com, we moved our datacenter roughly 60-days ago and updated our records with 1and1. However it is now December 15th and when I go here, http://registrar.verisign-grs.com/cgi-bin/whois?whois_nic=ns2.adappsolutions.com&x=0&y=0&type=nameserver I see it pointing to the incorrect address, as well as ns1.adappsolutions.com I have updated all the records I can find on 1and1.com and still there does not seem to be a way for this update to occur? So if someone can contact me off list, so I can get this addressed ASAP that would be wonderful. Thanks, Sincerely, Scott M. Likens
ADMIN: List FAQ/Monthly Post.
This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information === About NANOG:http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP:http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: adm...@nanog.org Posting Policy == The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://spam-l.com/mailman/listinfo * Contacting People * http://puck.nether.net/netops/ * http://www.peeringdb.com * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555- but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact adm...@nanog.org Please also avoid = * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists = * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists === Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php
Re: DNS question, null MX records
On 12/15/09 8:06 AM, Andy Davidson wrote: Eric J Esslinger wrote: I have a domain that exists solely to cname A records to another domain's websites. [...] I found a reference to a null MX proposal, constructed so: example.comINMX 0 . [...] Question: Is this a valid dns construct or did the proposal die? It's "valid", but you will probably find people still try to spam to machines on the A records, and all of the other weird and wonderful things that spambots try to do to find a path that will deliver mail... SRV records documented the hostname "." as representing "no service". However, errors made by non-RFC-compliant clients still generate a fair amount of root traffic attempting to resolve A records for ".". The MX record never defined a hostname "." to mean "no service" so it would be unwise to expect email clients will interpret this as a special case meaning "no service" as well. One might instead consider using: example.com.IN MX 0 192.0.2.0 IN MX 10 192.0.2.1 ... IN MX 90 192.0.2.9 where 192.0.2.0/24 represents a TEST-NET block. This should ensure traffic will not hit the roots or your servers. Assuming a sender tries all of MX addresses listed, they may still attempt to resolve A records for example.com. This MX approach will affect those failing to validate email prior to acceptance, and, of course, spammers. -Doug
Re: Need to contact someone with Verisign
Hi, Thank you for everyone who responded, I have contacted someone and hope to have it resolved. Thanks again, Scott M. Likens
Re: DNS question, null MX records
In message <4b284376.3000...@mail-abuse.org>, Douglas Otis writes: > On 12/15/09 8:06 AM, Andy Davidson wrote: > > Eric J Esslinger wrote: > >> I have a domain that exists solely to cname A records to another domain's > websites. > > [...] > >> I found a reference to a null MX proposal, constructed so: > >> example.comINMX 0 . > > [...] > >> Question: Is this a valid dns construct or did the proposal die? > > > > It's "valid", but you will probably find people still try to spam to > > machines on the A records, and all of the other weird and wonderful things > > that spambots try to do to find a path that will deliver mail... > > SRV records documented the hostname "." as representing "no service". > However, errors made by non-RFC-compliant clients still generate a fair > amount of root traffic attempting to resolve A records for ".". The MX > record never defined a hostname "." to mean "no service" so it would be > unwise to expect email clients will interpret this as a special case > meaning "no service" as well. One might instead consider using: > > example.com. IN MX 0 192.0.2.0 > IN MX 10 192.0.2.1 > ... > IN MX 90 192.0.2.9 Which will expand to: example.com.IN MX 0 192.0.2.0.example.com. IN MX 10 192.0.2.1.example.com. IN MX 90 192.0.2.9.example.com. MX records DO NOT take IP addresses. > where 192.0.2.0/24 represents a TEST-NET block. > > This should ensure traffic will not hit the roots or your servers. > Assuming a sender tries all of MX addresses listed, they may still > attempt to resolve A records for example.com. This MX approach will > affect those failing to validate email prior to acceptance, and, of > course, spammers. > > -Doug -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS question, null MX records *summary of on list and off list replies*
On Tue, 15 Dec 2009 11:51:29 -0600, Eric J Esslinger wrote: > B. Set spf -all, for those who bother to check that to stop inbound > mail from your domain. You might as well also add a DKIM ADSP policy with "dkim=discardable". Similar to your SPF policy, it announces that no unsigned mail (or no mail at all in your case) should come from this domain. But DKIM does not suffer from the problems SPF causes with email forwarding (see recent NANOG thread on that topic). -Phil
Re: Arrogant RBL list maintainers
[ Note: you're not talking about the RBL. You're talking about a DNSBL or RHSBL, which are generic terms. The RBL is a specific DNSBL and, as far as I know, does not have a listing policy related to this discussion. ] On Wed, Dec 09, 2009 at 03:18:47PM +, Sven Olaf Kamphuis wrote: > because they just assume that working, rfc compliant, reverse dns that > just-so-happens to be automatically generated would indicate dynamic ip > space.. It has long since become a best practice in mail server operations to pre-emptively blacklist all such space on sight. This is common knowledge among everyone who's kept pace with the field, and is an entirely appropriate reaction to what's sometimes called "the rise of the zombies". Real mail servers have non-generic, matching forward and reverse DNS with real hostnames. The farther hostnames move from that, the more problems can be expected. Nobody particularly likes this, as the work necessary in compiling such lists is onerous. But it is one of the most effective (in terms of FP and FN rates as well as resource costs) anti-spam measures available. ---Rsk
Re: Arrogant RBL list maintainers
On 09/12/2009 15:18, Sven Olaf Kamphuis wrote: a84-22-xx-xx.cb3rob.net. as it's RFC complient and we cannot be fucked to haha. and what precisely did you expect? that's not really what most people would consider valid reverse dns for a mail relay. (operational practice often beats RFC where they exist, and more often than not fills in where they don't). personally, i'd recommend not being a dick and setting valid *meaningful* reverse dns for things relaying mail. (i also notice that in later replies you claim that they're breaking eu data laws, but you seem to have bleeted on enough about how you think data is something that should be in the public domain, so you can download movies, err i mean, be like totally free man.) adama.
Re: Arrogant RBL list maintainers
On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong wrote: > personally, i'd recommend not being a dick and setting valid *meaningful* > reverse dns for things relaying mail. Many sites don't use names that will necessarily be meaningful to an outsider. Sometimes the non-meaningful name is the actual hostname and the _only_ name that machine is known by, even if the name appears "generic" or contains an IP. Host naming is a matter of local network policy, and the RFCs that pertain to hostnames specify syntax requirements only. Some sites might want to avoid certain "meaningful" RDNS entries since spammers, hackers, and other abusive users that scan IP ranges can utilize the RDNS to facilitate their activities. All reverse DNS information is in the hands of the enemy. For example, when spammers' IP scanning efforts find that an IP address reverses to "mail.example.com" the spammer will know to try @example.come-mail addresses for their dictionary-based brute-force spamming. On the other hand, if the MTA's IP reverses to something like a152.x.example.net. As is common for many domains. Spammers coming in by scanning large ranges of IPs, have no pointer to report the mailserver they discovered is @example.com inbound (or outbound) mail. Since the RDNS domain is different, and in fact generic, which helps avoid assisting the spammer in identifying the IP as an inbound mail server. -- -J
Re: Arrogant RBL list maintainers
Security by obscurity, in this day and age? :) On Wed, Dec 16, 2009 at 11:42 AM, James Hess wrote: > As is common for many domains. > Spammers coming in by scanning large ranges of IPs, have no > pointer to report the mailserver they discovered is �...@example.com > inbound (or outbound) mail. > > Since the RDNS domain is different, and in fact generic, which helps > avoid assisting the spammer in identifying the IP as an inbound > mail server. -- Suresh Ramasubramanian (ops.li...@gmail.com)
