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.
- Devel package for openSUSE:Factory
-
17
derived packages
- Links to openSUSE:Factory / bind
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout network/bind && cd $_
- Create Badge
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 371 (latest revision is 388)
Jorik Cronenberg (jcronenberg)
committed
(revision 371)
- 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 0