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
Hi,
On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh wrote:
>
> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
>
>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote:
>>>
>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>>
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wr
On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need t
On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote:
> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote:
>>
>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote:
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot regist
On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote:
>
> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
>
>> Hi,
>>
>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote:
>>>
>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Ok, yet another Newbus' limitation. Assuming a device exports
On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote:
>>
>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>>> Ok, yet another Newbus' limitation. Assuming a device exports more
>>> than one interface, and one of its child has need t
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote:
>
> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
>> Ok, yet another Newbus' limitation. Assuming a device exports more
>> than one interface, and one of its child has need to use more than one
>> interface, each interfaces cannot regist
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
> Ok, yet another Newbus' limitation. Assuming a device exports more
> than one interface, and one of its child has need to use more than one
> interface, each interfaces cannot register, concurrently, its own
> ivar. While I try to always have a s
On 2012/07/08 18:21, Chris Rees wrote:
Hi all / David,
doxygen has been failing for a while now on -CURRENT and apparently
-STABLE too. The current fix is disabling one of the tests in the
build, but obviously it points to a problem with our base system
I've trussed [1] the failing code [2
Hi folks,
Ok, yet another Newbus' limitation. Assuming a device exports more
than one interface, and one of its child has need to use more than one
interface, each interfaces cannot register, concurrently, its own
ivar. While I try to always have a single child per
interface/resource, I need to ke
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 5 July 2012 01:30, Tim Kientzle wrote:
> On Jul 4, 2012, at 4:41 PM, Jason Hellenthal wrote:
>>
>> On Wed, Jul 04, 2012 at 03:59:29PM -0700, Doug Barton wrote:
>>> On 07/04/2012 15:55, Jason Hellenthal wrote:
Seeing as sudo plays a big part of this
>>>
>>> No ... not only is sudo not a nec
On 2012-Jul-03 21:17:53 +1000, Peter Jeremy wrote:
>I have a reasonably recent 8-stable/amd64 system (r237444) with a "ATI
>Radeon HD 2400 Pro", xorg-server-1.10.6,1 and xf86-video-ati-6.14.3_1
>8GB RAM and ZFS. I'm seeing fairly consistent problems with Xorg
...
>How difficult would it be to mod
Hi all / David,
doxygen has been failing for a while now on -CURRENT and apparently
-STABLE too. The current fix is disabling one of the tests in the
build, but obviously it points to a problem with our base system
I've trussed [1] the failing code [2], and it looks as though it's
hanging on
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..
35 matches
Mail list logo