On 12/16/2013 03:26 PM, Mark Andrews wrote:
In message <52acf0ee.3040...@redbarn.org>, Paul Vixie writes:
this is true. and i am a strong opponent of mixed-mode (recursive plus
authoritative) servers, and i believe these are deprecated in later DNS
RFC's, and in any case not even BIND 10 will
Mark Andrews wrote:
> In message <52acf0ee.3040...@redbarn.org>, Paul Vixie writes:
>> this is true. and i am a strong opponent of mixed-mode (recursive plus
>> authoritative) servers, ...
>
> I don't care about mixed-mode for a nominally recursive server.
>
> If you are a *listed* authoritativ
In message <52acf0ee.3040...@redbarn.org>, Paul Vixie writes:
>
> this is true. and i am a strong opponent of mixed-mode (recursive plus
> authoritative) servers, and i believe these are deprecated in later DNS
> RFC's, and in any case not even BIND 10 will have that feature mix --
> but RFC 1034
Paul Vixie wrote:
> Robert Edmonds wrote:
> > i'm curious as to exactly what this root zone slaved resolver
> > configuration looks like and how it would behave. [...]
>
> > if i understand things right, this config could only be achieved with
> > particular resolver implementations that combine a
Robert Edmonds wrote:
> i'm curious as to exactly what this root zone slaved resolver
> configuration looks like and how it would behave. i don't believe i've
> ever set up a resolver like that before.
in BIND, you just make yourself a secondary server for ".", pulling from
192.5.5.241 (f-root
Mark Andrews wrote:
> In message <20131128000148.ga20...@mycre.ws>, Robert Edmonds writes:
> > i'm curious as to exactly what this root zone slaved resolver
> > configuration looks like and how it would behave. i don't believe i've
> > ever set up a resolver like that before.
>
> zone "." IN {
In message <20131128000148.ga20...@mycre.ws>, Robert Edmonds writes:
> David Conrad wrote:
> > Ed,
> >
> > On Nov 27, 2013, at 6:00 AM, Edward Lewis wrote:
> > > My excuse is - operators limit "the effort expended in fighting
> > > entropy." Imagine an average operations environment operating a
David Conrad wrote:
> Ed,
>
> On Nov 27, 2013, at 6:00 AM, Edward Lewis wrote:
> > My excuse is - operators limit "the effort expended in fighting entropy."
> > Imagine an average operations environment operating as most environments go.
> > ...
> > Eventually one day something breaks and then.
Ed,
On Nov 27, 2013, at 6:00 AM, Edward Lewis wrote:
> My excuse is - operators limit "the effort expended in fighting entropy."
> Imagine an average operations environment operating as most environments go.
> ...
> Eventually one day something breaks and then... ...include here "the
> on
My excuse is - operators limit "the effort expended in fighting entropy."
Imagine an average operations environment operating as most environments go.
One admin comes in a decides they can do a better job. And the admin does,
stellar talent.
Then the said stellar admin decides to move on care
Hi Damian,
At 18:17 26-11-2013, Damian Menscher wrote:
Back to solving the problem of traffic at the roots, I've always
been curious why recursive resolvers don't just AXFR the root zone
file and cache the list of TLDs. Yes,
From some RFC:
"Root servers SHOULD NOT answer AXFR, or other zon
On Tuesday 26 November 2013 at 21:17, Damian Menscher wrote:
> Back to solving the problem of traffic at the roots, I've always been curious
> why recursive resolvers don't just AXFR the root zone file and cache the list
> of TLDs. Yes, a new TLD might go unnoticed for the duration of your cache,
On 11/26/2013 01:06 PM, Andrew Sullivan wrote:
On Tue, Nov 26, 2013 at 08:58:18PM +, Jim Reid wrote:
+1. However the lookups I was talking about are not going to name servers that
google owns or have agreed to receive that traffic.
I'm not sure it's entirely true that, if you've decided
On Tue, Nov 26, 2013 at 08:58:18PM +, Jim Reid wrote:
> +1. However the lookups I was talking about are not going to name servers
> that google owns or have agreed to receive that traffic.
>
I'm not sure it's entirely true that, if you've decided to operate a
root name server, you haven't ag
On 26 Nov 2013, at 20:22, Vernon Schryver wrote:
> If those diagnoses are correct that the probes are for subdomains of
> the local hosts's domain
I'll be charitable. If these diagnoses are correct they fail to tell the full
story.
It's not possible to predict what the code does unless someone
On 26 Nov 2013, at 19:23, Vernon Schryver wrote:
> If the probing test requests are for domains that Google owns or has
> permission for junk queries, then no one outside Google has standing
> to complain.
+1. However the lookups I was talking about are not going to name servers that
google own
> From: Rubens Kuhl
> Yeap, in the source code. Some discussions on those:
> http://productforums.google.com/forum/#!topic/chrome/dQ92XhrDjfk
> https://code.google.com/p/chromium/issues/detail?id=47262
> http://serverfault.com/questions/235307/unusual-head-requests-to-nonsense-urls-from-chrome
>
>
> Is whatever Google doing documented somewhere? I didn't see anything
> with https://www.google.com/search?q=chromium+nxdomain+detection+dns
> and one or two similar searches.
Yeap, in the source code. Some discussions on those:
http://productforums.google.com/forum/#!topic/chrome/dQ92XhrDj
> From: Jim Reid
> This is definitely not a nice trick. It generates hundreds of millions
> of queries to the root servers every day that don't need to go there.
The devil is in the details.
If the probing test requests are for domains that Google owns or has
permission for junk queries, then n
On 26 Nov 2013, at 17:29, Damian Menscher wrote:
>> Which follows the known Chromium (main Google Chrome component) pattern of
>> a few random 10-character requests for every search query to make such
>> detection.
>
> I didn't realize Chrome did that -- nice trick!
This is definitely not a n
20 matches
Mail list logo
