Domain Name System (DNS) Server (named)

Edit Package bind

Berkeley Internet Name Domain (BIND) is an implementation of the Domain
Name System (DNS) protocols and provides an openly redistributable
reference implementation of the major components of the Domain Name
System. This package includes the components to operate a DNS server.

Refresh
Refresh
Source Files
Filename Size Changed
bind-9.18.15.tar.xz 0005476876 5.22 MB
bind-9.18.15.tar.xz.asc 0000000833 833 Bytes
bind-ldapdump-use-valid-host.patch 0000002541 2.48 KB
bind.changes 0000185383 181 KB
bind.conf 0000000444 444 Bytes
bind.keyring 0000009606 9.38 KB
bind.spec 0000021411 20.9 KB
dlz-schema.txt 0000006292 6.14 KB
dnszone-schema.txt 0000005637 5.5 KB
named.conf 0000000090 90 Bytes
named.root 0000003310 3.23 KB
vendor-files.tar.bz2 0000020221 19.7 KB
Revision 195 (latest revision is 207)
Dominique Leuenberger's avatar Dominique Leuenberger (dimstar_suse) accepted request 1087546 from Jorik Cronenberg's avatar Jorik Cronenberg (jcronenberg) (revision 195)
- Update to release 9.18.15
  Bug Fixes:
  * The max-transfer-time-in and max-transfer-idle-in statements
    have not had any effect since the BIND 9 networking stack was
    refactored in version 9.16. The missing functionality has been
    re-implemented and incoming zone transfers now time out
    properly when not progressing.
  * The read timeout in rndc is now 60 seconds, matching the
    behavior in BIND 9.16 and earlier. It had previously been
    lowered to 30 seconds by mistake.
  * When the ISC_R_INVALIDPROTO (ENOPROTOOPT, EPROTONOSUPPORT)
    error code is returned by libuv, it is now treated as a network
    failure: the server for which that error code is returned gets
    marked as broken and is not contacted again during a given
    resolution process.
  * When removing delegations from an opt-out range,
    empty-non-terminal NSEC3 records generated by those delegations
    were not cleaned up. This has been fixed.
  * Log file rotation code did not clean up older versions of log
    files when the logging channel had an absolute path configured
    as a file destination. This has been fixed.
  Known Issues:
  * Sending NOTIFY messages silently fails when the source port
    specified in the notify-source statement is already in use.
    This can happen e.g. when multiple servers are configured as
    NOTIFY targets for a zone and some of them are unresponsive.
    This issue can be worked around by not specifying the source
    port for NOTIFY messages in the notify-source statement; note
    that source port configuration is already deprecated and will
    be removed altogether in a future release.
Comments 2


openSUSE Build Service is sponsored by