Category: Domain Name System Security Extensions (DNSSEC)

Mar 20

At IETF92 Next Week, Much Happening With IPv6, DNSSEC, DANE, TLS and more…

Dallas skylineNext week is IETF 92 in Dallas, Texas, and there will be a great amount of activity happening with the topics we cover here on Deploy360: IPv6, DNSSEC (and DANE), TLS, anti-spoofing and securing BGP.  As part of the Rough Guide to IETF 92, several of us have written posts outlining what’s happening in the various topic areas:

In each of those posts you’ll find a summary of what’s happening and a list of the relevant working groups and the associated links about how to learn more.  More information about IETF 92 in general can be found on the main Rough Guide to IETF 92 page at:

https://www.internetsociety.org/rough-guide-ietf92

Beyond all of that, Chris Grundemann will also be talking about our “Operators and the IETF” work and discussing Best Current Operational Practices (BCOP) with people as well.

If you can’t get to Dallas next week, you can attend remotely!  Just visit the IETF 92 remote participation page or check out http://www.ietf.org/live/ for more options.

To that end, as a bit of a change both Megan Kruse and I (Dan York) will be participating in this IETF 92 remotely.  It’s very strange to not be attending an IETF meeting in person, but different circumstances have made it not possible for both of us.  Jan Žorž will also be remote having just returned from v6 World Congress in Paris and about to head off to another event.   Chris Grundemann will be there on site in Dallas, though, and so if you have any questions about Deploy360 activities or want to get more involved, please contact Chris!

We’re looking forward to the usual crazy busy blur of a week that is an IETF meeting… and we’re looking forward to learning what else we can do to help accelerate the deployment of these key Internet technologies to make the Internet work better, faster and be more secure!

An audio commentary about IETF 92 is also available from our SoundCloud account:

The post At IETF92 Next Week, Much Happening With IPv6, DNSSEC, DANE, TLS and more… appeared first on Internet Society.

Jul 17

A Huge Amount Of DNSSEC Activity Next Week At IETF 90 In Toronto

DNSSEC badgeIf you are interested in DNSSEC and/or “DNS security” in general, there is going to be a great amount of activity happening in a number of different working group sessions at IETF 90 next week in Toronto.

I wrote about all of this in a post on the ITM blog, “Rough Guide to IETF 90: DNSSEC, DANE and DNS Security“, a part of the Rough Guide to IETF 90 series of posts.

You can read the full details (and find links to all the drafts), but here’s a quick summary:

  • The DNSOP (DNS Operations) Working Group will be talking about DNSSEC key and signing policies and requirements for DNSSEC validation in DNS resolvers.  The group will also talk about the “DNSSEC roadblock avoidance” draft before getting into what should be a lively discussion about how we better optimize the distribution of data in the root zone of DNS.
  • The DANE Working Group will discuss a number of ways the DANE protocol can be used with applications such as OpenPGP, SMIME, SMTP and more.  There will also be a discussion of turning the “DANE Operational Guidance” draft into an actual update/replacement for RFC 6698 that defines DANE. It should be very interesting session!
  • The SIPCORE Working Group will discuss a draft about using DANE and DNSSEC for SIP-based Voice-over-IP (VoIP).
  • The TRANS Working Group will explore whether or not there is a role for Certificate Transparency (CT) to play with DNSSEC and/or DANE.
  • The HOMENET Working Group will discuss two different drafts relating to DNSSEC and customer-premise equipment (CPE) such as home wifi routers.

And a couple of other working groups may have DNSSEC-related discussions as well.  All in all it will be a very busy week at IETF 90!

Again, more details and links to all of the associated drafts can be found in the Rough Guide to IETF 90 article about DNSSEC.

If you aren’t able to actually be in Toronto, you still can participate remotely – see the IETF 90 Remote Participation page for more information about how you can join in to the discussions.

If you are in Toronto, please do feel free to say hello and introduce yourself.  You can pretty much expect to find me in all of these various DNSSEC-related sessions (and many of the IPv6-related sessions, too).

The post A Huge Amount Of DNSSEC Activity Next Week At IETF 90 In Toronto appeared first on Internet Society.

Dec 06

Want To Quickly Create A TLSA Record For DANE / DNSSEC?

Generate-TLSA-Record-3Would you like to use the DANE protocol to secure your SSL/TLS certificate via DNSSEC?  If so, the first step is to generate and publish a “TLSA record” in DNS – and that record generation can be a stumbling block for some people.  While there are command-line tools such as just the basic “openssl” or Paul Wouter’s “hash-slinger“, Shumon Huque recently released a web interface that lets you easily create a TLSA record.  As Shumon writes about on his blog, the tool is at:

https://www.huque.com/bin/gen_tlsa

All you need to do is to set the type of TLSA record you want to create, paste in the X.509 certificate, and enter the appropriate port number, protocol and domain name.  Shumon’s script then generates the appropriate TLSA record that you can paste into your DNS zone file.

Last year, Shumon wrote a post on “DNSSEC and Certificates” where he walked through how to do this using openssl on the command line – this latest post now builds on that to make it even easier.

It’s excellent that Shumon has made this tool available and we look forward to seeing many more TLSA records out there!  (If you have a SSL/TLS cert for your website, how about adding a TLSA record today?)

The post Want To Quickly Create A TLSA Record For DANE / DNSSEC? appeared first on Internet Society.

May 01

Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default

Google logoIt’s official… Google’s Public DNS service is now performing DNSSEC validation for all DNS queries by default!

When news broke back on March 19 that Google had enabled DNSSEC validation on its Public DNS service, there was some initial concern after people noticed that Google was only performing the DNSSEC validation when requested. This led to a clarification a few days later from Google that their initial rollout required a client to request DNSSEC validation so that they could test out the service – and that full validation was coming soon.

The Official Word

Yesterday, Google’s Warren Kumari posted in the dnssec-deployment mailing list that full validation IS now happening:

We have recently enabled validation by default globally, and you should now get SERVFAIL for validation failures.  Apologies again for the original, unclear announcement.

The blog / documentation has not been updated yet (that will probably happen in the next few days) but we wanted to give you the good news as soon as possible.

And indeed a quick test to see if I could get the DNS records for a test domain known to have a bad DNSSEC signature did produce the expected “SERVFAIL” message and correctly did not return any DNS records:

$ dig @8.8.8.8 www.dnssec-failed.org

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60286
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.dnssec-failed.org.        IN    A

This is great news for those of us who are advocates of DNSSEC and means that anyone using Google’s Public DNS servers for DNS name resolution are now automatically receiving the greater security of DNSSEC. Anyone using those servers will know that (for signed domains) the information they are getting out of DNS is the same information that the domain operator put into DNS – and not that of an attacker seeking to have you go to some other site.

If you, too, want to gain access to the increased security of DNSSEC, all you have to do is configure your computer or home router to have as its DNS servers the Google Public DNS servers:

8.8.8.8
8.8.4.4

2001:4860:4860::8888
2001:4860:4860::8844

That’s it!

Moving DNSSEC Validation Even Closer

As awesome as this move by Google is (and it is awesome), you could still increase the security provided by DNSSEC a bit more.  Because Google’s Public DNS servers are not on your local network and are rather somewhere out across the Internet, there is still a chance that an attacker could insert himself or herself between you and Google’s DNS servers.  The attacker could then pretend to be sending you back the correct information and masquerading as Google’s Public DNS servers.

To get the highest level of DNSSEC security, you ideally want to be performing the DNSSEC validation on at least your local network and potentially even your local computer. There’s a great whitepaper out from the folks at SURFnet called “Deploying DNSSEC: Validation on recursive caching name servers” that explains how you can simply enable DNSSEC validation for three of the common DNS servers used by enterprises and networks today.

Hey, if Google can enable DNSSEC validation, why can’t you?

If you can’t do DNSSEC validation locally (for example, if you only have a home WiFi router that doesn’t perform validation) then getting the validation performed at your ISP may be the next step… and if your ISP won’t do DNSSEC validation then you really have no other choice but to use a service like Google’s Public DNS services. Their DNSSEC validation is definitely far better protection than none at all!

Again, kudos to Google’s Public DNS team for taking this step and we look forward to the day when all DNS resolvers just perform DNSSEC validation automatically.

The post Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default appeared first on Internet Society.