Posts Tagged DNSSEC
Call for Participation – DNSSEC Workshop at ICANN 56 in Helsinki, Finland on 27 June 2016
Posted by Dan York in ICANN DNSSEC Workshops on April 28, 2016
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 56 meeting on 27 June 2016 in Helsinki, Finland. 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 55 meeting in Marrakech, Morocco, on 09 March 2016. The presentations and transcripts are available at: https://meetings.icann.org/en/marrakech55/schedule/wed-dnssec.
Examples of the types of topics we are seeking include:
1. DNSSEC Deployment Challenges
The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC. In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the nature:
— What are your most significant concerns with DNSSEC, e.g., implementation, operation or something else?
— What do you expect DNSSEC to do for you and what doesn’t it do?
— What do you see as the most important trade-offs with respect to doing or not doing DNSSEC?
We are interested in presentations related to any aspect of DNSSEC such as zone signing, DNS response validation, applications use of DNSSEC, registry/registrar DNSSEC activities, etc.
2. DNSSEC by Default
As more and more applications and systems are available with DNSSEC enabled by default, the vast majority of today’s applications support DNSSEC but are not DNSSEC enabled by default. Are we ready to enable DNSSEC by default in all applications and services? We are interested in presentations by implementors on the reasoning that led to enable DNSSEC by default in their product or service. We are also interested in understanding those that elected not to enable DNSSEC by default and why, and what their plans are.
3. DNSSEC Encryption Algorithms
How do we make DNSSEC even more secure through the use of elliptic curve cryptography? What are the advantages of algorithms based on elliptic curves? And what steps need to happen to make this a reality? What challenges lie in the way? Over the past few months there have been discussions within the DNSSEC community about how we start down the path toward adding support for new cryptographic algorithms such as Ed25519 and Ed448. At ICANN 55 in Marrakech we had a panel session that explored why elliptic curve cryptography was interesting and some high level views on what needs to happen. At ICANN 56 we are interested in presentations that dive into greater detail about what needs to be done and how we start the process. More background information can be found in this document: https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/
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 Wednesday, 18 May 2016.
We hope that you can join us.
Thank you,
Julie Hedlund
On behalf of the DNSSEC Workshop Program Committee:
Mark Elkins, DNS/ZACR
Cath Goulding, Nominet UK
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, CNNIC
Luciano Minuchin, NIC.AR
Russ Mundy, Parsons
Ondřej Surý, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society
ICANN 54 – DNSSEC For Everybody: A Beginner’s Guide – Video and Slides Available
Posted by Dan York in ICANN DNSSEC Workshops on October 30, 2015
Want to see the “skit” that explains DNS and DNSSEC? At the recently completed ICANN 54 meeting in Dublin, we recorded the skit and the other introductory slides and questions in a video available on the Deploy360 YouTube channel. The basic page for the DNSSEC For Everybody session that includes the slides and handout can be found at:
https://meetings.icann.org/en/dublin54/schedule/mon-dnssec-everybody
The video recording is available online and embedded here:
Thank you to everyone involved in the skit and session – we’ll look forward to doing it again at ICANN 55 in Marakech!
And if you want to get started with DNSSEC, check out the Deploy360 Start Here page as a place to begin.
Attending ICANN 52 In Singapore? Why Not Speak About DNSSEC or DANE?
Posted by Dan York in ICANN DNSSEC Workshops on December 4, 2014
Time is running out! We have already received several excellent proposals for the ICANN 52 DNSSEC Workshop to be held on Wednesday, February 11, 2015 at ICANN 52 in Singapore and only have room for a few more presentations! If you work with DNSSEC or DANE and will be at ICANN 52, we would encourage you to submit a proposal for consideration for the 6+ hour DNSSEC Workshop to be held on the Wednesday of the ICANN week.
All you need to do right now is send a short (1-2 sentences) proposal to [email protected] expressing your interest and saying what you would like to talk about.
We published the full Call for Participation here that gives many suggestions for the type of topics we’d like to include. Looking at the agenda for the recent ICANN 51 DNSSEC Workshop in L.A. may also help give you ideas.
Please let us know soon if you are interested in being considered for the program!
Thank you!
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.
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.
New gTLDs will support DNSSEC from the start
Posted by Mark Feldman in Uncategorized on January 12, 2012
Today is the first day ICANN is accepting applications for new generic top-level domains (gTLDs). The Applicant Guidebook makes it clear that all new gTLDs must support DNSSEC from the start. While the expansion of the TLD name space has been somewhat controversial, ensuring support for DNSSEC going forward has not been.
Steve Crocker, chairman of the board of ICANN, said:
The Board and the staff at ICANN have fully understood the importance of DNSSEC. ICANN signed the root in 2010 and has advocated all top level domains be signed. It is only natural that DNSSEC be required from the beginning for all new generic top level domains.
First key ceremony set for tomorrow
Posted by Denise Graveline in Uncategorized on June 15, 2010
ICANN detailed the first production DNSSEC key ceremony in a high security data center in Culpeper, VA, outside of Washington, DC, pictured here. The ceremony takes place tomorrow, June 16, and is designed to demonstrate the transparency and trust needed to secure the domain name system. The ICANN article describes the process that will be followed tomorrow:
During the key ceremony the first cryptographic digital key used to secure the Internet root zone will be generated and securely stored.
Each key ceremony consists of a series of detailed procedures designed to allow the private key material for the root zone to be managed in a transparent yet secure manner. The goal is for the whole Internet community to be able to trust that the procedures involved were executed correctly, and that the private key materials are stored securely.
Security of the private key is important because it ensures that any signature made by that key is known to originate from a legitimate key ceremony, and not by an untrusted third party.
DNSSEC deployed in .US; .BIZ shortly to follow, Neustar says
Posted by Denise Graveline in Uncategorized on June 7, 2010
Neustar announced today that DNSSEC has been deployed in the .US zone, and says that it is ready to accept Delegation Signer records. The .BIZ zone will be signed next, with DS record accepted as early as July 15, 2010. As a result, it will be “the second gTLD to be fully DNSSEC-enabled.”
Update – The .BIZ domain was signed on August 7, 2010.
ICANN Nairobi DNSSEC workshop now available online
Posted by Denise Graveline in Uncategorized on March 10, 2010
Today’s DNSSEC Workshop at the ICANN Nairobi meeting is now available online, with presentations and transcripts. The meeting also included live options for remote participants, which are now closed.
Comcast to deploy DNSSEC by 1st quarter 2011
Posted by Denise Graveline in Uncategorized on February 23, 2010
After two years of testing DNSSEC, Comcast — the largest provider of cable services in the U.S., with 23.6 million cable customers, 15.9 million high-speed Internet customers and 7.6 million voice customers — announced it is starting a trial today and plans to implement DNSSEC by the first quarter of 2011 or sooner. In a blog post, Comcast noted:
We plan to implement DNSSEC for the websites we manage, such as comcast.com, comcast.net and xfinity.com, by the first quarter of 2011, if not sooner. By the end of 2011, we plan to implement DNSSEC validation for all of our customers….If you don’t want to wait until 2011, you can participate in our DNSSEC customer trial, which starts today. Opt-in by changing your DNS server IP addresses to 75.75.75.75 and 75.75.76.76 (we’ll be adding IPv6 addresses soon). The servers supporting this are deployed nationally in the same locations as our other DNS servers that millions of customers use everyday.
You can find FAQs on the Comcast trial here.
Sponsored By
Recent Comments