> 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 a
> --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 Panko
> On 07/17/07 11:06, Heiko Wundram (Beenic) wrote:
> > On Tuesday 17 July 2007 10:52:43 Volker wrote:
> >>
> >> 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
> 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 roots
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 tha
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
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, al
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 amus
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
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 T
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
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 qu
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 s
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 s
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 goa
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 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 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
>unn
On 07/17/07 11:06, Heiko Wundram (Beenic) wrote:
> On Tuesday 17 July 2007 10:52:43 Volker wrote:
>>
>> 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. r
On 07/17/07 11:06, Heiko Wundram (Beenic) wrote:
> On Tuesday 17 July 2007 10:52:43 Volker wrote:
>>
>> 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. r
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 th
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
On Tuesday 17 July 2007 10:52:43 Volker wrote:
>
> 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 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:
>>
>
> Just like you did:
>
> [EMAIL PROTECTED] ~]$ dig -t AXFR @k.root-servers.net . | head -30
>
> ; <<>> DiG 9
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 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
On Tuesday 17 July 2007 10:00:43 Volker wrote:
> hmm... the root servers should not allow public AXFR. As I've verified
> using:
>
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)
;; glob
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 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
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: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 loc
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:
> >
> > list
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; };
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. Ho
34 matches
Mail list logo
