BIND 9.7.3 Release Notes HP-UX 11i v3 (761997-001, January 2014)

For this purpose the ‘attach-cache’ option was introduced in named.conf which takes the
cache_name as value. The cache name is the name of the first view whose cache needs to be
shared.
DNS rebinding attack prevention
In the DNS rebinding attack, the embedded web code (responsible for fetching web content) of a
malicious webpage queries the attackers DNS server for a domain that resolves to an IP address
internal to the victim’s domain. The resolved IP address could be the IP address of a machine that
stores sensitive data. The attack enables the attacker to bypass the firewall security.
To prevent this attack, BIND 9.7 introduces two new options which are deny-answer-addresses
and deny-answer-aliases with an except-from exclusion list.
deny-answer-addresses discards any response that resolves to an IP address which matches
the address-match-list specified and deny-answer-aliases discards if the name-list specified by it
matches any CNAME or DNAME alias in the response.
New default values for dnssec-keygen parameters
Without arguments, dnssec-keygen will now generate a 1024-bit RSASHA1 zone-signing
key, or with the -f KSK option, a 2048-bit RSASHA1 key-signing key.
Support for RFC 5011 automated trust anchor maintenance
BIND-9.7 allows named to keep track of changes to critical DNSSEC keys without any need for
the operator to make changes to configuration files. For this, managed-keys statement was
introduced in named.conf.
Prior to BIND 9.7, trust –anchors had to be maintained manually, which has risk in the scenario
when the zones KSK are compromised. In this case the zone operator would immediately replace
the existing KSK with a new one. This resolver still has the old KSK as trust anchor, which would
result in all of its queries for the secure domain to fail with SERVFAIL. This would continue until the
trust anchor is updated.
But with RFC 5011 support, the resolver would monitor the trust anchors for new additions of trust
anchors. A new trust-anchor would indicate the wish of the zone operator to change the current
trust-anchor. This would be noted by the resolver and when the original trust-anchor is revoked,
named smoothly transitions to the new trust-anchors, thus avoiding SERVFAIL. All this can be availed
simply by mentioning the zones name in managed-keys statement.
Smart signing: simplified tools for zone signing and key maintenance
Using this feature it is not required to manually insert the public keys into the zone files. The
‘dnssec-signzone –S’ now analyses the key timing metadata and takes decisions what to do
with the keys. The action could be to publish / sign with / revoke / delete.
After revoking an active key, the zone must be signed with both the revoked KSK and the new
active KSK. (Smart signing takes care of this automatically)
Named and other binaries can now print out a stack backtrace on assertion
failure, to aid in debugging
named and other BIND executables will log or print out a stack backtrace on assertion failures.
This can be used in debugging issues with the BIND code.
Full NSEC3 support
The drawback of NSEC was that its proof of non-existence would reveal the zone names which
allowed for zone enumeration. The technique to prevent is called NSEC3. In this the domain names
DNS rebinding attack prevention 7