Re: BIND Security Advisory (CVE-2009-0025; Severity: Low)
On Jan 7, 2009, at 2:32 PM, rob_aust...@isc.org wrote: Internet Systems Consortium Security Advisory. BIND: EVP_VerifyFinal() and DSA_do_verify() return checks. 7 January 2009 Versions affected: BIND 9.0 (all versions) BIND 9.1 (all versions) BIND 9.2 (all versions) BIND 9.3.0, 9.3.1, 9.3.2, 9.3.3, 9.3.4, 9.3.5, 9.3.6 BIND 9.4.0, 9.4.1, 9.4.2, 9.4.3 BIND 9.5.0, 9.5.1 BIND 9.6.0 Severity: Low. Description: Return values from OpenSSL library functions EVP_VerifyFinal() and DSA_do_verify() were not checked properly. Impact: It is theoretically possible to spoof answers returned from zones using the DNSKEY algorithms DSA (3) and NSEC3DSA (6). Would someone be able to provide some more details as to what particular configurations of BIND this affects? My interpretation is it only impacts recursive nameservers that have DNSSEC validation enabled. Speaking in terms of BIND config options, the dnssec- validation option would need to be set to yes (so just having the default of dnssec-enable set to yes isn't enough to make the server vulnerable). Is this a correct interpretation? Thanks, Dave Coulthart ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Security Advisory: Server Lockup Upon IXFR or DDNS Update Combined with High Query Rate
On Feb 22, 2011, at 3:55 PM, Larissa Shapiro wrote: > Description and Impact: > > When an authoritative server processes a successful IXFR transfer or a > dynamic update, there is a small window of time during which the IXFR/update > coupled with a query may cause a deadlock to occur. This deadlock will cause > the server to stop processing all requests. A high query rate and/or a high > update rate will increase the probability of this condition. Does the "authoritative server that processes an IXFR transfer" refer to: a) the IXFR server? b) the IXFR client? c) both? Thanks, Dave Coulthart ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
IXFR & manually edited zone files
BIND Version: 9.7.3 on Solaris 9 & 10 (locally compiled) Our current workflow for managing DNS involves generating master zone files from a database, pushing the new files to a hidden master nameserver & then running "rndc reload" on that nameserver. Based on the ARM & a posting to bind-users[1], I enabled "ixfr-from-differences master;" on the hidden master expecting the master nameserver would generate a "diff" from the previous zone file in memory and the new one being loaded so it could send an IXFR to the slaves. However, every time the slave requests an IXFR, it gets a non-incremental response & has to perform a full AXFR. I've configured this in a test environment with a single zone file so I know the slave has the first version of the zone file before loading the second version on the master & it still results in a AXFR-style IXFR. I've explicitly stated the options allow-query & allow-transfer in the config, but I do not have allow-updates configured, relying on the implicit default of denying all updates. Is there something I'm missing to get this working? Thanks, Dave Coulthart 1. https://lists.isc.org/pipermail/bind-users/2010-January/078591.html ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IXFR & manually edited zone files
On Mar 7, 2011, at 11:42 AM, Chris Thompson wrote: > On Mar 7 2011, David Coulthart wrote: >> BIND Version: 9.7.3 on Solaris 9 & 10 (locally compiled) >> >> Our current workflow for managing DNS involves generating master zone >> files from a database, pushing the new files to a hidden master nameserver >> & then running "rndc reload" on that nameserver. >> >> Based on the ARM & a posting to bind-users[1], I enabled >> "ixfr-from-differences >> master;" on the hidden master expecting the master nameserver would generate >> a "diff" from the previous zone file in memory and the new one being loaded >> so it could send an IXFR to the slaves. However, every time the slave >> requests an IXFR, it gets a non-incremental response & has to perform a >> full AXFR. I've configured this in a test environment with a single zone >> file so I know the slave has the first version of the zone file before >> loading the second version on the master & it still results in a AXFR-style >> IXFR. I've explicitly stated the options allow-query & allow-transfer >> in the config, but I do not have allow-updates configured, relying on >> the implicit default of denying all updates. >> >> Is there something I'm missing to get this working? > > Have you tested that the ixfr-from-differences is working at all at > the hidden master? E.g. by > > dig ixfr=[some-old-serial] [zone-name] @[hidden-master] > > from the slaves (or indeed elsewhere). In my initial testing I enabled debug level 3 on both the master & slave. In the slave's log I saw the following: transfer of 'example.com/IN' from 128.59.59.124#53: requesting IXFR for serial 2011030701 transfer of 'example.com/IN' from 128.59.59.124#53: sent request length prefix transfer of 'example.com/IN' from 128.59.59.124#53: sent request data transfer of 'example.com/IN' from 128.59.59.124#53: got nonincremental response I just tested again using dig as you described above and still got a full AXFR even when specifying the serial # that was in the zone file before the reload. From the master's log: client 127.0.0.1#34246: zone transfer 'example.com/IXFR/IN' approved client 127.0.0.1#34246: transfer of 'example.com/IN': AXFR-style IXFR started client 127.0.0.1#34246: transfer of 'example.com/IN': AXFR-style IXFR ended > There is also a named-journalprint utility which you can apply to the > journal file on the master to check it contains what you hope for. I don't see a journal file being created on the master after I do the reload. The only messages in the master's log about a journal are on initial startup: zone example.com/IN: starting load zone example.com/IN: number of nodes in database: 256 no journal file, but that's OK zone example.com/IN: journal rollforward completed successfully: no journal zone example.com/IN: loaded decrement_reference: delete from rbt: 2468d0 example.com zone_settimer: zone example.com/IN: enter zone example.com/IN: loaded serial 2011030701 On rndc reload, I don't see any mention of a journal being created or destroyed: zone example.com/IN: starting load dns_zone_maintenance: zone example.com/IN: enter zone_settimer: zone example.com/IN: enter zone_loaddone: zone example.com/IN: enter zone example.com/IN: number of nodes in database: 766 zone example.com/IN: loadeddecrement_reference: delete from rbt: 246ed0 example.com replacing zone database calling free_rbtdb(example.com) adjust_quantum -> 325 zone_settimer: zone example.com/IN: enter zone example.com/IN: loaded serial 2011030702 done free_rbtdb(example.com) Based on the description of ixfr-from-differences in the ARM, I think a journal file should be created. I have named running as user named, but I've checked permissions on the directory & zone file & confirmed that named can create files in the directory containing the zone file. > If those look OK, then it's something else in the configuration of > either master or slaves. I take it you aren't doing anything as > obvious as specifying "request-ixfr no" or "provide-ixfr no" in > server statements. I do not explicitly set these options in my config, relying on them defaulting to yes. Thanks for your help Chris. Dave Coulthart ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IXFR & manually edited zone files
On Mar 7, 2011, at 12:24 PM, David Coulthart wrote:
> On Mar 7, 2011, at 11:42 AM, Chris Thompson wrote:
>> On Mar 7 2011, David Coulthart wrote:
>>> BIND Version: 9.7.3 on Solaris 9 & 10 (locally compiled)
...
>>> Based on the ARM & a posting to bind-users[1], I enabled
>>> "ixfr-from-differences
>>> master;" on the hidden master expecting the master nameserver would generate
>>> a "diff" from the previous zone file in memory and the new one being loaded
>>> so it could send an IXFR to the slaves.
...
>> There is also a named-journalprint utility which you can apply to the
>> journal file on the master to check it contains what you hope for.
>
> I don't see a journal file being created on the master after I do the reload.
> The only messages in the master's log about a journal are on initial startup:
...
> Based on the description of ixfr-from-differences in the ARM, I think a
> journal file should be created. I have named running as user named, but I've
> checked permissions on the directory & zone file & confirmed that named can
> create files in the directory containing the zone file.
It looks like the problem is with setting ixfr-from-differences to master. If
I instead set the option to yes, a journal file is generated & IXFR works
correctly. The zone definition in my test named.conf is:
zone "example.com" {
type master;
file "example.com.zone";
};
so I expected setting "ixfr-from-differences master;" would cause a journal
file to be created for this master zone. Am I not understanding what the
master option for ixfr-from-differences is intended to do or is this a bug in
BIND?
Thanks,
Dave Coulthart
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: IXFR & manually edited zone files
On Mar 8, 2011, at 3:44 PM, Mark Andrews wrote: > In message , David > Coulthart > writes: >> It looks like the problem is with setting ixfr-from-differences to master. I >> f I instead set the option to yes, a journal file is generated & IXFR works c >> orrectly. ... >> Is this a bug in BIND? > > Index: bin/named/zoneconf.c > === > RCS file: /proj/cvs/prod/bind9/bin/named/zoneconf.c,v > retrieving revision 1.171.34.2 > diff -u -r1.171.34.2 zoneconf.c > --- bin/named/zoneconf.c 7 Mar 2011 04:16:39 - 1.171.34.2 > +++ bin/named/zoneconf.c 8 Mar 2011 20:44:00 - > @@ -1077,10 +1077,10 @@ > INSIST(result == ISC_R_SUCCESS && obj != NULL); > if (cfg_obj_isboolean(obj)) > ixfrdiff = cfg_obj_asboolean(obj); > - else if (strcasecmp(cfg_obj_asstring(obj), "master") && > + else if (!strcasecmp(cfg_obj_asstring(obj), "master") && >ztype == dns_zone_master) > ixfrdiff = ISC_TRUE; > - else if (strcasecmp(cfg_obj_asstring(obj), "slave") && > + else if (!strcasecmp(cfg_obj_asstring(obj), "slave") && > ztype == dns_zone_slave) > ixfrdiff = ISC_TRUE; > else Thank you very much, Mark. I've confirmed this patch fixes the problem. Thanks, Dave Coulthart ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Better solution than making a recursive nameserver authoritative?
Currently the two recursive caching nameservers for clients on our network are also authoritative for a few zones. In particular, they are authoritative for: 1) our main forward zone (columbia.edu) in order to provide an internal view of the zone 2) RFC 1918 reverse zones (e.g., 10.in-addr.arpa) I would like to follow best practices by separating authoritative & recursive functionality. Also, when I sign these zones, I would like the recursive nameservers to respond with the AD bit set instead of AA. But I'm struggling to find a way to do this with some of the constraints I'm facing: a) I can't move the internal-only RRs into a separate subdomain/zone b) Some of our authoritative secondaries are provided by other institutions that I cannot expect to configure views c) The zones include delegations for subdomains to other nameservers One solution suggested to me is to have our clients point to nameservers that are authoritative for the internal zones & forward all other queries to a new pair of recursive-only caching nameservers. Is this actually better/more secure than our current setup to justify the additional hardware? Also, as best I can tell, when the clients query for data in the internal zones they would still receive responses with the AA bit set instead of the AD bit. I've also considered configuring the internal zones as type forward on the recursive nameservers forwarding to authoritative-only nameservers for the internal zones. The concern I have with this is if I configure a zone on the authoritative nameserver with a delegation to another set of nameservers. If the forward zone on the recursive nameserver is configured with forward only, it will only get the delegation NS RRset & therefore returns a SERVFAIL. If I configure the zone as forward first, the recursive nameserver gets back the NS delegation & then uses that to perform an iterative query against the authoritative nameserver for the subdomain. This actually seems like it might solve my issues. Are there any problems with this setup I'm not seeing (other than the quirk of sending a recursive query to the forwarder when it is authoritative only)? There have been a few other, slightly crazier, ideas I've thought of or have been suggested to me. But I figured I would start with these as they are likely the simplest. However, other recommended solutions are always appreciated. Thanks, Dave C. ___ 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: Better solution than making a recursive nameserver authoritative?
On Jun 24, 2011, at 3:33 PM, Phil Mayers wrote:
> On 06/24/2011 06:39 PM, David Coulthart wrote:
>
>> configure the zone as forward first, the recursive nameserver gets
>> back the NS delegation& then uses that to perform an iterative query
>> against the authoritative nameserver for the subdomain. This
>> actually seems like it might solve my issues. Are there any problems
>> with this setup I'm not seeing (other than the quirk of sending a
>> recursive query to the forwarder when it is authoritative only)?
>
> forward first is the wrong tool; if the upstream nameservers are down (or
> fail to answer) it'll go to the internet, which you don't want.
This was what I was worried might happen with forward first. Thank you for
confirming.
> static-stub, introduced in bind 9.8 are what you want (see below)
>
>> There have been a few other, slightly crazier, ideas I've thought of
>> or have been suggested to me. But I figured I would start with these
>> as they are likely the simplest. However, other recommended
>> solutions are always appreciated.
>
> "type static-stub". These are designed for this purpose - they send
> non-recursive queries to the server-{addresses,names} you define, and will
> honour delegations, as opposed to forward zones that send recursive queries
> and expect a full reply.
I was wondering about static-stub. Based on my reading about stub zones, I
thought a (static) stub zone would cause my recursive nameserver to return
answers for the stub zone with the AA bit set. I thought a stub zone was like
a "mini-slave" zone where the nameserver doesn't have a local copy of the zone
file but will answer authoritatively after directly querying the authoritative
nameserver.
However, testing reveals that, as you describe, this does do exactly what I
want. Configuring my recursive name server with a static-stub zone, it sends a
non-recursive query to the specified server-address & iteratively follows the
delegation & returns an answer to the original client without the AA bit set.
Also, I see from the decreasing TTL when I repeat the query that the recursive
nameserver is indeed answering from cache.
> I didn't really understand why you needed or thought you needed views, so if
> you can expand, possibly people can give you a fuller answer.
For the RFC 1918 reverse zones I don't really need views as I could just
restrict allow-query in those specific zones to our local networks on our
authoritative nameservers. However, if I don't want my recursive nameservers
to be authoritative for those RFC 1918 zones, I do need some way to configure
them to use my authoritative nameservers for those zones instead of the ones
listed in the delegation NS RRsets in the in-addr.arpa zone. It looks like
static-stub will solve this problem.
For my forward zones, this is where I end up needing views on my authoritative
nameservers. The reason we use views today is for the external world we want
www.columbia.edu to be a CNAME pointing to an Akamai service that fails over to
backup content on their servers if our Internet connection goes down. For
users on our network, we want www.columbia.edu to always point directly to our
local load balancer, so that if our Internet connection goes down they can
still get to our home page (e.g., for emergency announcements).
Additionally, a "problem" with our current zone data is we publish records in
our external forward zones that point to RFC 1918 IP addresses. For example,
there is the server foobar.columbia.edu with a public IP address but it also
has an IP accessible console at foobar-console.columbia.edu with a RFC 1918 IP
address b/c it should only be accessible from within our network. Currently,
both of those A records are in both our external & internal views for the
columbia.edu zone. Since I already need two separate views for the reason
given above, I was hoping to clean this up as well and only publish the
foobar-console.columbia.edu A RR in the internal view of columbia.edu while
foobar.columbia.edu would be in both views.
However, as I originally described, not all of our authoritative nameservers
are completely under my control, so I can't configure them all with the two
views. So I need a way to force our local recursive nameservers to only use
those authoritative nameservers that have both views. Again, static-stub looks
like it will do this nicely.
If there are ways to achieve the same results for my forward zones without
views, I would love to know them.
Also, are there any caveats I should be aware of using static-stub?
Thanks,
Dave C.
___
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: avoid-v4-udp-ports ineffective? (BIND 9.8.1-P1)
On Nov 17, 2011, at 6:28 PM, Mark Andrews wrote:
> In message <20171600.pahg0ucw011...@scramble.princeton.edu>, Irwin
> Tillman writes:
>> It appears that named is trying to use ports I've mentioned in
>> avoid-v4-udp-ports.
>>
>> Platform: BIND 9.8.1-P1 on Solaris 10 / SPARC
>>
>> On some of the ports which BIND might otherwise choose to use,
>> I have other daemons running and/or the OS treats the ports
>> as privileged. To keep named from trying to use those ports, I have
>> in named.conf:
>>
>> options {
>>...
>># there is no use-v4-udp-ports statement.
>>avoid-v4-udp-ports { 1812; 1813; 2049; 4045; };
>># I don't speak v6.
>> };
>>
>> When I upgraded from BIND 9.7.3-P3 to 9.8.1-P1, I began seeing in the log:
>>
>> named[9185]: dispatch: warning: dispatch 42d950: open_socket(::#2049) ->
>> permission denied: continuing
>> named[9185]: dispatch: warning: dispatch 42d950: open_socket(::#4045) ->
>> permission denied: continuing
>>
>> ...which suggests to me that BIND is trying to use ports I specified in
>> avoid-v4-udp-ports.
>>
>>
>> Checking get_dispsocket() in ./lib/dns/dispatch.c, I see that a difference
>> between 9.7.3-P3 and 9.8.1-P1 is that 9.8.1-P1 logs a warning when an attempt
>> to open the socket returns ISC_R_NOPERM (perhaps the result of bind()
>> returning EACCESS ?),
>> while 9.7.3-P3 didn't log the warning. The warning is new.
>> When confronted with the error, both versions proceed to pick another port
>> to try again.
>> So I don't know if the older version was also trying to use these ports and
>> encountering
>> the same error.
>>
>> I imagine Solaris might return EACCESS because:
>>
>> % ndd /dev/udp udp_extra_priv_ports
>> 2049
>> 4045
>>
>>
>> I don't understand why named would try to use these ports in the first
>> place as they appear in avoid-v4-udp-ports.
>
> The "::" in the log message is the IPv6 equivalent of 0.0.0.0 in IPv4.
> You machine *is* dual stacked even if it only has IPv6 on loopback.
I noticed this same log message on our Solaris 9 servers and I don't see IPv6
enabled on any of our interfaces, including loopback:
$ /sbin/ifconfig -a inet6
$ /sbin/ifconfig -a inet
lo0: flags=1000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff00
bge0: flags=1000843 mtu 1500 index 2
inet 128.59.59.92 netmask ff00 broadcast 128.59.59.255
bge0:10: flags=1000843 mtu 1500 index 2
inet 128.59.59.70 netmask ff00 broadcast 128.59.59.255
It's not a big deal for me as it doesn't happen very often (& can be easily
avoided by setting a matching avoid-v6-udp-ports), but it did surprise me.
Thanks Irwin for the tip on ndd. I had to avoid those exact same ports & I
couldn't find a process bound to port 2049 causing it.
--
Dave Coulthart
___
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: ISC BIND 9.6.1-P3 is now available
On Jan 19, 2010, at 12:28 PM, Evan Hunt wrote: BIND 9.6.1-P3 is a SECURITY PATCH for BIND 9.6.1. It addresses two potential cache poisoning vulnerabilities, both of which could allow a validating recursive nameserver to cache data which had not been authenticated or was invalid. Do these vulnerabilities only apply to recursive name servers that have DNSSEC trusted keys or lookaside keys configured? Or do they also apply if the server has dnssec-enable & dnssec-validation enabled (as by default on 9.6.x) but no trusted keys or lookaside keys configured? Thanks, Dave Coulthart ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
