Re: response case in-sensitivity?
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 several weeks. We made a little bit of a breakthrough this evening when we observed in a packet trace that the response case was fully lowercase, regardless of the query case. It seems iOS is doing some kind of case sensitive comparison between the query and the response, causing DNS-SD to fail when they dont match. Then iOS (or the application) is broken. Domain names should always be compared case insensitively. Please report a bug to the app vendor and / or Apple. Isn't this the DNS 0x20 security enhancement? Clients send a random mix of case, and check that the response matches, to protect against spoofed responses. https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 -- Barry Margolin Arlington, MA ___ 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: response case in-sensitivity?
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 and / or Apple. Isn't this the DNS 0x20 security enhancement? Clients send a random mix of case, and check that the response matches, to protect against spoofed responses. https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 You must distinguish between the copy of the query in the reply packet, which BIND (like nearly all implementations) does copy exactly from the query, and the owner field used in the answer section, which recent versions of BIND make the same as that loaded from zone file (when authoritative), or as received from an authoritative nameserver (when from the cache). -- Chris Thompson Email: c...@cam.ac.uk ___ 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: REQUIRE(rdataset-rdclass == db-rdclass) failed
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 bind9-b...@isc.org. On the other hand: I don't see why you'd want to share a cache between two views if only one of them has access to the internal TLD. I submitted the bug report and it's ISC-Bugs #40205. I only have one view for in; the reason I am using views is to make chaos bind queries work for specific client IPs only. I don't want to waste a bunch of memory doing that if I don't have to - so I put in the shared cache option. Taking it out means I have to go back and do my sums again to work out what max cache sizes and number of clients to specify. Thanks, Maria ___ 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: do not stupidly delete ZSK files
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 query: Hidden primary (not authoritative for this zone): Key still in zone ... sorry, I'm confused. Which of the servers is doing the signing? This hidden primary nameserver does the signing. The zones I've created list only the secondary nameservers -- the ones that get zone transfers from this hidden primary -- as authoritative. Most zones have four authoritative nameservers, only one of which I manage. Of the three I don't manage, I'm pretty sure at least two have no DNSSEC-specific configuration -- a hint that any DNSSEC records they serve come from this hidden primary. Make sense? If not, please let me know what other info you need. dn ___ 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: do not stupidly delete ZSK files
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 go: First, since this appears to be an example zone, you could blow away the signed zone entirely: rm -f example.com.db.signed.*. Start named over again and it'll recreate the signed zone from scratch, this time without the key in it. Or second, if it's important to preserve the signed zone, then you can create new key files from the zone contents, then set the broken key to be deleted while other keys remain in place. $ cd /tmp $ dig @localhost dnskey example.com | dnssec-importkey -f - example.com $ dnssec-settime -D now Kexample.com.+007+36114.key $ mv Kexample.com.+007+35114.* /path/to/key/directory $ rndc loadkeys example.com dnssec-importkey creates a pair of key files containing the public key, but with the private key data omitted; named can't use it for signing data, but it can use it for determining what changes to make in the DNSKEY rrset. dnssec-settime sets the timing metadata for the key so that named will delete it next time it reads the key file. rndc loadkeys tells it to read the file. The key should be deleted from the zone now, and you can remove the key files safely. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: do not stupidly delete ZSK files
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... 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 go: First, since this appears to be an example zone, you could blow away the signed zone entirely: rm -f example.com.db.signed.*. Start named over again and it'll recreate the signed zone from scratch, this time without the key in it. Or second, if it's important to preserve the signed zone, then you can create new key files from the zone contents, then set the broken key to be deleted while other keys remain in place. $ cd /tmp $ dig @localhost dnskey example.com | dnssec-importkey -f - example.com $ dnssec-settime -D now Kexample.com.+007+36114.key $ mv Kexample.com.+007+35114.* /path/to/key/directory $ rndc loadkeys example.com dnssec-importkey creates a pair of key files containing the public key, but with the private key data omitted; named can't use it for signing data, but it can use it for determining what changes to make in the DNSKEY rrset. dnssec-settime sets the timing metadata for the key so that named will delete it next time it reads the key file. rndc loadkeys tells it to read the file. The key should be deleted from the zone now, and you can remove the key files safely. Thanks for this. 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 authoritative for this zone): Key still in zone Authoritative server for zone: Key not in zone Google's recursive server: Key not in zone Even after moving those 36114 key files into another directory and rerunning 'rndc loadkeys example.com', the hidden primary still thinks 36114 is a valid key for this zone. Is there some other step needed to remove it on the hidden primary? Thanks again! dn ___ 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: running named built with --enable-native-pkcs11 without HSM provider library
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 it loads just redirects all the calls into openssl. That in fact is exactly what SoftHSMv2 does. Bind will ask it to generate keys, and will assume that that provider will keep the private key part. So we still don't end up with the original /var/named/K*.private files. Technically you still have the files, but instead of the files containing private key material themselves, they have indentifiers to tell the HSM (or pseudo-HSM) which key is to be used. Well, this new provider is *only* used by bind, so it could run under the bind user account, have selinux access to /var/named, and keep its private key data in files, possibly in a new /var/named/pkcs11-openssl- shim directory. With this scheme, we would not need the -pkcs11 rpm subpackages, but could use /etc/sysconfig/named to control the switch between providers. Better than just replicating the behavior of SoftHSMv2 would be a shim that can switch between multiple PKCS#11 providers. You'd build BIND to link to the shim provider. The shim in turn could pass along PKCS#11 calls to either SoftHSM or some other HSM, depending on the key. Then for example, you could use a KeyPer (slow but very secure) for certain high value keys but use software crypto (much faster but less secure) for others. This has been on our to-do list for some time but other items have taken priority. Does redhat want to write (or fund the writing of) such a shim provider? We'd certainly be happy for any assistance. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: do not stupidly delete ZSK files
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 authoritative for this zone): Key still in zone ... sorry, I'm confused. Which of the servers is doing the signing? eh ___ 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
REQUIRE(rdataset-rdclass == db-rdclass) failed
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 query a subdomain then named dies with the error: general: critical: db.c:767: REQUIRE(rdataset-rdclass == db-rdclass) failed general: critical: exiting (due to assertion failure) So far my server is running fine once I remove 'attach-cache globalcache;'. Is this a known issue with internal private TLDs and I should just give up on using a shared cache? Getting rid of our internal domain is a huge undertaking which won't be completed any time soon. Thanks, Maria ? ___ 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
