Opened 4 years ago

Last modified 4 years ago

#4610 enhancement new

names should support RRSIG and DNSKEY records

Reported by: philmayers Owned by: philmayers
Priority: normal Milestone:
Component: names Keywords:
Cc: p.mayers@… Branch:
Author: Launchpad Bug:

Description

I have code for this and will attach it.

Attachments (2)

twisted-dnssec.patch (13.3 KB) - added by philmayers 4 years ago.
Basic DNSKEY and RRSIG support, including ability to validate a set of RRs against a DNSKEY
dnssec.patch (13.1 KB) - added by exarkun 4 years ago.

Download all attachments as: .zip

Change History (9)

Changed 4 years ago by philmayers

Basic DNSKEY and RRSIG support, including ability to validate a set of RRs against a DNSKEY

comment:1 Changed 4 years ago by philmayers

  • Keywords review added
  • Owner exarkun deleted

I've coded this up today. It's very basic, and needs NSEC and support for verifying wildcard records, but I would welcome comments on the basic approach.

comment:2 Changed 4 years ago by philmayers

  • Cc p.mayers@… added

comment:3 Changed 4 years ago by exarkun

  • Keywords review removed
  • Owner set to philmayers

The approach here seems fine to me (with my superficial level of DNSSEC knowledge). Once this patch is finished, that means Twisted Names will be able to serve these two record types if they appear in a zone file of some sort, right? But it won't make a Twisted Names server really DNSSEC capable, since DS support is still missing? And it doesn't change the client code to actually validate anything, though it does add an API to simplify that?

comment:4 Changed 4 years ago by philmayers

To be a DNSSEC authoritative server requires, at minimum, EDNS (OPT pseudo-RR) and NSEC support (or NSEC3 generation) for negative responses. DS is only required if you have signed child delegations, and is pretty trivial - I will add it.

TBH I'm completely unfamiliar with the Twisted DNS server implementations; in particular how they store their zones internally, which matters for NSEC serving. EDNS support also extends the error code range, which may have significant impact.

So at the moment no - this code wouldn't give you an authoritative server.

The validating recursive resolver again requires EDNS. It also ought to implemenent RFC 5011 support; growing consensus is that resolvers which don't are a menace. And like most recursive resolvers, it's a complex and error-prone job; certainly not something I'd be keen to take on.

What this code *does* let you do (and the reason I wrote it) is implement a dig/drill-like diagnostic tool.

I will look into what is required for OPT/NSEC support.

comment:5 Changed 4 years ago by exarkun

Thanks for explaining that. I don't want to open the door to scope creep on this ticket, I just wanted to know what we'd gain just by adding support for these two record types. The dig/drill-like diagnostic tool use-case sounds worthwhile to me.

comment:6 Changed 4 years ago by exarkun

  • Keywords review added
  • Owner philmayers deleted

comment:7 Changed 4 years ago by exarkun

  • Keywords review removed
  • Owner set to philmayers

Attaching an updated version of the patch which resolves trivial conflicts with the recent SPF additions.

  1. Somewhat lacking in docstrings (not that this will surprise you, but for completness)
  2. PyCrypto. How hard would it to be to use something else here? So far, PyCrypto is almost entirely confined to Conch. My default position is that it would be nice if we could contain it there, and someday fight it off altogether. It is tricky to use correctly, and upstream is unwilling to take patches from Americans (of practical concern because most Twisted developers are American). Also, it frequently changes in ways which break Twisted (often they are nice enough to correct these occurrences, but sometimes we don't catch them before a release goes out). We certainly shouldn't implement RSA ourselves. But what about... KeyCzar? Or something else like that? Is PyCrypto still the best choice for this kind of thing?
  3. twisted.python.hashlib is a cool thing

As far as the DNSSEC-y parts of this go, I should spent some more time with the RFCs to be sure, but it generally seems okay.

Changed 4 years ago by exarkun

Note: See TracTickets for help on using tickets.