[ISC-Bugs #44733] [ISC-support #10477] Log the rdata when nsupdate deletes a single RR
Currently we see this:
21-Feb-2017 12:35:20.295 client 127.0.0.1#49131: updating zone 'foo.co.uk/IN': adding an RR at 'foo.co.uk' NS ns2.foo.co.uk. 21-Feb-2017 12:35:20.295 client 127.0.0.1#49131: updating zone 'foo.co.uk/IN': adding an RR at 'foo.co.uk' NS ns3.foo.co.uk. 21-Feb-2017 12:35:20.296 zone foo.co.uk/IN: sending notifies (serial 59) 21-Feb-2017 12:35:53.752 client 127.0.0.1#49131: updating zone 'foo.co.uk/IN': deleting an RR at foo.co.uk NS 21-Feb-2017 12:35:53.757 zone foo.co.uk/IN: sending notifies (serial 60)
21-Feb-2017 12:29:53.197 client 127.0.0.1#49131: updating zone 'foo.co.uk/IN': adding an RR at 'handbag.foo.co.uk' A 127.0.0.2 21-Feb-2017 12:30:11.546 client 127.0.0.1#49131: updating zone 'foo.co.uk/IN': deleting rrset at 'handbag.foo.co.uk' A
In both cases, I know that I deleted one of several RRs in the same RRset, but named has not logged which one it was. This is really unhelpful if you are trying to troubleshoot historically what happened and when.
Since it's a single RR being deleted - the rdata has to have been specified in the nsupdate request, so update.c has to have it. (It would be a different matter if an RRset or all the RRs for a given name were being deleted).
Please can we upgrade the logging to do this a bit better/more helpfully?
Actually named always records what changed. That record goes into the journal. It is complete copy of what changed and it can be printed out.
Can it also be logged though, since this specific scenario is a singleton RR delete being requested, so we do have the rdata available to do so.
And named manages the journal, potentially rewriting it at any time, to be either larger or smaller, and possibly even throwing it away entirely or recreating it with entirely different contents.
Logging can be easily sent to syslog and from there distributed out to a remote syslog server for archival and retention.
That isn't so easily done with a zone journal file.
More specifically - the case where the nsupdate specifies a single RR delete by providing both the rtype and the rdata in the request.
(I don't think it's necessary to attempt to log when the nsupdate request is for the full rrset or for everything under a specific qname) - then we know that they're all gone - there isn't the same problem of not knowing which RR of several has been deleted.)