RFC2136 The peer didn't know the key we used

[kub3let]

@rseichter thank you for creating LetsDNS, I can see you put quite some effort in to it.

I just wanted to say it took me some time to figure out why it always told me The peer didn't know the key we used with action = dane-tlsa although the same key works with certbot just fine.

The problem is LetsDNS requires a HMAC-SHA256 TSIG key, while certbot let's you define what your key type is via dns_rfc2136_algorithm and usually you would use a HMAC-SHA512 key.

I assume the key type handling would need to be added here:

letsdns/letsdns/liveupdate.py

Lines 40 to 46 in e9c24ad

	path = conf.get('keyfile')
	if path:
	with open(path, 'r') as f:
	keyring = tsigkeyring.from_text(json.load(f))
	else: # pragma: no cover
	keyring = None
	update = Update(zone=zone, keyring=keyring)

trace:

Traceback (most recent call last):
  File "/usr/local/bin/letsdns", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/var/lib/letsdns/.venv/lib/python3.11/site-packages/letsdns/__main__.py", line 42, in main
    n = traverse_config(config)
        ^^^^^^^^^^^^^^^^^^^^^^^
  File "/var/lib/letsdns/.venv/lib/python3.11/site-packages/letsdns/core.py", line 65, in traverse_config
    _class.lifecycle(conf, _class())
  File "/var/lib/letsdns/.venv/lib/python3.11/site-packages/letsdns/liveupdate.py", line 35, in lifecycle
    return rdata_action_lifecycle(conf, action)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/var/lib/letsdns/.venv/lib/python3.11/site-packages/letsdns/tlsa.py", line 71, in rdata_action_lifecycle
    return action.execute(conf, dataset=dataset)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/var/lib/letsdns/.venv/lib/python3.11/site-packages/letsdns/liveupdate.py", line 56, in execute
    response: Message = query.tcp(update, nameserver, timeout=t)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/var/lib/letsdns/.venv/lib/python3.11/site-packages/dns/query.py", line 992, in tcp
    (r, received_time) = receive_tcp(
                         ^^^^^^^^^^^^
  File "/var/lib/letsdns/.venv/lib/python3.11/site-packages/dns/query.py", line 915, in receive_tcp
    r = dns.message.from_wire(
        ^^^^^^^^^^^^^^^^^^^^^^
  File "/var/lib/letsdns/.venv/lib/python3.11/site-packages/dns/message.py", line 1317, in from_wire
    m = reader.read()
        ^^^^^^^^^^^^^
  File "/var/lib/letsdns/.venv/lib/python3.11/site-packages/dns/message.py", line 1214, in read
    self._get_section(MessageSection.ADDITIONAL, adcount)
  File "/var/lib/letsdns/.venv/lib/python3.11/site-packages/dns/message.py", line 1158, in _get_section
    self.message.tsig_ctx = dns.tsig.validate(
                            ^^^^^^^^^^^^^^^^^^
  File "/var/lib/letsdns/.venv/lib/python3.11/site-packages/dns/tsig.py", line 305, in validate
    raise PeerBadKey
dns.tsig.PeerBadKey: The peer didn't know the key we used

[rseichter]

Thank you for reporting this; I will need to look into the matter. During development, I used BIND9 and its default settings (at the time). The potential need for using different hashing algorithms did not show up on my radar back then.

[kub3let]

I made a PR but it is untested !

#3

Maybe you could take a look at it.

I will see if I can test it myself on the weekend, but I have not much experience with pyton.

[rseichter]

I will have a look, but as stated in the documentation, I don't currently accept code contributions. This is meant to avoid copyright troubles. Also, there seems to be a fresh release of dnspython available, so I should check that one for how key material is handled in the library.

[kub3let]

I tested it now and it works just fine, please include it in LetsDNS since I need it and don't want to manage a fork. Also this feature is essential if you want to use LetsDNS with RFC2136 IMHO.

I give you the full rights to do with the source code whatever you want . Just commit it under your name.

[rseichter]

Thank you. Like I said, I am going to look into this issue, hopefully over the weekend. Conforming with RFCs is important to me as well.

[rseichter]

Issue resolved with LetsDNS release 1.2.0.