Bjørn Mork wrote:
>
> The reason I ask here first, is because RFC 7706 includes a BIND
> specific configuration example (as well as examples for other recursive
> server software). So before considering changing config or code, I
> wanted to know the background of that example.
On 7 Apr 2017, at 1:50, Bjørn Mork wrote:
bert hubert writes:
On Fri, Apr 07, 2017 at 10:20:00AM +0200, Bjørn Mork wrote:
Just to avoid any confusion: Although I demonstrated the issue by
running BIND on my laptop only, the real usage scenario is resolver
service
bert hubert writes:
> On Fri, Apr 07, 2017 at 10:20:00AM +0200, Bjørn Mork wrote:
>> Just to avoid any confusion: Although I demonstrated the issue by
>> running BIND on my laptop only, the real usage scenario is resolver
>> service for a few million distinct
On Fri, Apr 07, 2017 at 10:20:00AM +0200, Bjørn Mork wrote:
> Just to avoid any confusion: Although I demonstrated the issue by
> running BIND on my laptop only, the real usage scenario is resolver
> service for a few million distinct administrative domains (aka
> "customers"). Changing the trust
Just to avoid any confusion: Although I demonstrated the issue by
running BIND on my laptop only, the real usage scenario is resolver
service for a few million distinct administrative domains (aka
"customers"). Changing the trust anchor is not an option.
Bjørn
On Friday, April 7, 2017 12:51:40 AM GMT David Conrad wrote:
> Paul,
>
> On Apr 6, 2017, 2:24 PM -1000, Paul Vixie , wrote:
> > the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or
> > non-experienced or non-protocol-geeks;
> ... This strikes me as a bit
Paul,
On Apr 6, 2017, 2:24 PM -1000, Paul Vixie , wrote:
> the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or
> non-experienced or non-protocol-geeks;
7706 doesn't recommend editing someone else's zone file, re-signing it, and
figuring out how to
On Thursday, April 6, 2017 11:53:25 PM GMT David Conrad wrote:
> On Apr 6, 2017, 2:32 AM -1000, Paul Vixie , wrote:
> > if you want to run yeti-style, there are some perl scripts that will
> > fetch and verify the root zone, edit the apex NS and DNSKEY RRsets,
> > re-sign with
On Apr 6, 2017, 2:32 AM -1000, Paul Vixie , wrote:
> if you want to run yeti-style, there are some perl scripts that will
> fetch and verify the root zone, edit the apex NS and DNSKEY RRsets,
> re-sign with your local key, and give you a zone you can run on several
> servers
Bjørn Mork wrote:
> Tony Finch writes:
...
>> You might be able to work around the problem by adding a
>> match-recursion-only option to the recursive view, and adding a
>> non-recursive view that has allow-query-cache, and use attach-cache
>> so all views share the same cache. I
Bjørn Mork wrote:
>
> Recently I noticed a side effect of this configuration which I consider
> unwanted and unexpected: It changes how BIND replies to requests without
> the RD bit set. BIND will normally answer such requests with a "best
> possible redirection", using any
Hello,
We are currently trying out the configuration recommended by RFC7706,
serving a copy of the root zone on a loopback. We are using BIND 9.10
and our configuration is directly copied from the example in appendix
B.1. Even down to the actual loopback address used, as we needed a
dedicated
12 matches
Mail list logo