AXFR frequency limitations
J
DNS box at an ISP I consult with set up to receive AXFRs of a number of
DNSBLs (11 to be precise). For testing purposes I've got that NS acting
as a master for a server here at my house. Tonight it dawned on me when
I was trying to figure out where all my bandwidth was going that the
frequent AXFRs from these zones is consuming a lot of my DSL bandwidth.
For some reason it didn't dawn on me when I set it up. Is there a way
to configure my slave to only start an AXFR at a designated time or only
ask for an AXFR X times in a given time period? Static copies of the
zones won't work for what I'm trying to do. I'm working on both the
email and DNS systems in this arrangement. I don't however have to have
each and every update as the master (ISP's primary NS) gets them. I do
need to be getting some AXFRs though. I could work with 2-4 a day if
need be. Thoughts? If I had a newer kernel on the primary NS I'd use
some bandwidth throttling to control how much bandwidth is available for
sending the updates. That would help greatly.
Thanks
J
p...@icke-reklam.ipsec.nu
> Is there a way to configure how often an AXFR takes place? I've got a=20
> DNS box at an ISP I consult with set up to receive AXFRs of a number of=
=20
> DNSBLs (11 to be precise). For testing purposes I've got that NS actin=
g=20
> as a master for a server here at my house. Tonight it dawned on me whe=
n=20
> I was trying to figure out where all my bandwidth was going that the=20
> frequent AXFRs from these zones is consuming a lot of my DSL bandwidth.=
=20
> For some reason it didn't dawn on me when I set it up. Is there a wa=
y=20
> to configure my slave to only start an AXFR at a designated time or onl=
y=20
> ask for an AXFR X times in a given time period? Static copies of the=20
> zones won't work for what I'm trying to do. I'm working on both the=20
> email and DNS systems in this arrangement. I don't however have to hav=
e=20
> each and every update as the master (ISP's primary NS) gets them. I do=
=20
> need to be getting some AXFRs though. I could work with 2-4 a day if=20
> need be. Thoughts? If I had a newer kernel on the primary NS I'd use=20
> some bandwidth throttling to control how much bandwidth is available fo=
r=20
> sending the updates. That would help greatly.
> Thanks
> J
DNS is _supposed_ to propagate each and every change of the masters zonef=
iles.
A solution that might suit you however is IXFR, where only the changes ar=
e
propagated. Currently it restricts what versions of nameservers to use an=
d
also usually requires you to use "dynamic update" to the master ( which m=
ight
be just what you need in this case )
--=20
Peter H=E5kanson =20
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out=
,
remove "icke-reklam" if you feel for mailing me. Thanx.
Barry Margolin
The Refresh field in the SOA record specifies how often the slave server
should check the master to see if the zone has changed. However, the
master server will also send NOTIFY messages to the slaves whenever a new
version of the zone is loaded in, so that they'll do a zone transfer
immediately instead of waiting for the Refresh period. You can disable
this with the "notify no" option (either as a global option of per-zone).
However, if you don't administer the zones in question, you won't be able
to change the SOA records.
Perhaps, instead of configuring your server as a slave, configure it as a
master. Have a cron job that runs every few hours to do "dig <zone> axfr"
for each domain, with output redirected into the zone files.
--
Barry Margolin, barry.m...@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Ketil Froyn
> Is there a way to configure my slave to only start an AXFR at a
> designated time or only ask for an AXFR X times in a given time period?
RTFA (Read The Fine ARM):
min-refresh-time, max-refresh-time, min-retry-time, max-retry-time
These options control the server's behavior on refreshing a zone
(querying for SOA changes) or retrying failed transfers. Usually the SOA
values for the zone are used, but these values are set by the master,
giving slave server administrators little control over their contents.
These options allow the administrator to set a minimum and maximum
refresh and retry time either per-zone, per-view or globally. These
options are valid for slave and stub zones, and clamp the SOA refresh
and retry times to the specified values.
Ketil Froyn
ke...@froyn.name
http://ketil.froyn.name/