Archive for category DNSSEC
Call for Participation: DNSSEC Workshop at ICANN 51 on 15 Oct 2014
Posted by Dan York in DNSSEC, Meetings and Workshops on July 30, 2014
The call for participation is now out for the DNSSEC Workshop to be held on October 15, 2014, at ICANN 51 in Los Angeles.
If you have any ideas, or would like to ask questions about what is involved with the workshop, please email us at [email protected]. Initially, we don’t need a full abstract – just a couple of sentences about what you would like to speak about is perfectly fine. We are asking that all proposals be sent to us by no later than Friday, August 13, 2014 (but sooner is better as we expect this program to be quite full and we may not be able to accommodate all proposals).
Call for Participation — ICANN DNSSEC Workshop 15 October 2014
The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at the ICANN 51 meeting in Los Angeles, California, on 15 October 2014. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments.
For reference, the most recent session was held at the ICANN meeting in London on 25 June 2014. The presentations and transcripts are available at: http://london50.icann.org/en/schedule/wed-dnssec.
We are seeking presentations on the following topics;
1. DNSSEC activities in the North America region
For this panel we are seeking participation from those who have been involved in DNSSEC deployment in the North America region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions:
- What can DNSSEC do for you?
- What doesn’t it do?
- What are the internal tradeoffs to implementing DNSSEC?
- What did you learn in your deployment of DNSSEC?
We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers.
2. DANE / DNSSEC as a way to secure email
The DNS-based Authentication of Named Entities (DANE) protocol is an exciting development where DNSSEC can be used to provide a strong additional trust layer for traditional SSL/TLS certificates. We are both pleased and intrigued by the growing usage of DANE and DNSSEC as a means of providing added security for email. Multiple email servers have added support for DANE records to secure TLS/SSL connections. Some email providers are marketing DNSSEC/DANE support. We would like to have a panel at ICANN 51 focusing on this particular usage of DANE. Are you a developer of an email server or client supporting DANE? Do you provide DANE / DNSSEC support in your email service? Can you provide a brief case study of what you have done to implement DANE / DNSSEC? Can you talk about any lessons you learned in the process?
3. Potential impacts of Root Key Rollover
Given many concerns about the need to do a Root Key Rollover, we would like to bring together a panel of people who can talk about what the potential impacts may be to ISPs, equipment providers and end users, and also what can be done to potentially mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that will be affected by distribution of new root keys. We would like to be able to offer suggestions out of this panel to the wider technical community. If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you.
4. New gTLD registries and administrators implementing DNSSEC
With the launch of the new gTLDs, we are interested in hearing from registries and operators of new gTLDs about what systems and processes they have implemented to support DNSSEC. As more gTLDs are launched, is there DNSSEC-related information that can be shared to help those launches go easier?
5. The operational realities of running DNSSEC
Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC?
- What is the best practice around key rollovers?
- How often do you review your disaster recovery procedures?
- Is there operational familiarity within your customer support teams?
- What operational statistics have we gathered about DNSSEC?
- Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones?
6. DNSSEC automation
For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. Topics for which we would like to see presentations include:
- What tools, systems and services are available to help automate DNSSEC key management?
- Can you provide an analysis of current tools/services and identify gaps?
- Where are the best opportunities for automation within DNSSEC signing and validation processes?
- What are the costs and benefits of different approaches to automation?
7. When unexpected DNSSEC events occur
What have we learned from some of the operational outages that we have seen over the past 18 months? Are there lessons that we can pass on to those just about to implement DNSSEC? How do you manage dissemination of information about the outage? What have you learned about communications planning? Do you have a route to ISPs and registrars? How do you liaise with your CERT community?
8. DANE and DNSSEC applications
There is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as:
- What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries?
- What tools and services are now available that can support DANE usage?
- How soon could DANE and other DNSSEC applications become a deployable reality?
- How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet?
We would be particularly interested in any live demonstrations of DNSSEC / DANE applications and services. For example, a demonstration of the actual process of setting up a site with a certificate stored in a TLSA record that correctly validates would be welcome. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome.
9. DNSSEC and DANE in the enterprise
Enterprises can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises that have implemented DNSSEC on validation and/or signing processes and can address questions such as:
- What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so?
- What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges?
- How should an enterprise best prepare its IT staff and network to implement DNSSEC?
- What tools and systems are available to assist enterprises in the deployment of DNSSEC?
- How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates?
10. Guidance for Registrars in supporting DNSSEC
The 2013 Registrar Accreditation Agreement (RAA) for registrars and resellers requires them to support DNSSEC from January 1, 2014. We are seeking presentations discussing:
- What are the specific technical requirements of the RAA and how can registrars meet those requirements?
- What tools and systems are available for registrars that include DNSSEC support?
- What information do registrars need to provide to resellers and ultimately customers?
We are particularly interested in hearing from registrars who have signed the 2013 RAA and have either already implemented DNSSEC support or have a plan for doing so.
11. Implementing DNSSEC validation at Internet Service Providers (ISPs)
Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers. We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world. We are interested in presentations on topics such as:
- What does an ISP need to do to prepare its network for implementing DNSSEC validation?
- How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation?
- What measurements are available about the degree of DNSSEC validation currently deployed?
- What tools are available to help an ISP deploy DNSSEC validation?
- What are the practical server-sizing impacts of enabling DNSSEC validation on ISP DNS Resolvers (ex. cost, memory, CPU, bandwidth, technical support, etc.)?
12. APIs between the Registrars and DNS hosting operators
One specific area that has been identified as needing focus is the communication between registrars and DNS hosting operators, specifically when these functions are provided by different entities. Currently, the communication, such as the transfer of a DS record, often occurs by way of the domain name holder copying and pasting information from one web interface to another. How can this be automated? We would welcome presentations by either registrars or DNS hosting operators who have implemented APIs for the communication of DNSSEC information, or from people with ideas around how such APIs could be constructed.
13. Hardware Security Modules (HSMs) use cases and innovation
We are interested in demonstrations of HSMs, presentations of HSM-related innovations and real world use cases of HSMs and key management.
In addition, we welcome suggestions for additional topics.
If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to [email protected] by **Friday, 13 August 2014**
We hope that you can join us.
Thank you,
Julie Hedlund
On behalf of the DNSSEC Workshop Program Committee:
Steve Crocker, Shinkuro
Mark Elkins, DNS/ZACR
Cath Goulding, Nominet UK
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, CNNIC
Luciano Minuchin, NIC.AR
Russ Mundy, Sparta/Parsons
Ondřej Surý, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society
Signed Root Deployment: Framing the Issues
Posted by Mark Feldman in DNSSEC on March 18, 2013
This report, written in 2009 following the inaugural symposium of the DNSSEC Industry Coalition but unpublished until now, covers issues that remain important to ongoing DNSSEC deployment efforts. Written before the signing of the root zone, the “avoiding unintended consequences” section has been superseded by events, but the discussions of key distribution and use and key rollover remain as critical as ever for DNS and DNSSEC practitioners. [Note that this PDF contains comment markup from symposium participants.]
DNS Cache Poisoning Attack in Romania – Popular Sites Redirected.
Posted by Scott Rose in DNSSEC, News on December 3, 2012
Arstechnica reports that a possible DNS cache poisoning attack was used against the Romanian (.ro) versions of popular sites like Google, PayPal and Microsoft. While the exact cause is unknown, cache poisoning is suspected since it involved multiple domain names, but not the whole of the .ro domain:
For a span of one to several hours on Wednesday morning, people typing Google.ro, Yahoo.ro, and Romanian-specific addresses for other sites connected to a website that was purportedly run by an Algerian hacker, according to numerous security blog posts, including this one from Kaspersky Lab. Researchers said the most likely explanation for the redirection is a technique known as DNS poisoning, in which domain name system routing tables are tampered with, causing domain names to resolve to incorrect IP addresses.
More information from Kaspersky Lab.
The Collateral Damage of Internet Censorship by DNS Injection
Posted by Mark Feldman in DNSSEC, News on July 25, 2012
The Collateral Damage of Internet Censorship by DNS Injection (594KB PDF) by Anonymous, published in ACM SIGCOMM Computer Communication Review (Volume 42, Number 3, July 2012), looks at how
Some ISPs and governments (most notably the Great Firewall of China) use DNS injection to block access to “unwanted” websites. The censorship tools inspect DNS queries near the ISP’s boundary routers for sensitive domain keywords and inject forged DNS responses, blocking the users from accessing censored sites, such as twitter and facebook. Unfortunately this causes collateral damage, affecting communication beyond the censored networks when outside DNS traffic traverses censored links.
They point out that the techniques used are similar to Kaminsky-style attacks that can be perpetrated on non-DNSSEC-enabled systems:
In the absence of DNSSEC validation, the resolver will generally accept the faked answer because it arrives earlier than the real one, and, as a result, the access to the sensitive site will be blocked or redirected.
While DNSSEC is not able to guarantee transport of valid queries and responses, the paper goes on to say how it prevents the collateral damage associated with such machinations.
Is a $70 router fast enough for DNSSEC?
Posted by Olafur Gudmundsson in Adoption, Case Studies, DNSSEC on March 22, 2012
In a blog post a few days ago, Bob Novas talked about configuring an inexpensive home router as a DNSSEC validator for a home/small office network.
Such a router has much less computational power than most computers today, so many people assume it is not fast enough to do DNSSEC validation. To test that assumption, I ran the router through a set of tests designed to measure DNS and DNSSEC validation performance. I ran each of the following tests in sequence against the router with DNSMASQ (the default, non-validating forwarding resolver used by OpenWrt), Unbound without validation, and Unbound with validation:
- Test #1 Cold cache: query for X signed names from 2 different zones
- Test #2 Warm cache: query once for each of the names in #1
- Test #3 Mixed case query for the names in cache and intermingle 30% queries for names not in cache
- Test #4 Remote Ask for 50 nonexistent names in .gov
In tests 1-3, the names queried are from zones served by authoritative servers on the same LAN, minimizing network delays.
The reason I have the value X above is that I use different values depending on the speed of the device under test. The goal of the tests is to run experiments #1 and #3 for just long enough to get meaningful results.
When running without DNSSEC, DNSMASQ and Unbound performed about the same In the Cold test — around 700 queries/second.
Unbound was six times faster on the Warm test since it caches responses and DNSMASQ doesn’t. Unbound was two faster on Mixed test for the same reason.
With DNSSEC turned on, Unbound was able to handle about 140 validated queries/second, which is quite fast. This is with answers that are signed by a 1024-bit RSA key. It ran at the same speed as it did without DNSSEC in the Warm case.
This performance is more than enough for a home or small office.
When comparing the results for the Remote test, validating Unbound finished in about seven seconds while non-validating DNSMASQ took about ten. Network delay, not validation time, dominates the time to perform this test. In non-test situation, DNSSEC validation thus will not be a bottleneck when the doing lookups from the Internet.
A validating recursive resolver on a $70 home router
Posted by Bob Novas in Adoption, DNSSEC, Technical guides on March 15, 2012
As an experiment, I installed a validating recursive resolver on a home/SOHO router. I also set the router to advertise this resolver in DHCP as the DNS server for the LAN served by the router. The experiment was a resounding success — the clients on the router LAN only receive Secure or Provably Insecure DNS responses and do not receive Bogus responses.
I was able to verify this by navigating to a bogus addresses. For example, here is a screen shot of navigating to a domain with a bogus signature (http://bogussig.dnssec.tjeb.nl). If you are on a non-validating network, you will be able to resolve this link. If your network is validating, however, you should get an error if you click the link.
The HttpWatch browser plugin shows that the DNS query for this address very quickly returns an error.
Dump of a DNS query of a domain with a bogus signature
Loading a page where names are signed
So, how did I do this? I started with a Buffalo WZR-HP-G300NH v2 router, which I purchased online for just under US$70. The router runs a customized version of the DD-WRT Open Source software out of the box. The router has 32MB of NVRAM and 64MB of RAM. The basic configuration with an Unbound recursive resolver requires about 10MB of NVRAM, so this router has more than enough storage.
A few words of caution. Not all routers are suitable — you need to have a router that is supported by OpenWRT and the router needs to have enough flash memory. Also, you may lose any special features that are included in the manufacturer’s firmware. For the router I used, I lost the “movie engine” feature and the ability to support a file system on the router’s USB port. I could have loaded more packages from OpenWRT to support a file system. Finally, there is a risk that you will brick the router — i.e., turn it into a paperweight. You’ll need some level of expertise with technology and a platform that supports telnet, ssh and scp (e.g., Cygwin on Windows, or a Mac or Linux box).
Because of the greater ease of configuration that it offers, I reflashed the router with the OpenWRT router software. Then I loaded and configured Unbound, a BSD-licensed recursive resolver and was up and running.
Here are the specifics of how I accomplished this:
- I downloaded the right firmware image for the router from the OpenWRT nightly build site. For the Buffalo WZR-HP-G300NH2 router, I used this build for the squashfs file system for a system upgrade. The system upgrade is because I was going from a DD-WRT build to an OpenWRT build. Other firmware images are available for this router that are specific to other circumstances. If you are not flashing this specific router, you will need to establish the right firmware to use for yourself.
- I connected my PC to a LAN port on the router. I set the PC to use an address on the same subnet as the router – in my case 192.168.1.10 as the router is at 192.168.1.1.
- I pointed my browser at the router, set a password, and logged in to the router’s Web UI.
- I navigated to the Administration/Services page and enabled the SSH daemon. At the same time I set up the authentication for SSH.
- From a terminal window on my PC, I copied the OpenWRT firmware to the router.
scp openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-sysupgrade.bin [email protected]:/tmp
- I then logged into the router via ssh to flash OpenWRT onto the router in place of the supplied dd-wrt:
ssh [email protected] cd /tmp mtd -r write openwrt-ar71xx-wrz-hp-g300nh2-squashfs-sysupgrade.bin linux
- I waited for a good long while. When the red light stopped blinking, I had successfully flashed the router. It did not yet have a Web UI, but I was able to access it using telnet.
- I used telnet to acces the router with no username or password and set a password. This should disable telnet and enable ssh with that password (username root):
telnet 192.168.1.1 set a password when prompted
- I connected an Ethernet cable from my home LAN to the router’s WAN port (you could also connect the cable directly to your cable or DSL modem).
- I ssh’d into the router and loaded and installed the router’s Web UI, called luci:
ssh [email protected] opkg update opkg install luci ⁄etc⁄init.d⁄uhttpd enable ⁄etc⁄init.d⁄uhttpd start
- At this point I was able to login to the router’s Web UI by pointing my browser to 192.168.1.1. On my first login, I needed to set a username and password. I found that no matter what username I set, I always needed to use the username root to login to the router via ssh. It did use the password I set, however.
- I think the best thing to do next is to move the router’s LAN subnet to another subnet. My primary subnet (i.e., the one my ISP’s router provides and the one I have plugged into the router I’m working on’s WAN port) is 192.168.1.x. I logged in to the router’s Web UI and moved the router’s LAN to 192.168.2.1. This avoid IP address conflict between the two subnets. Since my PC is plugged into the LAN port of the router, I had to change my PC’s address to something like 192.168.2.10 so it can talk to the router once it’s on 192.168.2.1.
- I then ssh’d back into the router and installed unbound (This can also be done this using the Web UI from the System/Software page). I ssh’d into the router and used opkg to install Unbound:
ssh [email protected] opkg install unbound
- I enabled Unbound at startup by navigating a browser to the router’s System/Startup page and clicking on Unbound’s Enabled button to turn it to Disabled.
- I disabled dnsmasq’s (the default DHCP and DNS server on the router’s) DNS function by navigating the browser to the Network/DHCP and DNS/Advanced page and setting DNS Server Port to 0 (zero).
- Finally, from my ssh session, I told dnsmasq to advertise the router (unbound, really) as the DNS server in DHCP responses:
uci add_list dhcp.lan.dhcp_option="6,192.168.2.1" uci commit dhcp ⁄etc⁄init.d⁄dnsmasq restart
At this point, my router was up and running, dnsmasq’s DHCP was advertising the router as the DNS server, and Unbound was running as a recursive resolver on the router. All computers I put on the 192.168.2.1 router’s LAN that auto-configure using DHCP used this router’s unbound resolver for DNS, and are protected by DNSSEC. My network is configured as shown in the figure below.
One thing we noticed after running the router for a few days — be sure to leave NTP running on the router. In our case, we turned NTP off for some debugging and forgot to turn it back on (NTP is on the OpenWRT System/System page, under “Enable buildin NTP Server”.) After a few days, the router’s time was far enough off to cause validation to fail. Time is important for validation to work correctly because DNSSEC signatures have inception and expiration times.
We plan on doing some benchmarking of Unbound’s performance on this platform and on doing similar experiments with other routers. Email us at info @ dnssec-deployment.org with your experience doing this or any questions or feedback.
Some Fragments are more equal than other fragments
Posted by Olafur Gudmundsson in Adoption, DNSSEC, Technical guides on March 9, 2012
[Update of a post from January 28’th 2010 to fix broken links and add details]
My last post was about being able to receive fragmented DNS answers over UDP.
Last week (that is on January 20’th 2010) , I did a minor revision to a script of mine that checks to see if all of the name servers for a zone have the same SOA record and support EDNS0. This will indicate whether the servers are in sync and can serve DNSSEC. During testing of the updated script all the servers for .US timed out. This had never happened before, but .US turned on DNSSEC last month, so I started to investigate.
First I issued this query in dig format:
dig @a.gtld.biz US. SOA +dnssec +norec
Time-out confirms my script is reporting correctly. Then I tried again: (not asking for DNSSEC records)
dig @a.gtld.biz US. SOA +norec
This worked, the server is alive and the question has an answer, Then I tried getting the DNSSEC answer using TCP:
dig @a.gtld.biz US. SOA +norec +dnssec +tc
This gave me a 1558 byte answer (too large for one UDP packet) so fragmentation is needed to get over Ethernet links. But my system can handle big answers, so what’s wrong?
At this point I had number of questions:
- “What is NeuStar (the .US operator) doing?”
- “Are any other signed domains showing the same behavior?”
- “Are the fragments from these servers different from other fragments?”
First things first; “What is .US returning in their SOA answer?”
- In the answer section they give out the signed SOA record.
- In the authority section there is a signed NS set.So far, so good.
- In an additional section there are the glue A and AAAA records for the name servers, AND a signed DNSKEY set for the US. zone.
Conclusion: NeuStar is not doing anything wrong, but there is no need for the DNSKEY in the additional section. As this is turning up some fragmentation issues, I consider this a good thing.
At this point I moved on to the second question; “Is anyone else showing the same behavior?” All the signed TLD’s that I queried returned answers of less than 1500 bytes, so no fragmentation was taking place. I modified my script to ask for larger answers in order to force fragmentation. Instead of asking for type “SOA”, I ask for type “ANY”. For signed domains this should always give answers that are larger than 1500 bytes, since signed SOA, DNSKEY, NS and NSEC/NSEC3 are guaranteed to be in the answer and possibly others. Now things got interesting.
Almost all of the signed TLDs had one or more servers that timed out. .Org, for example, had 4 out of 6, .CH had 2, and .SE had one. So the issue is not isolated to anything that the .US operator is doing, but an indicator of something bigger.
I copied my script over to another machine I have and ran it there, and lo and behold, I got answers – no time-outs. The first machine is a FreeBSD-7.2 with PF firewall, the second machine is an old FreeBSD-4.12 with IPFW.
Now on to the next question; “Are the fragments different?” A quick tcpdump verified that answers were coming back. I fired up wireshark tool to do full packet capture. To make the capture smaller I activated the built-in DNS filter, and ran my script against the .ORG servers and the .US servers.
Looking at the DNS headers there was nothing different, and the UDP headers looked fine. On the other hand I noticed that the IP header flags field from the servers that timed out all had DF (Do Not Fragment) set on all packets, and on the first packet in the fragmentation sequence both the DF and MF (More Fragments) bits were set. MF tells IP that this is a fragmented upper layer packet and this is not the last packet. At this point I wondered if somehow this bit combination was causing problems in my IP stack or the firewall running on the host.
I disabled the PF firewall and suddenly the packets flowed through. After doing some searching on the Internet I discovered that I can tell PF to not drop these packets.
My old PF configuration had
scrub in all
The new one is
scrub in all no-df
Removing the scrub command also allows the packets to flow, but I do not recommend that solution.
I started asking around to find out what is causing the DF flag to be set on UDP packets, and the answer was “Linux is attempting MTU discovery”. I also noticed that for the last 2 years Bind releases have added code to attempt to force OS to not set DF on UDP packets. See file: lib/isc/unix/socket.c look for IP_DONTFRAG.
Conclusion: the tools I mentioned in the last post do not test to see if these malformed fragments are getting through. I have updated my perl script to ask for a large answer from an affected site, and to report on that. Please let me know if you have the same issue and what you did to fix it on your own systems and firewalls.
DNSSEC signed answers from L root server
Posted by Olafur Gudmundsson in Adoption, DNSSEC, News on January 27, 2010
The first root server (L) has started to serve up a signed version of the root zone. This is the first step in the live testing that will lead to a production signed root by the middle of the year. For information on the status of the root signing process visit: http://www.root-dnssec.org/
The root is intentionally publishing bogus signing keys, so the answers are not verifiable. Once the testing completes the actual keys will be published.
Current DNSKEY set advertised:
. 86400 IN DNSKEY 256 3 8 AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOULD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MORE/INFORMATION+++
+++++++++++++++++++++++++++++++++++++++++++++++8
. 86400 IN DNSKEY 257 3 8 AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOULD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MORE/INFORMATION+++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++8=
. 86400 IN RRSIG DNSKEY 8 0 86400 20100204235959 20100121000000 19324 . NO9bHgWYB3wQlVZXQKwDGUjTgIyfz1i8aWH8nBlT5isnYbr6PTfR4fWlSx8+avFfR0fVekauaQelKOyiUav4H9Y1AZ2OBguu7RjozQu1qErKboWd1NglIIOGar0Ol4Ur9+
4bo2LSxjp/X4ESypW0lX04z5uB6DZZei1zafzRGUnLIMdV9xdKEOJrm9UCKvYK5g8bjRq8KA8vT+
pidexZMrBQ3ie8R9daf/s6VK7zUJK0jF1vqhPbZFSQmBpJUlxh4VnOv7nnhcq4Moj49wqmNxKRqfvSwHAJBG6dEgShnlu/rfVsdxfFUCjIGX8YnSC7lYqODwgUGh+i/arA AK+bzg==
U.S. federal DNSSEC deployment lags behind deadline
Posted by Denise Graveline in Adoption, DNSSEC, Meetings and Workshops on January 21, 2010
Based on monitoring data from Secure64, Network World reported today that only 20 percent of U.S. federal agencies have deployed DNSSEC in time to meet a mandate from the White House Office of Management and Budget. From the article, Initiative partner Steve Crocker, CEO of Shinkuro, Inc., said:
Missing the mark by one year is pretty good news in this business…There is a gradual tightening of security going on up and down the Internet protocol stack. DNSSEC isn’t the be-all-and-end-all, but it’s an important piece. The technical community has been working on DNSSEC for 20 years. The top part of .gov is signed, and now we’re seeing the other pieces coming along.
U.S. federal deployment will be the topic of the DNSSEC Deployment Coordination Initiative’s special one-day program at FOSE 2010 on March 24. Go here to see an updated program and links to register or exhibit.
Educause factsheet highlights DNSSEC
Posted by Denise Graveline in Adoption, DNSSEC, Technical guides, Uncategorized on January 15, 2010
Educause has just published a two-page factsheet on 7 things you should know about DNSSEC, aimed at college and university information technology officials. Noting that “DNSSEC can be an important part of a broad-based cybersecurity strategy,” the fact sheet explains that security has special implications for institutions of higher education:
Colleges and universities are expected to be “good Internet citizens” and to lead by example in efforts to improve the public good. Because users tend to trust certain domains, including the .edu domain, more than others, expectations for the reliability of college and university websites are high. To the extent that institutions of higher education depend on their reputations, DNSSEC is an avenue to avoid some of the kinds of incidents that can damage a university’s stature.
-
You are currently browsing the archives for the DNSSEC category.
Sponsored By
Recent Comments