Support TsigProvider for Server and Transfer #1331
Conversation
|
/cc @Fattouche |
This is largely copied from github.com/miekg/pull/1323 by @Fattouche.
| @@ -74,6 +74,24 @@ func (key tsigHMACProvider) Verify(msg []byte, t *TSIG) error { | |||
| return nil | |||
| } | |||
|
|
|||
| type tsigSecretProvider map[string]string | |||
There was a problem hiding this comment.
This is good for a default TsigProvider, however it still doesn't solve the problem described in
We need some way for Generate to be able to unwrap the Message so that we can see the query name. This is specifically useful in situations where multiple tsigs have the same name, but exist under a different zone.
There was a problem hiding this comment.
That can be handled either in a separate PR or externally, but yes we do need to do something.
There was a problem hiding this comment.
How common a use case is that do you think?
There was a problem hiding this comment.
I would say it's fairly common. I ran into this problem early on with this library when trying to serve multiple zones that had different primaries, therefore different TSIGs on each primary meaning they could not use the TSIG name as the zone Name.
There was a problem hiding this comment.
Hey @tmthrgd have you thought any more about how we can best obtain the query name from the Generate function. I think having the opposite of TsigBuffer available in a function would make this possible. Alternatively we could consider passing in a context? It would be useful to have contexts everywhere anyway so that we could pass data around without needing to alter signatures.
|
/merge |
Automatically submitted.
This adds support for
TsigProviderto bothServerandTransfer. It also simplifies the implementation forClientandConn.Not sure why I didn't think to do this earlier. A miekg/dns/v2 could just push the
TsigSecretcode out into the callers.This also has the advantage that it doesn't add a bunch of extra code paths throughout, so it's safer to land.
Fixes #1300
Closes #1323
Fixes #1325