On Tue, Aug 21, 2012 at 12:56 PM, Doug Barton wrote:
> On 8/21/2012 11:08 AM, Bjoern A. Zeeb wrote:
>> On Tue, 21 Aug 2012, Doug Barton wrote:
>
>>> Neither importing ldns nor removing BIND is going to have any effect on
>>> the stub resolver library in libc.
>>
>> Yes it does as if we are not car
On 8/21/2012 11:08 AM, Bjoern A. Zeeb wrote:
> On Tue, 21 Aug 2012, Doug Barton wrote:
>> Neither importing ldns nor removing BIND is going to have any effect on
>> the stub resolver library in libc.
>
> Yes it does as if we are not carefull, we'll neither have a _proper_
> validating caching res
On Tue, 21 Aug 2012, Doug Barton wrote:
On 8/21/2012 10:11 AM, Bjoern A. Zeeb wrote:
On Tue, 21 Aug 2012, Dag-Erling Smørgrav wrote:
Doug Barton writes:
Dag-Erling, do you have a timeline for getting started on the
ldns/unbound import?
I imported the code into the vendor tree, but did not
On 8/21/2012 10:11 AM, Bjoern A. Zeeb wrote:
> On Tue, 21 Aug 2012, Dag-Erling Smørgrav wrote:
>
>> Doug Barton writes:
>>> Dag-Erling, do you have a timeline for getting started on the
>>> ldns/unbound import?
>>
>> I imported the code into the vendor tree, but did not proceed any
>> further as
On Tue, 21 Aug 2012, Dag-Erling Smørgrav wrote:
Doug Barton writes:
Dag-Erling, do you have a timeline for getting started on the
ldns/unbound import?
I imported the code into the vendor tree, but did not proceed any
further as there was still no firm consensus at the time.
I believe the co
Doug Barton writes:
> Dag-Erling, do you have a timeline for getting started on the
> ldns/unbound import?
I imported the code into the vendor tree, but did not proceed any
further as there was still no firm consensus at the time.
I believe the conclusion - to the extent that there was one - was
On 08/20/2012 02:19, Bjoern A. Zeeb wrote:
> On Mon, 20 Aug 2012, Doug Barton wrote:
>
>> On 08/20/2012 01:55, Bjoern A. Zeeb wrote:
>>
>>> We will continue to reject this until there are more firm plans,
>>> proper documentation on the security support side, which I cannot
>>> remember Simon got
On 08/20/2012 02:16, Mark Blackman wrote:
>
> On 20 Aug 2012, at 10:12, Doug Barton wrote:
>
>> On 08/20/2012 01:55, Bjoern A. Zeeb wrote:
>>
>>> We will continue to reject this until there are more firm plans,
>>> proper documentation on the security support side, which I cannot
>>> remember Si
On 20 Aug 2012, at 10:12, Doug Barton wrote:
> On 08/20/2012 01:55, Bjoern A. Zeeb wrote:
>
>> We will continue to reject this until there are more firm plans,
>> proper documentation on the security support side, which I cannot
>> remember Simon got an answer for.
>
> I gave a clear answer. I
On Mon, 20 Aug 2012, Doug Barton wrote:
On 08/20/2012 01:55, Bjoern A. Zeeb wrote:
We will continue to reject this until there are more firm plans,
proper documentation on the security support side, which I cannot
remember Simon got an answer for.
I gave a clear answer. If there are any piec
On 08/20/2012 01:55, Bjoern A. Zeeb wrote:
> We will continue to reject this until there are more firm plans,
> proper documentation on the security support side, which I cannot
> remember Simon got an answer for.
I gave a clear answer. If there are any pieces missing it's up to Simon
to follow u
On Mon, 20 Aug 2012, Doug Barton wrote:
On 08/06/2012 13:23, Vitaly Magerya wrote:
Doug Barton wrote:
On 07/07/2012 16:33, Garrett Wollman wrote:
The utilities (specifically host(1) and dig(1)) are the only
user-visible interfaces I care about.
[...]
ldns (a dependency of unbound) comes wi
On 08/06/2012 13:23, Vitaly Magerya wrote:
> Doug Barton wrote:
>> On 07/07/2012 16:33, Garrett Wollman wrote:
>>> The utilities (specifically host(1) and dig(1)) are the only
>>> user-visible interfaces I care about.
> [...]
>> ldns (a dependency of unbound) comes with drill, which is a dig-alike
Doug Barton wrote:
> On 07/07/2012 16:33, Garrett Wollman wrote:
>> The utilities (specifically host(1) and dig(1)) are the only
>> user-visible interfaces I care about.
[...]
> ldns (a dependency of unbound) comes with drill, which is a dig-alike
> tool. I'd like to see us produce a host-alike ba
On 7/10/2012 4:27 AM, Mark Blackman wrote:
> On 10 Jul 2012, at 08:12, Doug Barton wrote:
>
>> On 07/09/2012 14:47, Mark Blackman wrote:
>>> I never use '-t' with dig. drill *told* me I should use '-t'
>>> then completely failed to acknowledge I had done so.
>>
>> Have you reported this bug?
>
>
On 10 Jul 2012, at 08:12, Doug Barton wrote:
> On 07/09/2012 14:47, Mark Blackman wrote:
>> I never use '-t' with dig. drill *told* me I should use '-t'
>> then completely failed to acknowledge I had done so.
>
> Have you reported this bug?
Nope, you?
- Mark
On Tue, Jul 10, 2012 at 12:18 AM, Doug Barton wrote:
>> But I think you are wrong about this one aspect of your
>> proposed change. To discover that "dig" is suddenly not in the base
>> FreeBSD system any more some day would be just about the worst
>> violation of the Principle of Least Astonishm
On 07/10/2012 00:28, Mike Meyer wrote:
> I suspect that dnsmasq is a lot better tool for that job than BIND
I think "better" is in the eye of the beholder, particularly whether or
not the "O" is either small or well-staffed enough to pre-enter
hostnames into the zone files. That said, dnsmasq is a
On Tue, 10 Jul 2012 00:12:16 -0700
Doug Barton wrote:
> On 07/09/2012 19:46, Peter Jeremy wrote:
> > As I see it, FreeBSD systems fall roughly into 3 categories:
> > 1) Client systems that need to lookup external DNS servers only.
> > 2) SOHO systems that primarily do external lookups but need to
On 07/09/2012 16:45, George Mitchell wrote:
> On 07/09/12 17:01, Doug Barton wrote:
>> On 07/09/2012 06:45, Mark Blackman wrote:
>>
>>> Indeed, 'dig' and 'host' must be present and working as expected
>>> in a minimally installed system.
>>
>> So if you don't like the versions that get imported, in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/09/2012 19:56, Peter Jeremy wrote:
> On 2012-Jul-10 00:40:07 +0200, Dag-Erling Smørgrav
> wrote:
>> They are sufficiently similar that writing a wrapper that
>> supports a significant subset of dig's command-line option and
>> uses drill as a
On 07/09/2012 14:47, Mark Blackman wrote:
> I never use '-t' with dig. drill *told* me I should use '-t'
> then completely failed to acknowledge I had done so.
Have you reported this bug?
--
Change is hard.
___
freebsd-hackers@freebsd.org maili
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/09/2012 19:46, Peter Jeremy wrote:
> Firstly, I should note that I'm not against removing bind from base.
Thanks for clarifying.
> I'm merely saying that users are going to need some guidance during
> the transition.
I've never argued agains
On Monday 09 July 2012 22:53:14 Doug Barton wrote:
>
> We get it, change is hard.
No, that isn't what I said at all. I was pointing out that there's some
inconsistency between arguing that we need to make things more predictable
for new users, while simultaneously arguing that we should remove t
On Jul 9, 2012 7:57 PM, "Peter Jeremy" wrote:
>
> On 2012-Jul-10 00:40:07 +0200, Dag-Erling Smørgrav wrote:
> >They are sufficiently similar that writing a wrapper that supports a
> >significant subset of dig's command-line option and uses drill as a
> >backend shouldn't take more than an afterno
On 2012-Jul-10 00:40:07 +0200, Dag-Erling Smørgrav wrote:
>They are sufficiently similar that writing a wrapper that supports a
>significant subset of dig's command-line option and uses drill as a
>backend shouldn't take more than an afternoon for a reasonably
>experienced programmer.
I would fur
Firstly, I should note that I'm not against removing bind from base.
I'm merely saying that users are going to need some guidance during
the transition.
On 2012-Jul-09 13:52:15 -0700, Doug Barton wrote:
>On 07/09/2012 13:47, Peter Jeremy wrote:
>> On 2012-Jul-09 14:15:13 +0200, in freebsd-securit
On 07/09/12 17:01, Doug Barton wrote:
On 07/09/2012 06:45, Mark Blackman wrote:
Indeed, 'dig' and 'host' must be present and working as expected
in a minimally installed system.
So if you don't like the versions that get imported, install bind-tools
from ports.
Doug
Doug, you are one of th
Mark Blackman writes:
> drill certainly looks like a drop-in replacement for the common case
> as you suggest. But if it's not called 'dig' and I've never heard of
> 'drill', I'm unlikely to reach for 'drill', hence the alias
> suggestion. I *had* never heard of 'drill' until this thread came up.
On 9 Jul 2012, at 23:01, Dag-Erling Smørgrav wrote:
> Mark Blackman writes:
>> I never use '-t' with dig. drill *told* me I should use '-t' then
>> completely failed to acknowledge I had done so.
>>
>> Marks-Macbook% drill -t www.google.com
>> [...]
>> ;; WARNING: The answer packet was truncated
Mark Blackman writes:
> I never use '-t' with dig. drill *told* me I should use '-t' then
> completely failed to acknowledge I had done so.
>
> Marks-Macbook% drill -t www.google.com
> [...]
> ;; WARNING: The answer packet was truncated; you might want to
> ;; query again with TCP (-t argument), o
On 9 Jul 2012, at 22:37, Dag-Erling Smørgrav wrote:
> Mark Blackman writes:
>> my DNS resolution is broken, so my ports can't download any tarballs.
>> In this case, I reach for dig to see which part of the DNS resolution
>> chain is failing me.
>>
>> At the bare minimum, 'dig' should be an a
Mark Blackman writes:
> my DNS resolution is broken, so my ports can't download any tarballs.
> In this case, I reach for dig to see which part of the DNS resolution
> chain is failing me.
>
> At the bare minimum, 'dig' should be an alias for 'drill', which I have
> to say isn't working brillia
On 9 Jul 2012, at 22:01, Doug Barton wrote:
> On 07/09/2012 06:45, Mark Blackman wrote:
>
>> Indeed, 'dig' and 'host' must be present and working as expected
>> in a minimally installed system.
>
> So if you don't like the versions that get imported, install bind-tools
> from ports.
my DNS re
On 07/09/2012 06:45, Mark Blackman wrote:
> Indeed, 'dig' and 'host' must be present and working as expected
> in a minimally installed system.
So if you don't like the versions that get imported, install bind-tools
from ports.
Doug
--
This .signature sanitized for your protection
On 07/09/2012 06:33, Jonathan McKeown wrote:
> On Monday 09 July 2012 09:34:34 Avleen Vig wrote:
>> The issue is also one of barrier-to-entry. By removing `dig` and
>> `host`, I think we're making things unnecessarily more difficult for
>> people who don't *know* FreeBSD. `dig` and `host` a univers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/09/2012 13:47, Peter Jeremy wrote:
> On 2012-Jul-09 14:15:13 +0200, in freebsd-security, "Andrej (Andy)
> Brodnik" wrote:
>> Excuse my ignorance - but is there a how-to paper on transition
>> from bind to unbound for SOHO?
You don't need to t
On 2012-Jul-09 14:15:13 +0200, in freebsd-security, "Andrej (Andy) Brodnik"
wrote:
>Excuse my ignorance - but is there a how-to paper on transition from
>bind to unbound for SOHO?
In particular, if unbound has no authoritative server capabilities, what
suggestions are there for handling the pri
On Mon, Jul 09, 2012 at 09:42:43AM -0700, Jos Backus wrote:
> On Mon, Jul 9, 2012 at 12:34 AM, Avleen Vig wrote:
>
> > [snip]
> >
> The issue is also one of barrier-to-entry. By removing `dig` and
> > `host`, I think we're making things unnecessarily more difficult for
> > people who don't *kno
On Mon, Jul 9, 2012 at 12:34 AM, Avleen Vig wrote:
> [snip]
>
The issue is also one of barrier-to-entry. By removing `dig` and
> `host`, I think we're making things unnecessarily more difficult for
> people who don't *know* FreeBSD. `dig` and `host` a universally
> standard tools for doing DNS lo
On 9 Jul 2012, at 08:34, Avleen Vig wrote:
>
> Agreed. The idea of a "minimally functional system" itself might be
> flawed. Do you consider having `dig` and `host` essential in a
> minimally functioning system? I do.
> It's pretty f'king hard to resolve problems with installing the
> bind-utils
On Monday 09 July 2012 09:34:34 Avleen Vig wrote:
> The issue is also one of barrier-to-entry. By removing `dig` and
> `host`, I think we're making things unnecessarily more difficult for
> people who don't *know* FreeBSD. `dig` and `host` a universally
> standard tools for doing DNS lookups. Takin
On Sun, Jul 8, 2012 at 11:26 PM, Doug Barton wrote:
> On 07/08/2012 23:16, Avleen Vig wrote:
>> On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton wrote:
>>> On 07/08/2012 22:43, Avleen Vig wrote:
It would be silly not to keep bind-tools in base.
>>>
>>> Sounds easy, but not so much in practice. K
< said:
> I could care less about the resolver daemon itself, I agree with what
> you're saying and I don't think most end users will care about that.
> But getting rid of dig and host in base would be bad.
I don't think it's as bad as you suggest, although I do think they we
would likely get a f
On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton wrote:
> On 07/08/2012 22:43, Avleen Vig wrote:
>> It would be silly not to keep bind-tools in base.
>
> Sounds easy, but not so much in practice. Keeping any of the code
> doesn't solve the problem of the release cycles not syncing up. And for
> the va
On Sun, Jul 8, 2012 at 2:39 PM, Doug Barton wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 07/08/2012 10:10, Jason Hellenthal wrote:
>> From first impression it seems that drill(1) has a syntax that
>> leaves something to be desired like the eased use of host or dig.
>
> So once
On Sat, Jul 7, 2012 at 4:38 PM, Doug Barton wrote:
>
> On 07/07/2012 16:33, Garrett Wollman wrote:
> > < said:
> >
> >> BIND in the base today comes with a full-featured local resolver
> >> configuration, which I'm confident that Dag-Erling can do for unbound
> >> (and which I would be glad to ass
On Sun, Jul 8, 2012 at 10:29 AM, Doug Barton wrote:
> Unbound has different policies and release schedules that are more in
> line with ours. So in the short term (as in, the next few years) we're
> better off with unbound in the base.
Where is there information about this / what is their support
Gabor Kovesdan writes:
> Other than the functionality, when we replace something, it is also
> important to do some benchmarks and assure that the performance is not
> reasonably worse. Some time back I committed the error of not
> carefully pass this requirement with BSD grep but so far it seems
Avleen Vig writes:
> As bind-tools and BIND (the resolver) as separate, why not just leave
> bind-tools in base? They'll work happily with unbound.
The bind-tools (host, dig, nslookup) are command-line frontends for the
resolver.
Perhaps what you are trying to say is that they are separate from
Avleen Vig writes:
> It would be silly not to keep bind-tools in base. `host` and `dig` are
> very standard tools most people expect to be available in base, just
> as they are in the base/core/whatever of other operating systems.
We should definitely have an implementation of host(1), but dig(1)
On 7/9/12 12:44 AM, Dan Lukes wrote:
> On 07/08/12 23:55, Doug Barton:
>> On 07/08/2012 07:41, Dan Lukes wrote:
> ...
>> Sorry, you're not understanding what is being proposed. Specifically
>> you're confusing the system stub resolver (the bit that's compiled into
>> libc, and used by binaries) a
On 07/09/2012 00:34, Avleen Vig wrote:
> On Sun, Jul 8, 2012 at 11:26 PM, Doug Barton wrote:
>> On 07/08/2012 23:16, Avleen Vig wrote:
>>> On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton wrote:
On 07/08/2012 22:43, Avleen Vig wrote:
> It would be silly not to keep bind-tools in base.
>
On 07/08/2012 23:16, Avleen Vig wrote:
> On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton wrote:
>> On 07/08/2012 22:43, Avleen Vig wrote:
>>> It would be silly not to keep bind-tools in base.
>>
>> Sounds easy, but not so much in practice. Keeping any of the code
>> doesn't solve the problem of the r
On 07/08/2012 22:43, Avleen Vig wrote:
> It would be silly not to keep bind-tools in base.
Sounds easy, but not so much in practice. Keeping any of the code
doesn't solve the problem of the release cycles not syncing up. And for
the vast majority of users needs the tools we will import will be mor
On Sun, Jul 08, 2012 at 02:39:55PM -0700, Doug Barton wrote:
> On 07/08/2012 10:10, Jason Hellenthal wrote:
> > From first impression it seems that drill(1) has a syntax that
> > leaves something to be desired like the eased use of host or dig.
>
> So once again, if you need the exact capabiliti
On 07/08/12 23:55, Doug Barton:
On 07/08/2012 07:41, Dan Lukes wrote:
...
Sorry, you're not understanding what is being proposed. Specifically
you're confusing the system stub resolver (the bit that's compiled into
libc, and used by binaries) and the resolving name server (BIND). No one
is prop
On 07/08/2012 07:41, Dan Lukes wrote:
>> The ideal, long-term solution is to re-think what "The Base" is, and
>> give users more flexibility at install time.
>
> Flexibility is double-edged sword.
>
> Feel free to replace one resolver with another resolver (but don't do it
> so often, please). Ap
On 07/08/2012 13:25, Gabor Kovesdan wrote:
> On 2012.07.08. 1:17, Doug Barton wrote:
>> Other than authoritative DNS, what features does unbound lack that you
>> want?
> [Picking up a random mail from the thread.]
>
> Other than the functionality, when we replace something, it is also
> important
On 07/08/2012 10:43, Garrett Wollman wrote:
> < said:
>
>> Neither of which has any relevance to the actual root zone ZSK, which
>> could require an emergency roll tomorrow.
>
> Surely that's why there's a separate KSK. The ZSK can be rolled at
> any time.
The ZSK is rolled on a regular schedul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/08/2012 10:10, Jason Hellenthal wrote:
> From first impression it seems that drill(1) has a syntax that
> leaves something to be desired like the eased use of host or dig.
So once again, if you need the exact capabilities of ISC host and dig,
On 2012.07.08. 1:17, Doug Barton wrote:
Other than authoritative DNS, what features does unbound lack that you want?
[Picking up a random mail from the thread.]
Other than the functionality, when we replace something, it is also
important to do some benchmarks and assure that the performance i
< said:
> Neither of which has any relevance to the actual root zone ZSK, which
> could require an emergency roll tomorrow.
Surely that's why there's a separate KSK. The ZSK can be rolled at
any time.
-GAWollman
___
freebsd-hackers@freebsd.org mailing
The ideal, long-term solution is to re-think what "The Base" is, and
give users more flexibility at install time.
Flexibility is double-edged sword.
Feel free to replace one resolver with another resolver (but don't do it
so often, please). Applications can be patched to fit new API, scripts
On Sun, Jul 08, 2012 at 02:21:46AM -0700, Doug Barton wrote:
> On 07/08/2012 01:03, Bjoern A. Zeeb wrote:
> >
> > On 8. Jul 2012, at 02:44 , Warner Losh wrote:
> >
> >>
> >> On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote:
> >>> <
> >>> said:
> >>>
> BIND in the base today comes with a
On 2012-07-08 02:31, Doug Barton wrote:
On 07/07/2012 17:47, Darren Pilgrim wrote:
On 2012-07-07 16:45, Doug Barton wrote:
Also re DNSSEC integration in the base, I've stated before that I
believe very strongly that any kind of hard-coding of trust anchors as
part of the base resolver setup is
On 07/07/2012 17:47, Darren Pilgrim wrote:
> On 2012-07-07 16:45, Doug Barton wrote:
>> Also re DNSSEC integration in the base, I've stated before that I
>> believe very strongly that any kind of hard-coding of trust anchors as
>> part of the base resolver setup is a bad idea, and should not be don
line with ours. So in the short term (as in, the next few years) we're
better off with unbound in the base.
The ideal, long-term solution is to re-think what "The Base" is, and
give users more flexibility at install time. Unfortunately, there is a
making base as minimal as possible give you exa
On 07/07/2012 17:35, Adam Vande More wrote:
> I am unclear on how this solves the main problem I think was stated
> about syncing up with release branches.
I've already explained this at length in the past. ISC has changed both
their release schedule and their policy regarding not allowing new
fe
On 07/08/2012 01:07, Bjoern A. Zeeb wrote:
> On 7. Jul 2012, at 23:45 , Doug Barton wrote:
>
>> On 07/07/2012 16:34, Bjoern A. Zeeb wrote:
>>> On 7. Jul 2012, at 23:17 , Doug Barton wrote:
>
Other than authoritative DNS, what features does unbound lack that you
want?
>>>
>>> DNS64 as a
On 07/08/2012 01:03, Bjoern A. Zeeb wrote:
>
> On 8. Jul 2012, at 02:44 , Warner Losh wrote:
>
>>
>> On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote:
>>> < said:
>>>
BIND in the base today comes with a full-featured local resolver
configuration, which I'm confident that Dag-Erling can
On 07/07/2012 19:44, Warner Losh wrote:
>
> On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote:
>> < said:
>>
>>> BIND in the base today comes with a full-featured local resolver
>>> configuration, which I'm confident that Dag-Erling can do for unbound
>>> (and which I would be glad to assist with
On 7. Jul 2012, at 23:45 , Doug Barton wrote:
> On 07/07/2012 16:34, Bjoern A. Zeeb wrote:
>> On 7. Jul 2012, at 23:17 , Doug Barton wrote:
>>> Other than authoritative DNS, what features does unbound lack that you want?
>>
>> DNS64 as a start.
>
> Personally I would classify that as a highly-
On 8. Jul 2012, at 02:44 , Warner Losh wrote:
>
> On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote:
>> < said:
>>
>>> BIND in the base today comes with a full-featured local resolver
>>> configuration, which I'm confident that Dag-Erling can do for unbound
>>> (and which I would be glad to ass
what integration are you concerned about?
The utilities (specifically host(1) and dig(1)) are the only
user-visible interfaces I care about. I don't see any need for there
to be an authoritative name server in the base system. So long as the
resolver works properly and does DNSsec validation..
On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote:
> < said:
>
>> BIND in the base today comes with a full-featured local resolver
>> configuration, which I'm confident that Dag-Erling can do for unbound
>> (and which I would be glad to assist with if needed). Other than that,
>> what integration
On 2012-07-07 16:45, Doug Barton wrote:
Also re DNSSEC integration in the base, I've stated before that I
believe very strongly that any kind of hard-coding of trust anchors as
part of the base resolver setup is a bad idea, and should not be done.
We need to leverage the ports system for this so
On Sat, Jul 7, 2012 at 6:45 PM, Doug Barton wrote:
> On 07/07/2012 16:34, Bjoern A. Zeeb wrote:
> > On 7. Jul 2012, at 23:17 , Doug Barton wrote:
> >
> >> On 07/07/2012 14:16, Bjoern A. Zeeb wrote:
> >>>
> >>> On 3. Jul 2012, at 12:39 , Dag-Erling Smørgrav wrote:
> >>>
> Doug Barton writes:
< said:
> BIND in the base today comes with a full-featured local resolver
> configuration, which I'm confident that Dag-Erling can do for unbound
> (and which I would be glad to assist with if needed). Other than that,
> what integration are you concerned about?
The utilities (specifically host(
On 07/07/2012 16:34, Bjoern A. Zeeb wrote:
> On 7. Jul 2012, at 23:17 , Doug Barton wrote:
>
>> On 07/07/2012 14:16, Bjoern A. Zeeb wrote:
>>>
>>> On 3. Jul 2012, at 12:39 , Dag-Erling Smørgrav wrote:
>>>
Doug Barton writes:
> The correct solution to this problem is to remove BIND from t
On 07/07/2012 16:33, Garrett Wollman wrote:
> < said:
>
>> BIND in the base today comes with a full-featured local resolver
>> configuration, which I'm confident that Dag-Erling can do for unbound
>> (and which I would be glad to assist with if needed). Other than that,
>> what integration are you
On 7. Jul 2012, at 23:17 , Doug Barton wrote:
> On 07/07/2012 14:16, Bjoern A. Zeeb wrote:
>>
>> On 3. Jul 2012, at 12:39 , Dag-Erling Smørgrav wrote:
>>
>>> Doug Barton writes:
The correct solution to this problem is to remove BIND from the base
altogether, but I have no energy for a
On 07/07/2012 14:16, Bjoern A. Zeeb wrote:
>
> On 3. Jul 2012, at 12:39 , Dag-Erling Smørgrav wrote:
>
>> Doug Barton writes:
>>> The correct solution to this problem is to remove BIND from the base
>>> altogether, but I have no energy for all the whinging that would happen
>>> if I tried (again
83 matches
Mail list logo
