[Cerowrt-devel] thoughts toward improving cerowrt's DNS and DNSSEC in the next release

[Cerowrt-devel] thoughts toward improving cerowrt's DNS and DNSSEC in the next release

[Dave Taht]

The ongoing DNS issues bug me. For most uses these days I disable bind
entirely, as the 12-20MB it uses up are better used for packets. I do
use it on 3800s but not on 3700v2s.

0) the circular time issue (bug #113) remains a PITA. I was really
scarred by trying to fix that one last year and keep hoping someone
else will fix it...

1) The luci gui has hooks for dnsmasq's "use dns servers advertised by
peer" and "use custom dns servers", which are not tied into the bind
configuration.

This is confusing users. The way to do that manually is to get the
advertisement once, validate that those servers do NXDOMAIN and
DNSSEC, and toss them into forwarders.conf and enable forwarders.conf

2) Going the the DNS roots with bind, is OK, but it is always faster,
and more reliable to use the ISP provided DNS servers, if they can be
trusted to send DNSSEC information. Comcast's (if you are on comcast)
are fast as heck. I also recently discovered that google DNS does
indeed do dnssec, and although much further away than comcast on the
networks I have access to, they are universally available.

So I am thinking of enabling forwarding by default to google DNS. This
reduces enabling forwarding to another set of servers provided by the
ISP, if usable....

I would like a test of some sort that would prove a delegated ISP's
DNS server was "worthy", this test would include NXDOMAIN, DNSSEC, and
whatever else would be required to validate it as a potential
forwarder to overwrite the forwarders.conf file with that information.

I wouldn't mind establishing a global white/blacklist of DNS servers
that did NXDOMAIN/DNSSEC right/wrong somewhere, either...

dnsmasq may gain DNSSEC by the winter, btw....

3) A related problem is that when behind many walled gardens (a hotel,
for example), going to the DNS roots via bind doesn't work at all,
neither do things like google dns, and usually the forwarder is pretty
crappy in the first place. dnsmasq works in this scenario just fine...

4) A final alternative is to drop bind by default and install it
optionally. While this would lose DNSSEC, and split views and local
delegations, it would buy the integration with dnsmasq, which includes
things like AAAA naming, etc., and get some memory back. (I note that
the OOM issues we're encountering are USEFUL to encounter in that
optimizing for memory use throughout the system is very important, and
I have similar issues on 32MB routers like the picostation/nanostation
even without bind)

Given the amount of time, energy, and money (all 0) I personally have
to deal with these issues, I'm mostly tempted to save on hair by
making dnsmasq the default going forward, and write off bind for now.
Certainly continue to make it available for advanced users, but
install it optionally.

The advantages of having something closer to full blown dns in the
home are not apparent without tighter integration with dhcp, dhcpv6,
ahcp, etc, than presently exists anywhere.

-- 
Dave Täht
http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out
with fq_codel!"

Re: [Cerowrt-devel] thoughts toward improving cerowrt's DNS and DNSSEC in the next release

[George Lambert]

[-- Attachment #1: Type: text/plain, Size: 4098 bytes --]

We have been working on DNS stuff and I will make some DNS Recommendations
within the next couple of days - if that would help.

Bind is an unnecessary waste of memory.

UnBound is too slow.

We are making custom modifications to MaraDNS to make it
have the right low memory footprint and optimizations for a router.

George.



On Mon, Aug 20, 2012 at 2:25 PM, Dave Taht <dave.taht@gmail.com> wrote:

> The ongoing DNS issues bug me. For most uses these days I disable bind
> entirely, as the 12-20MB it uses up are better used for packets. I do
> use it on 3800s but not on 3700v2s.
>
> 0) the circular time issue (bug #113) remains a PITA. I was really
> scarred by trying to fix that one last year and keep hoping someone
> else will fix it...
>
> 1) The luci gui has hooks for dnsmasq's "use dns servers advertised by
> peer" and "use custom dns servers", which are not tied into the bind
> configuration.
>
> This is confusing users. The way to do that manually is to get the
> advertisement once, validate that those servers do NXDOMAIN and
> DNSSEC, and toss them into forwarders.conf and enable forwarders.conf
>
> 2) Going the the DNS roots with bind, is OK, but it is always faster,
> and more reliable to use the ISP provided DNS servers, if they can be
> trusted to send DNSSEC information. Comcast's (if you are on comcast)
> are fast as heck. I also recently discovered that google DNS does
> indeed do dnssec, and although much further away than comcast on the
> networks I have access to, they are universally available.
>
> So I am thinking of enabling forwarding by default to google DNS. This
> reduces enabling forwarding to another set of servers provided by the
> ISP, if usable....
>
> I would like a test of some sort that would prove a delegated ISP's
> DNS server was "worthy", this test would include NXDOMAIN, DNSSEC, and
> whatever else would be required to validate it as a potential
> forwarder to overwrite the forwarders.conf file with that information.
>
> I wouldn't mind establishing a global white/blacklist of DNS servers
> that did NXDOMAIN/DNSSEC right/wrong somewhere, either...
>
> dnsmasq may gain DNSSEC by the winter, btw....
>
> 3) A related problem is that when behind many walled gardens (a hotel,
> for example), going to the DNS roots via bind doesn't work at all,
> neither do things like google dns, and usually the forwarder is pretty
> crappy in the first place. dnsmasq works in this scenario just fine...
>
> 4) A final alternative is to drop bind by default and install it
> optionally. While this would lose DNSSEC, and split views and local
> delegations, it would buy the integration with dnsmasq, which includes
> things like AAAA naming, etc., and get some memory back. (I note that
> the OOM issues we're encountering are USEFUL to encounter in that
> optimizing for memory use throughout the system is very important, and
> I have similar issues on 32MB routers like the picostation/nanostation
> even without bind)
>
> Given the amount of time, energy, and money (all 0) I personally have
> to deal with these issues, I'm mostly tempted to save on hair by
> making dnsmasq the default going forward, and write off bind for now.
> Certainly continue to make it available for advanced users, but
> install it optionally.
>
> The advantages of having something closer to full blown dns in the
> home are not apparent without tighter integration with dhcp, dhcpv6,
> ahcp, etc, than presently exists anywhere.
>
> --
> Dave Täht
> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out
> with fq_codel!"
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
P THINK BEFORE PRINTING: is it really necessary?

This e-mail and its attachments are confidential and solely for the
intended addressee(s). Do not share or use them without approval. If
received in error, contact the sender
and delete them.

[-- Attachment #2: Type: text/html, Size: 5011 bytes --]

Re: [Cerowrt-devel] thoughts toward improving cerowrt's DNS and DNSSEC in the next release

[Evan Hunt]

As a BIND 9 author I confess to bias on this point, but I don't agree
that BIND is an unnecessary waste of memory.  MaraDNS is nice but last
I checked it didn't handle DNSSEC validation or signing, both of which
I use in my router.

Validation, at least, seems to me to be a must-have.  You can't trust
DNSSEC validation done somewhere else.  I don't trust Comcast,
Verizon, or AT&T never to lie to me.

Google's DNS does *not* do DNSSEC, neither does OpenDNS.  Google will
return RRSIGs when you ask for them, and they've fixed their DS bug,
but it doesn't authenticate the data -- and even if it's being used as
a forwarder for a validating stub, DNSSEC will break sometimes if the
forwarder isn't validating too.  (For example, one name server for a
zone has stale data with expired signatures and the others are
correct; a validating name server would know to ignore the stale data
and ask the other servers until it got something valid, but Google
will pass the stale data along unquestioningly and then your
validating stub doesn't work.)

IMHO the future we want to aim for is one where people do their own
DNSSEC validation at home, and for the moment that means BIND or
Unbound.

On Mon, Aug 20, 2012 at 11:43 AM, George Lambert <marchon@gmail.com> wrote:
> We have been working on DNS stuff and I will make some DNS Recommendations
> within the next couple of days - if that would help.
>
> Bind is an unnecessary waste of memory.
>
> UnBound is too slow.
>
> We are making custom modifications to MaraDNS to make it
> have the right low memory footprint and optimizations for a router.
>
> George.
>
>
>
> On Mon, Aug 20, 2012 at 2:25 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> The ongoing DNS issues bug me. For most uses these days I disable bind
>> entirely, as the 12-20MB it uses up are better used for packets. I do
>> use it on 3800s but not on 3700v2s.
>>
>> 0) the circular time issue (bug #113) remains a PITA. I was really
>> scarred by trying to fix that one last year and keep hoping someone
>> else will fix it...
>>
>> 1) The luci gui has hooks for dnsmasq's "use dns servers advertised by
>> peer" and "use custom dns servers", which are not tied into the bind
>> configuration.
>>
>> This is confusing users. The way to do that manually is to get the
>> advertisement once, validate that those servers do NXDOMAIN and
>> DNSSEC, and toss them into forwarders.conf and enable forwarders.conf
>>
>> 2) Going the the DNS roots with bind, is OK, but it is always faster,
>> and more reliable to use the ISP provided DNS servers, if they can be
>> trusted to send DNSSEC information. Comcast's (if you are on comcast)
>> are fast as heck. I also recently discovered that google DNS does
>> indeed do dnssec, and although much further away than comcast on the
>> networks I have access to, they are universally available.
>>
>> So I am thinking of enabling forwarding by default to google DNS. This
>> reduces enabling forwarding to another set of servers provided by the
>> ISP, if usable....
>>
>> I would like a test of some sort that would prove a delegated ISP's
>> DNS server was "worthy", this test would include NXDOMAIN, DNSSEC, and
>> whatever else would be required to validate it as a potential
>> forwarder to overwrite the forwarders.conf file with that information.
>>
>> I wouldn't mind establishing a global white/blacklist of DNS servers
>> that did NXDOMAIN/DNSSEC right/wrong somewhere, either...
>>
>> dnsmasq may gain DNSSEC by the winter, btw....
>>
>> 3) A related problem is that when behind many walled gardens (a hotel,
>> for example), going to the DNS roots via bind doesn't work at all,
>> neither do things like google dns, and usually the forwarder is pretty
>> crappy in the first place. dnsmasq works in this scenario just fine...
>>
>> 4) A final alternative is to drop bind by default and install it
>> optionally. While this would lose DNSSEC, and split views and local
>> delegations, it would buy the integration with dnsmasq, which includes
>> things like AAAA naming, etc., and get some memory back. (I note that
>> the OOM issues we're encountering are USEFUL to encounter in that
>> optimizing for memory use throughout the system is very important, and
>> I have similar issues on 32MB routers like the picostation/nanostation
>> even without bind)
>>
>> Given the amount of time, energy, and money (all 0) I personally have
>> to deal with these issues, I'm mostly tempted to save on hair by
>> making dnsmasq the default going forward, and write off bind for now.
>> Certainly continue to make it available for advanced users, but
>> install it optionally.
>>
>> The advantages of having something closer to full blown dns in the
>> home are not apparent without tighter integration with dhcp, dhcpv6,
>> ahcp, etc, than presently exists anywhere.
>>
>> --
>> Dave Täht
>> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out
>> with fq_codel!"
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
>
> --
> P THINK BEFORE PRINTING: is it really necessary?
>
> This e-mail and its attachments are confidential and solely for the
> intended addressee(s). Do not share or use them without approval. If
> received in error, contact the sender
> and delete them.

Re: [Cerowrt-devel] thoughts toward improving cerowrt's DNS and DNSSEC in the next release

[George Lambert]

[-- Attachment #1: Type: text/plain, Size: 7478 bytes --]

In the intrest of "FULL DISCLOSURE" the Author of MaraDNS is a good friend
of mine. As a contributor to MaraDNS - I admit that I have a Bias as well.
(not for mara,
but for overall performance which is how I came to use MARA in the first
place ).

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

[I am new here - but very well intentioned - and have been around for a
long time as well]


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.

The top end of the embedded router space is 128M of memory, and that is
hard to come by and uncommon.  I only found 4 locally available models last
week when I was searching (and returned my ASUS for a netgear) to
participate
in this project.

George Lambert


On Mon, Aug 20, 2012 at 3:16 PM, Evan Hunt <ethanol@gmail.com> wrote:

> As a BIND 9 author I confess to bias on this point, but I don't agree
> that BIND is an unnecessary waste of memory.  MaraDNS is nice but last
> I checked it didn't handle DNSSEC validation or signing, both of which
> I use in my router.
>
> Validation, at least, seems to me to be a must-have.  You can't trust
> DNSSEC validation done somewhere else.  I don't trust Comcast,
> Verizon, or AT&T never to lie to me.
>
> Google's DNS does *not* do DNSSEC, neither does OpenDNS.  Google will
> return RRSIGs when you ask for them, and they've fixed their DS bug,
> but it doesn't authenticate the data -- and even if it's being used as
> a forwarder for a validating stub, DNSSEC will break sometimes if the
> forwarder isn't validating too.  (For example, one name server for a
> zone has stale data with expired signatures and the others are
> correct; a validating name server would know to ignore the stale data
> and ask the other servers until it got something valid, but Google
> will pass the stale data along unquestioningly and then your
> validating stub doesn't work.)
>
> IMHO the future we want to aim for is one where people do their own
> DNSSEC validation at home, and for the moment that means BIND or
> Unbound.
>
> On Mon, Aug 20, 2012 at 11:43 AM, George Lambert <marchon@gmail.com>
> wrote:
> > We have been working on DNS stuff and I will make some DNS
> Recommendations
> > within the next couple of days - if that would help.
> >
> > Bind is an unnecessary waste of memory.
> >
> > UnBound is too slow.
> >
> > We are making custom modifications to MaraDNS to make it
> > have the right low memory footprint and optimizations for a router.
> >
> > George.
> >
> >
> >
> > On Mon, Aug 20, 2012 at 2:25 PM, Dave Taht <dave.taht@gmail.com> wrote:
> >>
> >> The ongoing DNS issues bug me. For most uses these days I disable bind
> >> entirely, as the 12-20MB it uses up are better used for packets. I do
> >> use it on 3800s but not on 3700v2s.
> >>
> >> 0) the circular time issue (bug #113) remains a PITA. I was really
> >> scarred by trying to fix that one last year and keep hoping someone
> >> else will fix it...
> >>
> >> 1) The luci gui has hooks for dnsmasq's "use dns servers advertised by
> >> peer" and "use custom dns servers", which are not tied into the bind
> >> configuration.
> >>
> >> This is confusing users. The way to do that manually is to get the
> >> advertisement once, validate that those servers do NXDOMAIN and
> >> DNSSEC, and toss them into forwarders.conf and enable forwarders.conf
> >>
> >> 2) Going the the DNS roots with bind, is OK, but it is always faster,
> >> and more reliable to use the ISP provided DNS servers, if they can be
> >> trusted to send DNSSEC information. Comcast's (if you are on comcast)
> >> are fast as heck. I also recently discovered that google DNS does
> >> indeed do dnssec, and although much further away than comcast on the
> >> networks I have access to, they are universally available.
> >>
> >> So I am thinking of enabling forwarding by default to google DNS. This
> >> reduces enabling forwarding to another set of servers provided by the
> >> ISP, if usable....
> >>
> >> I would like a test of some sort that would prove a delegated ISP's
> >> DNS server was "worthy", this test would include NXDOMAIN, DNSSEC, and
> >> whatever else would be required to validate it as a potential
> >> forwarder to overwrite the forwarders.conf file with that information.
> >>
> >> I wouldn't mind establishing a global white/blacklist of DNS servers
> >> that did NXDOMAIN/DNSSEC right/wrong somewhere, either...
> >>
> >> dnsmasq may gain DNSSEC by the winter, btw....
> >>
> >> 3) A related problem is that when behind many walled gardens (a hotel,
> >> for example), going to the DNS roots via bind doesn't work at all,
> >> neither do things like google dns, and usually the forwarder is pretty
> >> crappy in the first place. dnsmasq works in this scenario just fine...
> >>
> >> 4) A final alternative is to drop bind by default and install it
> >> optionally. While this would lose DNSSEC, and split views and local
> >> delegations, it would buy the integration with dnsmasq, which includes
> >> things like AAAA naming, etc., and get some memory back. (I note that
> >> the OOM issues we're encountering are USEFUL to encounter in that
> >> optimizing for memory use throughout the system is very important, and
> >> I have similar issues on 32MB routers like the picostation/nanostation
> >> even without bind)
> >>
> >> Given the amount of time, energy, and money (all 0) I personally have
> >> to deal with these issues, I'm mostly tempted to save on hair by
> >> making dnsmasq the default going forward, and write off bind for now.
> >> Certainly continue to make it available for advanced users, but
> >> install it optionally.
> >>
> >> The advantages of having something closer to full blown dns in the
> >> home are not apparent without tighter integration with dhcp, dhcpv6,
> >> ahcp, etc, than presently exists anywhere.
> >>
> >> --
> >> Dave Täht
> >> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out
> >> with fq_codel!"
> >> _______________________________________________
> >> Cerowrt-devel mailing list
> >> Cerowrt-devel@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
> >
> >
> >
> > --
> > P THINK BEFORE PRINTING: is it really necessary?
> >
> > This e-mail and its attachments are confidential and solely for the
> > intended addressee(s). Do not share or use them without approval. If
> > received in error, contact the sender
> > and delete them.
>



-- 
P THINK BEFORE PRINTING: is it really necessary?

This e-mail and its attachments are confidential and solely for the
intended addressee(s). Do not share or use them without approval. If
received in error, contact the sender
and delete them.

[-- Attachment #2: Type: text/html, Size: 9346 bytes --]

Re: [Cerowrt-devel] thoughts toward improving cerowrt's DNS and DNSSEC in the next release

[Evan Hunt]

> *** 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

Re: [Cerowrt-devel] thoughts toward improving cerowrt's DNS and DNSSEC in the next release

[George Lambert]

[-- Attachment #1: Type: text/plain, Size: 2902 bytes --]

Thank You for the response.

There may be benefit to a common UI configuration layer for DNS in the
router
that has a checkbox for [ ] DNSSEC - that transparently swaps out the DNS
Server
for the end user - and could deliver the best of both worlds today.

Most of the DNS Configuration Options in the UI could be abstracted out to
write
the correct configuration files for the DNS solution of your choice, and we
could
remove the integration detail to scripts that process the UI settings and
control
the appropriate Start / Stop Scripts.

It would take a small piece of MiddleWare called by the UI that can take
**any**
plugin solution that could be put into the Apps Package List

This basic design principal might be useful in other areas of the router UI
as
well, since there are probably a lot of "Swap This For That" options that
will
be useful over the long term.

That probably deserves more thought.

G.




On Mon, Aug 20, 2012 at 4:14 PM, Evan Hunt <ethanol@gmail.com> wrote:

> > *** 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
>



-- 
P THINK BEFORE PRINTING: is it really necessary?

This e-mail and its attachments are confidential and solely for the
intended addressee(s). Do not share or use them without approval. If
received in error, contact the sender
and delete them.

[-- Attachment #2: Type: text/html, Size: 3767 bytes --]

Re: [Cerowrt-devel] thoughts toward improving cerowrt's DNS and DNSSEC in the next release

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]


>>>>> "Dave" == Dave Taht <dave.taht@gmail.com> writes:
    Dave> The ongoing DNS issues bug me. For most uses these days I disable bind
    Dave> entirely, as the 12-20MB it uses up are better used for packets. I do
    Dave> use it on 3800s but not on 3700v2s.

Evan/Dave, I am not in a position to gather primary data, but how much
space does bind9 really need just to start with an empty cache?

I'd think that, at that point, how much memory is then allocated to the
cache can be controlled by some named.conf control?  It hasn't mattered
to me, so I've never looked it up... (and got no network, and tablet has
no bind(9)).

I think that we want to push the DNS servers that we get from DHCP into
bind's forwarders statement (which I think you agree with via
forwarders.conf comment, but I don't know if it's exactly equivalent to
forwarders {}).  
Let's leave the qualification of whether or not the servers do the right
thing to bind itself... the forwards {} stanza can have multiple items,
and bind will give up on them if they don't work, and talk to the root
name servers directly if none work. (Unless you have forwarders-only...)

Your NXDOMAIN concerns... is this about ISPs (like Rogers.com) that
helpfully lie and make up A records for things that do not exist?

I suggest that this determination be done separately (in another
module).  Someone else can solve that problem,  and withdraw things from
forwarders.conf as appropriate.

    Dave> 2) Going the the DNS roots with bind, is OK, but it is always faster,
    Dave> and more reliable to use the ISP provided DNS servers, if they

..if..if.. the biggest problem is not that it's faster, but that some
ISPs have services, e.g: "mail" which they do not document as FQDNs.

We (homenet-ish systems) need to have local DNS services, and have the
ability to query walled gardens, etc... 

    Dave> Given the amount of time, energy, and money (all 0) I personally have
    Dave> to deal with these issues, I'm mostly tempted to save on hair by
    Dave> making dnsmasq the default going forward, and write off bind for now.

I concur... "for now"
Maybe others with paid time can step up to make this happen.. (Evan?)

-- 
Michael Richardson
-at the cottage-




[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]