API for Zone Signer

[jschlyter]

I have started work on a zone signer in check https://github.com/jschlyter/dnspython/tree/rdataset_signer. The gist of the code is in:

• https://github.com/jschlyter/dnspython/blob/rdataset_signer/dns/dnssec.py#L1224
• https://github.com/jschlyter/dnspython/blob/rdataset_signer/tests/test_dnssec.py#L918

Things missing:

• A more generic API where one can choose between NSEC and NSEC3. Even though NSEC3 might not be implemented from the start, we might want to pass a signing policy to the zone signer anyway.

[jschlyter]

Two API designs I can think of:

1. an abstract class ZoneSigner with a sign() function. The NSEC zone signer can build upon this, and a future NSEC3 signer as well. The RRset signer function can either be a part of the signer class, or pass as Callable argument to the constructor.
2. a functional sign_zone() where a signing policy object is passed as well as the RRset signer. The policy would state things like NSEC or NSEC3 with N interations and salt X.

I personally like option 1 better, but 2 is more in line with dnspython in general I believe.

[bwelling]

What would you include in a signing policy object?

In my experience, the dnspython way is typically "method with a lot of parameters" (dns.message.make_query with 13, or dns.query.https with 14), so something like the following.

def sign_zone(
    zone : Zone,
    txn : Optional[Transaction] = None,
    keys : Optional[List[Tuple[PrivateKey, DNSKEY]]] = None,
    ksks : Optional[List[Tuple[PrivateKey, DNSKEY]]] = None,
    inception: Optional[Union[datetime, str, int, float]] = None,
    expiration: Optional[Union[datetime, str, int, float]] = None,
    lifetime: Optional[int] = None,
    nsec3 : Optional[NSEC3PARAM] = None
) -> None:

I'm sure that's missing some things; it's only a starting point. I think it covers the common case, and could be extended to handle more cases. It's also just my opinion.

[rthalley]

I think what Brian suggests is most in keeping with dnspython's style (for better or worse!). I'm not sure the abstract signer approach is good as while there are differences with NSEC3, there are also many shared things, and I'm sure it will split well into to instances. The policy object passed to function seems less good in this case, as the policy is basically everything, so it's seems you'd be better off with either function arguments or a class rather than a separate data-only policy class.

[jschlyter]

Yes, we can do that. I'd like to be able to specify an RRset signer function though, but that could be split into a special case - it would allow custom things like inception/expiration jitter, CSK instead of KSK/ZSK etc. The nsec3 parameter makes sense.

I'll do some more testing and report back.

[bwelling]

Having a way to override the signing behavior sounds reasonable enough.

As for CSK vs KSK/ZSK, I assumed that if you wanted separation, you'd pass both keys and ksks, and if you didn't, you'd just pass keys (and that's why it was called keys, and not zsks). But that might be too subtle.

[jschlyter]

I've done some more tweeks.

[jschlyter]

@bwelling I started to use contextlib.nullcontext() as you suggested, but mypy is not happy. Help appreciated.

[bwelling]

There are some other examples elsewhere in dnspython, but here's one using zone transactions. As far as I can tell, mypy is happy with it.

def dump(
    zone: dns.zone.Zone,
    txn : Optional[dns.transaction.Transaction] = None
) -> None:
    if txn:
        cm : contextlib.AbstractContextManager = contextlib.nullcontext(txn)
    else:
        cm = zone.writer()
    with cm as wtxn:
        for node in wtxn:
            print(node)

[jschlyter]

Regarding KSK vs ZSK:

1. sign RRset according to flags.SEP: KSK signs DNSKEY/CDS/CDNSKEY, ZSK signs all other RRset
2. explicit ksk/zsk split

I think I'd prefer (1) and always include all DNSKEYs use for signing in the zone. If one want to do it differently, one can always use a custom RRset signer. if there's not both SEP and non-SEP keys, sign all RRsets with all keys.

[bwelling]

I don't have a strong preference here, but I thought the normal usage was that the ZSK signed all RRsets, including the DNSKEY (and it does in isc.org, for instance). I'm not sure about CDS and CDNSKEY, as I've never used either and don't know who would have one.

[jschlyter]

ZSK MAY sign the DNSKEY RRset, but I would say it is NOT RECOMMENDED. CDS/CDNSKEY MUST be signed by KSK.

[jschlyter]

#911 submitted.