TTL mismatch handling
Checking TTL mismatches in RRSets. In some cases a TTL mismatch should lead to fatal error and refusing to load/accept zone, in others it should only trigger a warning:
- master zone load: refuse to load the zone, log error
- incoming UPDATE: refuse the UPDATE, log error
- slave zone load (from disk): load the zone, log warning
- incoming [A,I]XFR (slave): accept, but log warning
Currently it always logs the message as warning. To distinguish between warning and (fatal) errors would require minor modification of semantic check errors. @jkadlec should do that.
TESTS:
- I've added tests for zone load on master and slave.
- Tests for [A,I]XFR and UPDATEs will be done by @dsalzman
Merge request reports
Activity
117 /* Prepare additional info string. */ 118 char info_str[64] = { '\0' }; 119 char type_str[16] = { '\0' }; 120 knot_rrtype_to_string(rr->type, type_str, sizeof(type_str)); 121 snprintf(info_str, sizeof(info_str), "Record type: %s.", 122 type_str); 123 124 if (zc->master) { 125 /*! \todo REPLACE WITH FATAL ERROR */ 126 err_handler_handle_error(&err_handler, node, 127 ZC_ERR_TTL_MISMATCH, info_str); 128 return KNOT_EMALF; 129 } else { 130 err_handler_handle_error(&err_handler, node, 131 ZC_ERR_TTL_MISMATCH, info_str); 132 } Semantically, everything seems to be correct.
The error message construction on TTL mismatch is a bit flimsy - the Coverity will complain about unchecked result of
snprintf
.(And I'm not very happy about the propagation of ttl_err through scanner and RR set adding, but it is a best applicable solution at the moment. We've talked about it before.)