Today we are introducing Amazon Route 53, a programmable Domain Name Service. You can now create, modify, and delete DNS zone files for any domain that you own. You can do all of this under full program control—you can easily add and modify DNS entries in response to changing circumstances. For example, you could create a new sub-domain for each new customer of a Software as a Service (SaaS) application. DNS queries for information within your domains will be routed to a global network of 16 edge locations tuned for high availability and high performance.

Route 53 introduces a new concept called a Hosted Zone. A Hosted Zone is equivalent to a DNS zone file. It begins with the customary SOA (Start of Authority) record and can contain other records such as A (IPV4 address), AAAA (IPV6 address), CNAME (canonical name), MX (mail exchanger), NS (name server), and SPF (Sender Policy Framework). You have full control over the set of records in each Hosted Zone.

You start out by creating a new Hosted Zone for a domain. The new zone will contain one SOA record and four NS records. Then you can post batches of changes (additions, deletions, and alterations) to the Hosted Zone. You'll get back a change id for each batch. You can poll Route 53 to verify that the changes in the batch (as identified by the change id) have been propagated to all of the name servers (this typically takes place within 60 seconds).

The zone's status will change from PENDING to INSYNC when all of the changes have been propagated. You can update your domain registration with the new nameservers at this point. Our Route 53 Getting Started Guide contains a complete guide to getting started with a new Hosted Zone.

Each record in a Hosted Zone can refer to AWS or non-AWS resources as desired. This means that you can use Route 53 to provide DNS services for any desired combination of traditional and cloud-based resources, and that you can switch back and forth quickly and easily.

You can access Route 53 using a small set of REST APIs. Toolkit and AWS Management Console support is on the drawing board, as is support for the so-called "Zone Apex" issue.

Route 53 will cost you $1 per month per Hosted Zone, $0.50 per million queries for the first billion queries per month, and $0.25 per million queries after that.  Most sites typically see an order of magnitude fewer DNS queries than page views. If your site gets one million page views per month, it would be reasonable to expect about 100,000 DNS queries per month. In other words, one billion queries is a lot of queries and many sites won’t come anywhere near this number. The results of a DNS query are cached by clients. You could set a high TTL (Time to Live) on the records in your Hosted Zone in order to reduce the number of queries and the cost.

Route 53 supports up to 100 Hosted Zones per AWS account. If you need more, simply contact us and we'll be happy to help.

The Route 53 / CloudFront team has openings for several software developers and a senior development manager.

-- Jeff;

Today we are introducing Amazon Route 53, a programmable Domain Name Service. You can now create, modify, and delete DNS zone files for any domain that you own. You can do all of this under full program control—you can easily add and modify DNS entries in response to changing circumstances. For example, you could create a new sub-domain for each new customer of a Software as a Service (SaaS) application. DNS queries for information within your domains will be routed to a global network of 16 edge locations tuned for high availability and high performance.

Route 53 introduces a new concept called a Hosted Zone. A Hosted Zone is equivalent to a DNS zone file. It begins with the customary SOA (Start of Authority) record and can contain other records such as A (IPV4 address), AAAA (IPV6 address), CNAME (canonical name), MX (mail exchanger), NS (name server), and SPF (Sender Policy Framework). You have full control over the set of records in each Hosted Zone.

You start out by creating a new Hosted Zone for a domain. The new zone will contain one SOA record and four NS records. Then you can post batches of changes (additions, deletions, and alterations) to the Hosted Zone. You'll get back a change id for each batch. You can poll Route 53 to verify that the changes in the batch (as identified by the change id) have been propagated to all of the name servers (this typically takes place within 60 seconds).

The zone's status will change from PENDING to INSYNC when all of the changes have been propagated. You can update your domain registration with the new nameservers at this point. Our Route 53 Getting Started Guide contains a complete guide to getting started with a new Hosted Zone.

Each record in a Hosted Zone can refer to AWS or non-AWS resources as desired. This means that you can use Route 53 to provide DNS services for any desired combination of traditional and cloud-based resources, and that you can switch back and forth quickly and easily.

You can access Route 53 using a small set of REST APIs. Toolkit and AWS Management Console support is on the drawing board, as is support for the so-called "Zone Apex" issue.

Route 53 will cost you $1 per month per Hosted Zone, $0.50 per million queries for the first billion queries per month, and $0.25 per million queries after that.  Most sites typically see an order of magnitude fewer DNS queries than page views. If your site gets one million page views per month, it would be reasonable to expect about 100,000 DNS queries per month. In other words, one billion queries is a lot of queries and many sites won’t come anywhere near this number. The results of a DNS query are cached by clients. You could set a high TTL (Time to Live) on the records in your Hosted Zone in order to reduce the number of queries and the cost.

Route 53 supports up to 100 Hosted Zones per AWS account. If you need more, simply contact us and we'll be happy to help.

The Route 53 / CloudFront team has openings for several software developers and a senior development manager.

-- Jeff;

The reason it didn’t work is that Google introduced it’s own OpenID discovery protocol as they faced challenges not addressed by the current version (2.0) of the OpenID standard. And this means such OpenIDs are not recognized by current OpenID libraries. For this reason, Google provides with php-openid-apps-discovery an add-on to the PHP OpenID library.

I integrated this add-on into the OpenID component as an optional feature. You have to enable it with:

public $components = array('Openid' => array('accept_google_apps' => true));

I made it an optional feature because it introduces an additional step to the authentication process: the provided OpenID url is sent to Google to figure out whether it is a Google Apps OpenID. And this makes the authentication process a bit slower. Hence I think you should have a choice whether you want to use this feature.

The new version of the OpenID component doesn’t contain any other new features/bugfixes.

You can download the component from Github.

Enjoy!

For end users, NeoSphere turns a single laptop or desktop into a multi OS machine. Users can seamlessly move between environments without any degradation in performance or user experience. For instance, if a user has a touch screen monitor on their physical machine, it will operate with native performance within NeoSphere. In addition, NeoSphere delivers the broadest client hardware support in the industry. As a result, IT addresses end user needs with greater ease.

http://www.neocleus.com