From: Mark Andrews [EMAIL PROTECTED]
Date: Wed, 18 Jul 2007 16:54:00 +1000
Sender: [EMAIL PROTECTED]
On Tue, Jul 17, 2007 at 12:47:50PM +0200, Volker wrote:
As I think having a default to hint root zone is better, I'll file a
PR about that.
Which leads me to ask:
Why
On Tue, Jul 17, 2007 at 12:47:50PM +0200, Volker wrote:
As I think having a default to hint root zone is better, I'll file a
PR about that.
Which leads me to ask:
Why hasn't anyone recommended using stub zones for this? It seems the
goal is to cache NS records from the rootservers,
On 07/17/07 11:06, Heiko Wundram (Beenic) wrote:
On Tuesday 17 July 2007 10:52:43 Volker wrote:
snip
Relying on a zone transfer doesn't seem to be reliable to me as more
than half of the root servers doesn't reply to AXFR requests.
I've heard pretty much the same thing as you did
--nextPart2302559.jWhKoKUfrP
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Tuesday, 17. July 2007, Volker wrote:
On 07/17/07 09:20, Michael Nottebrock wrote:
On Tuesday, 17. July 2007, Yuri Pankov wrote:
On Tuesday, 17. July 2007, Yuri Pankov wrote:
On Mon, Jul 16, 2007 at 11:19:41PM +0200, Michael Nottebrock wrote:
I finally updated my desktop from 5.5-RELEASE to 6-STABLE. This got me a
new named.conf, which I modified to run named as a local resolver, like I
had before:
listen-on
On 07/17/07 09:20, Michael Nottebrock wrote:
On Tuesday, 17. July 2007, Yuri Pankov wrote:
On Mon, Jul 16, 2007 at 11:19:41PM +0200, Michael Nottebrock wrote:
I finally updated my desktop from 5.5-RELEASE to 6-STABLE. This got me a
new named.conf, which I modified to run named as a local
On Tuesday 17 July 2007 09:39:59 Volker wrote:
The root zone MUST be of type hint. You do not want to be a slave of
the root... don't you? ;)
Actually, I also thought that this is strange, but in a way, this is pretty
sensible, as the only thing you cache (more immediately than by making it a
On 07/17/07 09:45, Heiko Wundram (Beenic) wrote:
On Tuesday 17 July 2007 09:39:59 Volker wrote:
The root zone MUST be of type hint. You do not want to be a slave of
the root... don't you? ;)
Actually, I also thought that this is strange, but in a way, this is pretty
sensible, as the only
On Tuesday 17 July 2007 09:20:16 Michael Nottebrock wrote:
Yes - and this:
zone . {
type slave;
file slave/root.slave;
masters {
192.5.5.241;// F.ROOT-SERVERS.NET.
192.228.79.201; // B.ROOT-SERVERS.NET.
On Tuesday 17 July 2007 10:00:43 Volker wrote:
hmm... the root servers should not allow public AXFR. As I've verified
using:
snip
Just like you did:
[EMAIL PROTECTED] ~]$ dig -t AXFR @k.root-servers.net . | head -30
; DiG 9.3.4 -t AXFR @k.root-servers.net .
; (1 server found)
;; global
On Tuesday, 17. July 2007, Volker wrote:
On 07/17/07 09:20, Michael Nottebrock wrote:
On Tuesday, 17. July 2007, Yuri Pankov wrote:
On Mon, Jul 16, 2007 at 11:19:41PM +0200, Michael Nottebrock wrote:
I finally updated my desktop from 5.5-RELEASE to 6-STABLE. This got me
a new named.conf,
On Tuesday, 17. July 2007, Heiko Wundram (Beenic) wrote:
On Tuesday 17 July 2007 09:20:16 Michael Nottebrock wrote:
Yes - and this:
zone . {
type slave;
file slave/root.slave;
masters {
192.5.5.241;// F.ROOT-SERVERS.NET.
On 07/17/07 10:05, Heiko Wundram (Beenic) wrote:
On Tuesday 17 July 2007 10:00:43 Volker wrote:
hmm... the root servers should not allow public AXFR. As I've verified
using:
snip
Just like you did:
[EMAIL PROTECTED] ~]$ dig -t AXFR @k.root-servers.net . | head -30
; DiG 9.3.4 -t
On Tuesday 17 July 2007 10:52:43 Volker wrote:
snip
Relying on a zone transfer doesn't seem to be reliable to me as more
than half of the root servers doesn't reply to AXFR requests.
I've heard pretty much the same thing as you did wrt. root name servers
denying AXFR, but as it works (TM), I
On 2007-Jul-17 11:06:30 +0200, Heiko Wundram (Beenic) [EMAIL PROTECTED]
wrote:
By the way: using the roots as hints only adds to the number of requests your
server has to do in order to retrieve first-level domain name servers, so in
the end, the transmitted data should be way higher than doing
On Tuesday 17 July 2007 11:30:28 Peter Jeremy wrote:
Note that it's not just a single AXFR - you need to update your local
slave copy whenever the master copy changes. I'm not sure how often
this is but the current SOA has a 1-day timeout and appears to be about
24 hours old. I suspect the
On 07/17/07 11:06, Heiko Wundram (Beenic) wrote:
On Tuesday 17 July 2007 10:52:43 Volker wrote:
snip
Relying on a zone transfer doesn't seem to be reliable to me as more
than half of the root servers doesn't reply to AXFR requests.
I've heard pretty much the same thing as you did wrt. root
On 07/17/07 11:06, Heiko Wundram (Beenic) wrote:
On Tuesday 17 July 2007 10:52:43 Volker wrote:
snip
Relying on a zone transfer doesn't seem to be reliable to me as more
than half of the root servers doesn't reply to AXFR requests.
I've heard pretty much the same thing as you did wrt. root
On Tuesday 17 July 2007 12:47:50 Volker wrote:
I've googled a bit. RFC 2870 says:
2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
queries from clients other than other root servers. This
restriction is intended to, among other things, prevent
On Tue, 2007-07-17 at 13:08 +0200, Heiko Wundram (Beenic) wrote:
On Tuesday 17 July 2007 12:47:50 Volker wrote:
I've googled a bit. RFC 2870 says:
2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
queries from clients other than other root servers. This
On Tue, Jul 17, 2007 at 12:47:50PM +0200, Volker wrote:
As I think having a default to hint root zone is better, I'll file a
PR about that.
Which leads me to ask:
Why hasn't anyone recommended using stub zones for this? It seems the
goal is to cache NS records from the rootservers, and stub
On 07/17/07 13:45, Jeremy Chadwick wrote:
On Tue, Jul 17, 2007 at 12:47:50PM +0200, Volker wrote:
As I think having a default to hint root zone is better, I'll
file a PR about that.
Which leads me to ask:
Why hasn't anyone recommended using stub zones for this? It seems
the goal is to
On Tuesday 17 July 2007 13:45:04 Jeremy Chadwick wrote:
On Tue, Jul 17, 2007 at 12:47:50PM +0200, Volker wrote:
As I think having a default to hint root zone is better, I'll file a
PR about that.
Which leads me to ask:
Why hasn't anyone recommended using stub zones for this? It seems the
On Tue, Jul 17, 2007 at 07:30:28PM +1000, Peter Jeremy wrote:
Note that it's not just a single AXFR - you need to update your local
slave copy whenever the master copy changes. I'm not sure how often
this is but the current SOA has a 1-day timeout and appears to be about
24 hours old. I
On Tuesday 17 July 2007 15:17:22 David Malone wrote:
I measured the traffic levels a while back:
http://www.imconf.net/imc-2004/papers/p15-malone.pdf
It's actually pretty close for a moderately busy recursive resolver,
and if you allow IXFR (which, I belive, the root servers in
Michael Nottebrock wrote:
On Tuesday, 17. July 2007, Heiko Wundram (Beenic) wrote:
This is natural, unless you specifically enter the zones for 192.168.8.*
(forward and reverse) in your client DNS server (as slave or forward zones,
see the bind manual for the latter, which I'd recommend in
Volker,
I'm sorry to say that you've provided a great deal of incorrect
information in this thread.
Volker wrote:
Remember, AXFR requires a TCP transfer and not every firewall will
happily let it pass.
This is true, although since to the firewall an AXFR looks just like
any other stateful
Doug,
On 07/17/07 18:14, Doug Barton wrote:
Volker,
I'm sorry to say that you've provided a great deal of incorrect
information in this thread.
sorry? really? I couldn't find one!
Volker wrote:
Remember, AXFR requires a TCP transfer and not every firewall will
happily let it pass.
Volker wrote:
Doug,
On 07/17/07 18:14, Doug Barton wrote:
Volker,
I'm sorry to say that you've provided a great deal of incorrect
information in this thread.
sorry? really? I couldn't find one!
Yeah, that's part of the problem. Fortunately I'm here to help. :)
1. It's amusing, root
On Tue, Jul 17, 2007 at 02:01:52PM -0700, Doug Barton wrote:
3. Using the root zone as type stub should work (even while ARM says
it's not DNS standard). But ARM says, it's not recommended for new
configurations (I have no idea why it does state that).
This is just plain bad advice, although
Jeremy Chadwick wrote:
On Tue, Jul 17, 2007 at 02:01:52PM -0700, Doug Barton wrote:
3. Using the root zone as type stub should work (even while ARM says
it's not DNS standard). But ARM says, it's not recommended for new
configurations (I have no idea why it does state that).
This is just
On Tuesday 17 July 2007 23:06:22 Jeremy Chadwick wrote:
Can you expand on this, re: why it's bad advice? I also cannot make
heads or tails of the BIND ARM saying it's not recommended. Please
shed some light on this for those of us less experienced in the know,
if you could (I mean that
I finally updated my desktop from 5.5-RELEASE to 6-STABLE. This got me a new
named.conf, which I modified to run named as a local resolver, like I had
before:
listen-on { 127.0.0.1; };
listen-on-v6{ ::1; };
forward only;
forwarders {
192.168.8.1;
};
Everything else is default.
On Mon, Jul 16, 2007 at 11:19:41PM +0200, Michael Nottebrock wrote:
I finally updated my desktop from 5.5-RELEASE to 6-STABLE. This got me a new
named.conf, which I modified to run named as a local resolver, like I had
before:
listen-on { 127.0.0.1; };
listen-on-v6{ ::1; };
34 matches
Mail list logo
