Re: Zone Transfers Being Refused

. Original message From: Ondřej Surý Date: 31/07/23 8:10 PM (GMT+12:00) To: matt...@peregrineit.net Cc: bind-users@lists.isc.org Subject: Re: Zone Transfers Being Refused Well, for starters your primaries list 192.168.2.10, but your logs show connection from 192.168.1.1…--Ondřej Surý — ISC

Re: Zone Transfers Being Refused

Yeap, that's what my issue is  :-) On 31/07/2023 18:09, Ondřej Surý wrote: Well, for starters your primaries list 192.168.2.10, but your logs show connection from 192.168.1.1… -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated

Re: Zone Transfers Being Refused

Well, for starters your primaries list 192.168.2.10, but your logs show connection from 192.168.1.1… -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 31. 7. 2023, at 9:51, dulux

Re: Zone Transfers Being Refused

Hi Ondřej, Sorry, force of habit (re: "example.com"). External Secondary DNS Server (ns1.mjb-co.com): ~~~ acl "bogusnets" {     !"internal_hosts";     0.0.0.0/8;     10.0.0.0/8;     172.16.0.0/12;     192.0.2.0/24;     192.168.0.0/16;     224.0.0.0/3; }; acl "internal_hosts" {     192.168.1.0/

Re: Zone Transfers Being Refused

Hi, it’s hard to help you if you don’t provide your configuration (named-checkconf -px) and use example.com instead of real domain names. Are even the IP addresses real? Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated

Zone Transfers Being Refused

Hi All, Hoping someone can help with this: I've got a primary dns server on an internal network (192.168.2.10/24) and an external secondary dns server on the dmz network (192.168.1.10/24). The gateway for each (ie the router) is 192.168.x.1. The external domain is dynamic, with dnssec set up

gss-tsig for zone transfers

Hello, I have gss-tsig running for authenticating dynamic DNS update requests for a small MIT Kerberos realm, which is working fine. Is it possible to further use gss-tsig for zone transfers instead of shared keys? Thanks, Richard -- Visit https://lists.isc.org/mailman/listinfo/bind-users

Re: Use UDP for (small) incremental zone transfers?

Sending from the correct email alias! Hi again. How many is "many"? A busy server will be handling many 1000s of queries per second. A few (tiny) zone transfers per minute will be background noise compared to that and the extra overhead of TCP will be negligible in comparison. IMHO it&#

Re: Use UDP for (small) incremental zone transfers?

On 13/1/23 7:12, Greg Choules via bind-users wrote: Hi Jesus. No. Zone Transfer always uses TCP. Is it really that much of an overhead for you? Not now, but it could be in the future, with many secondaries and many (tiny) updates per minute. Per your answer, I understand that zone

Re: Use UDP for (small) incremental zone transfers?

Hi Jesus. No. Zone Transfer always uses TCP. Is it really that much of an overhead for you? Cheers, Greg On Fri, 13 Jan 2023 at 05:56, Jesus Cea wrote: > I have a dns zone with many dns updates per minute. The updates are > tiny, like 2-3 records, <500 bytes in total. > > Currently my secondari

Use UDP for (small) incremental zone transfers?

I have a dns zone with many dns updates per minute. The updates are tiny, like 2-3 records, <500 bytes in total. Currently my secondaries receive a NOTIFY and they do a TCP connection to request a incremental zone transfer. We know that TCP is "heavy" and the data I need to transfer is tiny be

Re: Zone transfers can be lost forever

Edit the primary zone, just put a TXT record in it, saying anything, gibberish even, save and reload the zone let us know so we can check it for currency on both your NS1 and NS2 If you followed Tony's advice there is no reason it is not in sync and I don't see an issue. On 18/10/2019 05:48

Re: Zone transfers can be lost forever

> > If the zone file on the primary can be edited by `named` (dynamic > updates, signing, etc) then you need to `rndc freeze`, edit, `rndc thaw` > instead. I did all that, even restarted the systemd service on the primary after noticing the the issue. Then, on *both* servers: *named-checkzone -j

Re: Zone transfers can be lost forever

jean-christophe manciot wrote: > However, if I increment the serial number (SN) on the primary from > 2019101614 to 2019101709 and order a retransfer on the secondary with "rndc > retransfer sdxlive.com", I get in the logs: > *on the primary*: > > (serial 2019101614) Did you `rndc reload sdxlive

Re: Zone transfers can be lost forever

Also, if I send the command "rndc notify sdxlive.com" on the primary, I get in the logs: *on the primary*: 17-Oct-2019 11:08:46.047 general: info: received control channel command 'notify sdxlive.com' 17-Oct-2019 11:08:46.053 notify: info: zone sdxlive.com/IN (signed): sending notifies (serial 201

Re: Zone transfers can be lost forever

However, if I increment the serial number (SN) on the primary from 2019101614 to 2019101709 and order a retransfer on the secondary with "rndc retransfer sdxlive.com", I get in the logs: *on the primary*: *17-Oct-2019 10:56:09.038 xfer-out: info: client @0x a.b.c.d#49155 (sdxlive.com <

Re: Zone transfers can be lost forever

> > wow something has chewed up your message and vomited it out again but some > of the remnants are vaguely legible... > I don't know what happened, but some IP addresses & other fields have been intentionally obfuscated. The original first message have been attached to this answer. I'm not sure

Re: Zone transfers can be lost forever

jean-christophe manciot wrote: wow something has chewed up your message and vomited it out again but some of the remnants are vaguely legible... > - the debug log shows that the zone transfer has *successfully* taken place > on the primary towards the secondary server: > > - actually, the zone t

Zone transfers can be lost forever

Hi there, Here's the *context*: *Ubuntu 19.10 / Debian bullseye 11* *bind9 9.15.4* *zone "sdxlive.com " { type master; file "/etc/bind/db.sdxlive.com "; // Publishing and activating dnssec keys auto-dnssec maintain;

Re: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

Am 14.07.2018 um 00:38 schrieb Matthew Pounsett: > On 13 July 2018 at 06:04, Michał Kępień wrote: > >> Hopefully this will shed some light on the matter: >> >> https://gitlab.isc.org/isc-projects/bind9/issues/339#note_12805 >> >> That is helpful, thanks. That comment says the issue require

Re: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

On 13 July 2018 at 06:04, Michał Kępień wrote: > Hopefully this will shed some light on the matter: > > https://gitlab.isc.org/isc-projects/bind9/issues/339#note_12805 > > That is helpful, thanks. That comment says the issue requires a journal entry of over 4G, however the original bug repor

Re: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

> > What is an "extraordinarily large zone transfer"? We do have regularly > > AXFR and IXFRs around 2GB. Is this "extraordinarily large"? > > > > I've also been curious about this. Are we talking millions of records, > tens or hundreds of millions, or billions? Hopefully this will shed some lig

Re: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

On 9 July 2018 at 16:22, Klaus Darilion wrote: > What is an "extraordinarily large zone transfer"? We do have regularly > AXFR and IXFRs around 2GB. Is this "extraordinarily large"? > I've also been curious about this. Are we talking millions of records, tens or hundreds of millions, or billion

Fwd: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

What is an "extraordinarily large zone transfer"? We do have regularly AXFR and IXFRs around 2GB. Is this "extraordinarily large"? regards Klaus Weitergeleitete Nachricht Betreff: Operational Notification: Extremely large zone transfers can result

Re: DNS views and zone transfers, cont

t; got the "empty zones" created, so any queries in those zones did not get >>> forwarded. I am fixing it by adding to that view the line: >>>empty-zones-enable no; >>> >>> -- >>> Bob Harold >>> >>> >>> On

Re: DNS views and zone transfers, cont

u, Sep 8, 2016 at 9:41 AM, Bob Harold wrote: >> >>> >>> On Thu, Sep 8, 2016 at 9:13 AM, project722 wrote: >>> >>>> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone >>>> transfers. First off, what is the reasoning or benefit

Re: DNS views and zone transfers, cont

that view the line: >empty-zones-enable no; > > -- > Bob Harold > > > On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold wrote: > >> >> On Thu, Sep 8, 2016 at 9:13 AM, project722 wrote: >> >>> Bob, in our prod environment, we are allowing 127.0.0.

Re: DNS views and zone transfers, cont

wrote: > >> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone >> transfers. First off, what is the reasoning or benefit of allowing >> localhost to make zone transfers? Secondly, In my new view config since I >> will be using 127.0.0.1 as a forwarder, wo

Re: DNS views and zone transfers

xternal view. Why is that? > The "internal" and "external" keys are so that I can test both views from anywhere with: dig something -k key.internal dig something -k key.external The keys are also used if you need to do notify's or zone transfers and get them to the r

Re: DNS views and zone transfers

;> >>>> }; >>>> >>>> view external { >>>> >>>> match clients - external { >>>> >>>> zone example.org { >>>> }; >>>> >>>> zone example.com { >>>> }; >>

Re: DNS views and zone transfers

On Wed, Sep 7, 2016 at 12:34 PM, /dev/rob0 wrote: > On Wed, Sep 07, 2016 at 11:48:54AM -0400, Bob Harold wrote: > > On Wed, Sep 7, 2016 at 11:37 AM, project722 > wrote: > > > > > Thanks Bob, I will look into this. Do you know if the forwarders > > > feature is supported in Bind 9.8.2? > > > > >

Re: DNS views and zone transfers

On Wed, Sep 07, 2016 at 11:48:54AM -0400, Bob Harold wrote: > On Wed, Sep 7, 2016 at 11:37 AM, project722 wrote: > > > Thanks Bob, I will look into this. Do you know if the forwarders > > feature is supported in Bind 9.8.2? > > > Yes, forwarders is an old and stable feature. > > ("in-view" is n

Re: DNS views and zone transfers

gt;>> >>> zone example.org { >>> }; >>> >>> zone example.com { >>> }; >>> >>> }; >>> >>> >>> >>> On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold wrote: >>> >>>> >>>

Re: DNS views and zone transfers

s - external { >> >> zone example.org { >> }; >> >> zone example.com { >> }; >> >> }; >> >> >> >> On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold wrote: >> >>> >>> On Thu, Aug 25, 2016 at 12:56 PM, project722 &

Re: DNS views and zone transfers

> > view external { > > match clients - external { > > zone example.org { > }; > > zone example.com { > }; > > }; > > > > On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold wrote: > >> >> On Thu, Aug 25, 2016 at 12:56 PM, project722 >> wr

Re: DNS views and zone transfers

On 06.09.16 16:23, project722 wrote: I'm interested in the "view forwarding" method. I'm only setting up views to resolve a split DNS issue with one domain. I'd like to have that one zone/domain in my internal view and then if the source IP requests info for any other zone forward that to my exte

Re: DNS views and zone transfers

Harold wrote: > > On Thu, Aug 25, 2016 at 12:56 PM, project722 wrote: > >> I have successfully setup TSIG keys for "views" using a DNS master/server >> pair. Zone transfers are working as expected between the 2 servers for each >> view. Before we go live into p

Re: DNS views and zone transfers

On Thu, Aug 25, 2016 at 12:56 PM, project722 wrote: > I have successfully setup TSIG keys for "views" using a DNS master/server > pair. Zone transfers are working as expected between the 2 servers for each > view. Before we go live into production with this I need some c

DNS views and zone transfers

I have successfully setup TSIG keys for "views" using a DNS master/server pair. Zone transfers are working as expected between the 2 servers for each view. Before we go live into production with this I need some clarification on a couple things. Our prod servers are also allowing zone tr

Re: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers

r Nix wri >> tes: >>>> Thanks for the quick response. "dig +noedns" did it. Thank you. >>> >>> It still should not have resulted in a "extra input data". >>> >>> It would be useful to see the hex dump of the dns message >

Re: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers

gt;> Thanks for the quick response. "dig +noedns" did it. Thank you. > > > > It still should not have resulted in a "extra input data". > > > > It would be useful to see the hex dump of the dns message > > that triggered the "ext

Re: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers

ata". > > It would be useful to see the hex dump of the dns message > that triggered the "extra input data" message. > > Mark > >>> On Nov 20, 2013, at 22:09, Evan Hunt wrote: >>> >>>> On Wed, Nov 20, 2013 at 09:46:40PM -0500, cy

Re: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers

age that triggered the "extra input data" message. Mark > > On Nov 20, 2013, at 22:09, Evan Hunt wrote: > > > >> On Wed, Nov 20, 2013 at 09:46:40PM -0500, cypher Nix wrote: > >> Bind 9.9.x is able to perform zone transfers from the Windows DC > >> w

Re: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers

Thanks for the quick response. "dig +noedns" did it. Thank you. > On Nov 20, 2013, at 22:09, Evan Hunt wrote: > >> On Wed, Nov 20, 2013 at 09:46:40PM -0500, cypher Nix wrote: >> Bind 9.9.x is able to perform zone transfers from the Windows DC >> without any i

Re: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers

On Wed, Nov 20, 2013 at 09:46:40PM -0500, cypher Nix wrote: > Bind 9.9.x is able to perform zone transfers from the Windows DC > without any issue. Performing a named-checkzone against the zone file > with bind 9.9.4 and bind 9.9.2 returns no errors. It looks like the > issue is j

dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers

osoft Windows DC but fails around the same SRV record with a message ";; Got bad packet: extra input data". I had the SRVs record re-created but this did not solve the issue. There are over 40,000 records on this zone. I can perform full zone transfers from the Windows DC if I use older ver

dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers

osoft Windows DC but fails around the same SRV record with a message ";; Got bad packet: extra input data". I had the SRVs record re-created but this did not solve the issue. There are over 40,000 records on this zone. I can perform full zone transfers from the Windows DC if I use older

Re: Delayed Zone Transfers?

> From: Phil Mayers > To: bind-users@lists.isc.org > Cc: > Sent: Monday, August 6, 2012 2:37 PM > Subject: Re: Delayed Zone Transfers? > > On 08/06/2012 05:33 PM, Jiann-Ming Su wrote: > >> Yeah, I've wondered about views.  We went to views to work around

Re: Delayed Zone Transfers?

On 08/06/2012 05:33 PM, Jiann-Ming Su wrote: Yeah, I've wondered about views. We went to views to work around a MTA config issue. The weird zone transfer performance seem to have coincided with our transition to views. Here's my named.conf, FWIW: view hc { include "/etc/named.zones"; view a

RE: Delayed Zone Transfers

bind-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..." Today's Topics: 1. Re: Delayed Zone Transfers? (Jiann-Ming Su) 2. Re: Delayed Zone Transfers? (Jiann-Ming Su) 3. Re: Delayed

Re: Delayed Zone Transfers?

> From: Jiann-Ming Su > To: "bind-users@lists.isc.org" > Cc: > Sent: Monday, August 6, 2012 12:33 PM > Subject: Re: Delayed Zone Transfers? > >> From: Phil Mayers >> To: bind-users@lists.isc.org >> Cc: >> Sent: Monday, August 6, 2

Re: Delayed Zone Transfers?

> From: Phil Mayers > To: bind-users@lists.isc.org > Cc: > Sent: Monday, August 6, 2012 12:07 PM > Subject: Re: Delayed Zone Transfers? > > On 06/08/12 17:03, Jiann-Ming Su wrote: > >> Here's an example of the zone file being updated, but BIND not serving

Re: Delayed Zone Transfers?

On 06/08/12 17:03, Jiann-Ming Su wrote: Here's an example of the zone file being updated, but BIND not serving out the new data. Running dig locally: # dig @localhost myhost.uts-sa.mydomain.ddns I note from your other email that you are using views. Are you sure you are querying the right v

Re: Delayed Zone Transfers?

> From: Jiann-Ming Su > To: "bind-users@lists.isc.org" > Cc: > Sent: Thursday, August 2, 2012 5:38 PM > Subject: Delayed Zone Transfers? > > What would cause a delay in zone transfers?  The notify go out immediately > when > the serial number c

Re: Delayed Zone Transfers?

> From: J > To: "bind-users@lists.isc.org" > Cc: > Sent: Thursday, August 2, 2012 5:57 PM > Subject: Re: Delayed Zone Transfers? > > Jiann-Ming Su wrote: >> What would cause a delay in zone transfers?  The notify go out >> immediately when the seria

Re: Delayed Zone Transfers?

Jiann-Ming Su wrote: > What would cause a delay in zone transfers? The notify go out > immediately when the serial number changes on the master, but some of the > secondaries can take up to 10 minutes before initiating the zone > transfer. Also, even after the zone has been tran

Re: Delayed Zone Transfers?

On 8/2/2012 2:38 PM, Jiann-Ming Su wrote: > What would cause a delay in zone transfers? The notify go out immediately > when the serial number changes on the master, but some of the secondaries can > take up to 10 minutes before initiating the zone transfer. Also, even after >

Delayed Zone Transfers?

What would cause a delay in zone transfers?  The notify go out immediately when the serial number changes on the master, but some of the secondaries can take up to 10 minutes before initiating the zone transfer.  Also, even after the zone has been transferred, the secondary will not immediately

RE: Split DNS and zone transfers

and zone transfers I’ve been pointed to the right place to figure this out. The answer is in using TSIG. That saved me a lot of time. I searched everywhere but the most-obvious place – the bind9 faq. Eric Chandler Systems Architect From: bind-users-bounces+eric.chandler=vonage

RE: Split DNS and zone transfers

c.org [mailto:bind-users-bounces+eric.chandler=vonage@lists.isc.org] On Behalf Of Eric Chandler Sent: Monday, April 16, 2012 11:36 AM To: bind-users@lists.isc.org Subject: Split DNS and zone transfers I have a situation where I need to filter out our private infrastructure from our public-facin

Re: Split DNS and zone transfers

On 16/04/12 16:36, Eric Chandler wrote: Now, what I would like to have are slave servers that would zone-xfer both the internal and external-flavored files for example.com and serve You need to use TSIG keys, and match on key rather than IP address. This comes up on the list from time to time

Split DNS and zone transfers

ed only by customer devices, and still others service our internal systems. I would like to get us down to just 1 set of configuration files across the board, using views as the way to do it, but what I can't get around are split zone transfers. In this example, we have a straightforwa

Re: split horizon and zone transfers to secondary DNS servers

Notifies are also a challenge. The two solutions are: -Use TSIG for the notifies and zone transfers. -Use extra IPs: on each primary and secondary, set up an IP address dedicated to notifies and transfers for a specific view. Your first view can use your preexisting IP but each additional view

Re: split horizon and zone transfers to secondary DNS servers

ify IP addresses -- there is only one IP for > the sec.) Yes, but the trick is to use TSIG keys so the two servers can tell the difference between zone transfers for the different views. Tony. -- f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger, Fisher, German Bight, Humber, Thames: Southerl

Re: split horizon and zone transfers to secondary DNS servers

> Judicious use of views with ACLs I haven't actually tested this, but there's a recent thread [1] which describes what I mean. Pay particular attention to the issue of getting master notification into the slaves. -JP [1] https://lists.isc.org/pipermail/bind-users/2011-May/083664.html _

Re: split horizon and zone transfers to secondary DNS servers

:-) >> Or should I use separate secondary DNS servers for internal and >> external zones? > > That depends a bit on your setup. Judicious use of views with ACLs > could help you solve your problem regarding the zone transfers, but you > may feel more comfortable w

Re: split horizon and zone transfers to secondary DNS servers

the same zone in the one view; same rules apply here.) > Or should I use separate secondary DNS servers for internal and > external zones? That depends a bit on your setup. Judicious use of views with ACLs could help you solve your problem regarding the zone transfers, but you may feel

split horizon and zone transfers to secondary DNS servers

:-) I have defined two views (let's call them an `internal' and an `external') for my zones on the primary DNS server. Let's assume I'd like the secondary DNS server to use the same two views synchronized to the primary DNS. May I transfer *views* rather than zone description files? May I transfer

Re: bind9.7.1 Skipping lots of Zone Transfers

Alan Clegg writes: > Are you able to "dig @139.78.100.1 78.139.IN-ADDR.ARPA axfr" when logged > into the slave? No and your diagnosis was spot on. > It seems that communications between the slave (which we don't know the > IP address of) and the server at 139.78.100.1 is broken. Oh, yes!

Re: bind9.7.1 Skipping lots of Zone Transfers

On 10/26/2010 8:45 AM, Martin McCormick wrote: > 26-Oct-2010 07:30:46.497 zone 78.139.IN-ADDR.ARPA/IN: refresh: > skipping zone transfer as master 139.78.100.1#53 (source 0.0.0.0#0) is > unreachable (cached) Are you able to "dig @139.78.100.1 78.139.IN-ADDR.ARPA axfr" when logged into the slave

bind9.7.1 Skipping lots of Zone Transfers

Ah, the wonderful world of high stakes no-return upgrades! I turned on a new installation of bind9.7.1 after running it in slave mode for a few days and: 26-Oct-2010 07:30:46.497 zone 78.139.IN-ADDR.ARPA/IN: refresh: skipping zone transfer as master 139.78.100.1#53 (source 0.0.0.0#0) is

Re: Zone transfers from slaves to slaves?

o notifying the slaves as well. > >=20 > > 172.16.0.100 is the master > > 172.16.0.101 is 1st slave > > 172.16.0.102 is 2nd slave > > Zone transfers can take place between slaves as well. If you want to > limit the number of NOTIFY messages, you may want to look int

Re: Zone transfers from slaves to slaves?

0.101 is 1st slave > 172.16.0.102 is 2nd slave Zone transfers can take place between slaves as well. If you want to limit the number of NOTIFY messages, you may want to look into: "also-notify { list; };" and "notify explicit;" What you are seeing is in the case where you have a

Zone transfers from slaves to slaves?

Hello, I think I have a configuration issue somewhere. It looks like from the logs that my master server is notifying the slaves correctly, but then the other slaves are also notifying the slaves as well. 172.16.0.100 is the master 172.16.0.101 is 1st slave 172.16.0.102 is 2nd slave Here is a l

Re: root and in-addr.arpa zone transfers

On Montag 14 September 2009 Stephane Bortzmeyer wrote: > > Faster queries after a named restart. Reverse lookups faster too, > > good for the spam filters. > > Did you measure it or is it, like most claims "X is faster", just a > guess? In normal Setup, we see lots of querie to the 3rd DNS entry i

Re: root and in-addr.arpa zone transfers

On Fri, Sep 11, 2009 at 07:28:56AM +0200, Michael Monnerie wrote a message of 51 lines which said: > Faster queries after a named restart. Reverse lookups faster too, > good for the spam filters. Did you measure it or is it, like most claims "X is faster", just a guess? __

Re: root and in-addr.arpa zone transfers

In message <20090912082415.ga13...@fantomas.sk>, Matus UHLAR - fantomas writes: > > On Freitag 11 September 2009 Matus UHLAR - fantomas wrote: > > > - it's quite useless to cache the .arpa and .in-addr.arpa since > > > unlike other TLD's they are hierarchically organised so there won't > > > be an

Re: root and in-addr.arpa zone transfers

> On Freitag 11 September 2009 Matus UHLAR - fantomas wrote: > > - it's quite useless to cache the .arpa and .in-addr.arpa since > > unlike other TLD's they are hierarchically organised so there won't > > be any valuable benefit from slaving them, only risks (see above). On 12.09.09 09:27, Michael

Re: root and in-addr.arpa zone transfers

On Freitag 11 September 2009 Matus UHLAR - fantomas wrote: > - it's quite useless to cache the .arpa and .in-addr.arpa since > unlike other TLD's they are hierarchically organised so there won't > be any valuable benefit from slaving them, only risks (see above). Every other point is OK, but I don

Re: root and in-addr.arpa zone transfers

On 11.09.09 09:13, Rich Goodson wrote: > Slaving root is certainly not something I would recommend to everyone. > In fact, I don't even use it on all of our name servers. I was just > answering the question regarding how one would go about doing something > rather than why or why not to do it.

Re: root and in-addr.arpa zone transfers

Slaving root is certainly not something I would recommend to everyone. In fact, I don't even use it on all of our name servers. I was just answering the question regarding how one would go about doing something rather than why or why not to do it. Here is why I do it and why I'm fairly comf

Restarting named [was: Re: root and in-addr.arpa zone transfers]

On Sep 11 2009, Sam Wilson wrote: In article , Michael Monnerie wrote: On Freitag 11 September 2009 Joseph S D Yao wrote: > However, as M. Bortzmeyer has said, why do this? Faster queries after a named restart. ... How often do you restart named? $ ps -o user,zone,pid,stime,time,comm -U

Re: root and in-addr.arpa zone transfers

In article , Michael Monnerie wrote: > On Freitag 11 September 2009 Joseph S D Yao wrote: > > However, as M. Bortzmeyer has said, why do this? > > Faster queries after a named restart. ... How often do you restart named? We hit our master once a day, in the early hours but that's just habit

Re: root and in-addr.arpa zone transfers

On Freitag 11 September 2009 Joseph S D Yao wrote: > However, as M. Bortzmeyer has said, why do this? Faster queries after a named restart. Reverse lookups faster too, good for the spam filters. mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660 / 415 65

Re: root and in-addr.arpa zone transfers

On Thu, Sep 10, 2009 at 11:27:27AM +0200, Michael Monnerie wrote: > On Mittwoch 09 September 2009 Rich Goodson wrote: > > zone "." { > > zone "arpa" { > > zone "in-addr.arpa" { > > Thank you Rich, and the others. Can anyone confirm that this is the way > to do? Or should I stay with ftp updates f

Re: root and in-addr.arpa zone transfers

On Thu, Sep 10, 2009 at 12:31:45PM +0200, Michael Monnerie wrote a message of 70 lines which said: > that's a clear statement, so I'll keep the ftp transfers. It would be better to drop them completely and to return to ordinary DNS resolution. What's the point of mirroring the root? What if y

Re: root and in-addr.arpa zone transfers

On Donnerstag 10 September 2009 Stephane Bortzmeyer wrote: > > right now I'm using scripts to download root.zone and in-addr.arpa > > from internic.net. But this is a non-standard way, > > But a secure way since the files on internic.net are PGP-signed. > > > I'd prefer to directly slave and zone-t

Re: root and in-addr.arpa zone transfers

On Mittwoch 09 September 2009 Rich Goodson wrote: > zone "." { > zone "arpa" { > zone "in-addr.arpa" { Thank you Rich, and the others. Can anyone confirm that this is the way to do? Or should I stay with ftp updates from the websites? Is there an "officially supported" or "recommended" way to do

Re: root and in-addr.arpa zone transfers

On Wed, Sep 09, 2009 at 11:00:37AM -0400, Rick Dicaire wrote a message of 23 lines which said: > Interestingcan any of the root servers be used, or must it be just > these three? No root server operator (except may be ISC for F) ever promised to keep zone transfer open. It is not regarded

Re: root and in-addr.arpa zone transfers

On Wed, Sep 09, 2009 at 08:23:23AM +0200, Michael Monnerie wrote a message of 54 lines which said: > right now I'm using scripts to download root.zone and in-addr.arpa > from internic.net. But this is a non-standard way, But a secure way since the files on internic.net are PGP-signed. > I'd

Re: root and in-addr.arpa zone transfers

Apparently FreeBSD only slaves F.ROOT-SERVERS.NET in it's default configuration for bind: http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/namedb/named.conf http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/namedb/named.conf?rev=1.21.2.9;content-type=text%2Fplain /* Slaving the following zones from

Re: root and in-addr.arpa zone transfers

On 09.09.09 11:00, Rick Dicaire wrote: > On Wed, Sep 9, 2009 at 10:51 AM, Rich Goodson > wrote: > > zone "." { > >        type slave; > >        file "slave/root.slave"; > >        masters { > >                192.33.4.12;    // C.ROOT-SERVERS.NET. > >                192.112.36.4;   // G.ROOT-SER

Re: root and in-addr.arpa zone transfers

On Wed, Sep 9, 2009 at 10:51 AM, Rich Goodson wrote: > zone "." { >        type slave; >        file "slave/root.slave"; >        masters { >                192.33.4.12;    // C.ROOT-SERVERS.NET. >                192.112.36.4;   // G.ROOT-SERVERS.NET. >                193.0.14.129;   // K.ROOT-SER

Re: root and in-addr.arpa zone transfers

Michael, Here's a snippet from my named.conf which does what you're talking about. I use this in our recursive resolvers, but for authoritative servers, I find the hints file to be somewhat more robust. FYI, I stole this originally from the default FreeBSD named.conf file that got pushed o

root and in-addr.arpa zone transfers

Hello, right now I'm using scripts to download root.zone and in-addr.arpa from internic.net. But this is a non-standard way, I'd prefer to directly slave and zone-transfer those 2 zones. Is it possible, and can you show the bind config for these? Thanks a lot, mfg zmi -- // Michael Monnerie,

Re: Unable to perform zone transfers

Elias wrote: Hi all, I'm having troubles getting a particular zone transferred over to our nameserver but can manually dig for it. After trying a couple of things out, I noticed that it didn't work because they had the parent iskl.edu.my and the subdmain lc.iskl.edu.my in the same zone. I wa

Unable to perform zone transfers

Hi all, I'm having troubles getting a particular zone transferred over to our nameserver but can manually dig for it. After trying a couple of things out, I noticed that it didn't work because they had the parent iskl.edu.my and the subdmain lc.iskl.edu.my in the same zone. I was only able to h

Re: zone transfers

Michael Di Martino wrote: > > I have a Master BIND9 server with 2 active (up) interfaces eth0 and eth1. > > I need my zone update notifications and zone transfer to use eth1 > instead of eth0 which is currently using. > > How can I change this behavior while still having the server listen on > e

Re: zone transfers

In article , Michael Di Martino wrote: > I have a Master BIND9 server with 2 active (up) interfaces eth0 and eth1. > I need my zone update notifications and zone transfer to use eth1 instead o= > f eth0 which is currently using. > How can I change this behavior while still having the server list

Re: zone transfers

> I have a Master BIND9 server with 2 active (up) interfaces eth0 and eth1. > I need my zone update notifications and zone transfer to use eth1 > instead of eth0 which is currently using. > How can I change this behavior while still having the server listen on > eth0? Have a look at the listen-o

  1   2   >