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

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,

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" {     

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

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

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's

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

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

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

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

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

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

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

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

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

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

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

Re: DNS views and zone transfers, cont

ones and forwarding to another view automatically >>> 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; >>> >>&g

Re: DNS views and zone transfers, cont

;> >> >> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold <rharo...@umich.edu> wrote: >> >>> >>> On Thu, Sep 8, 2016 at 9:13 AM, project722 <project...@gmail.com> wrote: >>> >>>> Bob, in our prod environment, we are allowing 127.0.0.1 to

Re: DNS views and zone transfers, cont

ixing it by adding to that view the line: >empty-zones-enable no; > > -- > Bob Harold > > > On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold <rharo...@umich.edu> wrote: > >> >> On Thu, Sep 8, 2016 at 9:13 AM, project722 <project...@gmail.com> wrote: &

Re: DNS views and zone transfers, cont

Sep 8, 2016 at 9:13 AM, project722 <project...@gmail.com> 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

Re: DNS views and zone transfers

ude the external key indie the external 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

Re: DNS views and zone transfers

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

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

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

Re: DNS views and zone transfers

nal { >>> >>> match clients - external { >>> >>> zone example.org { >>> }; >>> >>> zone example.com { >>> }; >>> >>> }; >>> >>> >>> >>> On Tue, Aug 30, 2016 at 2

Re: DNS views and zone transfers

gt;> >> match clients - external { >> >> zone example.org { >> }; >> >> zone example.com { >> }; >> >> }; >> >> >> >> On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold <rharo...@umich.edu> wrote: >> >>&

Re: DNS views and zone transfers

at 12:56 PM, project722 <project...@gmail.com> >> 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 in

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

Re: DNS views and zone transfers

aro...@umich.edu> wrote: > > On Thu, Aug 25, 2016 at 12:56 PM, project722 <project...@gmail.com> 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 &

Re: DNS views and zone transfers

On Thu, Aug 25, 2016 at 12:56 PM, project722 <project...@gmail.com> 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 product

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

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 e...@isc.org 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 issue. Performing a named

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

message. Mark On Nov 20, 2013, at 22:09, Evan Hunt e...@isc.org 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 issue. Performing a named-checkzone against the zone file with bind 9.9.4

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

, at 22:09, Evan Hunt e...@isc.org 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 issue. Performing a named-checkzone against the zone file with bind 9.9.4 and bind 9.9.2 returns no errors. It looks

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

, at 22:09, Evan Hunt e...@isc.org 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 issue. Performing a named-checkzone against the zone file with bind 9.9.4 and bind 9.9.2 returns no errors

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

. Mark On Nov 20, 2013, at 22:09, Evan Hunt e...@isc.org 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 issue. Performing a named-checkzone against the zone file with bind 9.9.4 and bind 9.9.2

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

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 versions of dig. I've tested

Re: Delayed Zone Transfers?

From: J b...@namor.ca To: bind-users@lists.isc.org 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 serial number changes

Re: Delayed Zone Transfers?

From: Jiann-Ming Su su_...@yahoo.com To: bind-users@lists.isc.org 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 changes

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

Re: Delayed Zone Transfers?

From: Phil Mayers p.may...@imperial.ac.uk 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 out the new data

Re: Delayed Zone Transfers?

From: Jiann-Ming Su su_...@yahoo.com To: bind-users@lists.isc.org bind-users@lists.isc.org Cc: Sent: Monday, August 6, 2012 12:33 PM Subject: Re: Delayed Zone Transfers? From: Phil Mayers p.may...@imperial.ac.uk To: bind-users@lists.isc.org Cc: Sent: Monday, August 6, 2012 12:07

RE: Delayed Zone Transfers

...@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 Zone Transfers? (Phil Mayers) 4. Re

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

Re: Delayed Zone Transfers?

From: Phil Mayers p.may...@imperial.ac.uk 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 a MTA config issue

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: 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 the zone has been

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 transferred

Split DNS and zone transfers

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 straightforward example

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

RE: Split DNS and zone transfers

[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-facing DNS

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 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

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.finch d...@dotat.at http://dotat.at/ Tyne, Dogger, Fisher, German Bight, Humber, Thames

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 with separate servers. I understand

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

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: split horizon and zone transfers to secondary DNS servers

; 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 more comfortable with separate servers

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: 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?

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! it

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

Re: Zone transfers from slaves to slaves?

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 master server that is not visible to all slaves

Re: Zone transfers from slaves to slaves?

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 into: also-notify { list; }; and notify explicit; What you are seeing

Re: root and in-addr.arpa zone transfers

On Fri, Sep 11, 2009 at 07:28:56AM +0200, Michael Monnerie michael.monne...@is.it-management.at 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,

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't

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

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 any valuable

Re: root and in-addr.arpa zone transfers

In article mailman.469.1252646962.14796.bind-us...@lists.isc.org, Michael Monnerie michael.monne...@is.it-management.at 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

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

On Sep 11 2009, Sam Wilson wrote: In article mailman.469.1252646962.14796.bind-us...@lists.isc.org, Michael Monnerie michael.monne...@is.it-management.at 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

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

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 SNIP /* Slaving the following zones

Re: root and in-addr.arpa zone transfers

On Wed, Sep 09, 2009 at 08:23:23AM +0200, Michael Monnerie michael.monne...@is.it-management.at 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

Re: root and in-addr.arpa zone transfers

On Thu, Sep 10, 2009 at 12:31:45PM +0200, Michael Monnerie michael.monne...@is.it-management.at 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

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 from the

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 Wed, Sep 9, 2009 at 10:51 AM, Rich Goodson rgood...@gronkulator.com 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;  

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 rgood...@gronkulator.com wrote: zone . {        type slave;        file slave/root.slave;        masters {                192.33.4.12;    // C.ROOT-SERVERS.NET.                192.112.36.4;   //

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

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

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? Michael DiMartino | Director of IT

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-on,

Re: zone transfers

In article h061r8$q8...@sf1.isc.org, Michael Di Martino m...@openaccessinc.com 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

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 eth0?

Re: stop zone transfers from coming in

In article gt8lk3$1pe...@sf1.isc.org, Chris Henderson henders...@gmail.com wrote: My server works as a secondary for a zone. I asked the master server's admin to stop the zone transfer; I didn't get any reply and thus commented out the zone's section in my named.conf. But I'm still getting

Zone transfers with views

I am trying to create three DNS slave servers with views for internal an external IP's. Each has an address in the DMZ and the firewall (actually a CSS) routes requests from the external IP's to the internal addresses. The correspondence is one-to-one: external.1 -- dmz.1 external.2 -- dmz.2

Re: Zone transfers with views

Stephen Carville wrote: I am trying to create three DNS slave servers with views for internal an external IP's. Each has an address in the DMZ and the firewall (actually a CSS) routes requests from the external IP's to the internal addresses. The correspondence is one-to-one: external.1 --

Re: Zone transfers with views

On Thu, Apr 30, 2009 at 10:20 AM, Kevin Darcy k...@chrysler.com wrote: Use TSIG keys to differentiate the views. I'll give that a try. Thank you. -- Stephen Carville ___ bind-users mailing list bind-users@lists.isc.org

stop zone transfers from coming in

My server works as a secondary for a zone. I asked the master server's admin to stop the zone transfer; I didn't get any reply and thus commented out the zone's section in my named.conf. But I'm still getting zone files coming in to my server. Here is what I have commented out: # zone

Re: stop zone transfers from coming in

I would honestly look for a typo since you're saying that it does work for some. Either way unless the admin turn it off you will get zone-transfers, the question lies in wether your name-server accepts them and propagates them down. Check in the log for transfer or notification refusals and make

Zone transfers of dlv.isc.org

discovered that ns-ext.isc.org didn't allow zone transfers for dlv.isc.org, I obviously failed to note that the other official nameservers for it do allow them ... Things have changed more than once since then. When the official slaves changed to the current set, {ams,sfba,ord}.sns-pb.isc.org