Re: static stub zone not working as expected
I'm still confused about why named looks further up the tree than
c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which it holds authoritatively via
master/slave zone type. That seems like incorrect behavior.
Is this something I can fix or work around?
__
Jay Ford , Network Engineering, University of Iowa
On Sat, 13 Jul 2019, Mark Andrews wrote:
I suspect this will be negative response synthesis. The cache has learnt that
d.f.ip6.arpa doesn’t exist in ip6.arpa and when the name in question is looked
up the covering NSEC is returned which covers all of ULA space.
If I’m right querying for DS d.f.ip6.arpa will load the cache appropriately to
allow this to be triggered. One then needs to trigger a lookup for a name
which finds the covering NSEC in the search back through the cache. Named
skips some responses in the search depending on the content but aborts it on
others content.
--
Mark Andrews
On 13 Jul 2019, at 00:42, Jay Ford wrote:
On Fri, 12 Jul 2019, Mark Andrews wrote:
On 12 Jul 2019, at 1:00 pm, Mark Andrews wrote:
On 12 Jul 2019, at 11:12 am, Jay Ford wrote:
I have a similar problem with zones for IPv6 ULA space. I'm running BIND
9.14.3. I had hoped that validate-except would do the trick, such as:
validate-except { "f.ip6.arpa"; };
but alas, no.
Extra puzzling so far is that the behavior is time-variable: delegated zones
will resolve most of the time, but then fail (NXDOMAIN) for a while.
In the ULA space it doesn't seem trivial to own the top zone (ip6.arpa) without
breaking stuff. Any suggestions for that case?
ULA space it trivial to own. D.F.IP6.ARPA is what you use if you have multiple
ULA prefixes.
If you have a single ULA prefix in use then just use that. e.g.
e.8.b.0.5.6.0.7.2.9.d.f.ip6.arpa
which matches the ULA prefix used in the system tests (fd92:7065:b8e::/48).
This is no different to using 10.in-addr.arpa, 168.192.in-addr.arpa or one of
16.172.in-addr.arpa
though 31.172.in-addr.arpa for RFC 1918 space.
If fc00::/8 is ever used then you would also have C.F.IP6.ARPA.
Named creates the D.F.IP6.ARPA zone automatically if you don’t create it when
the view is
configured for recursion. This is done to stop reverse lookups leaking onto
the internet
as a whole.
% dig soa d.f.ip6.arpa
;; BADCOOKIE, retrying.
; <<>> DiG 9.15.1 <<>> soa d.f.ip6.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23519
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: aa8a24a1cce6c010b9d3a1b75d28009bb013cb0a2f58a961 (good)
;; QUESTION SECTION:
;d.f.ip6.arpa.INSOA
;; ANSWER SECTION:
D.F.IP6.ARPA.86400INSOAD.F.IP6.ARPA. . 0 28800 7200 604800
86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul 12 13:38:03 AEST 2019
;; MSG SIZE rcvd: 116
Yep, that's what I thought. I have master/slave for the zone corresponding
to my ULA /48 (c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa), which is solid including
zones under it also handled as master/slave, but not for zones which are
delegated via NS records to other servers (not master/slave), such as
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which usually resolves like this:
% dig -t ns d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-itf.uiowa.edu
; <<>> DiG 9.10.3-P4-Debian <<>> -t ns
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-itf.uiowa.edu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23886
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. IN NS
;; ANSWER SECTION:
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc1.iowa.uiowa.edu.
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc4.iowa.uiowa.edu.
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc3.iowa.uiowa.edu.
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc5.iowa.uiowa.edu.
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc2.iowa.uiowa.edu.
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc6.iowa.uiowa.edu.
;; Query time: 2 msec
;; SERVER: fd9a:2c75:7d0c:5::e#53(fd9a:2c75:7d0c:5::e)
;; WHEN: Fri Jul 12 09:19:30 CDT 2019
;; MSG SIZE rcvd: 215
but sometimes fails like this:
% dig -t ns d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-cb.uiowa.edu
; <<>> DiG 9.10.3-P4-Debian <<>> -t ns
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-cb.uiowa.edu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20175
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
Re: static stub zone not working as expected
On Fri, 12 Jul 2019, Mark Andrews wrote:
On 12 Jul 2019, at 1:00 pm, Mark Andrews wrote:
On 12 Jul 2019, at 11:12 am, Jay Ford wrote:
I have a similar problem with zones for IPv6 ULA space. I'm running BIND
9.14.3. I had hoped that validate-except would do the trick, such as:
validate-except { "f.ip6.arpa"; };
but alas, no.
Extra puzzling so far is that the behavior is time-variable: delegated zones
will resolve most of the time, but then fail (NXDOMAIN) for a while.
In the ULA space it doesn't seem trivial to own the top zone (ip6.arpa) without
breaking stuff. Any suggestions for that case?
ULA space it trivial to own. D.F.IP6.ARPA is what you use if you have multiple
ULA prefixes.
If you have a single ULA prefix in use then just use that. e.g.
e.8.b.0.5.6.0.7.2.9.d.f.ip6.arpa
which matches the ULA prefix used in the system tests (fd92:7065:b8e::/48).
This is no different to using 10.in-addr.arpa, 168.192.in-addr.arpa or one of
16.172.in-addr.arpa
though 31.172.in-addr.arpa for RFC 1918 space.
If fc00::/8 is ever used then you would also have C.F.IP6.ARPA.
Named creates the D.F.IP6.ARPA zone automatically if you don’t create it when
the view is
configured for recursion. This is done to stop reverse lookups leaking onto
the internet
as a whole.
% dig soa d.f.ip6.arpa
;; BADCOOKIE, retrying.
; <<>> DiG 9.15.1 <<>> soa d.f.ip6.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23519
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: aa8a24a1cce6c010b9d3a1b75d28009bb013cb0a2f58a961 (good)
;; QUESTION SECTION:
;d.f.ip6.arpa. IN SOA
;; ANSWER SECTION:
D.F.IP6.ARPA. 86400 IN SOA D.F.IP6.ARPA. . 0 28800 7200
604800 86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul 12 13:38:03 AEST 2019
;; MSG SIZE rcvd: 116
Yep, that's what I thought. I have master/slave for the zone corresponding
to my ULA /48 (c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa), which is solid including
zones under it also handled as master/slave, but not for zones which are
delegated via NS records to other servers (not master/slave), such as
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which usually resolves like this:
% dig -t ns d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-itf.uiowa.edu
; <<>> DiG 9.10.3-P4-Debian <<>> -t ns
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-itf.uiowa.edu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23886
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. IN NS
;; ANSWER SECTION:
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc1.iowa.uiowa.edu.
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc4.iowa.uiowa.edu.
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc3.iowa.uiowa.edu.
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc5.iowa.uiowa.edu.
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc2.iowa.uiowa.edu.
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc6.iowa.uiowa.edu.
;; Query time: 2 msec
;; SERVER: fd9a:2c75:7d0c:5::e#53(fd9a:2c75:7d0c:5::e)
;; WHEN: Fri Jul 12 09:19:30 CDT 2019
;; MSG SIZE rcvd: 215
but sometimes fails like this:
% dig -t ns d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-cb.uiowa.edu
; <<>> DiG 9.10.3-P4-Debian <<>> -t ns
d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-cb.uiowa.edu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20175
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. IN NS
;; AUTHORITY SECTION:
ip6.arpa. 3009 IN SOA b.ip6-servers.arpa. nstld.iana.org. 2019024499
1800 900 604800 3600
;; Query time: 0 msec
;; SERVER: fd9a:2c75:7d0c:5::a#53(fd9a:2c75:7d0c:5::a)
;; WHEN: Fri Jul 12 09:19:25 CDT 2019
;; MSG SIZE rcvd: 145
Those 2 servers (& others) are configured identically regarding the zones in
question, but some of them sometimes fail this way despite being
authoritative for c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. An "rndc flushtree
ip6.arpa" will fix it for a while.
I do very similar stuff with zones for IPv4 RFC1918 space with no trouble. I
had noticed the authenticated behavior for f.ip6.arpa differing from the
behavior for 10.in-addr.arpa & friends. Thanks for poking at IANA about
that. As I mentioned earlier, my use of validate-except { "f.ip
Re: static stub zone not working as expected
I have a similar problem with zones for IPv6 ULA space. I'm running BIND
9.14.3. I had hoped that validate-except would do the trick, such as:
validate-except { "f.ip6.arpa"; };
but alas, no.
Extra puzzling so far is that the behavior is time-variable: delegated zones
will resolve most of the time, but then fail (NXDOMAIN) for a while.
In the ULA space it doesn't seem trivial to own the top zone (ip6.arpa)
without breaking stuff. Any suggestions for that case?
______
Jay Ford , Network Engineering, University of Iowa
On Fri, 12 Jul 2019, Mark Andrews wrote:
Because static-stub only overrides “where” to find the information about the
zone
not whether the zone content is valid.
With DNSSEC named will treat zone content as trusted (master/slave). Slave the
top
level internal zones. Note this doesn’t help any application that is also
performing
DNSSEC validation.
Note .local is reserved for mDNS. getaddrinfo() shouldn’t be looking in the DNS
for
.local names.
Mark
On 12 Jul 2019, at 7:25 am, btb via bind-users wrote:
hi-
i have an environment which over time has managed to accumulate various "internal" zones
[in this specific case, "foo.local"]. eventually, these zones will be phased out, but
unfortunately in the interim, i'm stuck with this. i'm attempting to configure them as static-stub
zones:
zone "foo.local" {
type static-stub;
server-addresses {
192.168.220.20;
192.168.220.21;
};
};
however, queries are not working. following a cache flush, the initial query
is servfail and subsequent queries are nxdomain:
dig @localhost foo.local ns
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @localhost foo.local ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2550
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.local. IN NS
;; Query time: 181 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 11 16:11:02 EDT 2019
;; MSG SIZE rcvd: 38
dig @localhost foo.local ns
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @localhost foo.local ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43056
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.local. IN NS
;; AUTHORITY SECTION:
. 10796 IN SOA a.root-servers.net.
nstld.verisign-grs.com. 2019071101 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 11 16:11:06 EDT 2019
;; MSG SIZE rcvd: 113
querying the auth nameservers directory is successful:
dig @192.168.220.20 foo.local ns +norec
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @192.168.220.20 foo.local ns +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23
;; flags: qr aa ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;foo.local. IN NS
;; ANSWER SECTION:
foo.local. 3600IN NS 01.foo.local.
foo.local. 3600IN NS 02.foo.local.
foo.local. 3600IN NS a2.foo.local.
foo.local. 3600IN NS a1.foo.local.
;; ADDITIONAL SECTION:
01.foo.local. 3600 IN A 192.168.0.20
02.foo.local. 3600 IN A 192.168.0.21
a2.foo.local. 3600 IN A 10.201.11.8
a1.foo.local. 1200 IN A 10.201.10.119
;; Query time: 82 msec
;; SERVER: 192.168.220.20#53(192.168.220.20)
;; WHEN: Thu Jul 11 16:35:39 EDT 2019
;; MSG SIZE rcvd: 214
additionally unfortunate, there is nat involved here, due to address space
collision, and while this obviously means the practical functionality of this
is questionable, i was expecting that with a static-stub zone, the query itself
would at least function.
i see these messages in the logs:
11-Jul-2019 16:08:51.406 lame-servers: info: error (insecurity proof failed)
resolving 'foo.local/NS/IN': 192.168.220.20#53
11-Jul-2019 16:08:51.489 lame-servers: info: error (insecurity proof failed)
resolving 'foo.local/NS/IN': 192.168.220.21#53
11-Jul-2019 17:08:44.111 lame-servers: info: error (no valid DS) resolving
'foo.local/NS/IN': 192.168.220.21#53
11-Jul-2019 17:08:44.194 lame-servers: info: error (broken trust chain)
resolving 'foo.local/NS/IN': 192.168.220.20#53
i've not had much experience with dnssec yet,
Re: Concerns/warnings in upgrading from 9.9 to 9.11?
On Tue, 9 Jan 2018, Oscar Ricardo Silva wrote: I currently run 9.9.9-P4 on recursive caching servers and with the announcement that 9.9 and 9.10 are approaching end of maintenance, I've decided it's time to move to 9.11. Are there any issues, warnings, concerns in upgrading? Changes that need to be made to named.conf? I know there are new features but I'm more concerned about an in-place upgrade with no change to the current build process or configuration. I've not actually run 9.11 in full deployment because we couldn't tolerate the number of names which were rendered unresolvable due to the more strenuous EDNS checking introduced in 9.11 (apparently as part of the COOKIE features). The problem is in the other broken servers rather than in BIND, but the practical effect that names couldn't be resolved prompted us to stay with 9.10 so far. The use of the relatively recent "send-cookie no;" option seems to work around that problem, providing a way for us to run 9.11 here. However, at this point I'm planning to skip 9.11 & go with 9.12 when it gets released for real (assuming my testing continues to yield favorable results). Some of the good things in BIND 9.11 (some introduced in 9.10 & some in 9.11) are: o IPv6 is enabled by default, including listening o response rate-limited (RRL) is built-in by default; that doesn't apply to purely recursive servers, but it's very nice o the "in-view" method allowing a zone to be shared among views o DNSTAP o general DNSSEC improvements The main things I'm after in 9.12 are: o named-handled rotation of DNSTAP output files; based on my testing that's broken for multi-threaded use in 9.12.0rc1 because the rolling of the file(s) seems to be done simultaneously by multiple threads with no coordination, but I hope to see it fixed in the real 9.12 release o configuration of the COOKIE secret, required for anycast servers; that's broken in 9.11 but seems to work correctly in 9.12 ________ Jay Ford, Network Engineering, University of Iowa ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSTAP output file rolling trouble in BIND 9.12.0rc1
Yeah, that's what I figured too, but I wasn't quite sure of the behavior.
After some experimenting I'm more sure of what I'm seeing now so I'll report
it as a bug.
Jay
On Tue, 2 Jan 2018, Alan Clegg wrote:
Looks like something that ISC would like to have logged as a bug... And
a perfect thing to find in rc1. 8-)
AlanC
On 1/2/18 3:00 PM, Jay Ford wrote:
I'm having some odd trouble with DNSTAP output file rolling in BIND
9.12.0rc1.
I have named built like:
BIND 9.12.0rc1
running on Linux x86_64 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1
(2016-03-06)
built by make with 'STD_CDEFINES=-DISC_FACILITY=LOG_LOCAL5'
'--libdir=/usr/lib/x86_64-linux-gnu' '--with-openssl' '--enable-dnstap'
'--enable-fixed-rrset' '--disable-openssl-version-check'
'--with-libtool' '--enable-dnsrps'
compiled by GCC 6.3.0 20170516
compiled with OpenSSL version: OpenSSL 1.1.0f 25 May 2017
linked to OpenSSL version: OpenSSL 1.1.0f 25 May 2017
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
threads support is enabled
I have DNSTAP configured like:
dnstap {
client query;
};
dnstap-output file "tmp/dnstap.out" versions 10 size 10m;
It mostly works as expected, except that named:
o logs twice about rolling the file every time, such as:
Jan 2 05:15:42 named[24758]: dnstap: info: rolling dnstap
destination 'tmp/dnstap.out'
Jan 2 05:15:42 named[24758]: dnstap: info: rolling dnstap
destination 'tmp/dnstap.out'
o sometimes crashes after logging that, possibly after rolling the file
o writes to multiple output files simultaneously, such as:
ls -lt dnstap* | head -2
-rw-r--r-- 1 bind bind 1282048 Jan 2 16:24 dnstap.out
-rw-r--r-- 1 bind bind 1273856 Jan 2 16:24 dnstap.out.0
& 2 minutes later:
ls -lt dnstap* | head -2
-rw-r--r-- 1 bind bind 1286144 Jan 2 16:26 dnstap.out
-rw-r--r-- 1 bind bind 1277952 Jan 2 16:26 dnstap.out.0
This system had 4 worker threads in use. Another similar system with
only 1 thread does not have such trouble, which got me wondering about
problems with threads & DNSTAP, specifically output file rolling.
Reducing the threads on the afflicted system (via named option "-n 1")
seems to avoid the problem, but it's a little early to tell, & it's not
a desirable fix.
I'd appreciate it if somebody who knows the code would comment on the
threads vs DNSTAP possibility or point me in some other direction to
figure this out.
I have a named core file & can provide more config... details if required.
________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
DNSTAP output file rolling trouble in BIND 9.12.0rc1
I'm having some odd trouble with DNSTAP output file rolling in BIND
9.12.0rc1.
I have named built like:
BIND 9.12.0rc1
running on Linux x86_64 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1
(2016-03-06)
built by make with 'STD_CDEFINES=-DISC_FACILITY=LOG_LOCAL5'
'--libdir=/usr/lib/x86_64-linux-gnu' '--with-openssl' '--enable-dnstap'
'--enable-fixed-rrset' '--disable-openssl-version-check' '--with-libtool'
'--enable-dnsrps'
compiled by GCC 6.3.0 20170516
compiled with OpenSSL version: OpenSSL 1.1.0f 25 May 2017
linked to OpenSSL version: OpenSSL 1.1.0f 25 May 2017
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
threads support is enabled
I have DNSTAP configured like:
dnstap {
client query;
};
dnstap-output file "tmp/dnstap.out" versions 10 size 10m;
It mostly works as expected, except that named:
o logs twice about rolling the file every time, such as:
Jan 2 05:15:42 named[24758]: dnstap: info: rolling dnstap
destination 'tmp/dnstap.out'
Jan 2 05:15:42 named[24758]: dnstap: info: rolling dnstap
destination 'tmp/dnstap.out'
o sometimes crashes after logging that, possibly after rolling the file
o writes to multiple output files simultaneously, such as:
ls -lt dnstap* | head -2
-rw-r--r-- 1 bind bind 1282048 Jan 2 16:24 dnstap.out
-rw-r--r-- 1 bind bind 1273856 Jan 2 16:24 dnstap.out.0
& 2 minutes later:
ls -lt dnstap* | head -2
-rw-r--r-- 1 bind bind 1286144 Jan 2 16:26 dnstap.out
-rw-r--r-- 1 bind bind 1277952 Jan 2 16:26 dnstap.out.0
This system had 4 worker threads in use. Another similar system with only 1
thread does not have such trouble, which got me wondering about problems with
threads & DNSTAP, specifically output file rolling. Reducing the threads on
the afflicted system (via named option "-n 1") seems to avoid the problem,
but it's a little early to tell, & it's not a desirable fix.
I'd appreciate it if somebody who knows the code would comment on the threads
vs DNSTAP possibility or point me in some other direction to figure this out.
I have a named core file & can provide more config... details if required.
________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Re: checkhints: view “internal”: b.root-servers.net/AAAA (2001:500:200::b) extra record in hints
On Sun, 10 Sep 2017, Mark Andrews wrote: I suspect that you are forwarding your queries and that your forwarder is returning out-of-date addresses. No forwarding here. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: checkhints: view “internal”: b.root-servers.net/AAAA (2001:500:200::b) extra record in hints
On Sat, 9 Sep 2017, Stefan Sticht wrote: since a couple of weeks i repeatedly see this in all my nameserver logs: Sep 8 12:12:56 ns-01 named[17926]: checkhints: view “internal”: b.root-servers.net/ (2001:500:200::b) extra record in hints Sep 8 12:13:03 ns-01 named[17926]: checkhints: view “internal”: b.root-servers.net/ (2001:500:84::b) missing from hints I get that, too, with the same view situation, but running BIND 9.10.6 using the built-in root hints. A query for view=internal type= name=b.root-servers.net fixes it for a while. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: view problem
On Wed, 19 Oct 2016, Mark Andrews wrote: In message <alpine.deb.2.20.1610181109390.8...@headset.its.uiowa.edu>, Jay Ford writes: Right. "in-view" can be useful for this, as long as you only need to refer to previously defined views (i.e., it unfortunatley doesn't allow forward references). So put the zone in the first view. Updates, notifies and queries are delivered to the zone from all views the zone is in. Acls are all configurable on the zone level if you don't like the inherited acls from the first view. To get any order we need to configure all views without the in-view zones then go back and configure all the in-view zones. We then would need to go and configure all the automatic empty zones as they need to be aware of bottom of zone cuts. It's do able but it isn't high on the priority list. Understood. I didn't say it was unreasonable; just unfortunate. There are some configurations which would benefit from order-independent in-view references, but I understand that it's not trivial. ________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: view problem
On Tue, 18 Oct 2016, Barry Margolin wrote: If there are zones that both sets of clients should see, you have to duplicate them in both views. Overlapping views don't do this automatically. Right. "in-view" can be useful for this, as long as you only need to refer to previously defined views (i.e., it unfortunatley doesn't allow forward references). ________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling rate-limit?
On Mon, 15 Aug 2016, blrmaani wrote: I inherited a DNS server which is running BIND 9.8.x. There was a DNS incident where our customers complained that they saw query timeouts intermittently (Our customers run cassandra/hadoop applications and send same queries repeatedly). They also run nscd on their hosts but I was told all have same TTL value of 3600 indicating all names expire at the same time on thousands of client hosts). I tried to reproduce the issue by sending hostname.bind queries and I see logs similar to the one below: named[]: limit responses to for hostname.bind CH TXT named[]: *stop limiting responses to for hostname.bind CH TXT I reviewed /etc/named.conf and do not see 'rate-limit' configuration. I am confused because BIND ARM says rate-limit is disabled by default. But logs indicate otherwise. The built-in view for the "CH" class has response rate-limting (RRL) enabled by default. It's possible to override it, but it might not help you any. Basically, your test queries are sufficiently different than normal queries that your test methodology is probably invalid. Do you see RRL log messages for normal queries? If not, then RRL is probably not your trouble. Other things like insufficient UDP buffering, lacking CPU horsepower, or overwhelmed iptables connection tracking can also cause time-outs. ________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation failures for www.hrsa.gov
On Sat, 25 Jun 2016, Mark Andrews wrote:
The servers for webfarm.dr.hrsa.gov are not EDNS and DNSSEC compliant.
They are returning FORMERR to queries with EDNS options. Unknown
EDNS options are supposed to be ignored (RFC 6891).
You can workaround this with a server clause to disable sending the
cookie option with a server clause.
server { request-sit no; }; // 9.10.x
server { send-cookie no; }; // 9.11.x
That did it, at least for now.
Now one could argue that FORMERR is legal under RFC 2671 (the initial
EDNS specification) as no options were defined and to use a option
you need to bump the EDNS version but the servers don't do EDNS
version negotiation either as they return FORMERR to a EDNS version 1
query rather than BADVERS. They also incorrectly copy back unknown
EDNS flags.
Whether this is the cause of your issue I don't know but it won't be
helping.
The HRSA folks claim that their "site is fine". In hopes of disabusing them
of that notion I'll have our folks who have to try to use the HRSA site pass
along the trouble report.
Thanks for the diagnosis & work-around. Excellent as always & crazy fast,
too!
________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC validation failures for www.hrsa.gov
I'm getting DNSSEC validation failures by BIND 9.10.4-P1 for www.hrsa.gov. The pertinent log messages are things like: lame-servers: info: no valid RRSIG resolving 'webfarm.dr.hrsa.gov/DS/IN': 165.112.137.222#53 lame-servers: info: no valid RRSIG resolving 'webfarm.dr.hrsa.gov/DS/IN': 162.99.248.222#53 lame-servers: info: no valid DS resolving 'webfarm.dr.hrsa.gov/A/IN': 162.99.248.222#53 lame-servers: info: broken trust chain resolving 'webfarm.dr.hrsa.gov/A/IN': 165.112.137.222#53 lame-servers: info: insecurity proof failed resolving 'dr.hrsa.gov/SOA/IN': 162.99.248.222#53 lame-servers: info: insecurity proof failed resolving 'dr.hrsa.gov/SOA/IN': 165.112.137.222#53 The dig output is: $ dig www.hrsa.gov @dns-spare.uiowa.edu ; <<>> DiG 9.10.3-P4-Debian <<>> www.hrsa.gov @dns-spare.uiowa.edu ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42947 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.hrsa.gov. IN A ;; Query time: 103 msec ;; SERVER: fd9a:2c75:7d0c:5::2#53(fd9a:2c75:7d0c:5::2) ;; WHEN: Fri Jun 24 18:49:06 CDT 2016 ;; MSG SIZE rcvd: 41 It doesn't fail with a similar config on 9.10.3-P4, but there are admittedly config differences. Other DNSSEC-signed things validate fine at both versions, so things are mostly OK. My guess is that BIND 9.10.4-P1 is checking something more stringently than previous versions did, & that something is broken with the DNS for www.hrsa.gov, but I can't spot what it is. There are some very short TTLs (5 seconds) in the data tree in question, including for SOAs, which seems like a really bad idea but I'm not sure it definitely breaks things. There are also some answers with both "AA" & "AD" set, which seems odd, but again, not definitely broken. dnsviz.net reports a couple of warnings, including a non-AA answer from authoritative servers, but it doesn't say it's bogus. If anybody can spot something broken for www.hrsa.gov, I'd be very glad to hear about it. ________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnskey algorithm update
On Wed, 6 Jan 2016, Carl Byington wrote: My zones are currently using algorithm 5 (RSASHA1), with two KSKs and two ZSKs with overlapping timers. In preparation for updating to algorithm 8 (RSASHA256), I read: The bind-users thread "KSK signing all records; NSEC3 algorithm status?" https://tools.ietf.org/html/rfc6781#page-31 https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over Is there a more authoritative document that describes the algorithm roll over procedure? It seems that I need to: generate new ZSK and KSKs using algorithm 8 sign the zone with all the keys wait one ttl cycle, then publish a new dnskey rrset wait one ttl cycle, then upload the new ds rrset ... eventually, remove the old KSKs from the dnskey rrset, but still use them to sign the zone wait one ttl cycle, then resign the zone without the old KSKs. Carl: When I did that algorithm upgrade, I used something close to this process (based on the dual-signature method): # generate new RSASHA256 ZSK & KSK (active & published) dnssec-keygen -K Keys.dnssec -a RSASHA256 -b 1024 -n ZONE $ZONE dnssec-keygen -K Keys.dnssec -a RSASHA256 -b 4096 -n ZONE -f KSK $ZONE # re-sign the zone, using smart signing to pick up all keys dnssec-signzone -K $KEY_DIR -d $KEY_DIR -S -o $ZONE $DIR/$ZONE # re-load the zone (add any other required rndc args) rndc reload $ZONE # add DS record(s) for new KSK in parent zone; # left as an exercise for the reader # wait at least 1 TTL cycle (minimum of that for $ZONE & that for the # DS records in the parent zone) to let new DNSKEY, RRSIG, & DS records # propagate # move old keys out of key dir so they don't get used mv $KEY_DIR/K$ZONE.+005+* $TMP_DIR # re-sign the zone (with just new keys) dnssec-signzone -K $KEY_DIR -d $KEY_DIR -S -o $ZONE $DIR/$ZONE # re-load the zone (add any other required rndc args) rndc reload $ZONE # delete DS record(s) for old KSK in parent zone; # left as an exercise for the reader # if all good, delete old keys rm $TMP_DIR/K$ZONE.+005+* where: $ZONE is the zone being upgraded $KEY_DIR contains the key files $DIR contains the zone files $TMP_DIR contains old keys temporarily You can get by with activating the new (RRSIG,DNSKEY,DS) set as a group immediately after creation & re-signing because the old set is still present as the basis for validation while the new set propagates around. Likewise, after the TTL cycle you can delete the old (RRSIG,DNSKEY,DS) set as a group because by then the new set is present as the basis for validation. It worked for me. As always, your experience might vary. I recommend working through this for a zone which: o doesn't matter o has the parent under your direct control These tools are extremely useful: http://dnsviz.net/ http://dnssec-debugger.verisignlabs.com/ Use them to view & verify things at each stage. To really have some fun, purposefully break some part of your test zone & see how the above tools show it. ________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Cloud DNS providers for secondary DNS
On Wed, 30 Dec 2015, Diggins Mike wrote: Thanks for the help. My question is hypothetical at this point and likely pointless since I intend to implement it the "right" way, but I'd still like to understand this better. I'm not looking to circumvent the rules. Good plan. My more specific question is this: If I'm a site on the internet looking for a server in my domain for the first time, I query the TLD servers for a list of name servers for my domain and pick one to query. Suppose I pick one that has the correct zone information and can answer the query, but that specific NS is not listed in the zone record. I believe that's called a LAME nameserver, correct? What happens? Does it answer the query regardless? Does specifying the NS record in the zone simply confirm to the remote site that this is a valid nameserver for this zone? A lame delegation is when you have an NS record to a server which doesn't know about the domain in question. You're glossing over some details which matter, & which often contribute to broken DNS configurations. The servers for the parent domain (edu, com, org...) will provide whatever information you specify via your registrar (NS records & A/ records for glue if pertinent). However, that information isn't authoritative, because those servers aren't authoritative for your domain. The information is offered as hints to find authoritative information. If you specify NS records for your servers & cloud servers, queriers will use both sets as hints. A querier with no knowledge of your domain will use those hints to find authoritative information. In your case, that querier will talk to your servers and/or the cloud servers. If the cloud servers respond with NS records for only your servers, the querier will subsequently talk to only your servers & not the cloud servers, because that's what the authoritative information says to do. This probably isn't what you want to happen, so you probably want to include NS records for the cloud servers, so that queriers will use the cloud servers for subsequent queries. The flip side of this is what your on-campus (or on-whatever) queriers do. If you have devices on your campus/whatever which use NS records (as opposed to just being pointed at a recursive resolver), they will (in general) use all of the NS records. As result some amount of such queries will go to the cloud servers when it might be better to have them go to your (presumably local) servers. As long as all the servers have the same information, the answers will be consistent, but performance might suffer. This might or might not be a problem. If you do split-view games, things get even more interesting. ________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 PTR Records
On Mon, 10 Mar 2014, Maechler Philippe wrote: How do you manage your IPv6 Reverse Entries? Let's assume that we have a /32 IPv6 subnet for our needs and that we only publish PTR records where they are needed like for mail servers and maybe DNS and web servers. Our Network is: 2001:db8::/32 This would give us a Zone named 8.b.d.0.1.0.0.2.ip6.arpa Our DNS has the ip 2001:db8:193:192::20/64 and the other one has 2001:db8:193:193::20/64 1) Would you create an entry in 8.b.d.0.1.0.0.2.ip6.arpa like: 20.2.9.1.0.3.9.1.0 IN A dns1.example.org. 20.3.9.1.0.3.9.1.0 IN A dns2.example.org. As Chris Buxton pointed out, you lost a few necessary 0s need 0.2 on the tail instead of 20. Provided you get the syntax right, any of those can work. Choose whatever level of delegation is convenient. We do most of ours at the /64 boundary, but we do some sparse subnets delegated at /56 such to avoid having a bunch of zones with almost nothing in them. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling RPZ for a few clients / views sharing zones
On Thu, 6 Feb 2014, Chuck Anderson wrote:
On Thu, Feb 06, 2014 at 09:50:26AM -0800, Doug Barton wrote:
On 02/06/2014 06:27 AM, Chuck Anderson wrote:
I was kinda hoping that newer
versions of BIND could share zones (with identical zone contents)
between views without requiring the messy multiple IP alias setup.
Evan Hunt just replied, but I already this typed so
I think that's coming in 9.10, which is in alpha now.
You have always been able to do this with include files.
I'm not sure how this helps. If you do this:
named.conf:
view no-rpz {
match-clients { 192.168.1.1; };
zone example.com {
type slave;
file /var/named/slaves/example.com.zone;
masters { 10.0.0.1; };
};
};
view global {
match-clients { any; };
response-policy { zone rpzip.example.com; };
zone rpzip.example.com {
type slave;
file /var/named/slaves/rpzip.example.com.zone;
masters { 10.0.0.2; };
};
zone example.com {
type slave;
file /var/named/slaves/example.com.zone;
masters { 10.0.0.1; };
};
};
Then the global view sees updates to example.com quickly, as soon as
NOTIFY is sent by the master and the zone is transferred. However,
the no-rpz view doesn't see changes to example.com in a timely
manner. I've had to wait awhile (SOA refresh) for new records to
appear and old records to disappear from the no-rpz view's
example.com zone.
I like the trick of having view A pull the zone from the real master
notify view B, while view B pulls the zone locally from view A, using TSIG
keys to indicate the other view for the notify transfer.
Adapting your config, using IPv6 loopback addresses, something like this
might work for you:
key be-internal.keys.example.com. {
algorithm hmac-md5;
secret ...secret stuff...;
};
view no-rpz {
match-clients {
192.168.1.1;
key be-internal.keys.example.com.;
};
zone example.com {
type slave;
file /var/named/slaves/example.com.zone;
masters { ::1; };
allow-notify { localhost; };
};
};
view global {
match-clients { any; };
// define self as server using be-internal key to allow
// external-internal notify for common zones mastered by
// servers unaware of our view games
server ::1 { keys intra-dns-be-internal.keys.uiowa.edu.; };
response-policy { zone rpzip.example.com; };
zone rpzip.example.com {
type slave;
file /var/named/slaves/rpzip.example.com.zone;
masters { 10.0.0.2; };
};
zone example.com {
type slave;
file /var/named/slaves/example.com.zone;
masters { 10.0.0.1; };
also-notify { ::1; }; // internal-external trickery
};
};
The relatively new ability to specify a key in a masters statement can
also be useful, but isn't required for the above example.
Evaluate it for use in your context. I don't know how/if this interacts with
RPZ. It also assumes you don't do anything else with DNS via loopback
addresses. ...
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling RPZ for a few clients / views sharing zones
On Thu, 6 Feb 2014, Chuck Anderson wrote: Neat. Is there any problem with using the exact same zone file in both views? I worry that one view might fight with the file from the other view... Oh yeah, sorry, I left that bit out. The slave files do need to be unique or they will over-write each other. I use a directory per view to keep things tidy. Jay ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
IPv4 control socket binding failure with BIND 9.9.4-P1 on RHEL6
I'm testing BIND 9.9.4-P1 on a RHEL6 system am getting this log message:
/etc/named.conf:56: couldn't add command channel 127.0.0.1#953: address in
use
That's with an rndc.key file in place no controls config, which implies
TCP 953 on 127.0.0.1 ::1.
Control via IPv6 (::1 port 953) works fine, but IPv4 doesn't:
% netstat -an -A inet | fgrep :953
% netstat -an -A inet6 | fgrep :953
tcp0 0 ::1:953:::* LISTEN
Even if I try to configure the controls to listen on a different port for
IPv6, such as:
controls {
inet ::1 port 954 allow { localhost; };
inet 127.0.0.1 allow { localhost; };
};
the IPv4 bind still fails, while the IPv6 bind works.
Interestingly, the bindings for the query ports (TCP UDP 53 IPv4 IPv6)
work fine, with just this under options:
listen-on-v6 { any; };
This is all using BIND built from ISC source (not a RedHat package). Here's
the named -V output:
BIND 9.9.4-RedHat-9.9.4-P1_UIOWA.el6 (Extended Support Version)
id:8f9657aa built with '--host=x86_64-redhat-linux-gnu'
'--build=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
'--sharedstatedir=/var/lib' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var'
'--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static'
'--disable-openssl-version-check' '--enable-rrl' '--with-gssapi=yes'
'--disable-isc-spnego'
'--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
'--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g' 'CPPFLAGS=
-DDIG_SIGCHASE'
using OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
using libxml2 version: 2.7.6
RHEL6 has kernel variable net.ipv6.bindv6only set to 0, which might or might
not be related. BIND 9.8.5-P2 works correctly on a RHEL5 system which also
has it set to 0. There are some comments in some of the 9.9 release notes
about bindv6only, but I couldn't find anything specific to this situation.
Is this a configuration problem or something more in the bug category?
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv4 control socket binding failure with BIND 9.9.4-P1 on RHEL6
On Thu, 5 Dec 2013, Shumon Huque wrote: On 12/5/13 11:49 AM, Jay Ford wrote: I'm testing BIND 9.9.4-P1 on a RHEL6 system am getting this log message: /etc/named.conf:56: couldn't add command channel 127.0.0.1#953: address in use I'm going to take a guess: you might have portreserve running that is reserving the control channel port, or v4 only because they forgot about v6. We usually turn it off. That was indeed the problem killing portreserve lets things work correctly now. Thanks much! Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DDOS attack Bind 9.9 - P2
On Tue, 30 Apr 2013, Jose Manuel Delgado G. wrote: I have isc.org attack. isc.org internet *?. It comes from my own clients that I have allowed in my ACL. the question is how to stop this attack? this causes my traffic on the interface is intense and also up my cpu percentage. that I can do to prevent it?? Assuming clients means things you connect to the net... If the queries are really from your clients, find fix them. They are probably attacking others in addition to you, so you'd be doing the rest of the Internet a favor while solving your own problem. If the traffic is spoofed as being from your clients, stop accepting traffic from elsewhere sourced from your client address space. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RSA warnings errors in 9.8.4
I just upgraded BIND on a Linux-based server from 9.8.3-P3 to 9.8.4. I started getting a bunch of RSA_verify errors, as has been discussed on this list. Is there a 9.8 release which quells those messages, or is hacking the source post-download still the recommended fix? Also, I got a spurt of log messages like: general: info: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100: general: info: error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:fips_rsa_eay.c:748: Anybody know what that's about? Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: reverse dns for IPV6 ranges
On Mon, 19 Mar 2012, hugo hugoo hugo...@hotmail.com wrote: Jay, - Can you give me an example of such configuration? Sure. Say I use a DHCP pool of /64_prefix:a123:b456::/96 within each /64 subnet. For example: subnet DHCP pool _ ___ 2001:db8:0:a::/64 2001:db8:0:a:a123:b456::/96 2001:db8:0:b::/64 2001:db8:0:b:a123:b456::/96 2001:db8:0:c::/64 2001:db8:0:c:a123:b456::/96 Then you put this in every /64 subnet zone: ; *.6.5.4.b.3.2.1.a IN PTR dhcpv6.whatever.edu. ; so that PTR queries for addresses like: 2001:db8:0:a:a123:b456::4 2001:db8:0:b:a123:b456:1:2 2001:db8:0:c:a123:b456:abc:def all return dhcpv6.whatever.edu. To make that less tedious, I create a file called dhcpv6.ptr.inc like this: ; ; dhcpv6.ptr.inc ; include file defining wildcard PTR record for DHCPv6 pools $TTL 86400 @ IN PTR dhcpv6.whatever.edu. ; Each subnet zone file (e.g., zone a.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa for subnet 2001:db8:0:a::/64) pulls in that file via: ; $INCLUDE dhcpv6.ptr.inc *.6.5.4.b.3.2.1.a ; That way if I want to change the name in the PTR record I edit 1 file instead of every zone file. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: reverse dns for IPV6 ranges
On Mon, 12 Mar 2012, hugo hugoo wrote: Has anyone else experience with reverse IPV6 configuration with Bind? We do static PTR records in the ip6.arpa zones like we do in the in-addr.arpa zones, to create address-name mappings matching the name-address mappings created by the A records. I fairly recently started fiddling with wildcard PTR records for DHCPv6 address pools, to at least return some answer for a query about the addresses. Right now I have it configured so that a query for any address in any of the pools returns the same name, but it could be changed to return different names for different pools. This obviously doesn't create symmetric name-address address-name mapping, which might or might not be a problem. I don't have enough real use of this to know whether this wildcard stuff is helpful or not. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Format of the IPv6 reversed zone
On Thu, 28 Jul 2011, Khuu, Linh Contractor wrote: I'm new to IPv6 configuring in BIND. I need help. The forward zone is simple enough with record, but the reversed zone is a bit confusing to me. For example, I want to add a hostname of www.example.com to 2001:1930:c00::2. This IPv6 address is /48. How can I add this IPv6 address in a reversed format? $ORIGIN 0.0.0.0.0.0.0.c.0.3.9.1.1.0.0.2.ip6.arpa. IN SOA .. @ NS dnstemp1.example.com What should I put for the PTR??? Is the reversed for IPv6 in the ip6.arpa file or IP6.int file??? It's in ip6.arpa. The whole name for 2001:1930:c00::2 should be: 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.0.0.3.9.1.1.0.0.2.IP6.ARPA In your origin above you lost a 0 right of the c. The :c00: chunk is actually :0c00:, so the correct origin is: 0.0.0.0.0.0.c.0.0.3.9.1.1.0.0.2.ip6.arpa in which the PTR RR would be: 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR www.example.com Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Split-DNS + Views + master/slave
, NS..., external-only data, an $INCLUDE of file #3 3. common view file: common data (no SOA...) If the SOA, NS... are the same between the views, they can also be in the common file. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: slave timers
On Mon, 18 Apr 2011, hugo hugoo wrote: I am testing the migration bind8 to Bind9 and the working for slave zones. To do this, I have put the following values to the timers in the master zone. $ORIGIN com. toto 3600IN SOA ns1.toto.com. postmaster.toto.com. ( 2011041404 302 3600 604800 3600 ) It is really not working good! - Are there some constraint in the timer values? For my test I have a 302 seconds expired time can this work even if this timer is smaller than the other ones? The second parameter is the refresh timer, not the expire timer. 302 seconds is pretty short. Assuming your master-slave notifies are working correctly an hour or 2 (3600 or 7200 seconds) should be fine for a refresh timer value, but there are probably valid reasons to use shorter values. - When I do a 'rndc reload' on the slave name server, there is no AXFR request to the Master. - When I do a bind9 stop/start on the slave name server, there is no AXFR request to the master. - There is no AXFR request to the master every 302 seconds. The slave will check the SOA serial number it has against that of the master. If the master's is newer, it will transfer the zone. If not, the slave has current data so doesn't need to transfer it again. Are you incrementing the SOA serial number on the master? rndc retransfer zone on the slave will force a transfer, ignoring the SOA serial number. See if that works. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: FORMERR for wikipedia...
On Thu, 17 Mar 2011, Mark Andrews wrote: The nameservers for wikipedia.org are broken. They put the wrong SOA record in the negative response, wikipedia.org != wikimedia.org. M vs P Exactly. The adminstrators of wikimedia.org were informed about this months ago but they don't seem to care. They fail to acknowledge the problem or to fix the problem. wikimedia.org are not alone in this. There are thousands on web sites that return the wrong answers to lookups. Meanwhile everyone wants resolver vendors to make the lookups work. We can't when the authoritative servers are broken. It time the users complained. That's where I'm going with this, but specific information with a suggested fix is usually better than just pointing out that it's broken. Is it known what software and/or config causes this broken behavior? Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: FORMERR for wikipedia...
On Thu, 17 Mar 2011, Mark Bergsma wrote: On Mar 17, 2011, at 6:48 AM, Jay Ford wrote: On Thu, 17 Mar 2011, Mark Andrews wrote: The nameservers for wikipedia.org are broken. They put the wrong SOA record in the negative response, wikipedia.org != wikimedia.org. The adminstrators of wikimedia.org were informed about this months ago but they don't seem to care. They fail to acknowledge the problem or to fix the problem. wikimedia.org are not alone in this. There are thousands on web sites that return the wrong answers to lookups. Meanwhile everyone wants resolver vendors to make the lookups work. We can't when the authoritative servers are broken. It time the users complained. That's where I'm going with this, but specific information with a suggested fix is usually better than just pointing out that it's broken. Is it known what software and/or config causes this broken behavior? It's PowerDNS 2.9.22 that is breaking this, and it will be fixed by PowerDNS 3.0 once that's released, and we get around to deploying it. HTH! Indeed it helps. Thanks for the info good luck with the upgrade. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
FORMERR for wikipedia...
A recursive resolver of mine running BIND 9.7.3 logs many messages like: resolver: DNS format error from 208.80.152.130#53 resolving \ en.wikipedia.org/ for client ::1#33887: invalid response lame-servers: error (FORMERR) resolving 'en.wikipedia.org//IN': \ 208.80.152.130#53 I see this for a variety of domains, including wikipedia.org, yahoodns.net, officedepot.com, staples.com. I did some investigation, including sniffing the DNS traffic. The problematic case seems to be names which have CNAMEs to names in other zones for which the queried record type doesn't exist. For example: en.wikipedia.org is a CNAME - text.wikimedia.org text.wikimedia.org is a CNAME - text.pmtpa.wikimedia.org text.pmtpa.wikimedia.org has an A record, but no , TXT... A query for type= name=en.wikipedia.org returns: % dig -t en.wikipedia.org ; DiG 9.7.3 -t en.wikipedia.org ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 45218 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;en.wikipedia.org. IN ;; Query time: 229 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Mar 16 11:34:08 2011 ;; MSG SIZE rcvd: 34 The response packet from the wikipedia/wikimedia DNS servers is: Internet Protocol, Src: 208.80.152.142 (208.80.152.142), \ Dst: 128.255.204.16 (128.255.204.16) User Datagram Protocol, Src Port: 53 (53), Dst Port: 55497 (55497) Domain Name System (response) [Request In: 159] [Time: 0.061065000 seconds] Transaction ID: 0xd49c Flags: 0x8400 (Standard query response, No error) Questions: 1 Answer RRs: 0 Authority RRs: 1 Additional RRs: 0 Queries en.wikipedia.org: type , class IN Authoritative nameservers wikimedia.org: type SOA, class IN, mname ns0.wikimedia.org so, basically: code NOERROR no answer authority citing wikimedia.org NOERROR seems right, but it includes authority information for the zone of the CNAME target without including the CNAME as an answer, amounting to a mismatch between the original query the cited authority. Note that if I do an A query first, I get the CNAME via a correctly formed response, after which the TXT queries work, with the CNAME chain filled in from local cache. To me it looks like BIND is doing the right thing (as usual ;^), but the wikipedia... servers are returning bogus responses. Is this interpretation correct? If so, does anybody know what apparently screwy DNS server or configuration causes this behavior? I saw something similar with an F5 installation here on campus briefly before I had the local folks fix it, but I'd like some confirmation that's what's going on with wikipedia... before I try to get them others to fix it. Further, if it's a systemic F5... problem, then a different approach is probably in order. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Advice wanted on Nameserver switchover
On Tue, 15 Mar 2011, Stewart Dean wrote: Have two questions about the switchover of our external nameservers: I'll call the old nameservers oldns1, oldns2, offsitens and the new nameservers newns1 and newns2 So, you're replacing oldns1 oldns2 with newns1 newns2, while keeping offsitens. The master is currently oldns1 will be newns1. The others are slaves. Yes? I suggest: 1. replace oldns2 with newns2 a. configure newns2 how you want it, pretty much identical to oldns2 but with different interface addresses; verify things work b. disconnect newns2 from the net c. change interface addresses of newns2 to those of oldns2 d. disconnect oldns2 from the net e. connect newns2 to the net f. verify newns2 working: zone transfers, query resolution... 2. replace oldns1 with newns1 a. configure newns1 how you want it, pretty much identical to oldns1 but with different interface addresses; verify things work b. disconnect newns1 from the net c. change interface addresses of newns1 to those of oldns1 d. disconnect oldns1 from the net e. connect newns1 to the net f. verify newns1 working: zone transfers, query resolution... 3. verify offsitens still works No SOA changes, no whois fiddling, back-out 1 box at a time if necessary. Regarding your idea of pointing whois information at name servers which aren't live: don't do that. DNS will probably handle it, but only after dealing with the fact that 2 of the 5 servers don't work. You'll see delays possibly failures. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tools for searching/removing stale keys
On Thu, 24 Feb 2011, Antonio Querubin wrote: Has anyone come up with scripts/tools for removing stale zone-signing keys but leaving key-signing keys which are in the same directory alone? Take a look at http://seatpost.its.uiowa.edu/bind_stuff/ It's a collection of scripts for dealing with routine DNS tasks related to multiple views DNSSEC. The check-keys script might be close to what you're after. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Some dnssec-signzone questions
On Tue, 1 Feb 2011, Torinthiel wrote: Third is about -N option: a well established practice (although I don't know what was the origin) is to set SOA serial number to eg 2011020101, which is current day and two-digit of daily version. This has benefit of being almost as good as putting unixtime of last modification, while being much more human-readable. How difficult would it be to implement this for dnssec-signzone -N, using a fourth format specifier? It's not hard. See my bind-users post of Oct 15 with subject: more flexible serial number handling in dnssec-signzone Since then I've quit using the serial number fiddling ability of dnssec-signzone. The problem is that it doesn't increment the serial number in the unsigned file, so future uses of dnssec-signzone -N could result with the same or even lower values. Instead, I created a zap-serial tool to zap the serial number in place within the unsigned zone file, either to a new literal value or incrementing the old number. My DNSSEC-related processes now zap the serial number before signing with dnssec-signzone. You can find the C source for zap-serial some possibly useful other DNSSEC-related scripts here (at least for now): http://seatpost.its.uiowa.edu/bind_stuff Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Telling rndc Which IP Address to Use
On Wed, 19 Jan 2011, Barry Finkel wrote:
I have a master DNS server that has two IP addresses - one used for
DNS and one used for non-DNS. On that master I run rndc to load
zones on slave servers. On the slave servers I have
controls{
inet a.b.c.d port 953
allow {127.0.0.1; e.f.g.h; } keys { rndc-key';};
}
Where e.f.g.h is the DNS address for the master server. Is there a
way on the master to run rndc and tell rndc which IP address to use?
Or do I have to put the non-DNS address of the master in the controls
directive on the slaves. I am running 9.7.2-P3. Thanks.
Does the -b option not suffice?
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Private Zones and Deligation bind9.7.2
On Mon, 6 Dec 2010, Martin McCormick wrote:
the config for this private zone is:
zone r.ds {
type master;
file /etc/namedb/master/r.ds.zone;
allow-update {
key updsrv;
};
allow-query { any; };
#a list of slaves
include /etc/zoneconfigs/stwnotify;
notify yes;
};
You configured this server to be master for the r.ds zone, which tells this
server that it is authoritative for names in that zone. If it gets a query
for a resource record in that zone which it doesn't know, it will answer
authoritatively with a negative answer (either NXDOMAIN if the name doesn't
exist at all, or NOERROR with no answer data if the name exists but not
with the queried type). NS records in a zone don't cause an authoritative
server to send queries elsewhere, because the server knows the answer by
virtue of being authoritative for the zone.
The NS records you list will direct *other* resolvers which see those NS
records to send queries for names in r.ds to the targets of the NS records,
but any queries for names in r.ds which end up at your server will get
handled as described above.
What you probably want to do is add something like the following to the
parent ds zone:
r IN NS stwrdc02.r.ds.
IN NS stwrdc03.r.ds.
stwrdc02.r IN A 192.168.1.1
stwrdc03.r IN A 192.168.1.2
then get rid of the r.ds zone definition on your server.
Your subject line includes private. What is it that's private about this
situation?
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: how to see ALL NS records in a zone file with dig
On Fri, 12 Nov 2010, M. Meadows wrote: If I use dig NS domain name I know I will see the NS records for the domain. I know I can do the same thing for other RR types. In the case where a zone file has RR records that define delegation for subdomains why can't I use this dig command to see those delegations? I assume this is easy and it's just something I've forgotten how to do. Thanks for any help you can provide! Try adding +norec to the dig command to disable recursion by the server: dig +norec -t ns name @server That will get the NS records as known by the parent above the delegation cut, instead of the NS records as known by the child below the delegation cut. Differences in those sets can sometimes be, shall we say, interesting. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple zones pointing to same zone file
On Tue, 19 Oct 2010, John Wingenbach wrote: I know that per Mark Andrews that named does not support having multiple zones pointing to the same zone file. I can understand the issue if named does not support it for a slave server. What about for a master server? Are there any issues with named supporting that? I would assume that whenever the zone file is changed, notifies for each zone utilizing that file would be sent out. Is that correct? Does named support that? If not, are there any plans for named to support having multiple zones utilizing the same zone file? I would prefer to make sure that we are using named in a supported fashion despite that it has been working this way. :) support might a little strong, but it won't cause problems for non-dynamic master zones like it will for slave zones. Dynamic zones will break if you have them share files, just like slave zones will break. Note that notifies are sent when the zone is (re)loaded, not when the associated file changes. You'll have to reload each zone which is based on the file after you change the file. This (along with other things) gets more interesting when you start signing the zones for DNSSEC, but you might be able to play symlink games with the unsigned file names to deal with that. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
more flexible serial number handling in dnssec-signzone
I found myself in need of more flexibility in the way dnssec-signzone handled SOA serial numbers, so I hacked in a way to have the new serial number generated by calling strftime(3) with a user-specified time format. For example dnssec-signzone -N '%Y%m%d1' ... will generate a serial number of the form mmdd1 (e.g., 201010151). The diff files for dnssec-signzone its documentation relative to the 9.7.2-P2 version of BIND are available at (for now anyway): http://seatpost.its.uiowa.edu/bind_stuff I'm a net guy not a programmer, so it's not the best code ever written I didn't increment any of the version headers, but it might be useful to some anyway. ISC folk: Please consider incorporating this or something similar into the stock dnssec-signzone. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
On Wed, 6 Oct 2010, Alex McKenzie wrote: Unfortunately, we do have need -- or at least a use -- to have smaller subnets in multiple files, but without delegating authority. The problem is that some of those small subnets should have a shorter TTL, or other settings changed. If there's a way to change all the settings by host in a single file, that would at least make that easier. You could use one real zone file which is referenced by named.conf, with $INCLUDE directives in that zone file to pull in the parts of the zone from files containing the subsets you want. A $TTL directive at the top of each small file should give you the variable TTL defaulting you want. For larger subnets we can use multiple zones, but I'd hoped to avoid it if possible. It sounds from this like there isn't a way, though. Right. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
On Wed, 6 Oct 2010, Alex McKenzie wrote: Out of curiosity: what if it's a /16 or /8 network? Do those also get built as 24 bit files, or can they be built differently? I seem to recall seeing an option for a reverse lookup file with hosts declared as: x.y PTR host.domain.tld. Does that work, or was that an old format that's been deprecated, or would it never have worked? Sure, that works For the /16 case, define the zone like b.a.in-addr.arpa define records like d.c PTR name. for address a.b.c.d. For the /8 case, define the zone like a.in-addr.arpa define records like d.c.b PTR name. for address a.b.c.d. Note the order of the address components in the zone file, with least significant furthest left. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recover deleted zone file
On Tue, 5 Oct 2010, Jay Moore wrote: I am running BIND 9.4.3-P1 on slackware 12.2. The server is only for internal use. I have accidentally removed one of my zone files, and I have no backup! Is there a way to restore this zone file from the cache? I looked at rndc and named options, but don't see anything that will help? Assuming zone transfers are allowed: dig -t axfr zone_name @127.0.0.1 rescued_zone_file Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Split View DNS
On Thu, 11 Mar 2010, Matus UHLAR - fantomas wrote: On 11.03.10 10:06, Jason Gates wrote: When using split view, can one point to the same file in both views? for master zones, yes, but you will have to reload it in all views explicitly (I think that server reload should take care of that) Right. A server reload will load all zones in all views. You can also reload individual zones in individual zones: rndc reload zone class view such as: rndc reload example.com in internal rndc reload example.com in external to load zone example com in view internal zone example com in view external. For split zones with common data, I like to have a (usually small) zone file for each view with the SOA RR any view-specific data, each including a (usually larger) file of data common to all views. This avoids duplication of data which are supposed to be the same could otherwise get out of sync. The common file doesn't have an SOA RR, so it's not a complete zone file, so you have to refer to the view-specific files for the master files when doing named-checkzone. (Pay attention to the origin in the included file, explicitly specifying it with @ if the first RR applies to the bare zone name.) I use directories for managing the files in each view. On the master: Primary.internal for internal view files Primary.external for external view files Primary.common for files common to both views On the slave: Secondary.internal for internal backup files Secondary.external for external backup files (There is no Secondary.common because the slave tranfers whole zones in each view, having no knowledge of how the zones were assembled on the master.) for slave zones, I'm afraid it's not possible. You will have either to fetch it two times from the master, or fetch from one view to another one... Yes, if you want slaves to have the same split-view behavior, they will need to transfer the zones in all views independently. I use special TSIG keys for this: the slaves use the special key for the view they want to get from the master, while the master uses the special key to present the corresponding view. It's a little complicated, but it does the trick for me. Note that the zones in each view are independent of zones in other views, even if they happen to have the same zone name. The master files are just loaded by named not messed with (unless you're doing dynamic update, in which case what I'm saying might not apply). Thus, you can have multiple zones loaded from the same file on the master. (This applies to other cases than just split-view, such is if you want the same data in multiple IPv6 prefixes because they're laid onto the same net.) The backup files on the slaves are written by named, so each (zone,view) instance has to have its own file. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Differences between 9.3 and later versions
On Tue, 23 Feb 2010, jcarrol...@cfl.rr.com wrote: Due to an security audit I have been given the task of upgrading our BIND from 9.3 to a new version (9.7 is preferred). Using the package from sunfreeware.com (Solaris 10/X86) the upgrade seem to work well. However, whenever someone tries to nslookup (or dig) an external site (i.e. cnn.com) they get REFUSED. If I back down to the 9.3 version all is well. I've tried to find what new security feature is required, but alas I can't seem to get it. What changes affect resolving outside sites? The allow-query* options might be pertinent. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
