January 2016 Summaries

On January 26th at 10am PT/1pm ET, CloudFlare is hosting a live discussion with experts Martin Woods, Reza Moaiandin, and Patrick Stox to share advanced technical SEO hacks for improving search rankings. Topics covered will include on-page code excellency, semantic markup, web server optimization with GZIP and HTTP/2, web content optimization, and site security with malware and DDoS prevention. Additionally, Reza and Martin from SALT.agency are offering a free 30-minute technical SEO consult to the first 50 people who sign up here and attend the live webinar event on January 26th at 10am PT.

CloudFlare has expanded its network by opening new data centers in Oslo, Norway (#75) and Minneapolis, Minnesota (#76). The Oslo data center is strategically placed to serve the Norwegian population with a high internet penetration rate of 95.05%. It also marks CloudFlare's northernmost data center on its network map. In Minneapolis, the company aims to provide excellent coverage for the Midwest region through participation in the local peering point, MICE. Both locations have historical ties with the development of internet technology and are expected to contribute significantly to CloudFlare's expansion plans.

A group of researchers has discovered an attack called "Forwarding Loop Attacks in the Content Delivery Networks" that can force multiple service providers to send each other an unending stream of requests in a loop, resulting in resource exhaustion and denial of service at the service provider. The attack is practical and can be performed using a large list of service providers. To prevent such attacks, all proxy services need to conform to HTTP 1.1 standards, which include the "Via" header for preventing request loops. However, some reverse proxy services allow customers to strip or modify headers, including the Via header, leading to potential vulnerabilities. CloudFlare has implemented protections against this attack and encourages other service providers to do the same by not allowing customers to remove or modify Via headers for requests to their site, appending an RFC 7230-compliant Via header when proxying traffic, and returning an appropriate error if a request comes in with its own Via header.

Cloudflare and Women Who Go are partnering to host the first distributed Go(lang) hackathon, Gopher Gala, in San Francisco. The event will take place on January 23rd and 24th from 9am-5pm at Cloudflare's headquarters. Participants can sign up through Meetup.com and are encouraged to use the provided office space for collaboration. Food and drinks will be available throughout the weekend, with some of Cloudflare's top Go developers participating as well.

The Go test coverage implementation is innovative as it allows setting a bit in a coverage bitmap when each code portion is executed. However, there's no straightforward way to obtain coverage data for tests run against the main version of a program. A workaround involves creating a dummy test that executes main(), compiling a binary with go test -c -cover and running only that test instead of the regular binary. This method has been used in RRDNS, a custom Go DNS server. To collect coverage information, run the test battery as usual and use gocovmerge to merge coverage profiles for unit tests.

Internet Exchange Points (IXPs) are facilities where networks meet and participate in peering, which interconnects various parts of the global internet. Peering has become a core requirement for the global internet, with around 54,000 unique Autonomous Networks making up the global internet, nearly 6,000 of those networks participating in the peering ecosystem. Cloudflare operates over 75 points of presence (PoPs) globally and almost all are located close to where a local Internet Exchange exists. By connecting to the local IXP (or multiple local IXPs), they provide their customers an unprecedented level of web and DNS service delivery. Peering at IXPs helps improve performance, redundancy, and counteracting DDoS attacks by removing intermediary networks that are in the path of a DDoS attack.

The blog discusses the use of DNSSEC in managing public keys for SSH access. With OpenSSH version 6.2 and later, remote hosts can retrieve public keys in a customized way instead of relying on the authorized_keys file in the ~/.ssh/ directory. This feature allows users to store their public keys in DNS records, which can be verified using DNSSEC. The author demonstrates how to use this method by storing Alice and Bob's respective public keys as TXT records in a domain example.com. They also provide instructions on configuring the SSH server to retrieve these keys from DNS records securely.