Subject: Consider revising the logging related to expired TSIG signatures MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Disposition: inline X-RT-Interface: Web Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: binary X-RT-Original-Encoding: utf-8 X-RT-Encrypt: 0 X-RT-Sign: 0 Content-Length: 1086 One of our customers encountered a situation where an underpowered VPN router (evidently with very large buffers) took over 5 minutes passing along the TCP stream for a zone transfer. This caused the signatures to be expired when named received the packets and attempted to verify them. The customer was initially sent off on the wrong troubleshooting path thanks to our log messages: 30-May-2017 16:44:46.814 xfer-in: error: transfer of 'SNIP/IN' from 10.54.53.121#53: failed while receiving responses: clocks are unsynchronized 30-May-2017 16:44:46.814 xfer-in: info: transfer of 'SNIP/IN' from 10.54.53.121#53: Transfer status: clocks are unsynchronized These messages sent them down the path of scrutinizing the (correct) NTP configuration and relative clocks. They have asked: Something more descriptive that would point away from NTP/TSIG as the sole cause...even if as simple as "transport problem or clocks are unsynchronized". I'm going to add that these messages would also be emitted if someone were to replay (intentionally or otherwise) signed messages. bconry