[SLUG] DHCP -> DDNS not updating
Kyle
I have an issue that is becoming more annoying the more I try to track
it down.
Can I ask those of you interested to take a look at the following thread
please:
https://www.centos.org/modules/newbb/viewtopic.php?topic_id=30080&forum=40
I realise this might be a little .... brave ... to ask you to go outside
the list, but it is a fairly detailed thread (i.e. lengthy read) with
all the necessary info on the box's config and all the testing I have done.
In short;
-----------
mixed clients XP, 7, OSX, Ubuntu 10 to a CentOS 5.5 svr all in an MS
WORKGROUP type setup.
DHCP licences handed out, some reserved.
DNS zones supposedly set up to provide name-based network browsing
within the WORKGROUP domain and for internal clients to find inbound
mail servers for 5 other domains.
-----------
But try as I might, I can't seem to get the DNS updated anymore and I
swear it USED TO WORK. The only thing I have since done is update the
packages as they came out.
I am as far as the error: "Unable to add forward map from
client1.domain1.com to 192.168.1.104: not authorized" and that's where
it stops. No amount of googlage has so far shone a torch on the issue.
The disheartening thing is the bloody redmond boxes CAN find other hosts
by name, but not the linux or OSX boxes.
If you have the time and incl. to have a read and point out where the
hell I'm going wrong pls, I'd be grateful.
--
------------------------------------------------------------------------
Kind Regards
Kyle
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Ben Donohue
I'd check that you are port forwarding or "virtual server" from the
modem port 53 tcp and udp to the internal dns server
reboot everything starting from the modem and working your way inwards
try to simplify the problem. Run up a new box if you can and stick it
temporarily on the inside of the modem and see if it is getting dns
correctly... go to websites etc.... if working then place it on the
other side of the svr1 and test from there...
Thanks,
Ben Donohue
Kyle
thanks for taking the time to look. Perhaps I wasn't clear. My issues
are not external clients not updating; rather internal only. I.e.
Everything behind my firewalls.
------------------------------------------------------------------------
Kind Regards
Kyle
Peter Chubb
I suggest looking in /var/log/messages (I believe the default
confiuration for CENTOS logs everything into there )
You should see lines like:
Feb 15 06:25:34 vampire dhcpd: DHCPREQUEST for A.B.C.D from
some:mac:address:here via eth0
then you might see something like
Feb 15 06:25:35 vampire named[3921]: client 127.0.0.1#53: update
'keg.ertos.in.nicta.com.au/IN' denied
or,
Feb 14 17:35:04 vampire named[4854]: client 127.0.0.1#42217: updating zone 'keg.ertos.in.nicta.com.au/IN': update unsuccessful: bigmac.keg.ertos.in.nicta.com.au: 'name not in use' prerequisite not satisfied (YXDOMAIN)
You may also want to check that can update named manually, using
nsupdate.
As root, on the machine running dhcpd, do
nsupdate -k keyfile
server whateveryournameserveris
domain domain.com
update add fred.domain.com 864000 A 192.168.1.100
show
send
or similar. Then try host fred.domain.com to see if you can see the
record you just added.
Peter C
--
Dr Peter Chubb peter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au ERTOS within National ICT Australia
All things shall perish from under the sky/Music alone shall live, never to die
Kyle
Ok, maybe I'm misunderstanding you.
Why would I need to be port forwarding?
All my relevant hosts and my DNS server all sit on the 192.168 subnet
all behind the same firewall with no reason to go near the modem? The
DNS server does act as a firewall, but yes, the relevant ports on the
eth1 side for DNS are open (namely 53 & for whatever reason - can't
remember now - 953).
For clarification the setup is
modem (FW)
|
Server (FW, DNS, DHCP, etc) eth0 = 10.X subnet eth1 = 192.168
subnet DHCP listens on 192.168.x.x
|
internal DHCP hosts on 192.168 subnet
------------------------------------------------------------------------
Kind Regards
Kyle
On 15/02/11 1:47 PM, Ben Donohue wrote:
> yes that's what I'm talking about.
>
> are you port forwarding DNS to your internal dns server?
>
> setup a test box on the inside of the modem and see if it works with
> just the modem in place.
>
> Thanks,
> Ben Donohue
Kyle
-------------------------------------------------
[root@server1 ~]# nsupdate -k /etc/rndc.key
could not read key from /etc/rndc.key: unexpected token
> [root@server1 ~]# man nsupdate
[root@server1 ~]# nsupdate -y domain1_key:<theSecretPhraseFrom_rndc.key>
> server 127.0.0.1
> domain domain1.com
incorrect section name: domain
> update add client1.domain1.com 864000 A 192.168.1.104
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
client1.domain1.com. 864000 IN A 192.168.1.104
> send
could not find enclosing zone
[root@server1 ~]# host client1
Host client1 not found: 3(NXDOMAIN)
[root@server1 ~]# host client1.domain1.com
Host client1.domain1.com not found: 3(NXDOMAIN)
-------------------------------------------------------------------------------------------------------
So questions arising from that are;
nsupdate -k /etc/rndc.key - The man page says that that format
requires a filename in the format 'K{name}.+157.+{random}.private'.
That's a new one on me. Where, why & how is that needed?
Just that error alone leads me to think the "not authorized" part of the
'forward map' error I was getting has to do with not being able to find
the key. But then, after issuing the send command, I get the error;
"could not find enclosing zone". I can imagine if the key were not being
found, the zone would not be found but don't know how/where that might
becoming from?
I'm going to assume the;
> domain domain1.com
incorrect section name: domain
is just a spurious section because the "domain <domainName>" command
doesn't exist.
------------------------------------------------------------------------
Kind Regards
Kyle
John Clarke
> > domain domain1.com
> incorrect section name: domain
I suspect you mean "zone domain1.com". "domain" is not a valid command.
> nsupdate -k /etc/rndc.key - The man page says that that format
> requires a filename in the format 'K{name}.+157.+{random}.private'.
> That's a new one on me. Where, why & how is that needed?
That's been the case for as long as I've been using nsupdate, at least
five years. The filename format is what dnssec-keygen outputs when you
ask it to generate a key.
One other thing you need to make sure of is that the client and server
have their clocks synchronised (e.g. with ntp), otherwise the update
will fail.
There's an nsupdate HOWTO here:
http://caunter.ca/nsupdate.txt
and I have a page explaining how to get DHCP3 to do DDNS updates here:
http://kirriwa.net/john/doc/ddns.html
John
--
"Bloody kids. If it hasn't got a front panel and you don't have to toggle in
the bootstrap by hand you haven't experienced a real installation."
-- Peter da Silva
John Clarke
> All my relevant hosts and my DNS server all sit on the 192.168 subnet
> all behind the same firewall with no reason to go near the modem? The
> DNS server does act as a firewall, but yes, the relevant ports on the
> eth1 side for DNS are open (namely 53 & for whatever reason - can't
> remember now - 953).
You need port 53 TCP and UDP, and port 953 TCP. Port 953 is bind's
default control port, i.e. what rndc uses to talk to the server.
nsupdate uses TCP port 53 IIRC.
John
--
Active ECM, coming soon to a WLAN near you!
-- Chris Suslowicz
Kyle
Thanks for the explanation John.
I have never before had to use nsupdate. I just tried it because Peter
suggested it and I figured it's a way to test dns updates manually.
I have always used BIND with rndc.key and it used to work. What's then
the difference between nsupdate and rndc and using BIND?
------------------------------------------------------------------------
Kind Regards
Kyle
On 15/02/11 6:52 PM, John Clarke wrote:
> On Tue, Feb 15, 2011 at 05:35:10PM +1100, Kyle wrote:
>
>>> domain domain1.com
>> incorrect section name: domain
> I suspect you mean "zone domain1.com". "domain" is not a valid command.
>
>> nsupdate -k /etc/rndc.key - The man page says that that format
>> requires a filename in the format 'K{name}.+157.+{random}.private'.
>> That's a new one on me. Where, why& how is that needed?
> That's been the case for as long as I've been using nsupdate, at least
> five years. The filename format is what dnssec-keygen outputs when you
> ask it to generate a key.
>
> One other thing you need to make sure of is that the client and server
> have their clocks synchronised (e.g. with ntp), otherwise the update
> will fail.
>
> There's an nsupdate HOWTO here:
>
> http://caunter.ca/nsupdate.txt
>
> and I have a page explaining how to get DHCP3 to do DDNS updates here:
>
> http://kirriwa.net/john/doc/ddns.html
>
>
>
> John
>
--
pe...@chubb.wattle.id.au
Kyle> Ah, ok. Thanks for the explanation John.
Kyle> I have never before had to use nsupdate. I just tried it because
Kyle> Peter suggested it and I figured it's a way to test dns updates
Kyle> manually.
Yes --- it'll check that the key you have actually works, and that the
nameserver allows DDNS updates.
The problem you describe has three components ---- it'd be good to try
testing them one at a time.
1. Is named accepting DDNS updates from the machine running DHCPD,
using the same key as DHCPD?
2. Is DHCPD generating DDNS requests for the correct zone?
3. Are clients getting the right address/name combinations?
Peter C
Kyle> I have always used BIND with rndc.key and it used to
Kyle> work. What's then the difference between nsupdate and rndc and
Kyle> using BIND?
Kyle> ------------------------------------------------------------------------
Kyle> Kind Regards
Kyle> Kyle
Kyle> On 15/02/11 6:52 PM, John Clarke wrote:
>> On Tue, Feb 15, 2011 at 05:35:10PM +1100, Kyle wrote:
>>
>>>> domain domain1.com
>>> incorrect section name: domain
>> I suspect you mean "zone domain1.com". "domain" is not a valid
>> command.
>>
>>> nsupdate -k /etc/rndc.key - The man page says that that format
>>> requires a filename in the format
>>> 'K{name}.+157.+{random}.private'. That's a new one on me. Where,
>>> why& how is that needed?
>> That's been the case for as long as I've been using nsupdate, at
>> least five years. The filename format is what dnssec-keygen
>> outputs when you ask it to generate a key.
>>
>> One other thing you need to make sure of is that the client and
>> server have their clocks synchronised (e.g. with ntp), otherwise
>> the update will fail.
>>
>> There's an nsupdate HOWTO here:
>>
>> http://caunter.ca/nsupdate.txt
>>
>> and I have a page explaining how to get DHCP3 to do DDNS updates
>> here:
>>
>> http://kirriwa.net/john/doc/ddns.html
>>
>>
>>
>> John
>>
Kyle> -- SLUG - Sydney Linux User's Group Mailing List -
Kyle> http://slug.org.au/ Subscription info and FAQs:
Kyle> http://slug.org.au/faq/mailinglists.html
Kyle
accepting the key it's being offered.
The final transaction I receive from an nsupdate exchange offers;
---------------------------------------------------------------------------------------
;; TSIG PSEUDOSECTION:
domain1_key. 0 ANY TSIG hmac-md5.sig-alg.reg.int.
1297798631 300 16 P0HVLAVNuSartbLEAqQ3Lg== 22243 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: _*NOTAUTH*_, id: 22243
;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; TSIG PSEUDOSECTION:
domain1_key. 0 ANY TSIG hmac-md5.sig-alg.reg.int.
1297798631 300 16 8KsZzvC3KJQNnX4EErqdXQ== 22243 NOERROR 0
--------------------------------------------------------------------------------------
So pretty much the same error as syslog was offering up. But I don't
seem to be able to hit on the right google keyword combination to offer
up the solution.
Can anyone with some in-depth (basically more than me - which is not
going to be hard) knowledge offer me avenues to chase down?
I have checked, dbl-checked and triple-checked that the key is generated
correctly. I have the correct key notation in named.conf, dhcpd.conf,
rndc.conf and rndc.key.
But I'm obviously missing come pivotal step in either permissions or
configuration.
------------------------------------------------------------------------
Kind Regards
Kyle
--
John Clarke
Sorry for the late reply; I've been busy.
> I have always used BIND with rndc.key and it used to work. What's then
> the difference between nsupdate and rndc and using BIND?
They have two quite different functions. nsupdate is used to modify
zone data by sending dynamic DNS updates. rndc is used to control the
name server itself, for example, to stop or restart the server, to
reload config and/or zone files.
John
--
Yes, but then you'd have a computer running OS X. There may be an upside,
but I'm not sure what it is.
-- Matt Palmer
Kyle
I've tried lots since this thread started to the extent I installed a
whole fresh machine on 192 subnet only, skimmed dhcpd and named confs
down to a simple, by the book, 1 domain setup and I still get the same
problem even on the fresh host. And this is a CentOS 5.5 (final)
install. I.e. the latest they publish.
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: _*NOTAUTH*_, id: 39734
;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; TSIG PSEUDOSECTION:
domain1.com. 0 ANY TSIG hmac-md5.sig-alg.reg.int.
1297906252 300 16 <someSecretHashHere> 39734 NOERROR 0
If I'm "reserving" an IP for a specific host in dhcpd.conf, am I
supposed to then be already placing a PTR record in the reverse zone
file for the reservation?
If so, doesn't that simply defeat the whole purpose of dhcp?
------------------------------------------------------------------------
Kind Regards
Kyle
On 17/02/11 1:26 PM, John Clarke wrote:
> On Tue, Feb 15, 2011 at 07:56:55PM +1100, Kyle wrote:
>
> Sorry for the late reply; I've been busy.
>> I have always used BIND with rndc.key and it used to work. What's then
>> the difference between nsupdate and rndc and using BIND?
> They have two quite different functions. nsupdate is used to modify
> zone data by sending dynamic DNS updates. rndc is used to control the
> name server itself, for example, to stop or restart the server, to
> reload config and/or zone files.
>
>
John Clarke
> I've tried lots since this thread started to the extent I installed a
> whole fresh machine on 192 subnet only, skimmed dhcpd and named confs
> down to a simple, by the book, 1 domain setup and I still get the same
> problem even on the fresh host. And this is a CentOS 5.5 (final)
> install. I.e. the latest they publish.
Are you having problems updating the A record or the PTR record, or
both?
Can you manually update either or both with nsupdate run on the DNS
server.
Can you do the same with nsupdate on the DHCP server?
Are the clocks on the DHCP server and the DNS server synchronised? I
don't remember why this mattered (it's been years since I set this up
myself), but I do remember having updates fail when the clocks were not
synchronised.
Can you send me your DNS and DHCP config files?
> If I'm "reserving" an IP for a specific host in dhcpd.conf, am I
> supposed to then be already placing a PTR record in the reverse zone
> file for the reservation?
By reserving, do you mean that you've configured your DHCP server to
allocate fixed addresses based on the host's MAC address? I wouldn't
have thought it would matter, that the DHCP server would update both the
A and PTR records anyway, as long as you've configured it to update both
zones in dhcpd.conf.
> If so, doesn't that simply defeat the whole purpose of dhcp?
No. The purpose of DHCP is to allow hosts to get an IP address and
other information without having to manually configure each host. The
DDNS update is just a bonus :-)
John
--
>What's the use of having a cupboard full of dingy little machines,
>none of which can run continuously for more than five minutes without
>needing 15 minutes of cooldown?
Our NT admins have an answer to that. -- Joe Moore
Kyle
Answers inline.
------------------------------------------------------------------------
Kind Regards
Kyle
On 17/02/11 2:00 PM, John Clarke wrote:
> Are you having problems updating the A record or the PTR record, or
> both?
## Both. DHCP is simply not updating DNS journals when a lease is renewed.
> Can you manually update either or both with nsupdate run on the DNS
> server.
## No, nsupdate extract from last email was run on the dns server.
> Can you do the same with nsupdate on the DHCP server?
## Same box.
> Are the clocks on the DHCP server and the DNS server synchronised? I
> don't remember why this mattered (it's been years since I set this up
> myself), but I do remember having updates fail when the clocks were not
> synchronised.
## Same box
> Can you send me your DNS and DHCP config files?
## Whole sordid sorry saga here (files and all), fresh this a.m.;
https://www.centos.org/modules/newbb/viewtopic.php?topic_id=30159
pe...@chubb.wattle.id.au
Kyle> John, Answers inline.
Kyle> ------------------------------------------------------------------------
Kyle> Kind Regards
Kyle> Kyle
Kyle> On 17/02/11 2:00 PM, John Clarke wrote:
>> Are you having problems updating the A record or the PTR record, or
>> both?
Kyle> ## Both. DHCP is simply not updating DNS journals when a lease
Kyle> is renewed.
I strongly suspect that the key setup is incorrect.
Take a look in /etc/bind/your-key-file
It should look like
key "DHCP_updater" {
algorithm hmac-md5;
secret "longstringofcharactersendingin==";
};
(this is the one referred to in /etc/dhcp3/dhcpd.conf with
include "/etc/bind/your_key_file"
)
And in /etc/bind/named.conf you should have:
include "/etc/bind/your_key_file"
and
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1;} keys { "DHCP_updater"; ... };
};
And again in each zone statement:
zone "domain.com" in {
type master;
file "/etc/bind/domain.zone";
allow-update { key DHCP_updater;
};
};
or similar.
If the name of the key isn't the same, or you're including different
keyfiles, it will fail because of an authorisation problem.
Peter C
Kyle
exactly!! THAT IS MY ISSUE I believe. But I have not yet found a log to
give me sufficient info to nut out WHY.
All my config files are presently up for the world to see at;
https://www.centos.org/modules/newbb/viewtopic.php?topic_id=30159
And from what I've read (LOTS in the last couple of days), they're
picture perfect.
------------------------------------------------------------------------
Kind Regards
Kyle
On 17/02/11 3:02 PM, pe...@chubb.wattle.id.au wrote:
> I strongly suspect that the key setup is incorrect.....
>
> .....it will fail because of an authorisation problem.
John Clarke
>> Can you manually update either or both with nsupdate run on the DNS
>> server.
> ## No, nsupdate extract from last email was run on the dns server.
OK, so if this doesn't work, then the DHCP server won't be able to do it
either. You need to fix this problem before you can get anything else
working.
What name did you give the key when you created it with dnssec-keygen?
Was it "domain1.com"? Is that what name you passed to nsupdate (in the
argument to -y)?
Do you still have the keyfiles generated by dnssec-keygen? Does
nsupdate work if you use -k instead of -y to pass the key?
Does "rndc status" work? "rndc reload"?
John
--
> ... I can use the cheaper frozen goat for IDE?
Though you _can_ sacrifice things to an IDE bus, there are no reports of
them ever sucking any less as a result, so it's likely a waste of a goat.
-- Anthony de Boer
Kyle
'domain1.com' is obfuscated from the real value. But rest assured I am
being painstakingly anal in ensuring the values are the same including
the 'key name' in named and dhcpd being exactly the same as used in the
dnssec-keygen command.
transcript of interaction. Long story short, the error is 'NOTAUTH'.
And the result is the same no matter whether I use the .private or .key
files.
[root@server3 etc]# rndc status
number of zones: 8
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/1000
tcp clients: 0/100
server is up and running
[root@server3 etc]# rndc reload
server reload successful
[root@server3 etc]# nsupdate -d -k Kdomain1.com.+157+63230.private
Creating key...
> server 127.0.0.1
> zone domain1.com
> update add client1.domain1.com 86400 A 192.168.1.100
> send
Sending update to 127.0.0.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 2442
;; flags: ; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;; ZONE SECTION:
;domain1.com. IN SOA
;; UPDATE SECTION:
client1.domain1.com. 86400 IN A 192.168.1.100
;; TSIG PSEUDOSECTION:
domain1.com. 0 ANY TSIG hmac-md5.sig-alg.reg.int.
1297920682 300 16 <someSecretHere> 2442 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOTAUTH, id: 2442
;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; TSIG PSEUDOSECTION:
domain1.com. 0 ANY TSIG hmac-md5.sig-alg.reg.int.
1297920682 300 16 <anotherSecretHere> 2442 NOERROR 0
> quit
------------------------------------------------------------------------
Kind Regards
Kyle
On 17/02/11 3:42 PM, John Clarke wrote:
> On Thu, Feb 17, 2011 at 02:48:45PM +1100, Kyle wrote:
>
> What name did you give the key when you created it with dnssec-keygen?
> Was it "domain1.com"? Is that what name you passed to nsupdate (in the
> argument to -y)?
>
> Do you still have the keyfiles generated by dnssec-keygen? Does
> nsupdate work if you use -k instead of -y to pass the key?
>
> Does "rndc status" work? "rndc reload"?
>
John Clarke
> 'domain1.com' is obfuscated from the real value. But rest assured I am
> being painstakingly anal in ensuring the values are the same including
> the 'key name' in named and dhcpd being exactly the same as used in the
> dnssec-keygen command.
OK, I just wanted to be sure, because the only way I've been able to
reproduce similar symptoms to yours was by using a different name.
> [root@server3 etc]# rndc reload
> server reload successful
I thought this might provide a clue, but I've tested it on my server
here and rndc seems to work even if the key it's told to use is not
authorised. Oh well.
> Reply from update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOTAUTH, id: 2442
> ;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
> ;; TSIG PSEUDOSECTION:
> domain1.com. 0 ANY TSIG hmac-md5.sig-alg.reg.int.
> 1297920682 300 16 <anotherSecretHere> 2442 NOERROR 0
Now this is slightly different to anything I've been able to reproduce.
If I give it the wrong key I see "BADKEY" in that last line instead of
"NOERROR".
This is just a guess because I've pretty much hit the limits of my
knowledge, and I've never used BIND's views, but could it be something
to do with the different views you've configured? You're trying to do
the update from localhost, so that matches the view
"localhost_resolver", but updates aren't allowed in that view
configuration. Updates are allowed in the view "internal", which also
matches localhost, but I wonder if BIND is simply using the first match
and thus disallowing updates?
John
--
Vs lbh'er ernqvat guvf, lbh ernyyl bhtug gb trg bhg zber
Ben Donohue
going on the same subject)
I've had a very similar setup to you in the past. I never had this much
trouble. I had only centos 5.x servers.
You've got split DNS. Internally, DNS resolves to your internal DNS
server from your clients and you can see what you have allowed from
internal as it's all internal.
Externally, the world goes to dnsmadeeasy.com as your domains are
delegated to this (i'm presuming). So if for example you are hosting a
webserver, then dnsmadeeasy would point that domain to your MODEM
external ip address. On your modem you would have a "virtual server"
setup with port 80 forwarded to your internal webserver ip address.
So from internal you get to the clients webserver from your internal
DNS. From external you get to your clients webserver from being
redirected through dnsmadeeasy to your external IP of your modem and
then from your modem forwarded to your webserver. You could even have
your internal clients all point to the modem for DNS. The modem would
ask dnsmadeeasy where that domain was, it would point to your modem and
then the modem would port forward them all back into your internal
webserver.
I never had any issues with dns key files or dnssec or whatever as I
never needed to use it/them. I would recommend removing all these until
the basics are working solidly.
Have you tried using "webmin" to setup dns on your internal dns server?
Thanks,
Ben Donohue
Kyle
And of course thanks also go to everyone else who kicked in.
For posterity and by way of explanation:
Because of the views and the fact the update was coming from dhcpd on
localhost, the 'localhost_resolver' view was taking over and disallowing
the update because it couldn't find the key "matched to the internal
zone" anywhere, as of course neither could the rest of the www where it
was further forwarding the request. Once I included the internal zones
into the 'localhost_resolver' view, hey presto!
I created the views pretty much carbon copy from the sample file in
/usr/share/doc that comes with this dist. of BIND. That file states
(verbatim);
// All BIND 9 zones are in a "view", which allow different zones to be
served
// to different types of client addresses, and for options to be set for
groups
// of zones.
//
// By default, if named.conf contains no "view" clauses, all zones are
in the
// "default" view, which matches all clients.
//
// If named.conf contains any "view" clause, then all zones MUST be in a
view;
// so it is recommended to start off using views to avoid having to
restructure
// your configuration files in the future.
The sample file does also state;
// These are your "authoritative" internal zones, and would probably
// also be included in the "localhost_resolver" view above :
But doesn't state when/why/etc. Nor does the manpage. In fact, nothing I
read anywhere made any determination of difference between running a
DHCP->DDNS setup on a single box or separate boxes. What the hell does
"probably" mean in that context?
To be fair, I had already tried including the internal zones in the
'localhost_resolver' view on my original host, but when I started BIND
thereafter, syslog showed each defined zone being loaded twice, so I had
discounted that as being "not good" (obviously something else going on
on the original host).
And no level of debugging log BIND enabled me to set up provided any
clues (any mortal could fathom anyway) as to why it wasn't authorised.
Thanks again all.
It's easy when you know how.
------------------------------------------------------------------------
Kind Regards
Kyle
On 17/02/11 6:24 PM, John Clarke wrote:
> This is just a guess because I've pretty much hit the limits of my
> knowledge, and I've never used BIND's views, but could it be something
> to do with the different views you've configured? You're trying to do
> the update from localhost, so that matches the view
> "localhost_resolver", but updates aren't allowed in that view
> configuration. Updates are allowed in the view "internal", which also
> matches localhost, but I wonder if BIND is simply using the first match
> and thus disallowing updates?
>
John Clarke
> And the gold star goes to John. Thanks John for thinking with me.
Thanks, but it was really just a lucky guess at the time ;-)
John
--
I'd miss the BBC, but not if I had time to reload.
-- Terry Pratchett 13/01/2001