Use of stale data during dnssec validation
Today, we had a case where one of our resolvers (9.16.37) failed to return an SOA-record for the TLD 'us'. digging with the +cd flag, returned a value, while delving with +vtrace failed: ;; fetch: us/SOA ;; resolution failed: SERVFAIL Fingers pointed to a failure to validate. I dumped the cache to a file, and then did a flushname of 'us.' digging and delving was then successful. When looking in the dumped cache, I see the RRSIG-record for the SOA-record is marked as 'stale', and the DNSKEY-record (id=54159) is marked as 'pending-answer' Is stale data used during the validation of answers? :: From the dumped cache :: us. 84964 SOA a.cctld.us. admin.tldns.godaddy. ( 1677862753 ; serial 1800 ; refresh (30 minutes) 300 ; retry (5 minutes) 604800 ; expire (1 week) 1800 ; minimum (30 minutes) ) ; secure ; stale 84964 RRSIG SOA 8 1 900 ( 20230402170130 20230303160130 54159 us. OKQQZoU8itxdg2T+AYpefOmGILJZRl1aA9zb NXzYL9sXWsMMlctwod9JkEM08/SYGEHTmaEa M+d9PMAjeeJMiChj3RV3TPGKRDubUbBrNJb2 R15fsjZRcVf8Iebhr0EZ/yxTJl4YzcTbUh9v ffNOEULcPuVJmv0Hda7HKvnBmVJszPZImfLX YIx3SyzRBp7jiZT1t7oyfZSlAbuRjX7zOw== ) ; secure 82614 DS 46144 8 2 ( 0C67E6017124BF19D50BE565CC486FF3CFE2 A278FE2E5983FF97B2A453386419 ) ; secure 82614 RRSIG DS 8 1 86400 ( 2023031605 2023030304 951 . NHCxlyjA2/t38e03sjyEnXMszz/2whq5GFmP Jf2Ttx9bUy1d/gq2n2PiM1BFZYKQvMGynB4f 58NK8905TG1fveBUTouF/eNo2gmHj/uBuPJm g19lPm05tIK5OCCyD+D16K3IncQAjZUKjfcH bT5qE8KF/ofRaO7PgFn27KbQwtnky+F3PXgJ BkFIfkPJ8SFX6WSEaM8FsLojLDiJWllwnoJK Qf6S0Ot8M3yOIb2oKCT0tucB7znRdkm9EEY5 oSe7waJRV+0sQL3rKhJePFVrd/AeTXY6ipaK kIjdEn+1DoxiBAy/E0uhJ18s16USrxcZSSUg D5GfeGeuLiT7f69a+g== ) ; pending-answer 3179 DNSKEY 256 3 8 ( AwEAAatbrQTiZd0FdSVbnkRFiU5jf9ACOPc4 M0CK+G+Gla4gH3ClPunwqBJhvRtMkKdhGE93 lMuzjNkGakBrkFvzwHtIw9pWLxum2Idysf+J xdhfSXNNYEzKcP0lCIjWf+iY2rtXoltVLxgT 2skvDgmbwq+a3Cb/7CAB/SmFRCl8tQJ4YpJl kHiHPbWXljjiPWsj3/52hv45GHKQPi4vRzPe aw0= ) ; ZSK; alg = RSASHA256 ; key id = 54159 3179 DNSKEY 257 3 8 ( AwEAAe5RHQBesQeThYEf56TkLfF5NysJv/H4 g1HeB7pnH25PsMVoVV/anWi7U3dSFsNzJ6nB HwY/sdmxJ/HLunC/mLSo8ugB6G+UgtAgnlL3 u8Uq/3PYiBgpdNL+ldR0luV5WLAx8/1gG8JZ w3Zu9VhurHKdGZso5ajSTFwBiY39lA0wWeDO kZ2z/EV49JODt1i2N6KnvMTe5kD0qHXkP2oH xTWOlf5vqUcmJmgfvLlGB1ROBT84xCm45Sfx 1U4FD8IPiOFrd9f/WcjPcW8MJFmzQmweVfKE pF28s+YZ5wKid3gYESvaCeSvj7FHzdVUCcVh Fr2+XHeB8O8GTLqk7HgfdM8= ) ; KSK; alg = RSASHA256 ; key id = 46144 -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Tools for parsing a dumped cache
The first thing I do when I'm trying to diagnose strange behavior of a resolver, is I dump the cache to a file. Later, I end up trolling through it with less and grep, looking for entries (usually incorrect RRSIG or DS records) which will explain the behavior I saw. I have two questions: Is there a spiffy cache-file-parsing tool out there, which will make this work easier? I'm thinking of something like what Wireshark does for packet-capture files. "Here is an A-record. Here is its RRSIG. Here is a error, because we don't have a DS over here." Is there a way to launch an instance of named, convincing it to "freeze in time"? i.e. "Please start, consume this cache file. Consult only your cache, perform no external queries, and do not expire anything." This would let me reproduce the failure-state and dig and delv at my leisure. -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
