On Mon, Sep 10, 2012 at 07:38:20AM +1000, Mark Andrews wrote:
> Running without a cache at all makes a difference but starting a
> caching nameserver has no real impact on the root servers or tld
> servers.
I would suggest the original poster had taken a much broader view.
There is of course an e
* Mark Andrews :
> Running without a cache at all makes a difference but starting a
> caching nameserver has no real impact on the root servers or tld
> servers.
Thank you. One less thing to worry about :-)
Stefan
___
dns-operations mailing list
dns-op
I said loss of cache, not loss of server, caused by a cache flush on the name
server software.
Rubens
Em 09/09/2012, às 20:38, Mark Andrews escreveu:
>
> In message <7699449b-57ab-499c-93c2-dcf4049e4...@nic.br>, Rubens Kuhl writes:
>>
>> It depends. I can tell from experience that for a la
In message <7699449b-57ab-499c-93c2-dcf4049e4...@nic.br>, Rubens Kuhl writes:
>
> It depends. I can tell from experience that for a large outbound SMTP syste=
> m(1M+ accounts), loss of DNS cache can hit it pretty hard. =
Except we are not talking about the loss of a cache (recursive
nameserver)
It depends. I can tell from experience that for a large outbound SMTP
system(1M+ accounts), loss of DNS cache can hit it pretty hard.
Rubens
Em 09/09/2012, às 12:06, Steven Carr escreveu:
> Is it really that much of an issue to have to start from an empty
> cache? given that >75% of the cach
In message , Rubens Kuhl writes:
> >
> > I'm not sure if I phrased my question correctly. It's not about
> > redundancy, but about keeping the queries to root/g(TLD) name servers
> > to a minimum.
Running without a cache at all makes a difference but starting a
caching nameserver has no real imp
On Sun, Sep 09, 2012 at 04:06:23PM +0100,
Steven Carr wrote
a message of 43 lines which said:
> Is it really that much of an issue to have to start from an empty
> cache?
+1 (And I work for a TLD operator so I would not condone solutions
which would increase the load on our authoritative name
There are many published papers about the load created by DNSSEC on
authoritative name servers. And a lot of practical experience as well,
some of it publically documented.
For the validating *resolvers*, I find on the Web a few tests in a lab
environment (setting up BIND or Unbound with and witho
Is it really that much of an issue to have to start from an empty
cache? given that >75% of the cached RRs will have a TTL of <8 hours
anyway.
Steve
On 9 September 2012 14:45, Rubens Kuhl wrote:
>>
>> I'm not sure if I phrased my question correctly. It's not about
>> redundancy, but about keepi
>
> I'm not sure if I phrased my question correctly. It's not about
> redundancy, but about keeping the queries to root/g(TLD) name servers
> to a minimum.
>
> In your example, if 127.0.0.1 was the resolver that just came up again
> after a restart, it wouldn't return a failure for a query that i
* Randy Bush :
> on client
>
> # cat /etc/resolv.conf
> search foux.you
> nameserver 127.0.0.1
> nameserver 14.666.0.42
> nameserver 666.14.0.42
>
> i.e. have a fallback server or three
I'm not sure if I phrased my question correctly. It's not about
redundancy, but about keeping the queries to r
on client
# cat /etc/resolv.conf
search foux.you
nameserver 127.0.0.1
nameserver 14.666.0.42
nameserver 666.14.0.42
i.e. have a fallback server or three
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman
Hello world,
I am by no means an experienced nameserver operator, so chances are
that this is a stupid question. Please tell me if that's the case.
Given the crappy resolvers I encountered at many ISPs, I've been
running recursive resolvers at quite a few sites. As long as these are
up and runnin
13 matches
Mail list logo
