Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Evan Hunt <ethanol@gmail.com>
To: George Lambert <marchon@gmail.com>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] thoughts toward improving cerowrt's DNS and DNSSEC in the next release
Date: Mon, 20 Aug 2012 13:14:37 -0700	[thread overview]
Message-ID: <CAPECp-DS4p55nFMgY1Km2yEj-LVcsPJV9-f=u1c-6RrCem6vrA@mail.gmail.com> (raw)
In-Reply-To: <CAC938DhT=yYEmPUD5-crcPvHgTiLJnFui8YZObp9J3rrk+k=VQ@mail.gmail.com>

> *** the following is mean to be an "opinion for discussion - not intended to
> cause friction.'  ***

Same here.  I have parental affection for BIND, but if something else
does a better job of making the internet better, then something else
ought to win.

> It is my opinion that - BIND9 should not be the only default install option,
> and there should probably be an either or choice DNS Security / or
> (Memory + Processor + Name Resolution Speed).
>
> I would agree that there is value in DNSSEC - for people who want it, but
> I believe that it should be optional due to the substantial performance
> penalty that comes from the combination of extra cpu and memory to run
> BIND9 - for those who do not expect DNSSEC, or see value in it.
>
> 3 years from now when the demand for DNSSEC may be higher -
> routers will have substantially more compute and memory, but today
> both of those are critical components in the overall solution.

I sort of agree and sort of don't.  If I'm designing for the
commonplace CPE of 2012, yeah, I'm probably not going to want BIND.
But I hope for cerowrt to blaze the trails people will be following
three years from now.  By then, not only will we have beefier routers
to run name servers on, but there'll probably be more choices of name
servers that support the necessary feature set.  Taking the memory hit
to run BIND now lets us learn lessons about how to deal with
home-network naming in a DNSSEC-enabled world while the stakes are
still relatively low.

I like your idea of having multiple options and making the tradeoffs
explicit though.

Evan

  reply	other threads:[~2012-08-20 20:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-20 18:25 Dave Taht
2012-08-20 18:43 ` George Lambert
2012-08-20 19:16   ` Evan Hunt
2012-08-20 19:44     ` George Lambert
2012-08-20 20:14       ` Evan Hunt [this message]
2012-08-20 20:23         ` George Lambert
2012-08-21 22:31 ` Michael Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPECp-DS4p55nFMgY1Km2yEj-LVcsPJV9-f=u1c-6RrCem6vrA@mail.gmail.com' \
    --to=ethanol@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=marchon@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox