<div>In the intrest of "FULL DISCLOSURE" the Author of MaraDNS is a good friend</div><div>of mine. As a contributor to MaraDNS - I admit that I have a Bias as well. (not for mara, </div><div>but for overall performance which is how I came to use MARA in the first place ). </div>
<div><br></div><div>*** the following is mean to be an "opinion for discussion - not intended to cause friction.'  *** </div><div>  </div><div>[I am new here - but very well intentioned - and have been around for a long time as well]</div>
<div><br></div><div><br></div><div>It is my opinion that - BIND9 should not be the only default install option, </div><div>and there should probably be an either or choice DNS Security / or </div><div>(Memory + Processor + Name Resolution Speed). </div>
<div><br></div><div>I would agree that there is value in DNSSEC - for people who want it, but </div><div>I believe that it should be optional due to the substantial performance </div><div>penalty that comes from the combination of extra cpu and memory to run</div>
<div>BIND9 - for those who do not expect DNSSEC, or see value in it. </div><div><br></div><div>3 years from now when the demand for DNSSEC may be higher - </div><div>routers will have substantially more compute and memory, but today </div>
<div>both of those are critical components in the overall solution.  </div><div><br></div><div>The top end of the embedded router space is 128M of memory, and that is </div><div>hard to come by and uncommon.  I only found 4 locally available models last</div>
<div>week when I was searching (and returned my ASUS for a netgear) to participate</div><div>in this project. </div><div><br></div><div>George Lambert </div><div><br></div><div><br></div><div><div><div><div class="gmail_quote">
On Mon, Aug 20, 2012 at 3:16 PM, Evan Hunt <span dir="ltr"><<a href="mailto:ethanol@gmail.com" target="_blank">ethanol@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As a BIND 9 author I confess to bias on this point, but I don't agree<br>
that BIND is an unnecessary waste of memory.  MaraDNS is nice but last<br>
I checked it didn't handle DNSSEC validation or signing, both of which<br>
I use in my router.<br>
<br>
Validation, at least, seems to me to be a must-have.  You can't trust<br>
DNSSEC validation done somewhere else.  I don't trust Comcast,<br>
Verizon, or AT&T never to lie to me.<br>
<br>
Google's DNS does *not* do DNSSEC, neither does OpenDNS.  Google will<br>
return RRSIGs when you ask for them, and they've fixed their DS bug,<br>
but it doesn't authenticate the data -- and even if it's being used as<br>
a forwarder for a validating stub, DNSSEC will break sometimes if the<br>
forwarder isn't validating too.  (For example, one name server for a<br>
zone has stale data with expired signatures and the others are<br>
correct; a validating name server would know to ignore the stale data<br>
and ask the other servers until it got something valid, but Google<br>
will pass the stale data along unquestioningly and then your<br>
validating stub doesn't work.)<br>
<br>
IMHO the future we want to aim for is one where people do their own<br>
DNSSEC validation at home, and for the moment that means BIND or<br>
Unbound.<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Aug 20, 2012 at 11:43 AM, George Lambert <<a href="mailto:marchon@gmail.com">marchon@gmail.com</a>> wrote:<br>
> We have been working on DNS stuff and I will make some DNS Recommendations<br>
> within the next couple of days - if that would help.<br>
><br>
> Bind is an unnecessary waste of memory.<br>
><br>
> UnBound is too slow.<br>
><br>
> We are making custom modifications to MaraDNS to make it<br>
> have the right low memory footprint and optimizations for a router.<br>
><br>
> George.<br>
><br>
><br>
><br>
> On Mon, Aug 20, 2012 at 2:25 PM, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
>><br>
>> The ongoing DNS issues bug me. For most uses these days I disable bind<br>
>> entirely, as the 12-20MB it uses up are better used for packets. I do<br>
>> use it on 3800s but not on 3700v2s.<br>
>><br>
>> 0) the circular time issue (bug #113) remains a PITA. I was really<br>
>> scarred by trying to fix that one last year and keep hoping someone<br>
>> else will fix it...<br>
>><br>
>> 1) The luci gui has hooks for dnsmasq's "use dns servers advertised by<br>
>> peer" and "use custom dns servers", which are not tied into the bind<br>
>> configuration.<br>
>><br>
>> This is confusing users. The way to do that manually is to get the<br>
>> advertisement once, validate that those servers do NXDOMAIN and<br>
>> DNSSEC, and toss them into forwarders.conf and enable forwarders.conf<br>
>><br>
>> 2) Going the the DNS roots with bind, is OK, but it is always faster,<br>
>> and more reliable to use the ISP provided DNS servers, if they can be<br>
>> trusted to send DNSSEC information. Comcast's (if you are on comcast)<br>
>> are fast as heck. I also recently discovered that google DNS does<br>
>> indeed do dnssec, and although much further away than comcast on the<br>
>> networks I have access to, they are universally available.<br>
>><br>
>> So I am thinking of enabling forwarding by default to google DNS. This<br>
>> reduces enabling forwarding to another set of servers provided by the<br>
>> ISP, if usable....<br>
>><br>
>> I would like a test of some sort that would prove a delegated ISP's<br>
>> DNS server was "worthy", this test would include NXDOMAIN, DNSSEC, and<br>
>> whatever else would be required to validate it as a potential<br>
>> forwarder to overwrite the forwarders.conf file with that information.<br>
>><br>
>> I wouldn't mind establishing a global white/blacklist of DNS servers<br>
>> that did NXDOMAIN/DNSSEC right/wrong somewhere, either...<br>
>><br>
>> dnsmasq may gain DNSSEC by the winter, btw....<br>
>><br>
>> 3) A related problem is that when behind many walled gardens (a hotel,<br>
>> for example), going to the DNS roots via bind doesn't work at all,<br>
>> neither do things like google dns, and usually the forwarder is pretty<br>
>> crappy in the first place. dnsmasq works in this scenario just fine...<br>
>><br>
>> 4) A final alternative is to drop bind by default and install it<br>
>> optionally. While this would lose DNSSEC, and split views and local<br>
>> delegations, it would buy the integration with dnsmasq, which includes<br>
>> things like AAAA naming, etc., and get some memory back. (I note that<br>
>> the OOM issues we're encountering are USEFUL to encounter in that<br>
>> optimizing for memory use throughout the system is very important, and<br>
>> I have similar issues on 32MB routers like the picostation/nanostation<br>
>> even without bind)<br>
>><br>
>> Given the amount of time, energy, and money (all 0) I personally have<br>
>> to deal with these issues, I'm mostly tempted to save on hair by<br>
>> making dnsmasq the default going forward, and write off bind for now.<br>
>> Certainly continue to make it available for advanced users, but<br>
>> install it optionally.<br>
>><br>
>> The advantages of having something closer to full blown dns in the<br>
>> home are not apparent without tighter integration with dhcp, dhcpv6,<br>
>> ahcp, etc, than presently exists anywhere.<br>
>><br>
>> --<br>
>> Dave Täht<br>
>> <a href="http://www.bufferbloat.net/projects/cerowrt/wiki" target="_blank">http://www.bufferbloat.net/projects/cerowrt/wiki</a> - "3.3.8-17 is out<br>
>> with fq_codel!"<br>
>> _______________________________________________<br>
>> Cerowrt-devel mailing list<br>
>> <a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
>> <a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
><br>
><br>
><br>
><br>
> --<br>
> P THINK BEFORE PRINTING: is it really necessary?<br>
><br>
> This e-mail and its attachments are confidential and solely for the<br>
> intended addressee(s). Do not share or use them without approval. If<br>
> received in error, contact the sender<br>
> and delete them.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>P THINK BEFORE PRINTING: is it really necessary?<br><br>This e-mail and its attachments are confidential and solely for the<br>intended addressee(s). Do not share or use them without approval. If received in error, contact the sender<br>
and delete them.<br>
</div></div></div>