Modified a zone, so when it becomes available?
Marcos Lorenzo de Santiago
When I modify a RR or add a new one on an existing zone, I have to
restart master server to make the change available. Is there any other
way to reload the zone without stopping bind?
I've tried with:
- rdnc reload [zone]
- rndc reconfig [zone]
- rndc refresh [zone]
But none of this makes bind re-read the zone file.
Am I missing anything?
Thank you in advance.
--
,-----------------------------------------------------------------------.
| +#if defined(__alpha__) && defined(CONFIG_PCI) |
| + /* |
| + * The meaning of life, the universe, and everything. |
| + * Plus this makes the year come out right. |
| + */ |
| + year -= 42; |
| +#endif |
| (From the patch for 1.3.2: (kernel/time.c), submitted by Marcus |
| Meissner) |
|-----------------------------------------------------------------------|
| Técnico de Sistemas | |
| Departamento de Informática | Debian GNU/Linux Powerer |
| Ayuntamiento de Getafe | .--. |
|--------------------------------------------| |o_o | |
| _________ | .''`. |:_/ | |
| |~~ @| Marcos Lorenzo de Santiago | : :' : // \ \ |
| | ==== | marcos....@ayto-getafe.org | `. `' (| | ) |
| |_________| Teléfono: (+34) 91-202-79-48 | `- /'\_ _/`\ |
| Móvil: (+34) 608-300-935 | \___)=(___/ |
| | |
`-----------------------------------------------------------------------'
Leonardo Rodrigues
> When I modify a RR or add a new one on an existing zone, I have to
> restart master server to make the change available. Is there any other
> way to reload the zone without stopping bind?
>
> I've tried with:
> - rdnc reload [zone]
> - rndc reconfig [zone]
> - rndc refresh [zone]
>
>
'rndc reload' is enough to make the zones being re-read and
new/updated records available.
Problably you're missing:
1) to increment the zone serial ... if you dont do that, bind wont know
you updated the zone. That's important, ALWAYS update the serial when
changing/adding records;
2) your DNS server itself is using another DNS server which is caching
the records, so cache needs to expire so new/updated records can be
seen. You can have your DNS server using itself (127.0.0.1) as DNS
server, that should solve if this is the problem;
--
Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br
Minha armadilha de SPAM, NÃO mandem email
gert...@solutti.com.br
My SPAMTRAP, do not email it
Udo Zumdick
rndc reload should do the job, but only if the serial in that zone has been
increased.
One other way I know is to use Dynamic DNS, but it is more complicated and
(in my opinion) also sort of unsecure.
Regards,
Udo
----
_|_|_|_|_|_| Udo Zumdick
_ _ _ _| _ Deutsche Telekom Netzproduktion GmbH
|_| |_| |_| _| |_| Hammer Str. 216 - 226; 48153 Muenster
_| mailto:u...@nic.dtag.de
_| phone: +49 251 7985311; fax: +49 251 7985109
--
Am Tue, 15 Sep 2009 11:52:24 +0200
schrieb Marcos Lorenzo de Santiago <marcos....@ayto-getafe.org>:
> This is another quite short and simple question:
>
> When I modify a RR or add a new one on an existing zone, I have to
> restart master server to make the change available. Is there any other
> way to reload the zone without stopping bind?
>
> I've tried with:
> - rdnc reload [zone]
> - rndc reconfig [zone]
> - rndc refresh [zone]
>
Marcos Lorenzo de Santiago
> Marcos Lorenzo de Santiago escreveu:
> > restart master server to make the change available. Is there any other
> > way to reload the zone without stopping bind?
> >
> > I've tried with:
> > - rdnc reload [zone]
> > - rndc reconfig [zone]
> > - rndc refresh [zone]
> >
> >
>
>
> 'rndc reload' is enough to make the zones being re-read and
> new/updated records available.
>
> Problably you're missing:
>
> 1) to increment the zone serial ... if you dont do that, bind wont know
> you updated the zone. That's important, ALWAYS update the serial when
> changing/adding records;
I always update the serial, I know little but I know this ;)
>
> 2) your DNS server itself is using another DNS server which is caching
> the records, so cache needs to expire so new/updated records can be
> seen. You can have your DNS server using itself (127.0.0.1) as DNS
> server, that should solve if this is the problem;
This master server is its own server, so that's not the case...
After making changes to zone, updated serial, and rndc reload, I dig my
zone and get always the old serial. The serial and the changes only
appear when I '/etc/init.d/bind restart' it.
I use bind 9.5.1 on debian 5.0.3.
Any clue?
Thanks in advance.
--
,-----------------------------------------------------------------------.
| Air is water with holes in it |
Cathy Almond
> El mar, 15-09-2009 a las 07:04 -0300, Leonardo Rodrigues escribi�:
changes?
Regards,
Cathy
Mark Andrews
> >> Marcos Lorenzo de Santiago escreveu:
> >>> When I modify a RR or add a new one on an existing zone, I have to
> >>> restart master server to make the change available. Is there any other
> >>> way to reload the zone without stopping bind?
> >>>
> >>> I've tried with:
> >>> - rdnc reload [zone]
> >>> - rndc reconfig [zone]
> >>> - rndc refresh [zone]
> >>>
> >>> Am I missing anything?
>
> >>
> >> 'rndc reload' is enough to make the zones being re-read and =
>
> >> new/updated records available.
> >>
> >> Problably you're missing:
> >>
>
> >> you updated the zone. That's important, ALWAYS update the serial when =
>
> >> changing/adding records;
> > =
>
> > I always update the serial, I know little but I know this ;)
>
> >> 2) your DNS server itself is using another DNS server which is caching =
>
> >> the records, so cache needs to expire so new/updated records can be =
>
> >> seen. You can have your DNS server using itself (127.0.0.1) as DNS =
>
> >> server, that should solve if this is the problem;
>
> > This master server is its own server, so that's not the case...
>
> > After making changes to zone, updated serial, and rndc reload, I dig my
> > zone and get always the old serial. The serial and the changes only
> > appear when I '/etc/init.d/bind restart' it.
>
> > I use bind 9.5.1 on debian 5.0.3.
>
> > Any clue?
> > =
>
> > Thanks in advance.
> > =
>
> Are your zone file modification timestamps being updated when you make
> changes?
>
> Regards,
>
> Cathy
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
It sounds like the zone is configured for dynamic update. Reload has
no effect if the zone is configured for dynamic update.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Udo Zumdick
schrieb Marcos Lorenzo de Santiago <marcos....@ayto-getafe.org>:
[....]
> After making changes to zone, updated serial, and rndc reload, I dig my
> zone and get always the old serial. The serial and the changes only
> appear when I '/etc/init.d/bind restart' it.
>
> I use bind 9.5.1 on debian 5.0.3.
>
> Any clue?
Maybe there are some .jnl files (IXFR journalfiles) which could prevent
bind from updating the zone ?
Removing them and disabling incremental zone transfer might help. I had
such problems in the past.
Marcos Lorenzo de Santiago
> Marcos Lorenzo de Santiago wrote:
> >> Marcos Lorenzo de Santiago escreveu:
> >>> When I modify a RR or add a new one on an existing zone, I have to
> >>> restart master server to make the change available. Is there any other
> >>> way to reload the zone without stopping bind?
> >>>
> >>> I've tried with:
> >>> - rdnc reload [zone]
> >>> - rndc reconfig [zone]
> >>> - rndc refresh [zone]
> >>>
> >>> Am I missing anything?
> >>>
> >>
> >>
> >> Problably you're missing:
> >>
> >> 1) to increment the zone serial ... if you dont do that, bind wont know
> >
> > I always update the serial, I know little but I know this ;)
> >
> >
> >
> > zone and get always the old serial. The serial and the changes only
> > appear when I '/etc/init.d/bind restart' it.
> >
> > I use bind 9.5.1 on debian 5.0.3.
> >
> > Any clue?
> >
> >
> Are your zone file modification timestamps being updated when you make
> changes?
Yes, it updates as I write on the zone file. What shocks me too is that
every while the zone file timestamp updates automatically I think due to
bind's strange beahaviour, my configuration is as follows, nothing
fancy:
options {
listen-on { any; };
directory "/var/cache/bind";
query-source address 10.5.20.11 port 53;
version "hidden";
allow-notify { none; };
allow-transfer { slaves-dmz; };
transfer-source 10.5.20.11;
allow-query { slaves-dmz; localhost; };
forwarders { 10.5.20.12; 10.5.20.13; };
forward only;
transfers-in 100;
recursion yes;
};
include "/etc/bind/dmz/zones";
Where "zones" is a file containing another 'include' statements with the
zone configuration of each domain like:
include "/etc/bind/zone1.conf";
include "/etc/bind/zone2.conf";
...
include "/etc/bind/zoneN.conf";
My server is chrooted and, otherwise everything else works fine.
--
,-----------------------------------------------------------------------.
| ..you could spend *all day* customizing the title bar. Believe me. |
| I speak from experience." |
| (By Matt Welsh) |
Kevin Darcy
> One other way I know is to use Dynamic DNS, but it is more complicated and
> (in my opinion) also sort of unsecure.
>
>
You don't let random people modify your files without proper
protections/permissions/processes in place, do you? And if it's a file
you really care about (e.g. has legal significance, governmental
significance, or something that directly affects your competitiveness in
the marketplace), you'd better have a robust auditing/logging regime so
you can see who changed it how and when. Preferably even some sort of
"versioning" so you can roll back the file to an earlier version if
necessary.
Same thing with Dynamic Update in DNS. If you're naive enough to simply
slap an "allow-update" on your zone(s), specifying IP addresses from
ranges you don't trust to the n'th degree, then shame on you. That would
be like having a world-writable file on your public-facing server
containing sensitive business-critical data.
Here, we only allow Dynamic Updates from the local box (in a few cases)
or (much more commonly) with a TSIG key. And we don't make that TSIG key
available to anyone outside of our own little trusted group (3 people)
directly. Everyone else goes through a fairly elaborate web interface
with an associated robust Access Control Subsystem, which ultimately
fetches the appropriate TSIG key behind the scenes when it's time to
make the actual Dynamic Update to DNS (after a bunch of permissions and
sanity/consistency checks have been performed).
- Kevin
Abello, Vinny
Besides incrementing the serial, be sure there are no syntactical errors in the zone file. Easiest way is to check your logs or use named-checkzone to validate the file. Your logs should show something regardless. "rndc reload <zone>" should return either "zone reload queued" or "zone reload up-to-date". What is it returning? If it always returns "zone reload queued" every time, then you likely have a syntax error in the zone which named-checkzone or your logs should be able to point out. Remember you must have a carriage return or newline at the end of the zone file as well.
-Vinny
-----Original Message-----
From: bind-user...@lists.isc.org [mailto:bind-user...@lists.isc.org] On Behalf Of Marcos Lorenzo de Santiago
Sent: Tuesday, September 15, 2009 5:52 AM
To: bind-...@lists.isc.org
Subject: Modified a zone, so when it becomes available?
This is another quite short and simple question:
restart master server to make the change available. Is there any other
way to reload the zone without stopping bind?
I've tried with:
- rdnc reload [zone]
- rndc reconfig [zone]
- rndc refresh [zone]
Am I missing anything?
Thank you in advance.
,-----------------------------------------------------------------------.
| +#if defined(__alpha__) && defined(CONFIG_PCI) |
| + /* |
| + * The meaning of life, the universe, and everything. |
| + * Plus this makes the year come out right. |
| + */ |
| + year -= 42; |
| +#endif |
| (From the patch for 1.3.2: (kernel/time.c), submitted by Marcus |
| Meissner) |
| Técnico de Sistemas | |
| Departamento de Informática | Debian GNU/Linux Powerer |
| Ayuntamiento de Getafe | .--. |
|--------------------------------------------| |o_o | |
| _________ | .''`. |:_/ | |
| |~~ @| Marcos Lorenzo de Santiago | : :' : // \ \ |
| | ==== | marcos....@ayto-getafe.org | `. `' (| | ) |
| |_________| Teléfono: (+34) 91-202-79-48 | `- /'\_ _/`\ |
| Móvil: (+34) 608-300-935 | \___)=(___/ |
| | |
`-----------------------------------------------------------------------'
Robert Spangler
> Please forgive my naivety if this is totally wrong but
> I don't have a chrooted bind environment to verify this atm.
I run a chroot environment
> But doesn't the init script in some distributions copy the
> configuration files (including zone files) into the chroot
> joil because bind cannot access them in /etc from there?
Not that I am aware of. If you know of a distro that does this let us know.
A chroot'ed bind has no knowledge of anything outside of it's chroot
environment so the files have to exist there.
> That could explain why it works when you use the init script
> to restart bind but it doesn't when you do rndc reload -
> the modified files don't get copied into the jail with
> rndc reload.
And they do not with the init script either. The init script is shutting down
bind and then reloading it again which forces a fresh read of all the files,
as rndc is just telling bind to re-read the zone.
--
Regards
Robert
Linux User #296285
http://counter.li.org
Marcos Lorenzo de Santiago
> On Tuesday 15 September 2009 08:16, Frank Stanek wrote:
>
> > Please forgive my naivety if this is totally wrong but
> > I don't have a chrooted bind environment to verify this atm.
>
> I run a chroot environment
>
> > But doesn't the init script in some distributions copy the
> > configuration files (including zone files) into the chroot
> > joil because bind cannot access them in /etc from there?
>
> Not that I am aware of. If you know of a distro that does this let us know.
> A chroot'ed bind has no knowledge of anything outside of it's chroot
> environment so the files have to exist there.
I just link the chrooted file named.conf to /etc/bind/named.conf, so the
file in /etc is actually a link to the file within then chrooted
environment.
>
> > That could explain why it works when you use the init script
> > to restart bind but it doesn't when you do rndc reload -
> > the modified files don't get copied into the jail with
> > rndc reload.
>
> And they do not with the init script either. The init script is shutting down
> bind and then reloading it again which forces a fresh read of all the files,
> as rndc is just telling bind to re-read the zone.
>
--
,-----------------------------------------------------------------------.
| Linux is obsolete |
| (Andrew Tanenbaum) |
Marcos Lorenzo de Santiago
> Am Tue, 15 Sep 2009 12:28:24 +0200
> schrieb Marcos Lorenzo de Santiago <marcos....@ayto-getafe.org>:
>
> [....]
> > zone and get always the old serial. The serial and the changes only
> > appear when I '/etc/init.d/bind restart' it.
> >
> > I use bind 9.5.1 on debian 5.0.3.
> >
> > Any clue?
>
> bind from updating the zone ?
> Removing them and disabling incremental zone transfer might help. I had
> such problems in the past.
There are no .jnl files, so I guess is turned off, but anyway, how can I
know If this is enabled? I don't have any allow-update option...
Thanks in advance.
>
> Udo
>
> ----
>
> _|_|_|_|_|_| Udo Zumdick
> _ _ _ _| _ Deutsche Telekom Netzproduktion GmbH
> |_| |_| |_| _| |_| Hammer Str. 216 - 226; 48153 Muenster
> _| mailto:u...@nic.dtag.de
> _| phone: +49 251 7985311; fax: +49 251 7985109
>
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
,-----------------------------------------------------------------------.
| "Open Standards, Open Documents, and Open Source" |
| -- Scott Bradner (Open Sources, 1999 O'Reilly and Associates) |
Sam Wilson
Marcos Lorenzo de Santiago <marcos....@ayto-getafe.org> wrote:
> El mar, 15-09-2009 a las 13:45 +0200, Udo Zumdick escribió:
> > Am Tue, 15 Sep 2009 12:28:24 +0200
> > schrieb Marcos Lorenzo de Santiago <marcos....@ayto-getafe.org>:
> >
> > [....]
> > > After making changes to zone, updated serial, and rndc reload, I dig my
> > > zone and get always the old serial. The serial and the changes only
> > > appear when I '/etc/init.d/bind restart' it.
> > >
> > > I use bind 9.5.1 on debian 5.0.3.
> > >
> > > Any clue?
> >
> > Maybe there are some .jnl files (IXFR journalfiles) which could prevent
> > bind from updating the zone ?
> > Removing them and disabling incremental zone transfer might help. I had
> > such problems in the past.
>
> There are no .jnl files, so I guess is turned off, but anyway, how can I
> know If this is enabled? I don't have any allow-update option...
>
> Thanks in advance.
Have you checked your log file yet? I don't know where the debian setup
puts the messages by default, but you should be able to see messages
saying what named is doing when you tell it to reload the zone.
Sam
Robert Spangler
> El mar, 15-09-2009 a las 17:27 -0400, Robert Spangler escribió:
> > On Tuesday 15 September 2009 08:16, Frank Stanek wrote:
> > > Please forgive my naivety if this is totally wrong but
> > > I don't have a chrooted bind environment to verify this atm.
> >
> > I run a chroot environment
> >
> > > But doesn't the init script in some distributions copy the
> > > configuration files (including zone files) into the chroot
> > > joil because bind cannot access them in /etc from there?
> >
> > Not that I am aware of. If you know of a distro that does this let us
> > know. A chroot'ed bind has no knowledge of anything outside of it's
> > chroot environment so the files have to exist there.
>
> I just link the chrooted file named.conf to /etc/bind/named.conf, so the
> file in /etc is actually a link to the file within then chrooted
> environment.
In my environment I have the other way. named.conf, named.zones and rndc.key
in /etc are linked to the chroot enviroment.
Barry Margolin
Robert Spangler <mli...@zoominternet.net> wrote:
If you're talking about hard links, there is no directionality. All
hard links are equivalent pointers to the same inode.
Symbolic links, on the other hand, are pointers from one filename to
another. A symbolic link in a chroot environment can't point outside of
it, because the target is interpreted relative to the chroot.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Marcos Lorenzo de Santiago
> In article <mailman.515.1253137...@lists.isc.org>,
> Robert Spangler <mli...@zoominternet.net> wrote:
>
> >
> > > > On Tuesday 15 September 2009 08:16, Frank Stanek wrote:
> > > > > Please forgive my naivety if this is totally wrong but
> > > > > I don't have a chrooted bind environment to verify this atm.
> > > >
> > > > I run a chroot environment
> > > >
> > > > > But doesn't the init script in some distributions copy the
> > > > > configuration files (including zone files) into the chroot
> > > > > joil because bind cannot access them in /etc from there?
> > > >
> > > > Not that I am aware of. If you know of a distro that does this let us
> > > > know. A chroot'ed bind has no knowledge of anything outside of it's
> > > > chroot environment so the files have to exist there.
> > >
> > > I just link the chrooted file named.conf to /etc/bind/named.conf, so the
> > > file in /etc is actually a link to the file within then chrooted
> > > environment.
> >
> > In my environment I have the other way. named.conf, named.zones and rndc.key
> > in /etc are linked to the chroot enviroment.
>
> hard links are equivalent pointers to the same inode.
That can only be done on files.
>
> Symbolic links, on the other hand, are pointers from one filename to
> another. A symbolic link in a chroot environment can't point outside of
> it, because the target is interpreted relative to the chroot.
That's why I said I make the link in /etc, not in the jail as it would
point to a dir that doesn't exist in the jail.
>
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
,-----------------------------------------------------------------------.
| "...very few phenomena can pull someone out of Deep Hack Mode, with |
| two noted exceptions: being struck by lightning, or worse, your |
| *computer* being struck by lightning." |
| (By Matt Welsh) |