Can update-policy accept IP addresses ?
Currently we have (for our Master zone) a list of IPs that can update
our DNS master using the allow-update statement:
zone "redacted.ac.nz" {
type master;
allow-update {
::1;
127.0.0.1;
131.123.103.2;
131.123.88.3;
...
}
We are wanting to transition to the more modern update-policy
statement (because we want to make use of keys), but as a transition
step we would like our existing whitelisted IPs to be included. We
have tried the following:
zone "redacted.ac.nz" {
type master;
update-policy {
grant ::1 zonesub ANY;
grant 127.0.0.1 zonesub ANY;
grant 131.123.103.2 zonesub ANY;
grant 131.123.88.3 zonesub ANY;
...
}
}
But all operations from the whitelisted IPs result in the following:
update 'assey.ac.nz/IN' denied
If we roll back to the "allow-update" statement block, everything
starts working again.
Could someone please advise whether update-policy allows IPs (there
are some sources on the net that suggest it should be able to accept
IPs and/or FQDN addresses - for example
http://pig.made-it.com/ddns.html) ?
If the statement does allow it, how can we go about troubleshooting ?
We have already tried starting named in the foreground with -d 10, but
don't get anything useful (just update 'assey.ac.nz/IN' denied)
With Thanks in Advance
Patrick
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: A beginners question regarding a caching-only name server
Hi Andrew, On 9/04/2011 12:37 a.m., andrew wales wrote: Remember that rndc dumpdb doesn't actually dump the cache to stdout. Has it actually written to named_dump.db in named's working directory? Regards, Andrew Thanks - you are spot on here :-) I was expecting the DB to be written to stdout. One thing that I have noticed, however, is that only information relating to the most recently resolved DNS hostname is being dumped. (If I set my /etc/resolv.conf on my client accordingly and then ping a bunch of different domains then I only get results for the last query.) Perhaps this because I have a forwarders directive (i.e. BIND is not actually functioning as a caching name server at present ?). Cheers, Patrick ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
A beginners question regarding a caching-only name server
I am new to using BIND and thought that I would start by setting up a
caching-only name server on a VM running CentOS 5.5. While in this
mode, my understanding is that named should be passively listening for
any DNS requests that are resolved and be adding them to its local DB.
Adding localhost to /etc/resolv.conf shouldn't be necessary in order for
entries to be added to the DB but obviously required if you want to make
use of the DNS caching.
What I'm observing is that any DNS requests that are resolved aren't
being added to the DB - i.e. the result of rndc dumpdb is always
empty. My named.conf file is as posted inline below; this is a vanilla
named.caching-nameserver.conf (as packaged by CentOS) aside from my
adding the VMWare subnet 192.168.239.0/24 which my VM is on. I also
post the output of named -g along with named.local below.
Any assistance would be appreciated.
named -g
[root@localhost named]# named -g
08-Apr-2011 21:11:39.672 starting BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 -g
08-Apr-2011 21:11:39.673 found 1 CPU, using 1 worker thread
08-Apr-2011 21:11:39.673 using up to 4096 sockets
08-Apr-2011 21:11:39.679 loading configuration from '/etc/named.conf'
08-Apr-2011 21:11:39.680 max open files (1024) is smaller than max
sockets (4096)
08-Apr-2011 21:11:39.681 using default UDP/IPv4 port range: [1024, 65535]
08-Apr-2011 21:11:39.682 using default UDP/IPv6 port range: [1024, 65535]
08-Apr-2011 21:11:39.684 listening on IPv4 interface lo, 127.0.0.1#53
08-Apr-2011 21:11:39.684 listening on IPv4 interface eth0,
192.168.239.141#53
08-Apr-2011 21:11:39.686 /etc/named.conf:24: using specific query-source
port suppresses port randomization and can be insecure.
08-Apr-2011 21:11:39.686 /etc/named.conf:25: using specific query-source
port suppresses port randomization and can be insecure.
08-Apr-2011 21:11:39.687 command channel listening on 127.0.0.1#953
08-Apr-2011 21:11:39.687 command channel listening on ::1#953
08-Apr-2011 21:11:39.687 ignoring config file logging statement due to
-g option
08-Apr-2011 21:11:39.689 zone 0.in-addr.arpa/IN/localhost_resolver:
loaded serial 42
08-Apr-2011 21:11:39.689 zone
0.0.127.in-addr.arpa/IN/localhost_resolver: loaded serial 1997022700
08-Apr-2011 21:11:39.690 zone 255.in-addr.arpa/IN/localhost_resolver:
loaded serial 42
08-Apr-2011 21:11:39.690 zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN/localhost_resolver:
loaded serial 1997022700
08-Apr-2011 21:11:39.690 zone localdomain/IN/localhost_resolver: loaded
serial 42
08-Apr-2011 21:11:39.691 zone localhost/IN/localhost_resolver: loaded
serial 42
08-Apr-2011 21:11:39.691 running -- I perform successful DNS
queries on the box at this point
08-Apr-2011 21:12:05.091 dumpdb started
08-Apr-2011 21:12:05.092 dumpdb complete -- db is always empty
# rndc dumpdb
# - no output
named.conf
--
options {
listen-on port 53 { 127.0.0.1; 192.168.239.0/24; };
//listen-on-v6 port 53 { ::1; };
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
// Those options should be used carefully because they
// disable port randomization
query-sourceport 53;
query-source-v6 port 53;
allow-query { localhost; 192.168.239.0/24; };
allow-query-cache { localhost; 192.168.239.0/24; };
};
logging {
channel default_debug {
file data/named.run;
severity dynamic;
};
};
view localhost_resolver {
match-clients { localhost; 192.168.239.0/24;};
match-destinations { localhost; 192.168.239.0/24;};
recursion yes;
include /etc/named.rfc1912.zones;
};
named.local
---
$TTL86400
@ IN SOA localhost. root.localhost. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
360; Expire
86400 ); Minimum
IN NS localhost.
1 IN PTR localhost.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: A beginners question regarding a caching-only name server
On 8/04/2011 10:11 p.m., Tony Finch wrote:
No, only DNS requests that are handled by the server itself are cached.
There is no sniffing going on.
Tony.
Thank you for the clarification. If I add nameserver 127.0.0.1 to the
VM (and comment out the existing name servers) and attempt to resolve a
DNS entry, the I see output similar to the following:
08-Apr-2011 22:51:50.116 network unreachable resolving
'www.redhat.com/A/IN': 2001:500:2f::f#53
08-Apr-2011 22:51:54.023 network unreachable resolving
'www.redhat.com/A/IN': 2001:503:c27::2:30#53
08-Apr-2011 22:51:54.024 network unreachable resolving './NS/IN':
2001:503:c27::2:30#53
I understand that this is because there is no upstream DNS for BIND as
configured in my named.conf. However, if I try to add a forward
forwarders {
192.168.239.2;
};
(where the host 192.168.239.2 is upstream DNS in my case), then DNS
queries are resolved by the client but do not appear to be cached, i.e.:
# rndc dumpdb
#
What am I missing ? Is it not possible to use a forwarders directive
in combination with a name caching server ?
Thanks,
Patrick
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
