“DNSSEC Mastery” status, dates, and acknowledgements

Monday night, I sent DNSSEC Mastery to copyedit. If all goes well, it’ll be back at the beginning of next month. Making corrections from copyedits is a quick task.

The copyedit-ready manuscript has been uploaded to LeanPub, so if you’re one of the early purchasers, it’s in your account for you. The manuscript is now technically correct.

I’m going to a writer’s workshop on 5 April. If all goes well, I’d like to have the ebook available before I go. That would also let me hand it to the print layout team by then. Which means that I would have print copies for BSDCan, of which I am a sponsor.

It might not be the final book. But I’d like to have a few proofs to give to reviewers and possibly even for the charity auction. (“It’s not defective, it’s limited edition.”)

I think it’s very important to appreciate those who help me, and publicly acknowledge that appreciation. In that spirit, here are the credits for DNSSEC Mastery.

Acknowledgments

A special thanks to my pre-publication reviewers: Henrik Lund Kramshøj, Fredrik Ludl, Jan-Piet Mens, Scott Murphy, Mike O’Connor, Eivind Olsen. Notably, Alan Clegg and Carsten Strotmann went above and beyond in reviewing the book.

Before even starting this book, I asked poor Doug Barton of BlueCat Networks to be my lead technical reviewer. Mutual friends tell me that he’s stopped moaning “Oh, the pain,” and should be able to talk coherently any day now. I do hope he’s learned his lesson.

Any errors in this book crept in despite the efforts of these fine folks.

As an experiment, I published in-progress versions of this manuscript on LeanPub (https://www.leanpub.com). To my surprise, many people bought the incomplete book. To my greater surprise, several people chose to overpay for it. I want to thank everyone who purchased the in-progress book. While I won’t publically name and shame those who wanted to give me a tip, I will say thanks to parts of their email addresses: sven, nawfal, bonetruck, alejandro, olgamirth, axel, shori, marcus, and cdjk.

Sadly, those early drafts included plain bad advice caught by the technical reviewers. My best fans got ripped off. I hope that they, too, have learned a valuable lesson.

This book is for the folks trying to keep their name service intact despite the miscellaneous scumbags trying to break it. For all the folks on Twitter who encouraged @mwlauthor to write it. And, of course, for She Who Must Be Obeyed.

Diagnosing “+Limiting icmp unreach response from…” with tcpdump

Anyone who has run a FreeBSD server for any length of time has seen these messages in their daily security emails. (You do read those, right?)

+Limiting icmp unreach response from 296 to 200 packets/sec
+Limiting icmp unreach response from 337 to 200 packets/sec
+Limiting icmp unreach response from 318 to 200 packets/sec
+Limiting icmp unreach response from 535 to 200 packets/sec
+Limiting icmp unreach response from 332 to 200 packets/sec
+Limiting icmp unreach response from 328 to 200 packets/sec

Way back in the Bronze Age, I learned that this mean “someone is port scanning.” The usual advice is to disable these messages by setting the sysctl net.inet.icmp.icmplim to 0. This silences the messages. I’m guilty of giving that advice myself.

What it really means is that something is sending your server UDP packets on a port that isn’t open. This could be a port scanner. It could also be a host legitimately trying to reach your host for a service it thinks you provide, or a service your host should be providing but isn’t.

I could go to my netflow collector and run a few commands to track down where these packets are coming from. In this case, the problem host is my netflow collector. I’m somewhat leery of using a tool to diagnose itself. An initial check shows that everything on the collector is running, so let’s see if it’s still happening with tcpdump.

I could run tcpdump -i em0 icmp and see all the ICMP traffic, but that’s inelegant. I don’t want to miss the traffic I’m looking for amidst a torrent of ICMP. And why have my brain filter traffic when ICMP will do it for me?

The first step is to identify exactly what we’re looking for. ICMP isn’t a monolithic protocol. Where TCP and UDP have ports, ICMP has types and codes. You can find a friendly list of types and codes here, or my readers can look in my Network Flow Analysis.

ICMP’s “port unreachable” message is type 3, code 3. Unlike TCP ports, the type and code are separate fields. Type 3 is “destination unreachable,” while the code indicates exactly what is unreachable — the port, the network, whatever. Type is ICMP field 0, while code is ICMP field 1. Tcpdump lets you filter on these just like the more familiar port numbers. Enclose more complicated filter expressions in quotes.

# tcpdump -ni em0 "icmp[0]=3 and icmp[1]=3"
10:01:03.287063 IP 10.250.250.10 > 192.0.2.214: ICMP 10.250.250.10 udp port 11022 unreachable, length 36
10:01:03.331388 IP 10.250.250.10 > 192.0.2.214: ICMP 10.250.250.10 udp port 11022 unreachable, length 36
10:01:03.356052 IP 10.250.250.10 > 192.0.2.214: ICMP 10.250.250.10 udp port 11022 unreachable, length 36
10:01:03.378256 IP 10.250.250.10 > 192.0.2.214: ICMP 10.250.250.10 udp port 11022 unreachable, length 36
10:01:03.411046 IP 10.250.250.10 > 192.0.2.214: ICMP 10.250.250.10 udp port 11022 unreachable, length 36
10:01:03.437458 IP 10.250.250.10 > 192.0.2.214: ICMP 10.250.250.10 udp port 11022 unreachable, length 36
10:01:03.457858 IP 10.250.250.10 > 192.0.2.214: ICMP 10.250.250.10 udp port 11022 unreachable, length 36

The host 192.0.2.214 is constantly trying to reach my collector on port 11022. 192.0.2.214 is my busiest border router.

That’s a router. This is a netflow collector. Maybe it’s netflow traffic? Let’s see.

# tcpdump -ni em0 -T cnfp ip host 192.0.2.214 and udp port 11022
192.0.2.214.11022 > 10.250.250.10.11022: NetFlow v5, 1897575.270 uptime, 1363184870.488773000, #1285199613, 30 recs
started 1897571.570, last 1897571.570
...

Yep. Either my router or my collector is misconfigured. And my monitoring system is misconfigured, because it should have caught that the collector process isn’t running. Or I should have noticed that I wasn’t actually getting any flow files from the collector running on another port.

Now to go back in time, find that young punk who wrote Absolute BSD, and whup his butt.

Tech Book Contracts

Several tech authors recently contacted me for advice about problems with their publishers. (No publisher in particular, mind you.) Apparently I’ve been doing this long enough that I’m considered an expert. I’m writing this post so I can point these people at it later.

If you’re a tech author thinking of asking for my wisdom: this is basically it.

None of this is anything against any particular publisher or any particular writer.

This is not legal advice. I am not a lawyer, nor do I play one on TV, nor do I write stories involving lawyers.

No, I will not look at your publishing contract.

I’ll point you to resources for fiction authors. Genre authors have been bludgeoned over the head repeatedly with this stuff. Tech book authors? Not so much. Most tech authors are technologists first, gamers second, have another hobby or a family or something, and write books as a distant fourth or fifth. Fiction writers who make a living writing have been forced to defend themselves against predatory practices. (“Fool me once, shame on me. Fool me and all of my peers for years, we will gang up on you and burn down your house.”)

Now that the disclaimers are done:

So, you’ve written a tech book. Or you want to write a tech book. You’ve found a publisher. They express interest, and send you a contract. Hurrah! You’re going to be published! An antload of fame and a soupcon of fortune will be yours!

STOP.

Do not sign the contract.

Techies in particular have a disdain for paperwork, but the wrong contract can ruin your life. Even if you know the publisher. Even if the publisher is your best friend, like, ever. Even if you’ve been trained to automatically click on “I accept the license terms.” Overcome that disdain.

READ THE DANGED CONTRACT.

Maybe Microsoft isn’t going to come after you for that extra copy of Windows 95, but your publishing contract is much more personal. It’s aimed at you. And contracts tend to favor the side that writes the contract. Even the most scrupulously even-handed contract by the most good-hearted publisher in the world includes provisions where you agree to do stuff. It’s not as simple as “you write the book, you get paid.”

By signing the contract, you’re agreeing to do what the contract says. The written contract overrides anything verbal. That handshake deal? Utterly worthless. The email paper trail? Also worthless in the face of the contract. Mutual understandings? Nonexistent.

A publishing contract exists between you and the publishing company. The publishing company is not the nice acquisitions editor you’ve been talking to. It’s a legal entity owned by someone. That legal entity can be sold to another entity at any time. The new owner can fire the nice editor and assign you one with a ninth grade diploma and a deeply rooted, highly personal distaste for your work, your subject, your family, your religion, your college, and your personal aroma, who wants to know what button to push to make Microsoft Word do this FECN thing you’re talking about.

I agree that the publisher’s attitude and reputation are important. I work with No Starch Press because they’re awesome to work with. They focus on making the best book possible. That’s great. But:

The only binding agreement is the contract.

Read it. Understand it. Print it out. Highlight anything you don’t understand. Highlight anything that might be a legal term of art. Highlight anything that could be used against you.

What sorts of things should you look for? There are things that real publishers include in their contracts. The exact terms differ, but the bones are there. If any of these things are missing from a contract, the publisher is not a real publisher. Run away. Run away quickly. Put their gmail address in your spam bucket and blacklist their IP address at your network border.

  • Real publishers offer advances against royalties. No Starch has an interesting model where they offer a large advance and a small royalty, a middling advance and a middling royalty, or no advance and a great big freaking royalty. I’m playing a long game, so I take the big royalty — but the important thing is, they offered me an advance and I chose not to take it. (An advance is an interest-free loan against future royalties; you don’t get any more money until your royalties exceed the advance.) A publisher that does not offer a royalty is not a real publisher.
  • Real publishers say what rights they’re buying. This is frequently World English Rights. Some, such as NSP, also buy world rights, sell translation rights, and share the proceeds with the author. Whatever those rights are, they’re spelled out. Authors do not sell books. They license copyright.
  • How long does the contract last? For technology books, “life of copyright” is not uncommon. But tech books have a shelf life. The rights to Windows 2.0 Unleashed for Complete Dummies are basically worthless now. Still, the contract should give a length. It should also include conditions under which the contract can be terminated early, and you get those rights back.
  • Due dates. Can you really fulfill everything in the contract in the stated time? Are you assuming everything goes correctly? What about when things go wrong? What if your appendix ruptures a week before the contract is due? The publisher is signing contracts for printing, distribution, and marketing based on your commitments. If a contract doesn’t include a due date, someone could take an advance and never write the book. I’ve seen a tech book contract without a due date.
  • How will the publisher request changes and/or reject the manuscript? How long will you have to do revisions?
  • When will they publish? They should say they will publish within X days/months/years of manuscript delivery. If they don’t publish, you never get royalties.
  • Will they promote the book? If it’s not in the contract, it doesn’t have to happen.
  • When do you get paid? Publishing has a baroque distribution system, including things like “rolling reserves against returns.” It’s an infuriating system. Any engineer or business person could design better, but the system was built by people who love books. You will get paid… eventually.
  • Then there’s warrants and indemnifications. It’s reasonable to warrant that you are the author of the book, and that you have the rights for all content. It’s not reasonable to warrant your book against any and all possible damages that might be caused by it. If one of my books mortally and morally offends someone and they decide to sue the publisher, too bad.
  • How many copies do you get? They’ll go quick.
  • How can YOU terminate the contract? Under what circumstances? I’ve seen tech publishing contracts without termination clauses.
  • How can THEY terminate the contract?

    You might see other things. NSP has a nice “artistic control” section where they enumerate the various decisions that they’ll consult me on. They won’t guarantee to follow my desires, which is why my books don’t come with a glossy cover featuring an extreme close-up of my smiling face, but being asked gives me warm fuzzies. While NSP takes my input seriously, it won’t help me get my way against Ninth-Grade Diploma Editor.

    Lots of details in publishing contracts can bite you. Some of these seem harmless at first glance. My favorite example is the “right of first refusal,” where the publisher says they get first dibs on your next book, under the same contract terms. This seems like it’s to your advantage, but it’s not. The proper form for the publisher to express interest in your next book is by saying “Hey, what are you writing next? We’d really like a look.” If your first book is a smash hit at Wal-Mart, you want freedom to negotiate your next contract. If your publisher totally screws up your first book, you want freedom to work with a different publisher next time. If the publisher treats you well, follows their own terms, and produces a good book, you will want to stick with them — they don’t need this clause. There are really good reasons why I’ve stuck with NSP for over a decade, despite being repeatedly courted by editors for other publishers.

    Publishers have all kinds of tricks. They’ve been in the business longer than you. They have better lawyers. Don’t fear them. Do respect the crap out of them.

    If you really want to get into how contracts can abuse you, check out genre writer resources like Writer Beware. And you should really read Kris Rusch’s Business Rusch blog every Thursday. They’re for fiction, but Rusch has been a writer long enough to have suffered every abuse and indignity a publisher or agent can perpetrate. Learn from her mistakes, as you don’t have time to make them all yourself.

    Now that you have your marked-up contract, talk to someone about it — not your buddy, and not an experienced author. Hire a lawyer, preferably one with publishing experience. A couple hours of a lawyer’s time to explain the contract to you might save you years of grief. And yes, I mean years.

    Most publishing contracts include at least one objectionable clause. If a publishing contract includes no objectionable clauses, you do not understand the contract. Group the problems into “things you’d like changed” and “things that I will not accept.” This is where that lawyer comes in really handy, especially a lawyer experienced in publishing.

    Talk with the publisher about the problem terms. Some terms cannot be changed — the publisher pays all their royalties at the same time, so you’ll get paid quarterly or twice a year or once a leap decade along with every other author. Some terms can change. Ask. See what you can get.

    If one of your deal-breakers can’t change?

    Walk away. That’s what a deal-breaker means.

    Or accept what follows.

  • Some “Absolute OpenBSD 2/e” dates

    No Starch intends to send AO2e to the printer on 22 March 2013. This would give a “bound book date” of approximately 12 April. Books would be in their hands roughly 19 April. They’re really good about shipping books to purchasers as soon as possible.

    Note that DNSSec Mastery should be available in ebook form about then. Not only do I have two books coming in 2013, I have two books coming in April 2013.

    All dates are subject to change based on the whim of the printer, phase of the moon, gasoline shortages, insurrections and iniquity and incivility, or any other reason whatsoever.

    Any Firefox add-on people out there?

    I’ve had really good luck asking random people to do work for me, so I’m going to try it again.

    RFC6698 defines the DANE protocol for attaching information to DNSSEC-secured DNS. Notably, you can validate SSL certificates via DNS. This is a game-changer. The key here is the TLSA DNS record.

    Web browsers don’t support this yet, but there is the Extended DNSSEC Validator Firefox add-on at os3sec.com, with source at github.

    If you have the newest version of the add-on installed, sites like https://www.dnssec.michaelwlucas.com/ show up as secure. There is no “invalid certificate” warning. That’s because I’ve published a TLSA record for this zone, telling the browser that the certificate with fingerprint such-and-such on this port on this host is trustworthy. (Install the plugin from the github source, not from the xpi on the site.)

    The interesting thing about this add-on is that it uses libunbound to perform DNSSEC validation at the client. Your local DNS servers don’t need to support DNSSEC. All you need to hack on this plugin is a desktop.

    But the add-on doesn’t support BSD — it’s Linux, MS, and Mac only. The add-on authors don’t have time for BSD support, but gave me a couple hints on how to implement it. The plugin can’t find libunbound on BSD.

    That seems like it would be easy to do. I’m capable of building the add-on from source, but I’ve never programmed any add-ons before. The source code looks like it’s easy to hack, but my efforts all segfaulted Firefox. Obviously, I need more expertise.

    So, if you know anything about Firefox add-ons, or have ever wanted to hack on them, this is your chance.

    DANE and TLSA are the killer applications for DNSSEC. The ability to validate cryptographic certificates via DNS is a game changer. (Cliche, but true.) You can have separate certificates for separate ports on a host. With DANE, there’s no longer any need for a self-signed certificate to be a disadvantage.

    Absolute OpenBSD blurbs

    One of the tasks on an author’s to-do list is gathering blurbs for the new book. A blurb is blatant promotion from a name a reader might recognize. Preferably a name that has some bearing on the topic of the book. You frequently see this in fiction, where the first couple of pages are other people saying “this book is fantastic! It cured my leprous bulemia!” Most often it’s multiple authors each saying nice things about the others’ books.

    “Nice,” I think. “They’re doing each other favors. It’s blatant backscratching. When I’m successful, I swear I will never do that.”

    For the first time, the fine folks at No Starch Press asked me to get blurbs for the new book. Apparently I have reached the point where I merit that. It’s not bad enough that going around asking people to praise me is like begging for approval. No, I’m a computer dork. Telling others about my accomplishments doesn’t come naturally, and doesn’t work well when I try. Apparently this is common.

    (For the record, I don’t particularly like bacon. Pig, yes, but bacon, not so much. I’m aware this is heresy on the Internet. Deal.)

    So I have my mission: get blurbs. I think about who I know, who might be interested in the book. With growing horror, I realize: most of them are writers. All of them are friends on some scale, somewhere on the spectrum from “call up when you’re in town and we’ll get gelato” to “I heard you need to borrow a kidney, my back is already shaved.”

    I guess I’m going back on my younger and dumber self’s sworn word. Dammit.

    At least they all wanted to see the book before they said nice things about it. That’s mild balm to my conscience.

    So, I’ve gotten a couple of them back and felt like sharing them. Actually, no, I misspeak. I don’t feel like sharing them. But if something embarrassing is going to happen, it’s best to take control and get it over with. So, in that spirit:

    From George Rosamond, a founding member of NYC*BSD User Group and noted detester of string beans and beets:

    “The space for BSD books is small, indeed.

    All the BSDs provide excellent documentation, from their handbooks and FAQs to their native manual pages. Got a question? There’s a good chance you will find the answer in the official documentation.

    Michael W. Lucas manages to squeeze into that ‘other’ space. He engages the reader. He answers those specific questions and addresses those methods that a manual page or online documentation can’t approach.

    He is the modest sysadmin sitting next to you in front of an OpenBSD box, narrating as you dive into an operating system that does things minimally without fuss. He’s not perched up high on a pedestal, preaching or obfuscating his words. He is a layperson’s tutor, who’s working through the same issues the average sysadmin does.

    So buy this book. Buy it because for the amateur or intermediate OpenBSD end-user, you will flatten any learning curves real or perceived. You will find the elegant simplicity of OpenBSD, while sometimes discouraging for the uninitiated user, is a fruitful path for building systems that just run.”

    And from Chris Sanders, author of the essential Practical Packet Analysis and better human being than I am:

    “It’s rare to find a book that can cover so much technical content while still being engaging and enjoyable to read. Absolute OpenBSD, 2nd edition, is one of those books that achieves that with flare. Whether you are an experienced OpenBSD user seeking a functional desk reference, or a new OpenBSD user seeking to gain the carnal knowledge necessary to become an expert, then Absolute OpenBSD is the book you have to have.”

    Somehow, I don’t think NSP will let me use those blurber descriptions, though. Pity.

    [UPDATE] Oh, yes, the plug. Forgot the plug. Preorder Absolute OpenBSD, 2nd Edition. Get ebook and print together for one low price. Use coupon code ILUVMICHAEL for a 30% discount and give me a couple extra bucks. Or, if you’re in a place where shipping from the US is prohibitive, get it locally. Whatever. In either case, thank you.

    DNSSEC Tech Reviewers Wanted

    Last night, I finished the first draft of DNSSEC Mastery. If you’re one of my fans who wants to see the existing work, a pre-pub version is now available on LeanPub.

    Now I’m looking for people familiar with DNSSEC on BIND to read the book and tell me where I’ve screwed up.

    This book is for an established DNS administrator who wants to deploy DNSSEC. I assume you know what named.conf is, why you don’t put PTR records in a forward zone, and so on. The goal is not to get 100% of the people 100% there, but to get 90% of the people 100% there and ground the other 10% so that they can identify their own rough edges. (The idea is roughly similar to my SSH Mastery or Cisco Routers for the Desperate.)

    The contents are:

      1. Introducing DNSSEC
      2. Cryptography and DNSSEC
      3. How DNSSEC changes DNS
      4. DNSSEC Resolver
      5. dig and DNSSEC
      6. Securing Zone Transfers
      7. KSKs and ZSKs
      8. Signing Zones
      9. Debugging
      10. Key Rotation
      11. Delegations and Islands of Trust
      12. DNSSEC for Data Distribution (needs better title, it’s SSHFP and TLSA)

    Many of these chapters are short. Chapter 10 is not. The writing is rough, especially near the end.

    So, if you know DNSSEC, and you’re interested in spreading the DNSSEC gospel, and you have enough time to read something about half the length of a short paperback novel, contact me via email at mwlucas at my domain.

    I’d need any comments by 15 March. I plan to revise that week and get the book into copyedit, so it can be out for BSDCan. Barring any really appalling revelations from the reviewers, that is. I’d rather the book be late than wrong.