“DNSSEC Mastery” now complete, ebook version available!

You can now get the complete DNSSEC Mastery: Securing the Domain Name System with BIND at Amazon, Barnes & Noble, Smashwords, and my personal ebookstore. It should (hopefully) trickle through to iTunes & such before long.

This book was a real education to write. Hopefully it will help improve the state of DNS security across the industry. Various DNS experts have expressed approval of the book, and here’s hoping that the wider world will as well.

The book has now gone on to physical production. Hopefully I will have a proof by BSDCan. We might even auction it off at the end of the con, as the OpenBSD auction did so well.

Review copies are available for folks who regularly review books.

If you should find an error in the ebook, please let me know. Converting an OpenOffice document to umpteen different formats for an incredibly wide variety of devices has its risks. I no longer have a PalmPilot to test that format, for example, and I have a specific model of Kindle that’s probably not the same as yours.

Thanks to everyone for their support.

4 Replies to ““DNSSEC Mastery” now complete, ebook version available!”

  1. Since I have avail greatly from your book , “Absolute FreeBSD” I am interested in this new book. Is there a soft/hard cover form yet?

  2. Another great resource! Thanks for this book.

    Clarification question (and if this isn’t the right forum, please let me know where to post).

    In chapter 1 on basic DNS checking, the text says UDP fragmentation and/or 53/tcp filtering will break DNSSEC, and that pf and other firewalls may be a problem here. Sure enough, I checked two DNS servers behind pf firewalls and found both block UDP fragments (though both allow DNS over TCP).

    My questions:

    1. Which is required for DNSSEC, both fragmentation and TCP, or is just DNS-over-TCP sufficient?

    2. If it is a requirement to allow UDP fragements, what’s a good rule set in pf to do this? I have something like this:

    match in all scrub (no-df max-mss 1440)
    match out all scrub (no-df max-mss 1440)

    But the OARC test still returns truncated results:

    [nycvelo@boonen ~]$ dig +short rs.dns-oarc.net txt @666.1.2.3
    ;; Truncated, retrying in TCP mode.
    “2607:ff38:1::64 DNS reply size limit is at least 4055”
    “Tested at 2013-06-12 18:55:04 UTC”
    “2607:ff38:1::64 sent EDNS buffer size 4096”


  3. You need both. Everything. Unfettered access to port 53.

    I’ve found all kinds of weirdness in packet filters between OS versions. This really varies between releases. On some machines, I had to drop scrub entirely. (Scrub not as effective as you would think, actually, so dropping it isn’t scary.)

    Also, some networks have multiple devices blocking port 53…

Comments are closed.