From sshebbar at gmail.com Mon Jan 2 08:25:04 2012 From: sshebbar at gmail.com (Srinivas Hebbar) Date: Mon, 2 Jan 2012 18:55:04 +0530 Subject: [MaraDNS list] deadwood: ttl is not aging on continuous nslookup/dig Message-ID: Hello, With the A record TTL set to 60, the aging stops at "30" as long as I do dig every second. If I stop dig for 30 seconds, the cache expires and new record with ttl 60 is responded by deadwood. This is happening on both 3.0.x and 3.1.x releases. Unless I stop dig for more than 30 seconds, the above record is never get updated. I have lots of LAN clients and the request is coming so often that the old record never expires from the cache. dig LOG: /home/shyam> while [ 1 ]; do dig @localhost test.testing.tindip.com | grep ^test; sleep 1; done test.testing.tindip.com. 60 IN A 2.2.2.2 test.testing.tindip.com. 59 IN A 2.2.2.2 test.testing.tindip.com. 58 IN A 2.2.2.2 test.testing.tindip.com. 57 IN A 2.2.2.2 test.testing.tindip.com. 56 IN A 2.2.2.2 test.testing.tindip.com. 55 IN A 2.2.2.2 test.testing.tindip.com. 54 IN A 2.2.2.2 test.testing.tindip.com. 53 IN A 2.2.2.2 test.testing.tindip.com. 52 IN A 2.2.2.2 test.testing.tindip.com. 51 IN A 2.2.2.2 test.testing.tindip.com. 50 IN A 2.2.2.2 test.testing.tindip.com. 49 IN A 2.2.2.2 test.testing.tindip.com. 48 IN A 2.2.2.2 test.testing.tindip.com. 47 IN A 2.2.2.2 test.testing.tindip.com. 46 IN A 2.2.2.2 test.testing.tindip.com. 45 IN A 2.2.2.2 test.testing.tindip.com. 44 IN A 2.2.2.2 test.testing.tindip.com. 43 IN A 2.2.2.2 test.testing.tindip.com. 42 IN A 2.2.2.2 test.testing.tindip.com. 41 IN A 2.2.2.2 test.testing.tindip.com. 40 IN A 2.2.2.2 test.testing.tindip.com. 39 IN A 2.2.2.2 test.testing.tindip.com. 38 IN A 2.2.2.2 test.testing.tindip.com. 37 IN A 2.2.2.2 test.testing.tindip.com. 36 IN A 2.2.2.2 test.testing.tindip.com. 35 IN A 2.2.2.2 test.testing.tindip.com. 34 IN A 2.2.2.2 test.testing.tindip.com. 33 IN A 2.2.2.2 test.testing.tindip.com. 32 IN A 2.2.2.2 test.testing.tindip.com. 31 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 28 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 test.testing.tindip.com. 29 IN A 2.2.2.2 Thanks, Hebbar. From emredondo at gmail.com Mon Jan 2 09:09:13 2012 From: emredondo at gmail.com (Enrique Redondo) Date: Mon, 2 Jan 2012 11:09:13 -0300 Subject: [MaraDNS list] Unsuscribe Message-ID: -- Enrique M. Redondo (03489) 15-622128 From dsevilla00 at hotmail.com Mon Jan 2 17:13:56 2012 From: dsevilla00 at hotmail.com (david sevilla) Date: Mon, 2 Jan 2012 15:13:56 -0700 Subject: [MaraDNS list] Unsuscribe In-Reply-To: References: Message-ID: from http://www.maradns.org/faq.html6. How do I get off the mailing list?Send an email to list-request at maradns.org with "unsubscribe" as the subject line. so sending an email to list at maradns.org won't help, plus fixing the typo might also help....FYI > From: emredondo at gmail.com > Date: Mon, 2 Jan 2012 11:09:13 -0300 > To: list at maradns.org > Subject: [MaraDNS list] Unsuscribe > > -- > Enrique M. Redondo > (03489) 15-622128 From emredondo at gmail.com Mon Jan 2 17:38:43 2012 From: emredondo at gmail.com (Enrique Redondo) Date: Mon, 2 Jan 2012 19:38:43 -0300 Subject: [MaraDNS list] Unsuscribe In-Reply-To: References: Message-ID: Thanks David!! 2012/1/2 david sevilla > > from http://www.maradns.org/faq.html6. How do I get off the mailing > list?Send an email to list-request at maradns.org with "unsubscribe" as the > subject line. > so sending an email to list at maradns.org won't help, plus fixing the typo > might also help....FYI > > > From: emredondo at gmail.com > > Date: Mon, 2 Jan 2012 11:09:13 -0300 > > To: list at maradns.org > > Subject: [MaraDNS list] Unsuscribe > > > > -- > > Enrique M. Redondo > > (03489) 15-622128 > > -- Enrique M. Redondo (03489) 15-622128 From maradns at gmail.com Tue Jan 3 12:48:51 2012 From: maradns at gmail.com (Sam Trenholme) Date: Tue, 3 Jan 2012 09:48:51 -0800 Subject: [MaraDNS list] Unsuscribe In-Reply-To: References: Message-ID: I have unsubscribed Enrique from the MaraDNS mailing list. - Sam On Mon, Jan 2, 2012 at 2:38 PM, Enrique Redondo wrote: > Thanks David!! > > 2012/1/2 david sevilla > >> >> from http://www.maradns.org/faq.html6. How do I get off the mailing >> list?Send an email to list-request at maradns.org with "unsubscribe" as the >> subject line. >> so sending an email to list at maradns.org won't help, plus fixing the typo >> might also help....FYI >> >> > From: emredondo at gmail.com >> > Date: Mon, 2 Jan 2012 11:09:13 -0300 >> > To: list at maradns.org >> > Subject: [MaraDNS list] Unsuscribe >> > >> > -- >> > Enrique M. Redondo >> > (03489) 15-622128 >> >> > > > > -- > Enrique M. Redondo > (03489) 15-622128 From maradns at gmail.com Tue Jan 3 12:50:08 2012 From: maradns at gmail.com (Sam Trenholme) Date: Tue, 3 Jan 2012 09:50:08 -0800 Subject: [MaraDNS list] deadwood: ttl is not aging on continuous nslookup/dig In-Reply-To: References: Message-ID: Thank you for the Deadwood bug report. I hope to have time over the next few days to investigate this bug. If I can reproduce it, I will then work on fixing the bug. - Sam On Mon, Jan 2, 2012 at 5:25 AM, Srinivas Hebbar wrote: > Hello, > > With the A record TTL set to 60, the aging stops at "30" as long as > I do dig every second. If I stop dig for 30 seconds, the cache ?expires and > new record with ttl 60 is responded by deadwood. > > This is happening on both 3.0.x and 3.1.x releases. > > Unless I stop dig for more than 30 seconds, the above record is never get > updated. > > I have lots of LAN clients and the request is coming so often that the old > record never expires > from the cache. > > dig LOG: > /home/shyam> while [ 1 ]; do dig @localhost test.testing.tindip.com | grep > ^test; sleep 1; done > > test.testing.tindip.com. 60 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 59 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 58 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 57 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 56 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 55 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 54 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 53 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 52 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 51 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 50 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 49 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 48 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 47 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 46 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 45 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 44 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 43 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 42 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 41 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 40 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 39 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 38 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 37 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 36 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 35 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 34 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 33 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 32 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 31 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 28 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 > > > Thanks, > Hebbar. From maradns at gmail.com Tue Jan 3 22:41:05 2012 From: maradns at gmail.com (Sam Trenholme) Date: Tue, 3 Jan 2012 19:41:05 -0800 Subject: [MaraDNS list] deadwood: ttl is not aging on continuous nslookup/dig In-Reply-To: References: Message-ID: Update: I have successfully reproduced this bug and have made a SQA regression for the bug. Today's snapshot (20120103) has this new regression (sqa/sqa_ttl_expire): http://maradns.org/deadwood/snap/ Next: Fix the bug in Deadwood's code. Timeframe: Unknown; hopefully tomorrow. - Sam On Tue, Jan 3, 2012 at 9:50 AM, Sam Trenholme wrote: > Thank you for the Deadwood bug report. ?I hope to have time over the > next few days to investigate this bug. ?If I can reproduce it, I will > then work on fixing the bug. > > - Sam > > On Mon, Jan 2, 2012 at 5:25 AM, Srinivas Hebbar wrote: >> Hello, >> >> With the A record TTL set to 60, the aging stops at "30" as long as >> I do dig every second. If I stop dig for 30 seconds, the cache ?expires and >> new record with ttl 60 is responded by deadwood. >> >> This is happening on both 3.0.x and 3.1.x releases. >> >> Unless I stop dig for more than 30 seconds, the above record is never get >> updated. >> >> I have lots of LAN clients and the request is coming so often that the old >> record never expires >> from the cache. >> >> dig LOG: >> /home/shyam> while [ 1 ]; do dig @localhost test.testing.tindip.com | grep >> ^test; sleep 1; done >> >> test.testing.tindip.com. 60 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 59 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 58 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 57 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 56 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 55 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 54 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 53 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 52 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 51 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 50 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 49 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 48 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 47 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 46 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 45 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 44 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 43 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 42 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 41 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 40 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 39 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 38 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 37 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 36 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 35 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 34 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 33 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 32 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 31 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 28 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> test.testing.tindip.com. 29 ? ? IN ? ? ?A ? ? ? 2.2.2.2 >> >> >> Thanks, >> Hebbar. From maradns at gmail.com Wed Jan 4 12:42:19 2012 From: maradns at gmail.com (Sam Trenholme) Date: Wed, 4 Jan 2012 09:42:19 -0800 Subject: [MaraDNS list] I have fixed Srinivas Hebbar's TTL expire issue Message-ID: Srinivas Hebbar reported that Deadwood changes the TTL of cached records to always have a TTL of at least 30 seconds. This results in Deadwood not removing a record from the cache if it's retrieved every 30 seconds or more. The reason why Deadwood did this is because: * The code for adding records to Deadwood's LRU hash requires a record to have a TTL of at least 30 seconds * Deadwood's code that ages TTLs and rotates records fetches a record from the LRU hash, then immediately puts the same record back in the LRU hash. To fix this issue, I modified the code that adds a record to the LRU hash. I have added special code, so that if the TTL has a value of -2, this means do the following: * Look to see if the record is already in the LRU hash. * If it is, do not alter the TTL when updating the record. * If it is not, give the new record a new TTL of 30 seconds. Using a SQA test I created for this issue yesterday, I have verified that my patch resolves Srinivas' issue. The patch is here: http://maradns.org/deadwood/patches/deadwood-3.1.03-ttl_expire.patch And the snapshot with this patch as well as the new SQA test is here: http://maradns.org/deadwood/snap/ - Sam From nicholas at periapt.co.uk Thu Jan 5 07:15:01 2012 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Thu, 05 Jan 2012 12:15:01 +0000 Subject: [MaraDNS list] freebsd support Message-ID: <4F059445.9000709@periapt.co.uk> Sam, In the 1.4.x series maradns build perfectly well on Debian feebsd. I have just verified that it continues to do so in the 2.0.x series. In order to do so, of course I had to contruct a Makefile. The attached file shows the post-patch diff between the 1.4 and 2.0 versions of build/Makefile.linux. I applied the same changes to the 1.4 version of build/Makefile.freebsd and it worked. I would appreciate it if you could restore support for freebsd. -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a.txt URL: From nicholas at periapt.co.uk Thu Jan 5 09:24:04 2012 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Thu, 05 Jan 2012 14:24:04 +0000 Subject: [MaraDNS list] horde of midge questions Message-ID: <4F05B284.8060903@periapt.co.uk> Sam, In preparing 2.0.x for Debian I did keep notes. I did not want to pester you with them and I have managed to eliminate some. So here they come. Nothing here is urgent. First of all you had concerns about running the logger in a chroot. I am fairly sure this is not a problem in Debian and I did not want to deal with it at the time. However I am lacking the specific experience needed to reproduce any such problem. Do you have any pointers? It would be nice if you could settle down and stop having the deadwood directory with a version number. It creates a little bit of extra work. The comments at lines 1317 and 1338 of tcp/zoneserver.c are unhelpfully identical. In the file doc/en/tutorial/recursive.html there is a broken link "customizing the resolution of some names". -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Thu Jan 5 11:04:40 2012 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 5 Jan 2012 08:04:40 -0800 Subject: [MaraDNS list] horde of midge questions In-Reply-To: <4F05B284.8060903@periapt.co.uk> References: <4F05B284.8060903@periapt.co.uk> Message-ID: > ? ? ? ?First of all you had concerns about running the logger in a chroot. I > am fairly sure this is not a problem in Debian and I did not want to > deal with it at the time. However I am lacking the specific experience > needed to reproduce any such problem. Do you have any pointers? It doesn't work in, as I recall, CentOS version 5. > ? ? ? ?It would be nice if you could settle down and stop having the deadwood > directory with a version number. It creates a little bit of extra work. The reason I do that is to make it easier to know which version of Deadwood is bundled with a given MaraDNS release. > ? ? ? ?The comments at lines 1317 and 1338 of tcp/zoneserver.c are unhelpfully > identical. The first block determines if they have permission to convert a DNS-over-TCP query in to a DNS-over-UDP query. The second block determines whether they have permission to perform DNS recursion. If they do, the DNS-over-UDP conversion of the DNS-over-TCP query will be sent with the RD ("recursion desired") bit turned on. If I were to write that code today, I would have used a separate function instead of cut-and-paste code. > ? ? ? ?In the file doc/en/tutorial/recursive.html there is a broken link > "customizing the resolution of some names". Indeed. What happened was that the 2.0 release of MaraDNS was rushed and I didn't have a chance to rewrite that bit of documentation to cover how it's done in Deadwood. To summarize: * Have MaraDNS run on one IP and Deadwood on another IP * Have lines like this in the Deadwood configuration file: upstream_servers = {} upstream_servers["local."] = "127.0.0.2" Where 127.0.0.2 is the IP of the MaraDNS server resolving "local." queries. - Sam From maradns at gmail.com Thu Jan 5 11:10:14 2012 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 5 Jan 2012 08:10:14 -0800 Subject: [MaraDNS list] freebsd support In-Reply-To: <4F059445.9000709@periapt.co.uk> References: <4F059445.9000709@periapt.co.uk> Message-ID: Could you make that a 'diff -u' instead of just a plain 'diff'. Hard to tell which file to change. Or, more simply, send me the Makefile.freebsd directly and I'll add it to the next MaraDNS 2 release. - Sam On Thu, Jan 5, 2012 at 4:15 AM, Nicholas Bamber wrote: > Sam, > ? ? ? ?In the 1.4.x series maradns build perfectly well on Debian feebsd. I > have just verified that it continues to do so in the 2.0.x series. In > order to do so, of course I had to contruct a Makefile. The attached > file shows the post-patch diff between the 1.4 and 2.0 versions of > build/Makefile.linux. I applied the same changes to the 1.4 version of > build/Makefile.freebsd and it worked. I would appreciate it if you could > restore support for freebsd. > > -- > Nicholas Bamber | http://www.periapt.co.uk/ > PGP key 3BFFE73C from pgp.mit.edu From nicholas at periapt.co.uk Thu Jan 5 12:51:27 2012 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Thu, 05 Jan 2012 17:51:27 +0000 Subject: [MaraDNS list] freebsd support In-Reply-To: References: <4F059445.9000709@periapt.co.uk> Message-ID: <4F05E31F.4030304@periapt.co.uk> Here is what I think the raw upstream Makefile.freebsd would be. On 05/01/12 16:10, Sam Trenholme wrote: > Could you make that a 'diff -u' instead of just a plain 'diff'. Hard > to tell which file to change. Or, more simply, send me the > Makefile.freebsd directly and I'll add it to the next MaraDNS 2 > release. > > - Sam > > On Thu, Jan 5, 2012 at 4:15 AM, Nicholas Bamber wrote: >> Sam, >> In the 1.4.x series maradns build perfectly well on Debian feebsd. I >> have just verified that it continues to do so in the 2.0.x series. In >> order to do so, of course I had to contruct a Makefile. The attached >> file shows the post-patch diff between the 1.4 and 2.0 versions of >> build/Makefile.linux. I applied the same changes to the 1.4 version of >> build/Makefile.freebsd and it worked. I would appreciate it if you could >> restore support for freebsd. >> >> -- >> Nicholas Bamber | http://www.periapt.co.uk/ >> PGP key 3BFFE73C from pgp.mit.edu -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Makefile.freebsd URL: From sshebbar at gmail.com Fri Jan 6 08:01:00 2012 From: sshebbar at gmail.com (Srinivas Hebbar) Date: Fri, 6 Jan 2012 18:31:00 +0530 Subject: [MaraDNS list] TTL is not aging after a big jump in system time. Message-ID: Hello, TTL get stuck at anywhere between 1 to 60 (The original A record TTL is 60) and until I restart the Deadwood, the record will stay in that state. This can be consistently reproduced by the following method. 1) Set the system time way back. (My box resets it to Jan 1, 1970). 2) dig test.testing.tindip.com 3) Now set the system time to current date. (Jan 6, 2012). 4) dig test.testing.tindip.com The TTL is stuck at some number and the record never expires. I don't think this is an short TTL issue. Basically, Deadwood is getting confused when a large step in system time. I haven't tested the date going backwards yet. Only the records which was queried prior to date change is affected. All new name lookups are working fine after the date change. Thank you, Srinivasa Hebbar. From maradns at gmail.com Fri Jan 6 12:28:43 2012 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 6 Jan 2012 09:28:43 -0800 Subject: [MaraDNS list] TTL is not aging after a big jump in system time. In-Reply-To: References: Message-ID: This is not a bug, it's a feature. Deadwood is year-2038 compliant, even on systems with a 32-bit time_t. In order to pull this off, Deadwood assumes that systems showing a timestamp before May 6 2007 (chosen because it was 6 months before the first Deadwood release [1]) have had their clock "wrap around" and that it's really far in the future, not far in the past. This allows Deadwood to have accurate timestamps on systems with a 32-bit time_t until 2143. The side effect is that Deadwood assumes that systems with a timestamp of 0 are not in 1970, but instead are in the year 2106. This results in all records stored in the cache on systems with an incorrect timestamp not expiring until 2106. If you're building Deadwood on a system which sometimes has an incorrect timestamp, there are some ways to work around this: * Set up the system to not start up Deadwood unless the system clock is set to May 2007 or later. * Change the value of DW_MINTIME in DwSys.h to a lower or negative value. Note that, if this is set, for example, to -1 instead of its current value (1178488417: May of 2007), Deadwood will start to have inaccurate timestamps on systems with 32-bit time_t in 2106, not 2143. Please upgrade your system to a 64-bit one before 2106. Please also note that dwh_put_int64() in DwHash.c (the code that writes the cache to disk) will not correctly store timestamps earlier than March 20, 1979 (they will simply be marked as being on that day). Such records in the cache *should* immediately expire on systems once the timestamp is correctly set, but this has not been tested at all. I'll let Seinivas Hebbar perform the SQA for this corner case. :) I'll update Deadwood docs to include this information. - Sam [1] http://maradns.blogspot.com/2007/10/groundbreaking-of-deadwood-project.html On Fri, Jan 6, 2012 at 5:01 AM, Srinivas Hebbar wrote: > Hello, > > TTL get stuck at anywhere between 1 to 60 (The original A record TTL is 60) > and until I restart the Deadwood, the record will stay in that state. > > This can be consistently reproduced by the following method. > > 1) Set the system time way back. (My box resets it to Jan 1, 1970). > 2) dig test.testing.tindip.com > > 3) Now set the system time to current date. (Jan 6, 2012). > 4) dig test.testing.tindip.com The TTL is stuck at some number and > ? ?the record never expires. > > I don't think this is an short TTL issue. Basically, Deadwood is > getting confused when a large step in system time. I haven't tested the > date going backwards yet. > > Only the records which was queried prior to date change is affected. > All new name lookups are working fine after the date change. > > Thank you, > Srinivasa Hebbar. From nicholas at periapt.co.uk Fri Jan 6 15:31:16 2012 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Fri, 06 Jan 2012 20:31:16 +0000 Subject: [MaraDNS list] horde of midge questions In-Reply-To: References: <4F05B284.8060903@periapt.co.uk> Message-ID: <4F075A14.1050501@periapt.co.uk> On 05/01/12 16:04, Sam Trenholme wrote: >> First of all you had concerns about running the logger in a chroot. I >> am fairly sure this is not a problem in Debian and I did not want to >> deal with it at the time. However I am lacking the specific experience >> needed to reproduce any such problem. Do you have any pointers? > > It doesn't work in, as I recall, CentOS version 5. Is there any chance for some more detail. Was it reproducible? Was it just the first message, or a random message. What version of syslog or equivalent does CentOS use? > >> It would be nice if you could settle down and stop having the deadwood >> directory with a version number. It creates a little bit of extra work. > > The reason I do that is to make it easier to know which version of > Deadwood is bundled with a given MaraDNS release. Any chance this is going to settle down or is it here to stay? -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Fri Jan 6 15:44:36 2012 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 6 Jan 2012 12:44:36 -0800 Subject: [MaraDNS list] freebsd support In-Reply-To: <4F05E31F.4030304@periapt.co.uk> References: <4F059445.9000709@periapt.co.uk> <4F05E31F.4030304@periapt.co.uk> Message-ID: Thank you for the file. I will add it to the head branch of MaraDNS tonight or tomorrow. - Sam On Thu, Jan 5, 2012 at 9:51 AM, Nicholas Bamber wrote: > Here is what I think the raw upstream Makefile.freebsd would be. > > On 05/01/12 16:10, Sam Trenholme wrote: >> Could you make that a 'diff -u' instead of just a plain 'diff'. ?Hard >> to tell which file to change. ?Or, more simply, send me the >> Makefile.freebsd directly and I'll add it to the next MaraDNS 2 >> release. >> >> - Sam >> >> On Thu, Jan 5, 2012 at 4:15 AM, Nicholas Bamber wrote: >>> Sam, >>> ? ? ? ?In the 1.4.x series maradns build perfectly well on Debian feebsd. I >>> have just verified that it continues to do so in the 2.0.x series. In >>> order to do so, of course I had to contruct a Makefile. The attached >>> file shows the post-patch diff between the 1.4 and 2.0 versions of >>> build/Makefile.linux. I applied the same changes to the 1.4 version of >>> build/Makefile.freebsd and it worked. I would appreciate it if you could >>> restore support for freebsd. >>> >>> -- >>> Nicholas Bamber | http://www.periapt.co.uk/ >>> PGP key 3BFFE73C from pgp.mit.edu > > > -- > Nicholas Bamber | http://www.periapt.co.uk/ > PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Fri Jan 6 16:05:04 2012 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 6 Jan 2012 13:05:04 -0800 Subject: [MaraDNS list] horde of midge questions In-Reply-To: <4F075A14.1050501@periapt.co.uk> References: <4F05B284.8060903@periapt.co.uk> <4F075A14.1050501@periapt.co.uk> Message-ID: >>> ? ? ? ?First of all you had concerns about running the logger in a chroot. >> It doesn't work in, as I recall, CentOS version 5. > Is there any chance for some more detail. ?Was it reproducible? Was it > just the first message, or a random message. What version of syslog or > equivalent does CentOS use? I'm not sure about the exact details of what sys logger CentOS 5 has. Perhaps a look at its list of packages will give some information: http://vault.centos.org/5.7/os/SRPMS/ >>> ? ? ? ?It would be nice if you could settle down and stop having the deadwood >>> directory with a version number. >> The reason I do that is to make it easier to know which version of >> Deadwood is bundled with a given MaraDNS release. > Any chance this is going to settle down or is it here to stay? I have no plans of changing this practice. Will I will guarantee is that deadwood-* will always point to a single directory with the current stable Deadwood release, so a line like this in the relevant shell script should always work (and it's a bug if this doesn't work): mv deadwood-* deadwood - Sam From nicholas at periapt.co.uk Fri Jan 6 17:42:53 2012 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Fri, 06 Jan 2012 22:42:53 +0000 Subject: [MaraDNS list] horde of midge questions In-Reply-To: References: <4F05B284.8060903@periapt.co.uk> <4F075A14.1050501@periapt.co.uk> Message-ID: <4F0778ED.3080003@periapt.co.uk> On 06/01/12 21:05, Sam Trenholme wrote: >>>> It would be nice if you could settle down and stop having the deadwood >>>> directory with a version number. > >>> The reason I do that is to make it easier to know which version of >>> Deadwood is bundled with a given MaraDNS release. > >> Any chance this is going to settle down or is it here to stay? > > I have no plans of changing this practice. Will I will guarantee is > that deadwood-* will always point to a single directory with the > current stable Deadwood release, so a line like this in the relevant > shell script should always work (and it's a bug if this doesn't work): > > mv deadwood-* deadwood > > - Sam > The file glob thing works in all places but one. That one place only requires one sed command to fix however it is a pain and will need to be documented for the benefit of my successors. -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From nicholas at periapt.co.uk Fri Jan 6 17:59:54 2012 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Fri, 06 Jan 2012 22:59:54 +0000 Subject: [MaraDNS list] IPv6 feedback Message-ID: <4F077CEA.50407@periapt.co.uk> Sam, I found two issues in testing the IPv6 support in maradns. 1.) There seems to be no support for listening on an IPv6 port in zoneserver. 2.) Despite documentation I cannot get the dns_port setting to work in deadwood. I tried to debug it but it is somewhere in the finite state machine. I've attached the config file. As far as I know, there is nothing left to do to get maradns 2.0.04 into Debian. However the split of a single process into two, means it won't get any further than the "experimental" release until I've had a chance to revisit how the configuration is managed. -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dwood3rc URL: From nicholas at periapt.co.uk Fri Jan 6 18:18:10 2012 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Fri, 06 Jan 2012 23:18:10 +0000 Subject: [MaraDNS list] IPv6 feedback In-Reply-To: <4F077CEA.50407@periapt.co.uk> References: <4F077CEA.50407@periapt.co.uk> Message-ID: <4F078132.2090202@periapt.co.uk> Actually it clicked what the parsing issue is. "dns_port" is numeric and should not be in quotes. Still a better error message would be nice. On 06/01/12 22:59, Nicholas Bamber wrote: > Sam, > I found two issues in testing the IPv6 support in maradns. > > 1.) There seems to be no support for listening on an IPv6 port in > zoneserver. > > 2.) Despite documentation I cannot get the dns_port setting to work in > deadwood. I tried to debug it but it is somewhere in the finite state > machine. I've attached the config file. > > As far as I know, there is nothing left to do to get maradns 2.0.04 into > Debian. However the split of a single process into two, means it won't > get any further than the "experimental" release until I've had a chance > to revisit how the configuration is managed. > -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From sshebbar at gmail.com Sat Jan 7 23:55:40 2012 From: sshebbar at gmail.com (Srinivas Hebbar) Date: Sun, 8 Jan 2012 10:25:40 +0530 Subject: [MaraDNS list] TTL is not aging after a big jump in system time. In-Reply-To: References: Message-ID: Hello, Thank you. My system doens't have RTC. Hence it used to start at 1970. After initialising the time to start from 2010Jan1, everything works fine. But, I expected the record to expire immediately if the timestamp on the given record is more than 2 years. Thanks, Hebbar. On Fri, Jan 6, 2012 at 10:58 PM, Sam Trenholme wrote: > This is not a bug, it's a feature. > > Deadwood is year-2038 compliant, even on systems with a 32-bit time_t. > In order to pull this off, Deadwood assumes that systems showing a > timestamp before May 6 2007 (chosen because it was 6 months before the > first Deadwood release [1]) have had their clock "wrap around" and > that it's really far in the future, not far in the past. > > This allows Deadwood to have accurate timestamps on systems with a > 32-bit time_t until 2143. The side effect is that Deadwood assumes > that systems with a timestamp of 0 are not in 1970, but instead are in > the year 2106. This results in all records stored in the cache on > systems with an incorrect timestamp not expiring until 2106. > > If you're building Deadwood on a system which sometimes has an > incorrect timestamp, there are some ways to work around this: > > * Set up the system to not start up Deadwood unless the system clock > is set to May 2007 or later. > > * Change the value of DW_MINTIME in DwSys.h to a lower or negative > value. Note that, if this is set, for example, to -1 instead of its > current value (1178488417: May of 2007), Deadwood will start to have > inaccurate timestamps on systems with 32-bit time_t in 2106, not 2143. > Please upgrade your system to a 64-bit one before 2106. > > Please also note that dwh_put_int64() in DwHash.c (the code that > writes the cache to disk) will not correctly store timestamps earlier > than March 20, 1979 (they will simply be marked as being on that day). > Such records in the cache *should* immediately expire on systems once > the timestamp is correctly set, but this has not been tested at all. > I'll let Seinivas Hebbar perform the SQA for this corner case. :) > > I'll update Deadwood docs to include this information. > > - Sam > > [1] > http://maradns.blogspot.com/2007/10/groundbreaking-of-deadwood-project.html > > On Fri, Jan 6, 2012 at 5:01 AM, Srinivas Hebbar > wrote: > > Hello, > > > > TTL get stuck at anywhere between 1 to 60 (The original A record TTL is > 60) > > and until I restart the Deadwood, the record will stay in that state. > > > > This can be consistently reproduced by the following method. > > > > 1) Set the system time way back. (My box resets it to Jan 1, 1970). > > 2) dig test.testing.tindip.com > > > > 3) Now set the system time to current date. (Jan 6, 2012). > > 4) dig test.testing.tindip.com The TTL is stuck at some number and > > the record never expires. > > > > I don't think this is an short TTL issue. Basically, Deadwood is > > getting confused when a large step in system time. I haven't tested the > > date going backwards yet. > > > > Only the records which was queried prior to date change is affected. > > All new name lookups are working fine after the date change. > > > > Thank you, > > Srinivasa Hebbar. > From maradns at gmail.com Sun Jan 8 11:47:57 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sun, 8 Jan 2012 08:47:57 -0800 Subject: [MaraDNS list] TTL is not aging after a big jump in system time. In-Reply-To: References: Message-ID: > But, I expected the record to expire immediately if the timestamp on the > given record is more than 2 years. Hopefully I will get enough sponsorship to make this happen in a future Deadwood release. - Sam From maradns at gmail.com Sun Jan 8 12:20:27 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sun, 8 Jan 2012 09:20:27 -0800 Subject: [MaraDNS list] IPv6 feedback In-Reply-To: <4F078132.2090202@periapt.co.uk> References: <4F077CEA.50407@periapt.co.uk> <4F078132.2090202@periapt.co.uk> Message-ID: I have added a FAQ entry explaining exactly what this error message means: http://maradns.org/deadwood/doc/FAQ.html - Sam On Fri, Jan 6, 2012 at 3:18 PM, Nicholas Bamber wrote: > Actually it clicked what the parsing issue is. "dns_port" is numeric and > should not be in quotes. Still a better error message would be nice. > > On 06/01/12 22:59, Nicholas Bamber wrote: >> Sam, >> ? ? ? I found two issues in testing the IPv6 support in maradns. >> >> 1.) There seems to be no support for listening on an IPv6 port in >> zoneserver. >> >> 2.) Despite documentation I cannot get the dns_port setting to work in >> deadwood. I tried to debug it but it is somewhere in the finite state >> machine. I've attached the config file. >> >> As far as I know, there is nothing left to do to get maradns 2.0.04 into >> Debian. However the split of a single process into two, means it won't >> get any further than the "experimental" release until I've had a chance >> to revisit how the configuration is managed. >> > > > -- > Nicholas Bamber | http://www.periapt.co.uk/ > PGP key 3BFFE73C from pgp.mit.edu From remco at webconquest.com Mon Jan 9 00:36:17 2012 From: remco at webconquest.com (Remco Rijnders) Date: Mon, 9 Jan 2012 06:36:17 +0100 Subject: [MaraDNS list] TTL is not aging after a big jump in system time. In-Reply-To: References: Message-ID: On Sun, Jan 08, 2012 at 10:25:40AM +0530, Srinivas wrote in : >Thank you. My system doens't have RTC. Hence it used to start at 1970. >After initialising the time to start from 2010Jan1, everything works fine. Hi Hebbar, As a work around, you may want to either put in a new battery in your system (hard to imagine a system without a built in clock these days), or first set time with chrony or ntp right after starting networking on your system and before bringing up maradns and other network daemons. Kind regards, Remco From maradns at gmail.com Fri Jan 13 15:46:13 2012 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 13 Jan 2012 12:46:13 -0800 Subject: [MaraDNS list] MaraDNS 1.3 and 1.4 update Message-ID: Hopefully the third time is the charm. While I added hash randomization to MaraDNS 1's code in late 2011, there was still a fairly easy way to add elements that collide to the hash. Hence, a one-line tweak to the hash. The hash should now be collision-resistant. It can be downloaded here: http://www.maradns.org/download/1.4/ http://www.maradns.org/download/1.3/ I've also update the patch for people running older versions of MaraDNS (this patch is to be applied to a version of MaraDNS with no hash randomization code in place): http://www.maradns.org/download/patches/maradns-1.3-better_hash.patch - Sam From nicholas at periapt.co.uk Sat Jan 14 08:03:13 2012 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Sat, 14 Jan 2012 13:03:13 +0000 Subject: [MaraDNS list] CVE status fo maradns Message-ID: <4F117D11.6020701@periapt.co.uk> Sam, The CVE status seems to be getting more and more confused. As I understand it http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0024 is what you were attempting to fix in 1.4.08. However they have issued a new number for the second attempt in http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5055. As for http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5056, I don't know what is going on there. Please confirm and clarify as necessary. -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Sat Jan 14 18:37:42 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sat, 14 Jan 2012 15:37:42 -0800 Subject: [MaraDNS list] CVE status fo maradns In-Reply-To: <4F117D11.6020701@periapt.co.uk> References: <4F117D11.6020701@periapt.co.uk> Message-ID: To add even more confusion: I did a final tweak to the hash compression function yesterday. TL;DR summary: Use MaraDNS 1.3.07.14, 1.4.10, any 2.0 release, or apply this patch to an older release of MaraDNS: http://maradns.org/download/patches/maradns-1.3-better_hash.patch Long summary: I made one release, realized that had problems, made another release the next day, realized *that* had problems, and made a (hopefully final) third update yesterday: http://samiam.org/blog/20111229.html http://samiam.org/blog/20111230.html http://samiam.org/blog/20120113.html And, oh, yeah you could argue that MaraDNS 2.0 has the issue, but it's much much less of an issue since someone has to control the zones MaraDNS uses to trigger the bug. But, yeah, since they filed a CVE for it, the latest 2.0 snapshot also has the bug fixed: http://maradns.org/download/2.0/snap/ I'm going to make a MaraDNS 2.0 release with this issue fixed once Deadwood 3.2 is out the door, probably in a month or so. - Sam On Sat, Jan 14, 2012 at 5:03 AM, Nicholas Bamber wrote: > Sam, > ? ? ? ?The CVE status seems to be getting more and more confused. > > ? ? ? ?As I understand it > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0024 is what you > were attempting to fix in 1.4.08. However they have issued a new number > for the second attempt in > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5055. > > ? ? ? ?As for http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5056, I > don't know what is going on there. > > ? ? ? ?Please confirm and clarify as necessary. > > -- > Nicholas Bamber | http://www.periapt.co.uk/ > PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Sun Jan 15 15:35:33 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sun, 15 Jan 2012 12:35:33 -0800 Subject: [MaraDNS list] freebsd support In-Reply-To: <4F05E31F.4030304@periapt.co.uk> References: <4F059445.9000709@periapt.co.uk> <4F05E31F.4030304@periapt.co.uk> Message-ID: I have added the Makefile.freebsd file to the latest MaraDNS snapshot: http://maradns.org/download/2.0/snap/ Since you have given me this file and wish it to be included with MaraDNS, said file will be released under the same 2-clause BSD license as the rest of MaraDNS. - Sam On Thu, Jan 5, 2012 at 9:51 AM, Nicholas Bamber wrote: > Here is what I think the raw upstream Makefile.freebsd would be. > > On 05/01/12 16:10, Sam Trenholme wrote: >> Could you make that a 'diff -u' instead of just a plain 'diff'. ?Hard >> to tell which file to change. ?Or, more simply, send me the >> Makefile.freebsd directly and I'll add it to the next MaraDNS 2 >> release. >> >> - Sam >> >> On Thu, Jan 5, 2012 at 4:15 AM, Nicholas Bamber wrote: >>> Sam, >>> ? ? ? ?In the 1.4.x series maradns build perfectly well on Debian feebsd. I >>> have just verified that it continues to do so in the 2.0.x series. In >>> order to do so, of course I had to contruct a Makefile. The attached >>> file shows the post-patch diff between the 1.4 and 2.0 versions of >>> build/Makefile.linux. I applied the same changes to the 1.4 version of >>> build/Makefile.freebsd and it worked. I would appreciate it if you could >>> restore support for freebsd. >>> >>> -- >>> Nicholas Bamber | http://www.periapt.co.uk/ >>> PGP key 3BFFE73C from pgp.mit.edu > > > -- > Nicholas Bamber | http://www.periapt.co.uk/ > PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Mon Jan 23 13:32:13 2012 From: maradns at gmail.com (Sam Trenholme) Date: Mon, 23 Jan 2012 10:32:13 -0800 Subject: [MaraDNS list] New full example Deadwood configuration file Message-ID: I have made a new full example Deadwood configuration file which shows all of the documented dwood3rc parameters: http://maradns.org/deadwood/doc/dwood3rc-all This will hopefully make it a little easier to set up some of the more esoteric Deadwood parameters. - Sam