The Byte Stops Here

I watched two Git preso over the last week by CF folks. They both tried really hard to make Git sound better than SVN, and easier to use.

But looking at their preso, if I was a newbie to source code management, I'd be scared. All that Git bash stuff is a nightmare!

Git isn't perfect, nor is it well suited for web development. But it also doesn't need to be scary.

As a long time SVN (and previously CVS) user, I moved to Git for all development earlier this year, but this was after watching preso and researching Git for years! And I found one common thread, it does better merging, but it can also be scary. Why? There aren't any good tools!

Earlier this year, the great folks at syntevo GmbH launched SmartGit, and it made Git sooooo much easier to use and manage. This is what made the switch from SVN (for which they have a killer tool called SmartSVN) so much easier, and really did it for me.

Maybe someday someone will create a version control tools best suited for web development, without the confusing terminology that Git and SVN has, but for now, we've found a great combo that works.

Each developer has his own branch in which he works, then we have a dev branch, a staging branch, a UAT branch, and a prod/master branch. Developers commit code in their branch on a daily basis. When they feel ready they merge in (which is very easy with SmartGit) their changes to the Dev branch. As other developers have also been committing code to the dev branch, they also merge out their changes from dev back into their branch, so that they have the latest changes. The dev branch is where intergrations testing can occur, all developers code meets up, and we do our own testing on the dev box. Once we're good, we merge from dev to stage, where QA does their testing on the staging server. And then when tickets are passed, then we merge from stage to UAT, which is on the same environment externally as prod. If we need to show off any code to customers early, we can do that here, and we also make sure the code runs OK in prod. And finally, when code has passed UAT testing, then we merge to MASTER, and push the update to the servers on the next launch. Works well for us.

Developers may also create their own experimental branches on the fly. I have one right now for testing our move from Verity to Solr, for example.

The only problem with this model is that you have to be careful when pushing up, as you can push up code that hasn't been fully passed. So you can cherry pick commits, or just be careful. This is where the "art" of source control comes in, there is no exact science, its all what works best for your team.

My greatest wish for source control would be if you could tag a commit as being at a specific level only. So if you commit code, and say this is, for example, "dev" only, any merge from dev to stage would ignore that code, until the ticket associated with that code passes on dev, and then it'll move up. This would make merges soooo much easier, and you could be sure your code will never make it to prod unless its passed at that level by QA. Anyways, wishful thinking.

Oh, and Git integration into Eclipse is half-baked, so much so its useless for me. I always have SmartGit and CFBuilder open side by side. Good thing is that SmartGit runs on most platforms!

Hot news! Chipmaker's formal foray into Enterprise software.

Read more @ http://finance.yahoo.com/news/Intel-buying-McAfee-in-push-apf-2695002564.html?x=0.

Today, I received a letter from the President of DNSMadeEasy. I use their service, and have found it to be very powerful and far cheaper than their competitors. At first I was shocked to read they suffered a DDOS attack of the scale of 50GB/s. They have an illustrious 8 year 100% uptime that is now marred. However the letter I got was so refreshing and honest, I was amazed. See below (if this sort of thing interests you!).

*****

Dear DNS Made Easy Client,

On August 07, 2010 DNS Made Easy was the target of a large multi Gb/s attack against all of our name servers.   The attack started at 8:00 UTC and was fully mitigated by 14:00 UTC.  During this time period there were regional outages from some or all of our name servers.  Regional outages means that certain regions of the world were not able to resolve your DNS and other regions of the world were resolving normally.  When all name servers were not reachable a DNS query would have been lost, when some name servers were not reachable then DNS performance would have been slower than normal but still operational.

The regional downtime was in very small periods but it still did affect the overall resolution for all of our client's DNS.  It is for this reason that we are explaining the situation in full to all of our clients now.


1) How long were the DNS outages?
In some regions there were no issues, in other regions  outages lasted a few minutes, while in other regions there were sporadic (up and down) outages for a couple of hours.  In Europe for instance there was never any downtime.  In Asia downtime continued longer than other regions. In United States the west coast was hit much harder and experienced issues longer than the central and east coast.


2) Many clients have asked us if in fact there was downtime since they did not notice issues.
Many clients did not notice any DNS downtime.   In fact many clients would not have noticed this issue if we had not sent this email.  But we feel disclosure of this issue is something that we owe our client base. 
If you want to see if there is a significant loss of DNS queries you can quickly compare your daily queries from this Saturday to last Saturday in the DNS Made Easy control panel.  Overall query statistics comparing this Saturday's query load (minus attack traffic) to recent Saturdays' query loads shows that our servers properly responded to a query total this Saturday within a 2% difference from recent Saturdays.


3) Where did the attack come from?
We believe that the DDoS came from a botnet attack originating from Asia.  Most attack traffic originated in or transited through China.  The source IPs appear to be mostly spoofed but the vast majority are assigned by APNIC to Chinese Networks and Chinese ISPs.  Traffic levels reported to us by our bandwidth providers regarding their connections through which this traffic entered their networks also points to origins in Asia.


4) How large of an attack was this?
This attack hit levels that were so high that our Tier1 upstreams were suffering latency and network issues for other clients at many of their locations due to this attack.  This caused some of our Tier1 bandwidth providers to use their last resort response of null routing traffic to some of our IPs from some networks to prevent major service degradation to their core networks. 
Measuring the exact size of this attack is rather difficult.  However, discussions with our Tier1 bandwidth providers during the attack led to an estimate of 50 Gb/s in size.  This was based on reports of multiple 10Gb/s lines being saturated at multiple different providers in different geographic regions.
During our after-action discussions internally and with our providers after the attack was mitigated we analyzed all information available to us through monitoring systems and traffic reports and we revised our estimate of the attack size to be fluctuating between 20Gb/s and 40Gb/s during the attack.  We will never know the true size of this attack as we actively moved traffic around to different locations throughout the attack and IPs were temporarily null routed into and through various networks, and some traffic was blocked from provider to provider in response to the attack.
We do know that due to the service implication to the Tier1 providers, networking teams from China Netcom, China Telecom,  Level3, GlobalCrossing, Tiscali, and Arbinet were involved to stop the attacks.  Level3 and Arbinet both played special heroic roles in facilitating that the correct people were involved from all networks to make sure that the attack was stopped as quickly as possible.


5) How was this attack stopped?
Fighting attacks of this magnitude is very complex and a full answer involves much information that we do not want these criminals to know.  What we can say is that that we used a combination of routing techniques, DDoS mitigation tools, customized firewalls, and high level inter-provider negotiations.
China Netcom and China Telecom had to null route the name servers from their networks in order for the attack to not impact other traffic they had going to the United States. 


6) Will an SLA credit be issued?
Yes it will be.  With thousands paying companies we obviously do not want every organization to submit an SLA form.  Even though not all clients noticed the attack, we plan on issuing an SLA to every single paying DNS account.
You will be receiving an email about the SLA credit to your account in the next few days. 


7) Does this affect your 100% uptime history?
Yes, any service outage would result in loss of uptime.  We had a history leading uptime of over 8 years of 100% uptime.  With a calculated two hour outage (which is probably longer than we were actually down for anyone) this DDOS attack put our overall uptime history at a calculated 99.9999%.  This is still an excellent uptime history.


8) What would it take to get your 100% uptime history back?
That is mathematically impossible.  But we can work on increasing our 99.9999% uptime history and we will work hard on building another run of more than 8 years of 100% uptime.  We are confident that we can do it and we look forward to the challenge.


9) Would another DNS provider have been able to stop this attack?
We are sure that our competitors will claim that the answer is yes.  In fact we have been called by several of our competitors with very amusing phone calls during and after the attack asking us to update our website to say that we no longer have a 100% uptime history (which we have started and will complete soon).  This was a very large attack, so we do not believe that other DNS services could have stopped it either.  If any of our customers are considering leaving our services based on this issue, then we would recommend highly that you request a detailed report for how any new potential DNS provider would deal with an attack of this magnitude.  Please note that this was our first issue of downtime over our 8+ years of providing enterprise managed DNS services.


10) What is the next step?
At this time all DNS resolution is functioning as intended from all of our global locations.
In our 8+ year history, we have had numerous attacks against our services.  Historically we have been able to mitigate these attacks without any service degradation. One thing we have always taken away from every attack is a deeper understanding of what we need to do to make our network and services stronger and more reliable.
This DDoS attack against us was different from others in that the size was massive enough that our standard mitigation strategies were not sufficient to prevent several network nodes from being flooded.  We now have a deeper understanding of what happened during the attack and have started planning network upgrades and mitigation strategies to help fight these criminals in the future.  It is, and always has been, our commitment to make the DNS Made Easy network the strongest and most reliable DNS network in the world.


11) Can I pay more for a higher level of service with DNS Made Easy?
We believe that we provide more service per dollar than any competitor in the DNS industry.  This is why we have the best ROI in the industry.  We do not do this by cutting networking cost.   As many of you aware DNS Made Easy feels we can cut costs by eliminating a lot of the sales (including commissions), presales, and unnecessary marketing expenditures.
Everyone at DNS Made Easy feels that our network is as strong as or stronger than any competitor in the United States and Europe and you can verify this with speed tests and our highest industry uptime.   As all DNS Made Easy customers know, as our customer base grows, so does our network.  This is how we can continually keep adding to our network and always remain a fraction of the price of our competition.
You will hear more from our network team as we plan on adding additional precautions to keep everything running smoothly during attacks in the future.


One thing that I want to say is that we sincerely apologize that this happened to your DNS service.  We understand that hundreds of thousands of domains rely on our DNS services each day to keep their businesses running smoothly.  This is not something that we treat lightly and this is not something that we are going to just let slip away.  We have already started to plan on building a network to focus on preventing attacks like this from causing any service disruption in the future.
Everyone here at DNS Made Easy would like to thank you for your continued loyalty and kind words during this time.  We can easily say the DNS Made Easy customers are the best in the business.

Question, comments, concerns?

Please let us know.  I personally will be answering as many tickets and questions as possible in the following weeks.  Our full DNS Made Easy staff is dedicated to answering your questions and easing any concerns that you have.

Regards,
-Steven Job
President and Founder of DNS Made Easy

In the CF 9.0.1 list of What's New and Changed, the last item listed in the "other enhancements" area is a small note that "CFID, CFTOKEN, and jsessionid are marked httpOnly". This is a small but significant step in the right direction.

What is httpOnly mean? Well, the OWASP website has a nice explanation. Basically it means: "If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party."

In plain english, I think it means these cookies are basically read-only, meaning you can't write something in the browser to manipulate them. The big caveat being that the browser must support the optional flag to have this functionality.

Lots of people have started posting wish lists for enhancements to CF10. Read more on Pete Freitag's blog and Jason Dean's as well.

The new release includes (among other things):

• ORM support for multiple data sources
• Amazon S3 support
• Support for IIS 7
• New script functions implemented as CFCs
• Support for BlazeDS 4 and LCDS 3
• Configurable seed for password encryption 
• Server monitoring enhancements to handle load conditions

It is also noted: "In addition, there are some enhancements related to Language, Caching, Ajax, SpreadSheet, Solr, and Logging and scores of bug fixes."

Read more @ http://kb2.adobe.com/cps/847/cpsid_84723.html.

Download files @ http://www.adobe.com/support/coldfusion/downloads_updates.html#cf9.