Thanks to everyone who attended this morning’s webinar on DNSSEC! If you missed the 6 am PDT run, there’s another coming up at 9 am PDT. We’ll be uploading the slides after the second run, so check back here after 10 am PDT. In the mean time, I’ll answer a few of the questions that came in during the first webinar:
Is a consequence of DNSSEC implementation that most DNS queries will be done with TCP vs. UDP?Generally speaking, no. DNSSEC requires something called EDNS0, extensions to DNS that allow queriers to signal that they can accept large UDP-based responses. Without EDNS0, responses are limited to 512 bytes, but with EDNS0, they can be as large as 4K. Most DNSSEC-signed responses will fit into 4K.
How much adoption of DNSSEC among ISPs and telecommunications providers do you see?Not a whole lot, frankly. Comcast is a notable exception here in the U.S. They have a beta test of DNSSEC going on right now. Good for them.
What is the logical relationship between IPv6 and DNSSEC?There isn’t any special relationship between IPv6 and DNSSEC. DNSSEC works independently of transport protocol (i.e., IPv4 or IPv6), and as far as DNSSEC is concerned, AAAA records (used to map domain names to IPv6 addresses) are just like any other zone data to be signed.
Will DNSSEC affect DNS amplification attacks?Inasmuch as responses that include DNSSEC records are typically substantially larger than unsigned responses, it’ll be easier to find good sources of DNS amplification on the Internet. However, hackers today often set up their own authoritative name servers specifically to return very large RRsets in responses. They don’t need DNSSEC to make those RRsets big: SPF or TXT RRs will do. Then they induce open recursive name servers to look up those RRsets and return them to spoofed addresses.
Why is it taking so long for TLDs to be signed?Partly, I think, it was because some registries (which manage TLDs) waited for the whole NSEC3 issue to be resolved before committing. But even after deciding to implement DNSSEC, most registries have a huge amount of work to do: They need to write code (VeriSign has its own name server implementation, for example, called ATLAS), incorporate DNSSEC into their production systems, figure out how DNSSEC data will be exchanged between registrars and the registry, and a ton more that I’m blissfully unaware of.
Does BIND 9 have the necessary stuff to do this now?Yes, BIND 9.6 does. It supports the latest version of DNSSEC completely, including NSEC3.
I’ll post more answers later. Thanks again for tuning in!
