> On 14 Sep 2018, at 7:12 pm, Klaus Malorny <klaus.malo...@knipp.de> wrote: > > On 14.09.18 00:55, Mark Andrews wrote: >> I was testing TSIG with a well known key against TLD servers and got the >> following response. Once you get past the bad class field (reported to the >> operator) there were a >> number of other items: >> * the tsig name does not match the request. >> * the algorithm doesn’t match the algorithm in the request. >> * time signed is not set. >> * the fudge value is zero. >> Should these match the request / be set for BADKEY? >> Mark > > > Hi Mark, > > thanks for bringing this to our attention. I have fixed the DNS class, the > key and algorithm name. For the latter two, it makes some sense to return the > values from the request. Regarding the time and fudge, I have currently left > it to zero, as IMHO they have no meaning without having a signature. But I am > open to conviction…
Actually having the clients time and fudge in those fields for BADKEY provides spoofing protection for the unsigned responses. This is especially important with opportunistic TSIG,which is what TSIG with a WKK will be, as there is no longer the presumption that server is configured for the key that there was when TSIG was originally drafted. It’s all about getting answers through acceptance filters. For non opportunistic TSIG the client is still expected to wait for a valid TSIG response even if it sees a BADKEY response. > By the way, the parsing error of DiG seemed to be solely caused by the wrong > class; after changing it to ANY, the RDATA was parsed and displayed correctly. > > Regards, > > Klaus > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
