VeriSign Inc. has just launched its newest cloud computing service designed to ease the implementation of Domain Name System Security Extensions (DNSSEC). Bizjournals states that the DNSSEC provides an additional layer of security to all users of the internet by protecting against cache websites and "man-in-the-middle" attacks. These attacks occur when forged data is used to redirect users to fraudulent websites and unintended addresses.
The VeriSign DNSSEC Signing Service will allow companies to incorporate signing and provisioning into their databases while reducing costs, according to Bizjournals. This service is designed specifically for registrars who provide DNS hosting and management services for their registrants without the additional complexity of signing and managing the keys associated with DNSSEC.
Source: VeriSign Launches Cloud Security Service, Retrieved on December 6, 2010, from bbb.org/us/post/verisign-launches-cloud-security-service--8435
Share
Monday, December 6, 2010
VeriSign Launches Cloud Security Service
Wednesday, November 10, 2010
Kaminsky To Release 'Phreebird' For Easy DNSSEC
Free toolkit lets organizations, developers test-drive new DNS security protocol
Renowned researcher Dan Kaminsky tomorrow at Black Hat Abu Dhabi will release a free toolkit that lets organizations test-drive DNSSEC deployment and also demonstrates his claims that the protocol is simple to implement.
"I've been making a lot of claims and promises about what DNSSEC is capable of and why the security industry should care. This is the argument I've been putting forth, in code form. This is for real," says Kaminsky, who will make the Phreebird Suite 1.0 kit available tomorrow on the Black Hat website. Kaminsky gave a sneak peek demonstration of Phreebird at Black Hat USA in July.
Phreebird Suite 1.0 is a real-time DNSSEC proxy that sits in front of a DNS server and digitally signs its responses. "This is a collection of technologies [that show how] DNSSEC can be very easily deployed on the server side and trivially on client side," he says. The code is not for operational use, he says, but for testing out the technology.
"This code is cool. It makes DNSSEC easy to achieve," Kaminsky says. "It makes it easy to take your existing DNS deployment and supplement it with DNSSEC services."
The goal is to show how DNSSEC could be used to "bootstrap" trust -- a.k.a. authentication -- across organizations, he says, authenticating clients, business partners, customers, contractors, and other groups with one another. DNSSEC has been in the works for nearly two decades: It was finally fully deployed in the root this summer and so far has been implemented in the .gov, .net, .edu, and .org. domains. The .com domain will be signed by DNSSEC in March. The protocol is considered the key to preventing attacks exploiting the now-infamous cache-poisoning vulnerability Kaminsky revealed at Black Hat USA in 2008.
Kaminsky hopes to dispel concerns that DNSSEC will be complex, disruptive, and expensive to deploy in organizations. "Application developers don't want to be cryptography experts," Kaminsky says. "They just want the key ... and to move on."
Phreebird automatically generates keys and provides real-time signing. There is "zero configuration" on the server side with the tool. "There is enough context in the DNS reply to figure out all of the necessary settings for how to sign it. You don't have to have a huge amount of preconfiguration. This is a revolution here," Kaminsky says.
The tool requires using GoDaddy for creating a test .org domain, and in the end it takes about 30 seconds to get valid, signed records via the Internet, according to Kaminsky.
On the client side, Phreebird includes Phreeload, a tool that adds DNSSEC support to OpenSSL applications and sits at the authentication layer. DNSSEC can be used in lieu of of X.509 certificates: Phreebird's Phreeload tool basically provides authentication without certificates, using DNSSEC instead. "At present, it's surprisingly difficult and expensive to validate key material via X509 and CAs [certificate authorities]. I'm demonstrating how to make it easy and inexpensive to validate the same material using DNSSEC," Kaminsky says.
Kaminsky is also working on a Phreebird tool that lets email systems use DNSSEC for authenticating correspondents. "When my mom receives an email from the bank, she should know it's from the bank," he says.
Meanwhile, Kaminsky is urging fellow researchers to hack at Phreebird to look for vulnerabilities. He's hoping to get up-front input on any major vulnerabilities.
Source: Kelly Jackson Higgins, DarkReading, Retrieved on November 10, 2010 from darkreading.com/authentication/security/app-security/showArticle.jhtml?articleID=228200646&cid=RSSfeed_DR_News
Share
Tuesday, November 9, 2010
Observers recommend broader role for government in cybersecurity
FCC is now identifying the five most critical threats to the Internet, as well as a plan to address such risks in accordance with the Obama administration's National Broadband Plan, a roadmap for attaining ubiquitous, affordable high-speed Internet access. To assess the threat landscape, the agency on Friday sought the input of about 10 security officials who work for Internet service providers, research institutions and the government.
The most vocal participants said the mercurial nature of attacks makes it nearly impossible to devise defensive procedures or rely on computer users to ensure that viruses don't spread. The most effective role for the government is preparing for the unknown, they said.
October marked the government's annual cybersecurity awareness month. This year's theme was the notion that cybersecurity is a shared responsibility among the government, network services providers and Web surfers.
But James Lewis, a senior fellow at the Center for Strategic and International Studies, a Washington think tank, said educating end users will not protect the Internet.
"I've kind of given up on the end points. We had National Cybersecurity Awareness month last month. A complete waste of time," he said. "We're never going to get the end, the edge, to be safe. It's never going to happen."
Instead, the government should concentrate on which agency or combination of agencies, such as FCC and the Homeland Security Department, should coordinate with ISPs, Lewis said. They should cooperate to ensure that customers, including federal workers, are supplied almost automatically with the best defenses against malevolent intruders.
An example of the need for such proactive tactics is the shift from attacks against networks to botnets. Botnets -- organized by cybercriminals -- invisibly hijack multiple Internet users' computers or mobile devices to spread content that steals personal information through the users' communications with others.
"We've seen less attacks on the Internet, or at us, and more using us to go after financial gain," said Ed Amoroso, senior vice president and chief security officer for AT&T. "The threat that seemed so real two or three years ago around attacks at infrastructure really in two years has changed."
Studying past attacks to defend against future threats, therefore, may not be productive, he added. "It's hard to lay out a concrete set of best practices and follow it because what we do is so fluid that we have to be willing to take the playbook and throw it out and start a new one the next week or the next month, depending on what the threat is." Amoroso said that today he is obsessed with how botnets are affecting his customers but tomorrow he could be worried about vulnerabilities with different risks and fixes.
A more effective approach for protecting government and private sector computers would be practicing solutions to worst-case scenarios, the panelists said. "Have you had a day yet where you came in and you had a directive at work, where it said: 'Don't turn on your Blackberry . . . It's probably infected. If you do, all this awful stuff is going to happen,' " Amoroso said. "And you would go, 'Ok, what do I do?' "
The government has not discussed those sorts of situations, he said. "I think this idea of preparing for a battle that we can't define today is the way we need to start to operate," Amoroso said.
But other participants said there are some strategies to reduce risks that government and industry should immediately carry out.
"It's true that this problem is not going to go away. That doesn't mean we give up on trying to solve it," said Ari Schwartz, senior Internet policy adviser at the National Institute of Standards and Technology. He likened the situation to fighting fires. "We're never going to have an end to all fire accidents. But we can come up with different standards, different technologies, different policies that help us mitigate them," such as building codes and smoke alarms, Schwartz said.
Many preventive measures are expensive for ISPs to deploy across the country. That's where the government can step in to help, even without subsidies, which the industry generally opposes, panelists noted.
The federal government -- the largest U.S. consumer -- can wield its purchasing power to require that ISPs include security enhancements in all federal contracts. Such technologies include the Domain Name System Security Extensions (DNSSEC) protocol, a set of standards for identifying server addresses that ensures that when computers and mobile devices talk to each other, hackers can't misdirect their communications to fake websites.
If agencies bought only products that support DNSSEC, that would help the Web industry afford to develop the same protections for all products and services nationwide, said Andy Ellis, senior director of information security and chief security architect for Akamai, a content delivery company.
"That's not a subsidy. That's the government as a consumer, saying, 'We feel that level of security is important for us and therefore we'll pay for it,' "Ellis said. "When the government decides to do that, people will build it. And once you've built a technology, you're really happy to go sell it to everybody else."
Source: Observers recommend broader role for government in cybersecurity, Aliya Sternstein, NextGov, Retrieved on November 9, 2010 from nextgov.com/nextgov/ng_20101108_4659.php?oref=topnews
Share
Monday, October 18, 2010
Comcast begins DNS security rollout
First in U.S. to protect customers against Kaminsky-style cache poisoning attacks
Comcast has begun migrating its customers to a new Internet security mechanism that will help protect them from being inadvertently routed to phony Web pages for pharming attacks, identity theft and other scams.
Comcast is the first major ISP in the United States to adopt the new mechanism, which is known as DNS Security Extensions (DNSSEC).
Source: Carolyn Duffy, Marsan, Network World, Retreived on October 18, 2010 from networkworld.com/news/2010/101810-comcast-dns-security.html?hpg1=bn
Share
Wednesday, October 13, 2010
Afilias Secures Latin American and Caribbean Countries of Antigua, Barbuda, Belize, Honduras, St. Lucia and St. Vicent and the Grenadines with Deployment of DNSSEC
Afilias, a global provider of Internet infrastructure services, today announced that it has enabled Domain Name System Security Extensions (DNSSEC) for five country code Top-Level-Domains (ccTLDs) in Latin America and the Caribbean region. The ccTLDs whose zones have been secured by DNSSEC include: .AG (Antigua and Barbuda), .BZ (Belize), .HN (Honduras) .LC (St. Lucia), and .VC (Saint Vincent and the Grenadines). These TLDs were officially signed by Afilias on October 5, 2010.
Source: http://www.circleid.com/posts/20101013_afilias_increases_dns_security_in_latin_america_caribbean_dnssec/
Share
Wednesday, September 22, 2010
Majority of U.S. Federal Domain Names Still Fail to Meet Federal Internet Security Mandate for DNSSEC Adoption
The report was the first independent study into the deployment of DNSSEC across a majority of .gov domains including Federal, state, local, Native American and others. .gov domains are not published publicly, but IID was able to track down a majority of them for this study. IID analyzed the DNS of more than 2,900 .gov domains and found:
- 421 Federal .gov domains are fully authenticated with DNSSEC out of 1,185 (36 percent)
- Two percent of Federal .gov domains signed with DNSSEC are incorrectly configured and fail completely when DNSSEC checks are done at some DNS resolvers
- Another two percent of Federal .gov domains have basic DNS misconfigurations that keep them from operating properly at all
- Two states, Idaho and Vermont, have successfully authenticated many of their domains with DNSSEC – a good sign for non-Federal adoption
“DNS is still the wild west of Internet infrastructure and it remains relatively wide open for cyber criminals today," said Online Trust Alliance (OTA) Founder and President Craig Spiezle. "It is essential for organizations to not only adopt DNSSEC, but also utilize various other solutions which help ensure online trust.”
More findings from the IID report including how improperly implementing DNSSEC has actually hamstrung some domains can be found at www.internetidentity.com/resources/trend-reports. Rod Rasmussen will discuss the findings of this report while at the OTA Online Trust & Cybersecurity Forum in Washington, D.C. this Friday, September 24.
About IID
IID (Internet Identity) has been providing technology and services that secure the Internet presence for an organization and its extended enterprise since the company was founded in 1996. It recently started delivering the industry’s first and only solution for detecting, diagnosing and mitigating domain name system (DNS) security and configuration issues for an organization and its extended enterprise. IID also provides anti-phishing, malware and brand security solutions for many of today’s leading financial service firms, e-commerce, social networking and ISP companies, and more. The company is working hard to deliver solutions that help keep the Internet safe and trusted for businesses. IID is headquartered in Tacoma, Washington. More information can be found at www.internetidentity.com.
Source: Business Wire, Majority of U.S. Federal Domain Names Still Fail to Meet Federal Internet Security Mandate for DNSSEC Adoption, Retrived on September 22, 2010 from businesswire.com/news/home/20100922006548/en
Share
Friday, September 17, 2010
Microsoft Points to IE 9 Security Measures
At least that's the thinking when it comes to the security parameters in the new browser. Users will get more of a warning than in the past when they download unknown files with IE 9, for instance.
"Our features are kind of like 'stranger danger' against malware and other threats," said Dean Hachamovitch, Microsoft's corporate vice president of Internet Explorer. "Internet Explorer 9 is the only browser that uses download reputation to help users make safety decisions."
For the new browser, Microsoft is tapping filtering technology that has already repelled at least 1.3 billion malicious downloads. The key feature to look for in the IE 9 beta is the download manager, which integrates Microsoft's SmartScreen Filter.
The IE 9 beta introduces the "SmartScreen download reputation" feature, which uses site reputation data to "remove unnecessary warnings for well-known files, and show more severe warnings when the download has a higher risk of being malicious," according to Microsoft's announcement.
Brian Hall, general manager of Windows Live and Internet Explorer, said that IE 8 was the most secure browser ever built. He added that IE 9 simply takes that capability forward with its "database" of trusted and nontrusted Web sites.
"With IE 9, we make it plain what's dangerous and what's not but we understand that our security is never done," Hall said. "We'll have to continue to invest heavily in the ability to create a safe enterprise and customer experience."
Chenxi Wang, principal analyst of security and risk management at Forrester Research, predicted before the IE 9 launch event that "some sort of malware detection and Web site reputation capability built right into the browser" would be seen in the IE 9 beta. However, she'd like to see implementation of other browser security measures. For instance, support could be added for Domain Name System Security Extensions (DNSSEC) to help verify Web sites.
"I'd like to see some kind of visual cue to users whether the Web site they are going to is a DNSSEC-validated domain name," she said.
Trust is an issue with so-called "drive-by installs," where malware can be spread by getting the user to visit a malicious Web page. Users can also be led to click on a malicious link if it's sent by a trusted source.
Will the release of IE 9 bring fewer security bulletins to Windows users? The answer is "No," according to Rob Juncker, vice president of technology at Shavlik Technologies, a company that makes security software.
"Are we saying that we won't see a security bulletin that resembles something along the lines of 'vulnerability in Internet Explorer 9.0 could allow remote code execution?' Absolutely not," Juncker said. He did credit Microsoft somewhat, adding that Microsoft seems to "have realized how to guard the wall better than they have in the past."
Source: Redmonmag.com, Microsoft Points to IE 9 Security Measures, Jabulani Leffall, Retrieved on 09/16/2010 from redmondmag.com/articles/2010/09/15/microsoft-points-to-ie-9-security-measures.aspx
Share
Tuesday, September 7, 2010
EURid: .eu DNSSEC chain of trust complete
Source: http://www.reuters.com/article/idUS75194+06-Sep-2010+HUG20100906
Share
Sunday, August 22, 2010
Seven Smartcard Keys To The Internet
There has been a bit of buzz lately regarding an Internet “kill switch” and a handful of trusted individuals given the responsibility of rebooting the Internet, should it go down from cyber attack or be shut down for whatever reason.
The operation is born of the Internet Corporation for Assigned Names and Numbers (ICAAN). ICANN was formed in 1998. It is a not-for-profit public benefit corporation with participants from all over the world dedicated to keeping the Internet secure, stable, and interoperable. It promotes competition and develops policy on the Internet’s unique identifiers.
ICANN doesn’t control content on the Internet. It cannot stop spam and it doesn’t deal with access to the Internet. But through its role coordinating the Internet’s naming system, it does have an important impact on the expansion and evolution of the Internet.
Popsci reports that “part of ICANN’s security scheme is the Domain Name System Security (DNSSEC), a security protocol that ensures Web sites are registered and “signed” (this is the security measure built into the Web that ensures when you go to a URL you arrive at a real site and not an identical pirate site). Most major servers are a part of DNSSEC, as it’s known, and during a major international attack, the system might sever connections between important servers to contain the damage.”
The lucky seven holders of the smartcard keys are from all over the world. Each key has an encrypted number which is part of the DNSSEC root key that by themselves are useless, but combined they have the ability to restart the Internet. The process of rebooting the web requires five of the seven key holders to be in the United States together with their keys. That’s a pretty lofty responsibility for anyone. You can learn more about the card process in this video.
Robert Siciliano, personal security expert contributor to Just Ask Gemalto, discusses the possibility of an Internet crash on Fox Boston. (Disclosures) - http://www.bloggernews.net/125108
Share
Tuesday, July 27, 2010
The Six Guys That Have the Keys to the Internet
- Paul Kane of the U.K
- Dan Kaminsky of the US;
- Jiankang Yao from China;
- Moussa Guebre of Burkina Faso;
- Bevil Wooding from Trinidad and Tobago;
- Ondrej Sury of the Czech Republic;
- Norm Ritchie of Canada.
The “chain of trust” was developed by the private ICANN (Internet Corporation for Assigned Names and Numbers) internet organization. Metro reported
It is not possible to turn off the entire web, despite reports that US president Barack Obama could get a ‘flick switch’.If the system is crashed, any of the keyholders have access to a system that keeps scammers at bay. The DNSSEC (Domain Name System Security) ensures that websites are officially approved and ‘signed’.
Mr Kane, chief executive of CommunityDNS, based at Bath University, was handed the key in a secret US bunker and has stored it in a safety deposit box.
In the event the system needs the keys to restart, keyholders go US base to watch and verify the system has started securely and within protocols, which includes creating new keys."
Share
DNS Enhancements in Windows Server 2008 R2
"DNS is our trusted guide to the digital world. When we access a server by name, we're trusting DNS to give us the IP address of the correct destination. If our DNS infrastructure is compromised, names might be resolved to malicious hosts, which could capture sensitive information and credentials, distribute misinformation, or just disrupt our access to services.
Today’s infrastructure houses highly sensitive information and forms the backbone of many businesses, so we need something more. Confidence in our DNS infrastructure and the information it provides is crucial to maintaining an organization's security and integrity. With Windows Server 2008 R2, we have some very powerful technologies with which to gain this confidence. Let's start with a little background, then see what new enhancements such as DNS Security Extensions (DNSSEC) can provide.
Traditional DNS Shortcomings
With traditional DNS, clients can perform only basic checks to determine whether DNS responses have been spoofed. A client can check whether the DNS server address matches the expected address; however, this capability is often disabled due to network infrastructure configurations. This check is also easy to fake: The port used in the response needs to match the client request's port, which is easy to guess.Even with new Server 2008 R2 DNS enhancements to source-port randomization, the risk isn't mitigated so much as the time required for an attack is increased. The random XID value sent by the client (included in the response) is sent in clear text, so it's easy to duplicate. Also, in traditional DNS, the client's query is echoed back, but if a technology is smart enough to capture the request and spoof a response, echoing back the initial response is easy.
There's no checksum within the DNS response—say, to ensure that the content of the response hasn't been altered. So, man-in-the-middle attacks can modify the content as it's transmitted to the client. Also, consider that many of our DNS results don't come from the authoritative DNS server; rather, they come from an in-between DNS server that has a cached lookup and returns the information in the cache. Many hackers poison the cache of DNS servers by bombarding them with false records.
DNSSEC for All
DNS Security Extensions (DNSSEC) isn't a proprietary Microsoft technology but rather an Internet-standard extension to DNS defined in RFCs 4033, 4034, and 4035 that Microsoft has implemented as part of the Server 2008 R2 DNS role. An earlier version of DNSSEC was defined in RFC 2535, but it's been replaced by the aforementioned RFCs and implementations that follow RFC 2535. Windows 2003 Server and even Server 2008 aren't compatible with the Windows 2008 R2 implementation.At its most basic level, DNSSEC assures the integrity of the DNS infrastructure through technologies that verify the authenticity of received data, including authenticated denial-of-existence responses. Assurance is enabled through public key cryptography, which enables the use of digital signatures on all DNS responses. A successful digital signature validation means that the data received is genuine and can be trusted. The digital signature is generated using the DNS zone's private key (which is kept secret) and the content of the record, and can be validated with the public key. If a packet is generated from a malicious source, its digital signature will fail; if a packet has been modified, the signature will no longer match the content.
Facilitating this public key cryptography are several new DNS record types—specifically, DNS Public Key (DNSKEY), which is a container for a DNS zone's public key; Resource Record Signature (RRSIG), which contains the digital signature of a DNS response; Delegation Signer (DS), which is used between a child and parent zone that are both DNSSEC-enabled; and Next Secure (NSEC), which allows authenticated denial-of-existence records by effectively returning the name that would be prior to the non-existent requested name (if they were in alphabetical order) and notifying what the next secure record would be. For example, if you had records A and E in your DNS zone, and you were asked for record C, the response would be A NSEC E with a signature, thereby notifying you that the asked-for record doesn't exist because there are no records between A and E.
The critical element is the trust. The client must trust the zone's public key because the public key is used to authenticate the response by decrypting the signature, which was created using the private key. Ensuring that clients trust only the “real” authoritative DNS zone owner is achieved through chains of trust.
In an ideal world, this PKI hierarchy would be self-contained in the DNS hierarchy in that the root of DNS—“.”—would be DNSSEC-enabled and globally trusted by all clients, Then, the root could sign the top-level domain names (e.g., com, net, org), which could then sign their subordinate domains (e.g., company.com), thereby creating a trust path. This means that clients would need only to trust the root zone, since the root zone is used to authenticate all the other child zones. In Figure 1's example, .net is DNSSEC-enabled, so any child zone that is signed by the .net parent would be trusted by any DNS client that trusts .net.
Figure 1: Setting the trust anchor
At this time, the DNS root zone doesn't support DNSSEC, and neither does COM, but this will change in the near future as the use of DNSSEC is being mandated by many governments around the world. The DNS root will be DNSSEC-enabled in mid-2010, and COM some time in 2011 or 2012. Therefore, we need an interim solution to enable clients to trust the DNS zones that are DNSSEC-enabled.
Whenever we talk about digital signatures, we need a mechanism for clients to be able to validate the signature. This is achieved through public key cryptography. A public key for the secured DNS zone is available for clients to use to validate the digital signature that was generated using the DNS zone's private key. This public key at the root of a DNSSEC trusted namespace—for example, .net—is known as the trust anchor; it’s the anchor of trust between the client and DNS namespace. If a client has a trust anchor to a zone, the client builds a chain of authentication to any child zone of the trust anchor, removing the need for DNS clients to explicitly trust every zone within a namespace. Don’t panic, though: You don't need a full PKI deployed in your environment. The public keys for the security zones are actually stored within the DNS infrastructure, but how do you know who to trust? How do you get valid trust anchors since the root DNS zone can't sign?
Through a process called DNSEC Lookaside Validation (DLV), public keys can be configured to be trusted by DNS clients. There are repositories on the Internet that allow DNSSEC-enabled zones to upload their public keys, which clients can then use. These public repositories are trust anchors on the clients. We trust these repositories to do the right thing and make sure the public keys they store are legitimate—the same way we trust Verisign to ensure that a company is genuine before giving them SSL or code signing certificates. An organization can download the content of this repository, and Active Directory (AD) can replicate the DNSSEC information downloaded to all DNS servers. (DLV isn’t supported in Server 2008 R2.)
Figure 2: Trusting DNS responses
Alternatively, you can manually configure trust anchors within DNS by specifying a zone name and specifying the public key that zone name servers give, as Figure 2 shows. When the entry point for a trust chain (i.e., a trust anchor)is being configured, and you’re specifying the key signing key (more on this later), you would check the Secure Entry Point (SEP) option in addition to the zone signing key. If you want to share your public key so that another organization or repository can add it as a trust anchor, that organization will need the content of the %systemroot%\System32\dns\keyset-
Figure 3: Sharing the public key
This functionality isn’t between a DNS client (e.g., your workstation) and the authoritative DNS server for the lookup you’re performing. We can’t actually define trust anchors on a DNS client! In fact, even though I’ve been using the term DNS client, DNSSEC is actually more important between DNS servers. In the typical DNS-resolution flow, you ask your local DNS server and it recursively looks up the answer, so your DNS server is the component that needs to validate responses. In most environments, the client won’t perform DNSSEC validation; it relies on its DNS server to do that by asking the DNS server to use DNSSEC.
To provide maximum protection for end clients, best practice is to use IPsec to authenticate the data and perhaps encrypt communication between the client and the local DNS server. This method ensures no local corruption of data from the DNS server to the client.
To configure the DNS clients’ expectation of DNSSEC, you use the Name Resolution Policy Table (NRPT), which is what determines how security should be used for DNS, whether you have entries for various DNS namespaces (e.g., microsoft.com), whether DNSSEC validation is required for each namespace, and whether IPsec should be used between the client and its next DNS hop (i.e., the client’s local DNS server). You typically manage NRPT through Group Policy instead of trying to manually configure it across many clients. Figure 4 shows a sample policy. Note that you can base your NRPT on more than just the DNS suffix: You can use prefix, fully qualified domain name (FQDN), and subnet.
Figure 4: Specifying DNSSEC requirements for a DNS zone
To enable DNSSEC on your Server 2008 R2 zones, you use DnsCmd utility to generate the key signing keys and zone signing keys, and store them in the local computer’s certificate store (MS-DNSSEC). The zone signing key (ZSK in the code below) signs all the records in the zone, and the key signing key (KSK in the code) signs only other keys, such as the ZSK. You also need to create the DNSSEC resource records at the root of the trust chain. To create my certificates, for example, I perform the following:
dnscmd /offlinesign /genkey /alg rsasha1 /flags KSK /length 2048 /zone secure.savilltech.com /SSCert /FriendlyName KSK- secure.savilltech.com dnscmd /offlinesign /genkey /alg rsasha1 /length 2048 /zone secure.savilltech.com /SSCert /FriendlyName ZSK- secure.savilltech.comFor your AD-integrated zones, you need to export the zone to a file, sign the file-based zone with your certificates, and save to a new file. Then, you need to delete the existing zone, import the new signed zone file, and reset to be AD integrated. Here are the major steps I used in my environment after creating the aforementioned certificates:
dnscmd /zoneexport secure.savilltech.net securesavilltechnet.dns dnscmd /offlinesign /signzone /input securesavilltechnet.dns /output securesavilltechnetsigned.dns /zone secure.savilltech.net /signkey /cert /friendlyname KSK-secure.savilltech.net /signkey /cert /friendlyname ZSK-secure.savilltech.netdnscmd /zonedelete secure.savilltech.net /dsdel /f dnscmd /zoneadd secure.savilltech.net /primary /file securesavilltechnetsigned.dns /load dnscmd /zoneresettype secure.savilltech.net /dsprimaryFigure 5 shows our various DNSSEC-related entries.
Figure 5: DNSSEC-related entries
Implementing DNSSEC involves many steps, and keeping it running and ensuring that the keys are maintained is similarly time-consuming. The keys we created have a limited lifetime and need to be updated; if we have trust anchors configured, those public keys will change and therefore require updating. I strongly recommend reading the Microsoft article “Deploying DNS Security Extensions (DNSSEC)”—at technet.microsoft.com/en-us/library/ee649268(WS.10).aspx—a great step-by-step guide.
DNS Devolution
DNSSEC is probably the most famous Server 2008 R2 DNS feature, but there are some other useful enhancements. In environments that have a deep DNS namespace, it can sometimes be tricky to know the correct DNS suffix for an address. For example, in my environment, I know the host is called savdalfile01, but I’m a member of dallas.na.savilltech.net, and I’m not sure if savdalfile01 should be savdalfile01.dallas.na.savilltech.net, savdalfile01.na.savilltech.net, or savdalfile01.savilltech.net. In the past, we would define a global suffix list of all the DNS suffixes that should be tried when resolving a name.Server 2008 R2 and Windows 7 offers an update to a key feature—DNS Devolution—that lets DNS resolution requests traverse up the DNS namespace until a match is found or until a certain number of devolutions is reached. (Every move up the namespace to a parent is a devolution to one level above.) An example would be savdalfile01: With DNS Devolution enabled, when a client attempts to resolve savdalfile01, savdalfile01.dallas.na.savilltech.net would be initially queried, then it would be up to the parent to search for savdalfile01.na.savilltech.net. (It’s checking a third-level devolution because the DNS suffix has three parts—na, savilltech, and net). If there's no match, it's up to that zone's parent to look for savdalfile01.savilltech.net (which now has a devolution level of 2, as this DNS suffix has twoparts). Basically, it allows a member of a child namespace to access resources in the parent without having to specify the parent’s namespace as part of the DNS query.
New to the Server 2008 R2 and Windows 7 DNS client is the ability to set a devolution level. As an administrator, you can define whether DNS devolution is enabled and which DNS devolution level you’ll devolve down to. For example, setting a devolution level of 2 means you would devolve down to the two-part Forest Root Domain (FRD) second-level domain (e.g., savilltech.net). Setting a devolution level of 3 means you would devolve only to the third-level DNS domain (e.g., na.savilltech.net).
You can configure DNS Devolution using Group Policy, through the Primary DNS Suffix Devolution and Primary DNS Suffix Devolution Level policies found at Computer Configuration\Policies\Administrative\Templates\Network\DNS Client, as Figure 6 shows. You can also set DNS Devolution directly in the registry with the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\UseDomainNameDevolution and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache\Parameters\DomainNameDevolutionLevel subkeys.
Figure 6: Setting the DNS devolution level
This functionality is useful in environments that have multiple levels of DNS namespace. The Microsoft security advisory “Update for DNS Devolution” (www.microsoft.com/technet/security/advisory/971888.mspx) offers an update for older versions of Windows.
DNS Cache Locking
At the beginning of this article, I mentioned that one DNS vulnerability was that DNS servers cache entries for recursive lookups (lookups for records they aren’t authoritative for, and for which they have to consult other DNS servers) they've performed to speed up future lookup requests for the same information. Those lookups have a specific time to live (TTL) before the record must be rechecked to see if it’s changed. The exploit uses DNS cache poisoning to send incorrect responses to a DNS server to try and update that cache so that clients using the server will receive incorrect information.DNS Cache Locking is a new Server 2008 R2 feature that helps mitigate cache poisoning: It locks the entries in the cache for the record’s TTL. So, if someone tries to poison the cache with a replacement record, the DNS server will ignore it and thus maintain the integrity of the cache content.
To use Cache Locking, you set a percentage of the TTL of records that the cache content is locked for—for example, a setting of 75 means that cached records can’t be overwritten until 75 percent of their TTL has passed. The default value is 100, which means records can’t be updated until the TTL has expired. However, you can change this by setting’s registry value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\CacheLockingPercent to our desired percentage. Note that if this value isn’t present, the default of 100 is used.
More on the NRPT
I already discussed how the NRPT helps define the way clients and servers act for different DNS zone requests. You have numerous entries in the NRPT, and if a DNS query matches an entry in it, the query is handled according to the configuration of the matching NRPT entry. If no match is found, the system performs default DNS handling.In addition to DNSSEC, the NRPT is used for one other key piece of Windows 7 and Server 2008 R2 functionality—namely, DirectAccess, which is the new technology that lets Windows 7 clients communicate with corporate resources no matter where they are on the Internet, without having to use VPNs. The client just accesses a corporate resource, and DirectAccess facilitates secure communicate back to the corporate network.
This automatic use of DirectAccess to get to resources raises an important question: How does the Windows 7 client know which destinations in the corporate network should be accessed through DirectAccess and which should just use normal Internet connectivity? I don’t want my Amazon purchases to be sent via my corporate network when I’m sitting at home or at Starbucks.
This decision is based on the Name Resolution Policy Table and in the same way we can define DNSSEC actions for various DNS name and IP values we can do exactly the same thing for DirectAccess using the DirectAccess tab as shown in Figure 7. If you want to check a machine's Group Policy rules, you'll find them at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig. You can also create exceptions, which let you create general rules for an entire namespace but then treat a particular host or namespace portion differently.
Figure 7: Enabling the use of DirectAccess
Server 2008 R2 brings you a very powerful DNS service that adheres to some of the most recent specifications. You should definitely consider Server 2008 R2 DNS to be the secure release and use it to replace previous Microsoft DNS services to offer maximum protection. DNS is your trusted advisor to the computer world, so make sure it can really be trusted!"
Source: DNS Enhancements in Windows Server 2008 R2, John Savill, Retrieved on July 28, 2010 from http://windowsitpro.com/article/dns2/DNS-Enhancements-in-Windows-Server-2008-R2.aspx
Share
Wednesday, July 21, 2010
DNSSEC is fully deployed on DNS root servers
Ken Silva, senior vice president and chief technology officer at VeriSign, elaborated on the significance to InternetNews.com, "The milestone is crucial because it means that administrators of recursive name servers--the servers that look up Internet addresses using data from the Domain Name System (DNS)--can in most cases enable validation of DNS data by configuring just the root's public key."
Of course, the hierarchical nature of DNS means that it has to be employed at every level to the individual ISPs to be truly effective. As such, it might be some time yet before DNS is properly secured, though this is certainly an important and necessary start.
Source: Retrieved on July 21, 2010 from fiercecio.com/techwatch/story/dnssec-fully-deployed-dns-root-servers/2010-07-20
Share
Thursday, July 15, 2010
US domain registrar does IPv6, DNSSEC
Sean Leach, Name.com's chief technology officer, tells The Reg that registrar customers can now submit both IPv4 and IPv6 addresses for a host name through its standard web interface. "If you want to enable IPv6 for one of your records, you can click a button to add an IPv6 address, and we'll submit it to the registry for you," he says.
And if you're using Name.com's DNS service as well, it will automatically answer IPv6 calls.
Next week, users will also have the option of enabling DNSSEC, or DNS Security Extensions, a means of protecting against a well-known trick that allows attackers to silently lure netizens to impostor websites. Leach says Name.com customers will be able to make the switch to DNSSEC (on supported top level domains) by uploading their keys via a web interface.
But later in the year, Leach and company intend to simplify the process. "We'll offer a kind of one-click DNSSEC. When we host your DNS, you'll basically click a button that says 'Enable DNSSEC' and you won't have to do anything else. That's what a lot of people really want, especially small businesses. They don't want to mess with it, they just want it."
Source: US domain registrar does IPv6, DNSSEC, Cade Metz, The Register.co.uk, Retrieved on July 15th, 2010 from theregister.co.uk/2010/07/13/name_dot_com_does_ipv6_and_dnssec
Share
Monday, June 21, 2010
ICANN Maps Out Internet Defense
The Internet Corporation for Assigned Names and Numbers -- or ICANN, as it’s better known -- is responsible for managing the Internet’s domain name system. While much of its focus has been on new top-level domains, ICANN these days is busily ramping up the technology and its pitch for making the Internet more secure for its users.
More@ http://www.esecurityplanet.com/features/article.php/3888791/ICANN-Maps-Out-Internet-Defense.htm
Share
Thursday, June 3, 2010
Can .gov trust .com?
The last of 13 servers in the Domain Name System’s authoritative root zone was digitally signed with the DNS Security Extensions May 5, paving the way for the publication this summer of the root trust anchor that will remove a major hurdle to the widespread deployment of DNSSEC.
“Since the beginning of the year, we have been incrementally rolling out DNSSEC in the root zone,” said Joe Waldron, director of product management at VeriSign Naming Services.
The DNS root zone, which contains the records needed to resolve the domain names used by people and applications to the numerical IP addresses used by routers and servers, is overseen by the Commerce Department’s National Telecommunications and Information Administration, and the files are managed by VeriSign. DNSSEC provides a layer of security on the Internet by using cryptographic digital signatures to authenticate responses to DNS queries. The effort by NTIA, VeriSign and the Internet Corporation for Assigned Names and Numbers to deploy DNSSEC in the root zone has been called the biggest structural improvement to the DNS in 20 years.
Source: Can .gov trust .com?, William Jackson, GNC, Retrieved on Jun 03, 2010 from gcn.com/articles/2010/06/07/dnssec-update.aspx
Share
Friday, May 7, 2010
Root zone switches to DNSSEC
The last of the internet's 13 root servers has been switched to a secure version off the Domain Name System (DNS). This means that the entire root zone for the internet is now operating using DNSSEC.
Share
Wednesday, April 28, 2010
Cloud Computing Gets Easier with Xila Cloud's Free DNS Management
“Customers can create a free account with Xila Cloud and choose to launch cloud servers or simply take advantage of our Free DNS service. Because our proprietary control panel handles cloud servers and DNS Management we’re hoping those customers that sign up strictly for our Free DNS service will find our cloud servers useful to them in the future, therefore bringing in new paying customers.”
Free DNS service does not mean that Xila Cloud just implemented basic DNS management for its Free DNS offering. Instead, the company offers a feature rich DNS platform, which is capable of handling millions of queries per second. Here is a brief overview of feature-packed Xila DNS platform.
Xila Cloud’s Free DNS includes unlimited zones, or domains, unlimited host, unlimited URL forwards, unlimited E-Mail forwards, and unlimited queries, all at no cost to users. If users are looking for a new domain this can also be handled with Xila Cloud’s Free DNS as well.
Xila Cloud also offers a domain registration service for a reasonable pricing. Its single click domain registration starts at only $12.95 per year.
Another added advantage of registering domain with Xila is: Domains registered via Xila Cloud’s control panel are added to the Free DNS platform allowing users to manage DNS on the domain immediately.
Xila Cloud’s Free DNS service supports A, CNAME, DNSSEC, LOC, MX, NS, SRV, TXT, PTR, and AAAA records with nameservers in the United States and the United Kingdom.
Source: Madhubanti Rudra, TMCnet, Cloud Computing Gets Easier with Xila Cloud's Free DNS Management, Retrived on April 28, 2010 from dns.tmcnet.com/topics/dns/articles/83269-cloud-computing-gets-easier-with-xila-clouds-free.htm
Share
Tuesday, April 13, 2010
Trusted Community Representatives Approach to DNSSEC Root Key Management
As part of the joint effort to secure the Domain Name System (DNS) and the Root DNSSEC key management process currently under consideration, a number of persons acting as trusted representatives of the Internet community will be sought to participate in the root key generation and signing ceremonies. These persons are called Trusted Community Representatives (TCRs).
ICANN will select 21 TCRs and a number of candidate TCRs. Initially, this will be done on a provisional basis to determine the approach's viability based on the success of the first Hardware Security Module (HSM) initialization and key generation that is scheduled for June 2010.
The selection will be based on Statements of Interest, solicited from the Internet community at http://www.root-dnssec.org/tcr/. Persons considered affiliated with ICANN, VeriSign or the US Department of Commerce may not become a Trusted Community Representative.
For more information: http://www.root-dnssec.org/wp-content/uploads/2010/04/ICANN-TCR-Proposal-20100408.pdf [PDF, 102 KB]
Source: Retrived on April 13, 2010 from ag-ip-news.com/GetArticle.asp?Art_ID=8167〈=en
Monday, March 29, 2010
Yahoo wants two-faced DNS to aid IPv6 deployment
Today, the 0.09 percent of Web users with broken IPv6 suffer significant timeouts if they, for instance, aim their Web browser at an IPv6-enabled site. The browser will first try to connect over IPv6 for upwards of a minute before giving up and retrying over IPv4. This is a big problem for important Web destinations such as Google and Yahoo, because they don't want to lose 0.09 percent (or more, as IPv6 use increases) of their visitors and therefore, revenue.
Google has "solved" this problem with its Google over IPv6 program which requires DNS server operators to get whitelisted. Users of whitelisted DNS servers subsequently receive google.com's and youtube.com's IPv6 addresses as well as the usual IPv4 addresses when they perform a DNS query for the addresses that go with those DNS names. Everyone else gets only the IPv4 addresses. Apparently, Google, Netflix, and Microsoft have been exploring the possibilities of a shared, industry-wide IPv6 whitelist.
However, Yahoo is taking a different approach. If a user is performing DNS queries over IPv6, then obviously his or her IPv6 connectivity works. So exposing IPv6 addresses to users sending DNS queries over IPv6 should be fairly risk-free. Everyone agrees that this solution, like the whitelist solution, is rather ugly. This means implementing "two-faced DNS": a DNS server that gives different answers to different people performing the same query. Obviously, such practice isn't particularly DNSSEC-friendly. (But that can be solved by also giving DNSSEC enabled users the IPv6 information.)
There are two problems with Yahoo's approach. First of all, mechanisms for computers to learn the IPv6 addresses of nameservers are lacking. Unlike IPv4, IPv6 often doesn't use DHCP (many systems, such as Windows XP and Mac OS X don't even support IPv6 DHCP). One alternative mechanism to learn IPv6 DNS server addresses, RFC 5006, is even less widely deployed. So most systems that have both IPv4 and IPv6 connectivity perform their DNS requests over IPv4.
The other issue is that there is at least one other server between a Yahoo user's computer and Yahoo's DNS servers. If that server is operated by people who are oblivious to IPv6, it's unlikely that they will configure it such that it only gives out Yahoo's IPv6 addresses to users who send queries over IPv6. So the whole thing hinges on the cooperation of those network operators who are breaking IPv6 connectivity in the first place.
If this is the only way that content networks such as Yahoo and Google are prepared to become IPv6-capable, it's still better than nothing. And perhaps this downside will be addressed when the Yahoo engineers work out the details of this proposal, which is so far just a set of presentation slides.
In the meantime, it would be nice if network operators wouldn't arbitrarily block IPv6 packets inside IPv4 packets, thereby disabling "IPv6 tunnels," and for people who enable IPv6 to make sure it keeps working after the initial excitement of running the new protocol wears off."
Source: Yahoo wants two-faced DNS to aid IPv6 deployment, Iljitsch van Beijnum, Retrived on March 29, 2010 from arstechnica.com/web/news/2010/03/yahoo-wants-two-faced-dns-to-aid-ipv6-deployment.ars
Tuesday, March 23, 2010
Top U.S. domain name registrars lag on DNS security
Source: Retrieved on March 23, 2010 from networkworld.com/news/2010/032310-domain-name-registars-lagging.html
Friday, March 12, 2010
The .org domain set to sign off on largest DNSSEC implementation to date
The Public Interest Registry, which operates the .org top-level domain, expects to complete deployment of the Domain Name System Security Extensions (DNSSEC) in the .org registry in June by accepting second-level signed zones.
“Dot-org is the largest of any zone to be signed to date,” said Jim Galvin, technical standards director for Afilias Ltd. of Dublin, Ireland, the registry’s back-end service provider. “The only zones larger are .com and .net, and they won’t come around until later this year.”
The .org space has more than 7.5 million domains registered in it. The .gov top-level domain has about 3,700 domains registered in it.
Source: The .org domain set to sign off on largest DNSSEC implementation to date, Government Computer News, William Jackson, Retrieved on March 12, 2010, from gcn.com/articles/2010/03/12/org-dnssec-implementation.aspx
Wednesday, March 10, 2010
Dan Kaminsky on Future of DNSSEC
Dan Kaminsky: "DNSSEC is an essential tool in sealing DNS vulnerabilities and mitigation of DNS cache poisoning attacks that undermine the integrity of the DNS system. The lack of DNS security makes the Internet more vulnerable. Thank you for signing with DNSSEC early. I see DNSSEC as an automated and integral part DNS, fully deployed within the next few years."
Dan Kaminsky is a security researcher and director of penetration testing at IOActive, widely credited for discovering a fundamental flaw in the Domain Name System and the protocol itself.
The GLOBE Program was launched to promote and support the collaboration of students, teachers and scientists on inquiry-based investigations of the environment and the Earth system, working in close partnership with NASA and NSF Earth System Science Projects in study and research about the dynamics of Earth's environment.
Source: Retrieved on March 9, 2010 from thewhir.com/web-hosting-news/030910_Government_Program_Chooses_Dyn_Incs_Dynect_Platform_to_Deploy_DNSSEC
Friday, February 26, 2010
UK Registry to Implement DNSSEC
Nominet, the U.K.'s domain name registry, will begin implementing a security protocol on Monday designed to protect the DNS (Domain Name System).
The system, called DNS Security Extensions (DNSSEC), uses public key cryptography to digitally "sign" the DNS records for Web sites. It is designed to stop attacks such as cache poisoning, where a DNS server is hacked, making it possible for a user to type in the correct Web site name but be directed to a fake Web site.
Nominet will begin signing the ".uk" top-level domain beginning Monday, a process which will conclude a week later, said Simon McCalla, director of IT at the registry.
Interestingly, there are just a little over a dozen Web sites that use ".uk" since a decision was made more than a decade ago to close off registrations, he said. Much more common are second-level domains, such as ".co.uk" and ".org.uk," among others.
However, signing the ".uk" zone is crucial to building the so-called "chains of trust" required for full DNSSEC implementation, McCalla said. Cryptographic keys used to sign Web sites in different zones are validated by other zones.
That signing culminates at the "root zone," or the 13 authoritative nameservers located around the world that contain the master list of where computers can go to look up an address in a particular domain such as ".com." The DNS translates Web site names, such as www.idg.com into a numerical IP (Internet Protocol) address, which is used by computers to find a Web site.
Nominet will begin signing ".co.uk" -- comprising more than 8 million Web sites -- later this year, working with any entity that operates a nameserver, as their software will have to be upgraded for DNSSEC.
So far, other entities have been slow to upgrade. McCalla said many appear to be waiting for the root zone to be signed. "I expect we will see a much greater awareness this year," he said.
Source: Retrieved on February 26th from pcworld.com/article/190285/uk_registry_to_implement_dns_security_protocol.html
Tuesday, February 16, 2010
Debian to start deploying DNSSEC
The Debian system administrators (DSA) have announced that they will soon be deploying DNSSEC for selected Debian zones. "The plan is to introduce DNSSEC in several steps so that we can react to issues that arise without breaking everything at once. [...] We will start with serving signed debian.net and debian.com zones. Assuming nobody complains loudly enough the various reverse zones and finally the debian.org zone will follow. Once all our zones are signed we will publish our trust anchors in ISC's DLV Registry, again in stages. [...] The various child zones that are handled differently from our normal DNS infrastructure (mirror.debian.net, alioth, bugs, ftp, packages, security, volatile, www) will follow at a later date." (Thanks again to Paul Wise.)
Source: http://lwn.net/Articles/374473
Tuesday, February 9, 2010
OpenDNSSEC Available To Download Today
Developed by industry leaders including .SE (The Internet Infrastructure Foundation), NLNetLabs, Nominet, Kirei, SURFnet, SIDN and John Dickinson, OpenDNSSEC will seamlessly integrate domain name security extensions (DNSSEC) into already existing IT systems without the need for organisations to change their infrastructure.
How does it work?
DNSSEC secures the information used to translate domain names (such as nominet.org.uk) to computer addresses by adding to it a cryptographic signature created by a securely held key. When the information is retrieved as a result of a DNS query, the signature is also returned.
The computer making the query checks the information received against the signature. As it is impossible to create the correct signature without the secure key, a match implies that the information is authentic – it was retrieved from the correct place and was not modified in transit.
OpenDNSSEC is software that simplifies the process of creating and managing the DNSSEC signatures. Available under the BSD licence, it can be downloaded and installed on existing systems, and quickly set up to provide a secure DNS service.
Lesley Cowley, CEO at Nominet comments: "OpenDNSSEC ensures that the domain name system is not tampered with, and that Internet users are directed to a preferred web site without intervention. This piece of software provides an extra layer of security to the DNS. The collaboration in evidence, shows that the Internet community is committed to forging a safer, more trusted Internet for all."
For further information about how OpenDNSSEC works or to download the beta, please visit http://www.OpenDNSSEC.org."
Source: Retrieved on February 9, 2010 from businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20100209006314&newsLang=en
Wednesday, February 3, 2010
Swiss Among World Leaders in Enabling DNSSEC
The added security for internet users allows for a more secure internet, especially important for banks and other financial services providers, for example.
At the Domain Pulse conference, Urs Eppenberger of SWITCH and Marc Furrer of the Swiss Federal Communications Commission (ComCom) enabled DNSSEC.
Furrer said he was very pleased with the efforts of SWITCH to be playing a leading role in the implementation of more secure internet communications and commerce.
"I am particularly proud of the fact that Switzerland is one of the first countries in Europe to introduce DNSSEC. This now guarantees security in the internet" said a delighted Marc Furrer, President of ComCom, in a statement.
Meanwhile DENIC is on schedule to prepare a test bed for registrars and this phase will run until 2011, said Sabine Dolderer, the company's CEO.
However nic.at will not be introducing DNSSEC in 2010, said Richard Wein, CEO of nic.at. Wein believes there is not yet the demand or the market for it in Austria (.AT) at the moment, but like DENIC, nic.at will be watching developments closely in the .CH ccTLD closely. Nic.at will be preparing for DNSSEC internally to have it ready for deployment when there is a demand.
Nic.at is also preparing an innovative business model to allow internet companies from registries, and in particular those planning to apply for new generic Top Level Domains (gTLDs), registrars, banks and others demanding a high level of security, to use their infrastructure. It is planned to have this finalised in the summer of 2010.
Among other presentations included Steve Gobin from ICANN who spoke of the new Registrar Accreditation Agreement while Simon Kopp of Kantonspolizei Luzern spoke about Fit4Chat website, an initiative of the Luzern canton's police department to help parents and children deal with unwanted contact from strangers, and in particular older adults, online.
There was also a presentation on internationalised domain names (IDNs) from Leonid Todorov from the Coordination Centre for TLD RU who explained the difficulties for Russian users in having to use only Latin characters for domain names. With a very small number of English speakers, especially in the more remote regions, and no adequate Latin/Cyrllic script translation, particularly relating to international trademarks, the introduction of IDNs will be of huge benefit to internet users in the country.
The 2011 Domain Pulse conference will be held in Vienna, Austria, from 17 to 18 February which will more or less coincide with the predicted one millionth .AT domain registration milestone.
Videos and slides of all presentations, mostly in German, are available on the Domain Pulse website at Domain Pulse conference website although without simultaneous translations as occurred during the meeting.
Source: David Goldstein, CircleID.com, Swiss Among World Leaders in Enabling DNSSEC, Retrived on February 3, 2010 from circleid.com/posts/20100203_swiss_among_world_leaders_in_enabling_dnssec/
Monday, February 1, 2010
Google and Neustar propose security fix for DNS geolocation technology
Google and Neustar, which posted the proposal on an IETF mailing list last week, would like to see the protocol extended to include significant significant IP address information about the computer making a DNS request. The extension to DNS would enable nameservers to understand roughly where a query was coming from, which would reduce the risk of attacks such as DNS poisoning, in which a nameserver can be convinced by a rogue computer that an illegitimate internet destination is the right one.
"It specifies an EDNSo option that carries IP address information (by default, only the first 24 bits to preserve privacy) of the user that triggered a DNS resolution," said the posting, made by executives from Google and Neustar. "This should allow authoritative name servers that keep geo-targeted responses to be more accurate, even in cases where the resolver and its users are close to each other."
The posting accompanied a 20-page document detailing the extension, which allows an authoritative name server to issue responses based upon the client's network address, rather than the network address of a recursive name server.
Google has been increasingly active in the battle to make the domain name service more secure. Ever since a fundamental flaw was discovered by researcher Dan Kaminskiy in 2008, the security of the service, which results URLs to IP addresses on the internet, has been in question.
Early last month, it was revealed that 80% of US federal agencies had failed to implement DNSSEC, a set of security extensions to DNS that use public-key encryption to help make the service more secure. The government had imposed a deadline of Dec. 31, 2009 for the upgrades.
Source: Google and Neustar propose security fix for DNS geolocation technology, Retrieved on February 2, 2010 from infosecurity-us.com/view/6920/google-and-neustar-propose-security-fix-for-dns-geolocation-technology/
Friday, January 22, 2010
80% of government Web sites miss DNS security deadline
Most U.S. federal agencies -- including the Department of Homeland Security -- have failed to comply with a Dec. 31, 2009, deadline to deploy new authentication mechanisms on their Web sites that would prevent hackers from hijacking Web traffic and redirecting it to bogus sites.
Agencies were required to roll out an extra layer of security on their .gov Web sites under an Office of Management and Budget mandate issued in August 2008, although at least one expert calls that yearend deadline "a little aggressive."
Aggressive or not, independent monitoring indicates that only 20% of agencies show signs of deploying this new security mechanism, which is called DNS Security Extensions, or DNSSEC for short.
Source: Carolyn Duffy Marsan, IDG News Service, Retrieved on January 21, 2009 from news.idg.no/cw/art.cfm?id=519CAE32-1A64-67EA-E410635A87B80381
Friday, January 15, 2010
Testing and Implementation Requirements for the Initial Deployment of DNSSEC in the Authoritative Root Zone
Excellent DNSSEC document provided by DOC NTIA, ICANN and VeriSign.
Get it here:
Testing and Implementation Requirements for the Initial Deployment of DNSSEC in the Authoritative Root Zone
Thursday, January 14, 2010
Root DNSSEC
Information about DNSSEC for the Root Zone
This website contains announcements, releases and other pertinent information about the deployment of DNSSEC for the root zone.
DNSSEC for the root zone is a joint effort between ICANN and VeriSign, with support from the U.S. Department of Commerce.
Planned High Level Timeline
* December 1, 2009: Root zone signed for internal use by VeriSign and ICANN. ICANN and VeriSign exercise interaction protocols for signing the ZSK with the KSK.
* January, 2010: The first root server begins serving the signed root in the form of the DURZ (deliberately unvalidatable root zone). The DURZ contains unusable keys in place of the root KSK and ZSK to prevent these keys being used for validation.
* Early May, 2010: All root servers are now serving the DURZ. The effects of the larger responses from the signed root, if any, would now be encountered.
* May and June, 2010: The deployment results are studied and a final decision to deploy DNSSEC in the root zone is made.
* July 1, 2010: ICANN publishes the root zone trust anchor and root operators begin to serve the signed root zone with actual keys – The signed root zone is available.
Please note that this timeline is tentative and subject to change based on testing results or other unforeseen factors.
Get more info at http://www.root-dnssec.org/
Monday, January 11, 2010
Deploying and Monitoring DNS Security (DNSSEC)
helps identify operational errors in the DNSSEC deployment
and discover unforeseen obstacles. It collects, verifies, and
publishes the DNSSEC keys for DNSSEC-enabled zones, which
enables operators of both authoritative zones and recursive
resolvers to deploy DNSSEC immediately, and benefit from its
cryptographic protections. In this paper we present the design
and implementation of SecSpider as well as several general
lessons that stem from its design and implementation."
Paper: Deploying and Monitoring DNS Security (DNSSEC) (PDF)
We Are Spreaking on DNSSEC @ RSA 2010 - Save $200 on Registration With Cupon
Want $200 off your RSA 2010 Conference registration? Enter the following discount code: PRMSO3616GBJ (5 left)
Posts
