In article mailman.2375.1438232213.26362.bind-us...@lists.isc.org,
Mark Andrews ma...@isc.org wrote:
In message 23dee83f-7476-432b-92b9-f8d34d617...@nau.edu, Mathew Ian Eis
writes:
Howdy BIND,
Weve been troubleshooting an issue with iOS print discovery using DNS-SD
for the last
On Jul 30 2015, Barry Margolin wrote:
In article mailman.2375.1438232213.26362.bind-us...@lists.isc.org,
Mark Andrews ma...@isc.org wrote:
[... snip ...]
Then iOS (or the application) is broken. Domain names should always
be compared case insensitively. Please report a bug to the app
vendor
On Thu, Jul 30, 2015 at 05:56:31PM +, Evan Hunt wrote:
On the one hand: No, this is a bug, and I'd appreciate it if you'd
bundle up your named.conf (with key secrets stripped out; you can use
named-checkconf -px to do this automatically) and the details of the query
you sent to
On 7/30/15 10:37 AM, Evan Hunt wrote:
On Thu, Jul 30, 2015 at 10:30:33AM -0700, David Newman wrote:
After that second procedure (and also chown'ing the keyfiles to the bind
user), the command 'dig +dnssec +multi dnskey example.com' gives
different results depending on which nameserver gets the
On Wed, Jul 29, 2015 at 07:29:29PM -0700, David Newman wrote:
It's a static zone. The zone file did not have the key in it.
... oh, it's inline-signing.
Unfortunately, by its nature, inline-signing gives you less direct
control over the signed side of the zone.
There are two ways you can go
On 7/30/15 9:06 AM, Evan Hunt wrote:
On Wed, Jul 29, 2015 at 07:29:29PM -0700, David Newman wrote:
It's a static zone. The zone file did not have the key in it.
... oh, it's inline-signing.
Sorry, I also didn't mention that this is a hidden primary server, which
may be relevant below...
On Thu, Jul 30, 2015 at 10:19:49AM -0700, Carl Byington wrote:
RHEL7/Centos7 now has softhsm v2 available. What about a new pkcs11
provider that is just an interface into openssl?
--enable-native-pkcs11 \
--with-pkcs11=pkcs11-openssl-shim
Bind uses native pkcs11, but the default .so
On Thu, Jul 30, 2015 at 10:30:33AM -0700, David Newman wrote:
After that second procedure (and also chown'ing the keyfiles to the bind
user), the command 'dig +dnssec +multi dnskey example.com' gives
different results depending on which nameserver gets the query:
Hidden primary (not
We have a private internal TLD which I have our resolver pull as a slave zone
to prevent it failing dnssec. It has subdomains and normally our
resolver follows the delegations and resolves those correctly without
needing to pull slave copies.
If I use the option:
attach-cache globalcache;
and
9 matches
Mail list logo
