Re: minimum cache times?
At Tue, 5 Oct 2010 09:19:49 -0400, Atkins, Brian (GD/VA-NSOC) wrote: I asked a similar question 2 weeks ago and got a non-response (e.g., a response with no real information). From what I've read, everyone seems to frown on over-riding cache times, but I haven't seen any specifics as to why it's bad. Because it's a protocol violation, deliberately ignores the cache time set by the owner of the data, and is dangerous. Eg, you ask me for the address of my web server. I answer, saying that the answer is good for a week, after which you need to ask again because I might have changed something. You override the TTL time and cache the data for two weeks. Meanwhile, I start the process of moving my server to a different address. Protocol says I have to wait the time I set in the TTL, then I can assume that all cached copies of the old data are dead, at which point it's safe for me to kill the old address. But you're ignoring the TTL. So I go ahead and move my server, your users still see your past-expiration copy of the old address, can't reach my server, and my help desk phone starts ringing. Your fault, but I pay for it, because you violated the protocol. The above is a simple example. For some real fun, throw DNSSEC into the mix and think about signature expiration times. min-ttl is a really bad idea. I first saw it proposed in the late '80s. It was a bad idea then, and it's still a bad idea now. Every few years somebody exhumes it, it lurches, undead, into some patch set, and we replay this discussion again. Most likely the reason you didn't get an immediate response is simply that playing whack-a-zombie gets old after the first decade or so. The TTL mechanism is part of the protocol for a reason: it's to control how tightly consistent the data are supposed to be in the opinion of the publisher of the data. Nobody but the publisher of the data has enough information to know how long it's safe to keep the data. Some publishers make silly decisions about this setting, which causes other problems, but keeping data past its expiration time is not the answer. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: minimum cache times?
At Tue, 5 Oct 2010 10:45:04 -0400, Nicholas Wheeler wrote: I think Brian's OP was about a max-ttl override ... Which is the opposite. The only disadvantages I see is a potential waste of bandwidth (and it violates the protocol). max-ttl is (very) different from min-ttl. max-ttl might (or might not) be a waste of bandwidth, but it can't be a violation of the protocol, because nobody can require you to cache at all, or to preserve your cache across reboots, etc. max-ttl has been around since at least, um, 1985, when I implemented it in a non-BIND iterative resolver to cope with the TTLs that we were receiving from certain badly configured authoritative nameservers. It's not something to use blindly, but it's definitely legal, and is sometimes necessary. The trick with max-ttl is to set it to a sane value for your situation. Eg, an iterative resolver associated with a busy MTA might use a max-ttl setting equal to half of the MTA's queue lifetime, to insure that it tried looking for an updated MX RR at least once before giving up on a message. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
At Fri, 1 Oct 2010 07:05:40 -0600, Nicholas F Miller wrote: It is interesting, when I try an update from a client all I get are denies. When I try an update using nsupdate -g from the DNS server I will get a REFUSED but I will also get a DNS/h...@domain kerb ticket from the keytab. It might be worth watching the Kerberos (UDP port 88) traffic during both exchanges, to see if there are visible differences. Basic capture of Kereberos can tell you a fair amount about principals, realms, and algorithm negotiations. tshark's -K option lets you load keytabs, which in theory might let you peer deeper into the packet, but I've never experimented with that option and don't know if it's useful in this scenario. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: GSS-TSIG and Active Directory
If you're trying to grant update rights to a specific machine (rather than every machine in the realm), something like: grant d...@realm. subdomain dnsname.; might work better, where d...@realm is (eg) the Kerberos principle corresponding to your DC and dnsname is the tree to which you want to grant rights. The $ is a Microsoft-ism. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
Sorry, I spent most of the last two weeks locked in a conference room and mostly off net, still catching up. At Mon, 27 Sep 2010 07:54:54 -0600, Nicholas F Miller wrote: DNS Standard query TKEY 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e Queries 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class IN Additional records 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class ANY Algorithm name: gss-tsig Signature inception: Sep 27, 2010 07:26:04.0 Mountain Daylight Time Signature expiration: Sep 28, 2010 07:26:04.0 Mountain Daylight Time Mode: GSSAPI GSS-API Generic Security Service Application Program Interface OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation) Simple Protected Negotiation negTokenInit mechTypes: 3 items MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5) MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5) MechType: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - User to User) krb5_blob: KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5) Kerberos AP-REQ Realm: FQN of DOMAIN Server Name (Service and Instance): DNS/fqn of the DNS server DNS Standard query response TKEY Queries 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class IN Answers 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class ANY Algorithm name: gss-tsig Signature inception: Dec 31, 1969 17:00:00.0 Mountain Standard Time Signature expiration: Dec 31, 1969 17:00:00.0 Mountain Standard Time Mode: GSSAPI Error: Bad key The nameserver appears to be rejecting the GSSAPI negotiation due to some basic failure, there are too many possibilities (all of which the protocol lumps into BADKEY, sigh) to guess which. In theory named should have logged something like failed gss_accept_sec_context: blah where blah is the output of gss_error_tostring(); if there really is no such message (ie, it's not just lost under all the noise), this may indicate that you're somehow getting an impossible GSSAPI failure, ie, something that we don't ever expect to fail, so we're handling it via a RETERR() wrapper around an API call, or something like that (in which case said error clearly is not impossible and probably needs to be handled differently). The timestamps in the response is just the Unix epoch. I don't recall offhand whether that's what TKEY is supposed to return in this mode if there's no signature, but if not this would be consistent with the theory that something is erroring out early in processing. FWIW, here's the ktpass incantation that's worked for me in the past: C:\ ktpass -out foo.keytab -princ DNS/foo.example@example.org -pass * -mapuser f...@example.org where foo.keytab is the filename for the new keytab, DNS/foo.example@example.org is the principal name, and f...@example.org is the Active Directory user account. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
At Fri, 17 Sep 2010 09:17:09 -0600, Nicholas F Miller wrote: I was wondering if it is possible to use the tkey-gssapi-credential and update-policy on a Windows install of bind. It strikes me that running bind on a Windows server, snapped into the AD it will serve DNS to, should be the easiest way of getting DDNS with update-policy control working. It would be, except for one small problem: the Windows native Kerberos doesn't support GSS-API (or didn't, when last I checked), instead it supports some similar-but-different Microsoft proprietary API whose name has temporarily escaped my memory. So either we would have to hack Windows-specific code here to use Microsoft's API, or we would have to get a Unix-style Kerberos library working on Windows. We spent an insane amount of time banging our head against the latter approach, but never got it to work, for reasons that never made a lot of sense (eg, linking against precompiled MIT Kerberos binaries resulted in binaries that worked fine for everything but GSS-TSIG but failed silently for that, attempting to build MIT Kerberos for Windows from source resulted in Kerberos code that couldn't even kinit, and nobody on the MIT Kerberos project could tell us why). We eventually gave up, because we had deadlines to meet and this configuration (BIND9 running GSS-TSIG on Windows) wasn't on our critical feature list. Am I nuts? Should I just install it on a Linux box and be done? Yes, unless you (or some other brave soul) have the time and energy to get this working on Windows, in which case please tell us what you did (and i will stand you a beer if we ever meet...). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
At Fri, 17 Sep 2010 13:18:42 -0600, Nicholas F Miller wrote: Does anyone have instructions on how to setup a Linux bind server to use GSS-TSIG against an AD? I have found many articles from people having issues with it but none that had good instructions on how to get it working. Last year we played around with it but were having issues getting it to work. kinit would work against the AD on our RHEL bind server but our clients couldn't update their records. Beyond what's already been posted here? Not really. I can perhaps tell you two things that might be useful. 1) The code really does work, honest. I have personally seen it work (in the lab -- my last stint as an operator supporting anything on Windows predated AD) with Windows 2000, Windows 2003 Server, and Windows XP. I have not (yet) personally tested it with anything more recent than that, but unless Microsoft has done something weird (nah) it still should. 2) If you run into problems, the best debugging tools I can recommend are: a) Running named with full debugging (named -g and capture the stderr output somewhere, or do the equivalent with logging options in named.conf); and b) A good packet sniffer watching both DNS and Kerberos traffic. For (b) I recommend Wireshark (or tshark, same difference). You can use some other tool (eg, tcpdump) to capture the dump, but understanding what happened requires an analyzer that do deep insepction of both DNS and Kerberos. Make sure you capture full packets for both Kerberos and DNS, ie, UDP ports 88 and 53 as well as TCP port 53 (Yes, Windows uses all three). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7.0a1 and dnssec-signzone verification
At Wed, 24 Jun 2009 18:23:52 +, Evan Hunt wrote: On Wed, Jun 24, 2009 at 05:45:33PM +0200, holger.zule...@arcor.net wrote: I have some issues with dnssec-signzone under BIND 9.7.0a1. I'm using different algorithms for key- and zone signing keys. You can use multiple algorithms in a zone, but each algorithm must be represented as both KSK and ZSK. If you have an RSASHA1 KSK, an RSAMD5 KSK, an RSASHA1 ZSK and an RSAMD5 ZSK, you'll be fine. But if all your KSKs are RSASHA1 and all your ZSK's are RSAMD5, that's actually a protocol violation. dnssec-signzone should have been complaining all along; it was a bug that it didn't. Evan's rule (that the KSK and ZSK algorithms should match) is correct, but the reasons are a bit (more) complex. The protocol requirement is that every signed RRset in a zone have an RRSIG for each algorithm listed in the zone's DS RRset in the parent. A simpler way of saying this is that every KSK algorithm in a zone must also be a ZSK algorithm. Note that this has nothing to do with the SEP bit in the DNSKEY RRs, only to do with which keys sign which RRsets (the protocol forbids the validator from using the SEP bit). The validator allows ZSK algorithms which are not KSK algorithms, but signing your zone that way leaves you vulnerable to the same algorithm downgrade attack that resulted in the seemingly bizzare protocol requirement noted above. So don't do that. Allowing ZSK algorithms that aren't KSK algorithms is useful during certain transitions, but you don't want verification to rely on mismatched algorithms. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Has PGP key been changed?
At Tue, 26 May 2009 15:12:15 +0200, Adam Tkac wrote: has PGP key been changed? Yes. Current ISC key located on http://oldwww.isc.org/about/openpgp/pgpkey2006.txt has different ID - 1BC91E6C. Would it be possible to publish updated PGP key, please? Sigh. The new key is in the worldwide PGP keyserver system, but yes, the copy on the ISC web site should have been updated. Thanks. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind-9.5 GSS-TSIG and dynamic updates.
At Mon, 9 Feb 2009 20:11:20 -0500, Peter Fraser wrote:
HI All
I have been working to get dynamic updates working with bind-9.5 and
FreeBSD 7 So far I have done the following:
1. COmpiled bind with GSSAPI enabled.
2. Added these to named.conf
options {
...
tkey-gssapi-credential DNS/mydomain.com;
...
};
and
zone mydomain.com {
type master;
file master/mydomain.com;
update-policy {
grant MYDOMAIN.COM ms-subdomain * A;
};
};
zone 1.168.192.in-addr.arpa {
type master;
file master/1.168.192.in-addr.arpa;
update-policy {
grant MYDOMAIN.COM ms-subdomain * PTR;
};
};
3. Created a user in AD called binddns and set the password to never expire.
4. Used ktpass to create the keytab like this:
C:\ ktpass -out krb5.keytab -princ
DNS/binddns.mydomain@mydomain.com -pass * -mapuser
bind...@mydomain.com
5. Copied krb5.keytab to /etc
6. At s point I figured I should be done. Reloaded bind but no updates.
When I run rndc trace, I see this in the logs for the zone
09-Feb-2009 07:36:30.369 dns_zone_dialup: zone atlas.local/IN: notify
= 0, refresh = 0
Is there anything I am leaving out?
Nothing blatant, but I may have missed something. Things to try:
1) Run named -g to get full debugging output during your tests.
2) Try running an update with GSS-TSIG from unix if that's easier than
forcing an update from Windows:
$ kinit
$ nsupdate -g
You will of course have to modify your update-policy to permit
whatever principal you use for this test.
3) tshark is your friend. Make sure you watch port 53 on both TCP and
UDP, as well as port 88 (krb5) on UDP.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND Security Advisory (CVE-2009-0025; Severity: Low)
At Thu, 8 Jan 2009 09:10:42 -0500, David Coulthart wrote: Would someone be able to provide some more details as to what particular configurations of BIND this affects? My interpretation is it only impacts recursive nameservers that have DNSSEC validation enabled. And not even all of those. It only affects DSA signatures (RSA is not affected), and only if an attacker can provoke a rather peculiar error condition. The root problem, which was also behind the recent OpenSSL release, is that a couple of the low-level OpenSSL libcrypto library functions that deal with DSA signatures return a tri-state value rather than a boolean: 1 == success, 0 == bad signature, -1 == other failure (eg, malloc() failure). The corresponding RSA functions return boolean values, this is a peculiarity of the DSA routines. Due to the, um, minimal nature of the OpenSSL internals documentation, a lot of code that calls the OpenSSL DSA was not checking the error returns correctly, and was misinterpreting other errors as success. Among others, affected code included both a few routines in BIND's DNSSEC code and portions of OpenSSL itself (if you look closely at the recent OpenSSL release, you'll see that there were a bunch of little changes in libssl to fix this). So an attacker trying to exploit this vulnerablity would have to provoke an other error while the victim was validating a DSA signature. This is pretty freaking unlikely, hence the Severity: low rating on the BIND security advisory, but as nobody can prove that this can't be done and BIND really wasn't checking the return code correctly, it seemed best to handle the fix as a security issue. Speaking in terms of BIND config options, the dnssec-validation option would need to be set to yes (so just having the default of dnssec-enable set to yes isn't enough to make the server vulnerable). Is this a correct interpretation? Vulnerable in this case means could be tricked into believing DNSSEC signatures that should not have passed validation. That is, we're not talking about named crashing here, we're talking about a security mechanism not working as expected due to a bug. If you don't have DNSSEC validation enabled you presumably have no expectation that DNSSEC signatures will be checked correctly, so, indeed, you are not affected, in that without DNSSEC there are easier ways to feed you bad data. At Fri, 09 Jan 2009 15:37:27 -0500, Steve Shockley wrote: The OpenSSL vulnerability affects DSA and ECDSA certificates; an attacker is able to bypass validation of the certificate. Since DNSSEC uses ECDSA, this means an attacker could use a forged certificate in a man-in-the-middle attack. s/certificate/RRSIG/ (DNSSEC doesn't use certificates). If you're not using DNSSEC, then this vulnerability doesn't really affect you, since you already have no way of knowing if a MITM attack is occurring. Exactly. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9 Kerberos authentication
At Wed, 07 Jan 2009 09:51:07 +1000, Da Rock wrote: I'm trying to find some more clarification on how to use kerberos for dnssec. I thought it may have been possible a while ago, was told there was only tsig, then found a reference to it in the Administrators guide. I've been trying to find a tutorial or howto (or at least something) on google but with no luck at all. Anyone here that could help? You're confusing DNS object security with DNS channel security. There's a (hideously complex) specification for using Kerberos to provide DNS channel security (GSS-TSIG). There is no mechanism for using Kerberos to provide DNS object security (DNSSEC), nor is there likely to be. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Using bind 9.5.0 with Active directory
No obvious reason why it shouldn't work with ms-subdomain. Next step is probably a protocol trace to see what's happening on the wire. wireshark/tshark is pretty good for this kind of analysis. Probably best to run named with -g while you're doing the trace and capture the output as well (if you're not doing that already), since there may be clues in the log that aren't obvious with your normal logging configuration. If possible, do the trace on the same machine that's running named, so that timestamps in packet trace and log will match up. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Using bind 9.5.0 with Active directory
At Fri, 26 Dec 2008 14:28:13 +0100, Nico De Ranter wrote: Dec 26 13:55:33 dns named[8546]: configuring TKEY: not implemented The error suggests that you don't really have GSSAPI enabled (dst_gssapi_acquirecred() returns that error when called with GSSAPI support disabled). Check your build log to make sure that -DGSSAPI was included on the command line when compiling lib/dns/gssapictx.c. If not, you've got some kind of autoconf problem or are specifying the wrong directory for the GSSAPI libraries, so check config.log next to see what happened. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
