Re: [Declude.JunkMail] OT: DNS Failover advice
Forgot to add the most important part regarding Simple DNS. They have an add-on monitoring piece that will switch DNS records automatically, and this can be used to automatically switch over to the backup. Matt Matt wrote: Rob, As far as DNS goes, the best way to do this is to use Simple DNS Plus with a server in a second location. Simple DNS does full server replication instead of individual secondaries, and if you have a lot of domains, it is nice to just manage one installation. If you have a smaller number of zones, it is easy to just set up secondaries with any software. I don't generally recommend large DNS services because they have been attacked and brought down, and that would be a single point of failure even though the providers claim to be immune from such attacks. Look up the "Blue Security" for one such example. This attack also brought down some of Tucow's systems for over 12 hours, including their E-mail hosting/filtering service. My company just started with VMware's hosting provider program to provide legitimate hosting on VMware ESX (virtual servers). VMware is an enterprise solution unlike most of the others on the market, and they have a lot of very nice features and add-ons for fail-over and replication. If you have multiple servers that could be placed on a big VMware server, you could save a lot of money by going with this approach since the hardware costs are greatly reduced. Administration is also simplified, and restoration or moving of the guest operating systems is a breeze. VMware is the future. As far as regional redundancy goes, you would be best off by moving way outside of Chicago. You likely won't get much more in terms of redundancy by going to Milwaukee than you would by going to another colo in Chicago. You want to be on a different power grid, and you want to be on a completely separate provider's network. If something is big enough to affect all of Chicago, it is big enough to affect Milwakee too. If you are in need of some assistance, feel free to give me a call at (888) 862-9042 x3. My company does do colocation and many other custom solutions for those that prefer choosing experience, knowledge and capabilities over branding and value. In the very least, advice is always free, and it sounds like there are many avenues for you to explore. Matt Robert Grosshandler wrote: Gents and the occasional lady: You all are the smartest network folks I interact with. If you'd be so kind as to give me your opinion / suggestions on the following, I'd be forever grateful. We're trying to increase the level of uptime and redundancy for our service. To that end, we're looking to establish a hot failover site in a location remote from our current colocation facility. We're in Chicago, we're thinking a driveable city on a completely different grid (Milwaukee, probably.) If the entire Midwest gets nuked, nobody is going to be buying much online. We're looking at approaches to achieve that failover automatically. Our budget and technical expertise aren't large (we now can handle BGP internally if we have to, but we don't have any of the necessary infrastructure to do that, and would very much prefer not to invest in that infrastructure.) We rely on our colo facility to provide bandwidth, routing, internal DNS, etc. (they have great bandwidth, routing, seven providers, etc.) but since there are humans involved, they could screw up, too. We rely on Ultradns for external DNS. Once our users actually reach our firewall, we have great redundancy inside our rack. The most promising approach at this time seems to be to use somebody like ultradns or dnsmadeeasy to provide dns failover. That is, they're watching our site, and if we go down, they switch out A records and point traffic to the backup site. If it matters, we run ms sql, mirroring and log shipping. We'd have the mirror db and the witness in the remote location. Thanks for whatever thoughts you can add to this challenge. DNS failover a workable solution? We'll be looking for a colo facility in Milwaukee or Indianapolis with 4U available if somebody wants to point us there. Yours, Rob = www.iGive.com [EMAIL PROTECTED] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: DNS Failover advice
Rob, As far as DNS goes, the best way to do this is to use Simple DNS Plus with a server in a second location. Simple DNS does full server replication instead of individual secondaries, and if you have a lot of domains, it is nice to just manage one installation. If you have a smaller number of zones, it is easy to just set up secondaries with any software. I don't generally recommend large DNS services because they have been attacked and brought down, and that would be a single point of failure even though the providers claim to be immune from such attacks. Look up the "Blue Security" for one such example. This attack also brought down some of Tucow's systems for over 12 hours, including their E-mail hosting/filtering service. My company just started with VMware's hosting provider program to provide legitimate hosting on VMware ESX (virtual servers). VMware is an enterprise solution unlike most of the others on the market, and they have a lot of very nice features and add-ons for fail-over and replication. If you have multiple servers that could be placed on a big VMware server, you could save a lot of money by going with this approach since the hardware costs are greatly reduced. Administration is also simplified, and restoration or moving of the guest operating systems is a breeze. VMware is the future. As far as regional redundancy goes, you would be best off by moving way outside of Chicago. You likely won't get much more in terms of redundancy by going to Milwaukee than you would by going to another colo in Chicago. You want to be on a different power grid, and you want to be on a completely separate provider's network. If something is big enough to affect all of Chicago, it is big enough to affect Milwakee too. If you are in need of some assistance, feel free to give me a call at (888) 862-9042 x3. My company does do colocation and many other custom solutions for those that prefer choosing experience, knowledge and capabilities over branding and value. In the very least, advice is always free, and it sounds like there are many avenues for you to explore. Matt Robert Grosshandler wrote: Gents and the occasional lady: You all are the smartest network folks I interact with. If you'd be so kind as to give me your opinion / suggestions on the following, I'd be forever grateful. We're trying to increase the level of uptime and redundancy for our service. To that end, we're looking to establish a hot failover site in a location remote from our current colocation facility. We're in Chicago, we're thinking a driveable city on a completely different grid (Milwaukee, probably.) If the entire Midwest gets nuked, nobody is going to be buying much online. We're looking at approaches to achieve that failover automatically. Our budget and technical expertise aren't large (we now can handle BGP internally if we have to, but we don't have any of the necessary infrastructure to do that, and would very much prefer not to invest in that infrastructure.) We rely on our colo facility to provide bandwidth, routing, internal DNS, etc. (they have great bandwidth, routing, seven providers, etc.) but since there are humans involved, they could screw up, too. We rely on Ultradns for external DNS. Once our users actually reach our firewall, we have great redundancy inside our rack. The most promising approach at this time seems to be to use somebody like ultradns or dnsmadeeasy to provide dns failover. That is, they're watching our site, and if we go down, they switch out A records and point traffic to the backup site. If it matters, we run ms sql, mirroring and log shipping. We'd have the mirror db and the witness in the remote location. Thanks for whatever thoughts you can add to this challenge. DNS failover a workable solution? We'll be looking for a colo facility in Milwaukee or Indianapolis with 4U available if somebody wants to point us there. Yours, Rob = www.iGive.com [EMAIL PROTECTED] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] OT: DNS Failover advice
Gents and the occasional lady: You all are the smartest network folks I interact with. If you'd be so kind as to give me your opinion / suggestions on the following, I'd be forever grateful. We're trying to increase the level of uptime and redundancy for our service. To that end, we're looking to establish a hot failover site in a location remote from our current colocation facility. We're in Chicago, we're thinking a driveable city on a completely different grid (Milwaukee, probably.) If the entire Midwest gets nuked, nobody is going to be buying much online. We're looking at approaches to achieve that failover automatically. Our budget and technical expertise aren't large (we now can handle BGP internally if we have to, but we don't have any of the necessary infrastructure to do that, and would very much prefer not to invest in that infrastructure.) We rely on our colo facility to provide bandwidth, routing, internal DNS, etc. (they have great bandwidth, routing, seven providers, etc.) but since there are humans involved, they could screw up, too. We rely on Ultradns for external DNS. Once our users actually reach our firewall, we have great redundancy inside our rack. The most promising approach at this time seems to be to use somebody like ultradns or dnsmadeeasy to provide dns failover. That is, they're watching our site, and if we go down, they switch out A records and point traffic to the backup site. If it matters, we run ms sql, mirroring and log shipping. We'd have the mirror db and the witness in the remote location. Thanks for whatever thoughts you can add to this challenge. DNS failover a workable solution? We'll be looking for a colo facility in Milwaukee or Indianapolis with 4U available if somebody wants to point us there. Yours, Rob = www.iGive.com [EMAIL PROTECTED] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: Adding a non-authoritative DNS A record and associated PTR record
You seem to have failed to ask the actual question here. If you create the domain locally, you must create all records on the public domain for full DNS functionality to be maintained. Just creating one record will result in lookup failures for all other records on that domain. Matt Michael Hoyt wrote: Sorry for the off topic post but I know someone here will have a easy answer to this question. I currently host DNS records for our Active Directory domain on our domain controller (Win 2003 with local domain "COMMARTS.LAN") and want to create a local only NON-AUTHORITATIVE "A" and associated "PTR" record for image.commarts.com while the AUTHORITATIVE commarts.com DNS records are hosted by our ISP. I need to do this temporarily while we are developing the website and want the record to be available to my Active Directory members without having to mess with local hosts files. Thank you in advance, --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] OT: Adding a non-authoritative DNS A record and associated PTR record
Sorry for the off topic post but I know someone here will have a easy answer to this question. I currently host DNS records for our Active Directory domain on our domain controller (Win 2003 with local domain "COMMARTS.LAN") and want to create a local only NON-AUTHORITATIVE "A" and associated "PTR" record for image.commarts.com while the AUTHORITATIVE commarts.com DNS records are hosted by our ISP. I need to do this temporarily while we are developing the website and want the record to be available to my Active Directory members without having to mess with local hosts files. Thank you in advance, -- Michael Hoyt Communication Arts 110 Constitution Drive Menlo Park, CA 94025 (650) 326-6040 fax:(650) 326-1648 e-mail: [EMAIL PROTECTED] Web Site: http://www.commarts.com --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Outlook 'Blank Folding' Vulnerability
I agree with all your comments, but if so, I ask the team declude correct the Declude manual to reflect the truth. Now I read in the Declude manual that RFC does not allow such lines. It will be difficult to convince the Incredimail technical support to solve this problem if I can not find a section in RFC specifying that is not allowed. Thank you. Ruben Marti. Mon Mariola, S.L. - Original Message - From: Mike N. To: declude.junkmail@declude.com Sent: Monday, December 03, 2007 4:00 PM Subject: Re: [Declude.JunkMail] Outlook 'Blank Folding' Vulnerability The 'Blank Folding' vulnerability may be allowed by the RFC, but that doesn't make them the right thing to do. The problem is that virus scanners don't scan for attachments that could be embedded into the headers in one of these lines but Outlook would still execute them.Just because no virus has used this technique yet is not a good reason to continue to leave the door open. - Original Message - From: "Mon Mariola - Rubén" <[EMAIL PROTECTED]> To: Sent: Monday, December 03, 2007 9:40 AM Subject: Re: [Declude.JunkMail] Outlook 'Blank Folding' Vulnerability Maybe I explained poorly. I want to send the request to Incredimail technical support. My doubt is that the Declude manual says that according to section 3.2.3 of RFC822, it is not valid to have such lines, and I not located in RFC822 that section. http://www.faqs.org/rfcs/rfc822.html After reading the RFC 822, I see that the process "unfolding" allows these lines, but I do not see where specifies that are invalid. I need this information for the technical support Incredimail correct this problem. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Outlook 'Blank Folding' Vulnerability
The 'Blank Folding' vulnerability may be allowed by the RFC, but that doesn't make them the right thing to do. The problem is that virus scanners don't scan for attachments that could be embedded into the headers in one of these lines but Outlook would still execute them.Just because no virus has used this technique yet is not a good reason to continue to leave the door open. - Original Message - From: "Mon Mariola - Rubén" <[EMAIL PROTECTED]> To: Sent: Monday, December 03, 2007 9:40 AM Subject: Re: [Declude.JunkMail] Outlook 'Blank Folding' Vulnerability Maybe I explained poorly. I want to send the request to Incredimail technical support. My doubt is that the Declude manual says that according to section 3.2.3 of RFC822, it is not valid to have such lines, and I not located in RFC822 that section. http://www.faqs.org/rfcs/rfc822.html After reading the RFC 822, I see that the process "unfolding" allows these lines, but I do not see where specifies that are invalid. I need this information for the technical support Incredimail correct this problem. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Outlook 'Blank Folding' Vulnerability
Maybe I explained poorly. I want to send the request to Incredimail technical support. My doubt is that the Declude manual says that according to section 3.2.3 of RFC822, it is not valid to have such lines, and I not located in RFC822 that section. http://www.faqs.org/rfcs/rfc822.html After reading the RFC 822, I see that the process "unfolding" allows these lines, but I do not see where specifies that are invalid. I need this information for the technical support Incredimail correct this problem. Thank you. Ruben Marti. Mon Mariola, S.L. - Original Message - From: Dean Lawrence To: declude.junkmail@declude.com Sent: Monday, December 03, 2007 2:53 PM Subject: Re: [Declude.JunkMail] Outlook 'Blank Folding' Vulnerability Wouldn't you want to send the support request to the developers of incredimail? They are the ones who are generating the invalid header. Declude is only warning you about it. Dean On Dec 3, 2007 7:47 AM, Mon Mariola - Rubén <[EMAIL PROTECTED]> wrote: The program "incredimail" generates subjects, in certain cases, ended with "0D 0A 09 0D 0A." These messages are captured by Declude virus like "Outlook 'Blank Folding' Vulnerability". I want to send a letter requesting to technical support solve this problem, but I really do not see the point 3.2.3 in RFC 822 indicating that this is not allowed. Thank you. Ruben Marti. Mon Mariola, S.L. From Declude manual: Outlook 'Blank Folding' Vulnerability: This vulnerability occurs when there is a line in the headers with just a single space or a single tab character. Outlook can treat this as the end of the headers, allowing it to see a virus that is embedded in the headers. RFC822 3.2.3 says that it is not valid to have such lines, nor is there any legitimate reason for an E-mail to contain a blank line in the headers with a single space or tab (note that it is OK to have a line with a single space or tab in the E-mail body, just not the headers). --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Outlook 'Blank Folding' Vulnerability
Wouldn't you want to send the support request to the developers of incredimail? They are the ones who are generating the invalid header. Declude is only warning you about it. Dean On Dec 3, 2007 7:47 AM, Mon Mariola - Rubén <[EMAIL PROTECTED]> wrote: > The program "incredimail" generates subjects, in certain cases, ended with > "0D 0A 09 0D 0A." These messages are captured by Declude virus like "Outlook > 'Blank Folding' Vulnerability". I want to send a letter requesting to > technical support solve this problem, but I really do not see the point > 3.2.3 in RFC 822 indicating that this is not allowed. > > Thank you. > Ruben Marti. > Mon Mariola, S.L. > > From Declude manual: > > Outlook 'Blank Folding' Vulnerability: This vulnerability occurs when there > is a line in the headers with just a single space or a single tab character. > Outlook can treat this as the end of the headers, allowing it to see a virus > that is embedded in the headers. RFC822 3.2.3 says that it is not valid to > have such lines, nor is there any legitimate reason for an E-mail to contain > a blank line in the headers with a single space or tab (note that it is OK > to have a line with a single space or tab in the E-mail body, just not the > headers). > > > > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be found > at http://www.mail-archive.com. > > -- __ Dean Lawrence, CIO/Partner Internet Data Technology 888.GET.IDT1 ext. 701 * fax: 888.438.4381 http://www.idatatech.com/ Corporate Internet Development and Marketing Specialists --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
