Re: Bind not starting
On Fri, Oct 01, 2010 at 09:44:42AM +0530, rams brames...@gmail.com wrote a message of 300 lines which said: But bind is started successfully when commented below ns domains which are marked as RED. Some people are color-blind and some do not use a Web browser to read email. Using colors on a technical list is a really bad idea. zone nsdomain.com/IN: NS 'ns1.nsdomain.com' has no address records (A or ) It is true: you configure name servers for nsdomain.com which are themselves inside the nsdomain.com zone but these name servers appear nowhere. You have to add address records (A or records with the addresses of these in-zone name servers). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind not starting
On Fri, Oct 01, 2010 at 09:44:42AM +0530, rams brames...@gmail.com wrote a message of 300 lines which said: But bind is started successfully when commented below ns domains which are marked as RED. On 01.10.10 08:57, Stephane Bortzmeyer wrote: Some people are color-blind and some do not use a Web browser to read email. Using colors on a technical list is a really bad idea. using HTML mail is a bad idea, especially on mailing lists :-) zone nsdomain.com/IN: NS 'ns1.nsdomain.com' has no address records (A or ) It is true: you configure name servers for nsdomain.com which are themselves inside the nsdomain.com zone but these name servers appear nowhere. You have to add address records (A or records with the addresses of these in-zone name servers). Every NS record must poing to name that has A and/or records. The NS record for the zone itself must also have same NS records in the parent zone, together with A records if NS point to the zone. They are called glue records and are required for DNS traversal. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The box said 'Requires Windows 95 or better', so I bought a Macintosh. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone-recursion?
On 1/10/10 9:15 AM, Joerg Dorchain jo...@dorchain.net wrote: On Thu, Sep 30, 2010 at 07:13:11PM -0400, Kevin Darcy wrote: Per-zone recursion control doesn't exist in BIND, because frankly it doesn't make sense. I used to think that, too, until I came to my specific problem. Either a zone type is meaningless *without* recursion (type forward, type stub), or recursion is *unnecessary* because the nameserver answers from authoritative data (type master, type slave). Exactly. Up to here I completely agree. Put another way, have you thought through exactly what you want to happen if a client queries something not specifically carved out for recursion, e.g. isc.org? Yes. To explain my setup further, there is a view based on src-IPs for some clients, where recursion is turned on. The rest of the world gets non-recursive answers, e.g. with authoritative data, or refused. In case of that specfic forward zone, bind answers in the non-recursive case with a referal to itself (there is only one public IP), which is causing a loop, as there is no way to specify a different port in the DNS protocol (AFAIK) This is the problem and the reason I agree with Kevin. The referral is correct behaviour. Your DNS set up is wrong. You have 2 choices and a third less palatable option: 1. Make the other DNS software available on another IP. So normal DNS behaviour works. 2. Add the zone as a slave within your authoritative view. (this option may be the easiest for your situation). 3. recursive view with forwards to both your authoritative view and the dynamic subdomain. I think this solution is silly and will be problematic to maintain, but its likely to suite your needs exactly. The response from a BIND instance, when recursion is denied or not requested, is always either (as per Section 4.3.1 of RFC 1034): a) an answer from authoritative data, b) an answer from cache c) a negative-caching response, d) a (0 answers) referral, or e) some sort of non-response, like an error (SERVFAIL) or an administrative rejection of the query (REFUSED) If (a) doesn't apply (because not authoritative) and neither does (b) (because how can answers be cached in the first place if recursion is being denied?), that leaves (c) through (e), none of which are particularly useful to the client. So you might as well REFUSE queries outside of zones for which recursion is not explicitly enabled. Configure allow-query { none; }; as the default followed by specific exceptions for the zones you want to open up, e.g., dynsup.example.net. You have summarized my thoughts very well. At this point I found out that the current grammar for bind does not allow to combine type forward; with an allow-query (or allow-recursion). A quick look at the sources also showed that forward zones are implemented differently than real zones like master or slave. This way I came to the point where I am wondering if it is possible to configure bind either - do recursion on a per-zone base for forward zones, as the currently implemented criteria (src-ip, dst-ip, recursion flag) do not cover my case in an obvious way - forward queries to a specific destination and the answers back, acting as a reverse-proxy without too much intelligence. Bye, Joerg ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
nsupdate
An observation in nsupdate: Suppose we have two A records as , *addforixfr.bind9712.com. 3456 IN A 10.32.21.30* *addforixfr.bind9712.com. 3456 IN A 10.32.21.20* When we update TTL value as below for one of the records , the TTL value changes for both the records. *update add addforixfr. bind9712.com 8564 A 10.32.21.30* * * [root@ zones]# dig @ addforixfr.bind9712.com ; DiG 9.2.4 @ addforixfr.bind9712.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 15707 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 0 ;; QUESTION SECTION: ;addforixfr.bind9712.com. IN A ;; ANSWER SECTION: *addforixfr.bind9712.com. 8564 IN A 10.32.21.20* *addforixfr.bind9712.com. 8564 IN A 10.32.21.30* ;; AUTHORITY SECTION: bind9712.com. 86400 IN NS ns3.bind9712.com. bind9712.com. 86400 IN NS ns4.bind9712.com. bind9712.com. 86400 IN NS ns5.bind9712.com. bind9712.com. 86400 IN NS ns1.bind9712.com. bind9712.com. 86400 IN NS ns2.bind9712.com. ;; Query time: 1 msec ;; SERVER: 10.31.142.24#53(10.31.142.24) ;; WHEN: Mon Mar 15 02:53:32 2010 ;; MSG SIZE rcvd: 163 Please clarify me. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nsupdate
On Fri, Oct 01, 2010 at 02:58:28PM +0530, rams brames...@gmail.com wrote a message of 240 lines which said: Suppose we have two A records as , These two records have the same {name, class, type} and therefore belong to the same RRset (Resource Record Set). When we update TTL value as below for one of the records , the TTL value changes for both the records. Which is expected since all the members of a RRset share the same TTL value. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone-recursion?
On Fri, Oct 01, 2010 at 11:25:31AM +0200, Kalman Feher wrote: Yes. To explain my setup further, there is a view based on src-IPs for some clients, where recursion is turned on. The rest of the world gets non-recursive answers, e.g. with authoritative data, or refused. In case of that specfic forward zone, bind answers in the non-recursive case with a referal to itself (there is only one public IP), which is causing a loop, as there is no way to specify a different port in the DNS protocol (AFAIK) This is the problem and the reason I agree with Kevin. The referral is correct behaviour. Your DNS set up is wrong. You have 2 choices and a third Well, I could agree agree that wrong means not thought of by RfC-Designers and bind implementators (yet). less palatable option: 1. Make the other DNS software available on another IP. So normal DNS behaviour works. Hm, this is not too easy in practice, but of course optimal solution. IPv6 will help here, I hope. 2. Add the zone as a slave within your authoritative view. (this option may be the easiest for your situation). Not feasible as it contains dynamically generated content, typically with a TTL of 0. 3. recursive view with forwards to both your authoritative view and the dynamic subdomain. I think this solution is silly and will be problematic to maintain, but its likely to suite your needs exactly. Hm, I have to think about that. As said, I do not want to give recursive answers to the whole world. It sounds like a hack, though. The more I am into the problem, the more I come to the point where I like to have some sort of query switch, i.e. something that redirects queries for a certain domain to one address, and other queries to other servers. It would be great if it would be part of bind. Bye, Joerg signature.asc Description: Digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: GSS-TSIG and Active Directory
Yea, it seems that people got it working when the functionality came out but subsequently I haven't seen it working for anyone in a production environment. _ Nicholas Miller, ITS, University of Colorado at Boulder On Sep 30, 2010, at 3:24 PM, Dave Knight wrote: On 2010-09-30, at 11:24 AM, Nicholas F Miller wrote: Does anyone actually have GSS-TSIG working with an Active Directory? I see plenty of posts from people trying to get it to work. I have yet to see anyone who claims to actually have it working. Did MS change something in 2008r2 since GSS-TSIG was implemented in bind to make it inoperable? Right after GSS-TSIG appeared I built a lab for the purpose of demonstrating and documenting a working setup. That lab contained a couple of W2k3 servers, XP clients and BIND servers running on FreeBSD. I went from bare iron to a working W2k domain using BIND+GSS-TSIG exclusively for name service. As I recall I did the initial population of the zone used for the W2k domain without security enabled, ie: I informed the Windows machine that the BIND server was to be used and configured the BIND server to allow updates from the Windows server on the basis of its IP address, then ran dcpromo.exe to create the domain, then did the necessary Kerberos bits, then locked down the BIND server to henceforth accept only GSS-TSIG authenticated updates. I haven't touched this stuff since though, so I have nothing to say about how it might work with contemporary Windows and BIND versions. dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: GSS-TSIG and Active Directory
Thanks, I'll give it a try and see if things begin to work. _ Nicholas Miller, ITS, University of Colorado at Boulder On Sep 30, 2010, at 10:15 AM, Tony Finch wrote: On Thu, 30 Sep 2010, Nicholas F Miller wrote: Does anyone actually have GSS-TSIG working with an Active Directory? There are some GSS-TSIG interop fixes in 9.7.2. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
That is how I created my keytab as well. 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. _ Nicholas Miller, ITS, University of Colorado at Boulder On Sep 30, 2010, at 4:00 PM, Rob Austein wrote: 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
Where is managed-keys.bind ?
Hello bind-users, Today I jumped from BIND 9.6.2 to 9.7.2-P2 Seems to be ok, except: Oct 1 08:30:19 stroph named[24453]: set up managed keys zone for view _default, file 'managed-keys.bind' Oct 1 08:30:19 stroph named[24453]: managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found Oct 1 08:30:19 stroph named[24453]: managed-keys-zone ./IN: loaded serial 0 We do not sign (yet) our zones with DNSSEC, is it safe to turn off dnssec-lookaside, and how ? dnssec-lookaside no ? Any other suggestion ? Thanks in advance, -- ** Magali BERNARD - DSI pôle Système, Réseau et Sécurité Université Jean Monnet de Saint-Étienne - FRANCE - A: Yes. Q: Are you sure ? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email ? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Where is managed-keys.bind ?
On Oct 1 2010, Tony Finch wrote: On Fri, 1 Oct 2010, Magali Bernard wrote: Oct 1 08:30:19 stroph named[24453]: set up managed keys zone for view _default, file 'managed-keys.bind' Oct 1 08:30:19 stroph named[24453]: managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found Oct 1 08:30:19 stroph named[24453]: managed-keys-zone ./IN: loaded serial 0 We do not sign (yet) our zones with DNSSEC, is it safe to turn off dnssec-lookaside, and how ? dnssec-lookaside no ? dnssec-lookaside is off by default, and both DLV and the managed keys zone relate to validation rather than serving signed zones. The managed keys zone is used for RFC 5011 trust anchor rollover which you can use with both DLV (via the dnssec-lookaside auto; setting) and the root trust anchor (which requires a managed-keys clause as below). Bind creates the managed keys zone if it isn't present, and the warning it logs when it does this is benign. Except that it is classified as an error, not a warning. And if you don't have any managed keys, then it won't create the file, and so will complain again the next time BIND is restarted. An empty file managed-keys.bind in BIND's working directory will get it to shut up. -- Chris Thompson Email: c...@cam.ac.uk ___ 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: Where is managed-keys.bind ?
On Oct 1 2010, Tony Finch wrote: On Fri, 1 Oct 2010, Magali Bernard wrote: Oct 1 08:30:19 stroph named[24453]: set up managed keys zone for view _default, file 'managed-keys.bind' Oct 1 08:30:19 stroph named[24453]: managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found Oct 1 08:30:19 stroph named[24453]: managed-keys-zone ./IN: loaded serial 0 We do not sign (yet) our zones with DNSSEC, is it safe to turn off dnssec-lookaside, and how ? dnssec-lookaside no ? dnssec-lookaside is off by default, and both DLV and the managed keys zone relate to validation rather than serving signed zones. The managed keys zone is used for RFC 5011 trust anchor rollover which you can use with both DLV (via the dnssec-lookaside auto; setting) and the root trust anchor (which requires a managed-keys clause as below). Bind creates the managed keys zone if it isn't present, and the warning it logs when it does this is benign. Except that it is classified as an error, not a warning. And if you don't have any managed keys, then it won't create the file, and so will complain again the next time BIND is restarted. An empty file managed-keys.bind in BIND's working directory will get it to shut up. Thanks a lot ! I did: touch managed-keys.bind and now BIND is silently working. -- ** Magali BERNARD - DSI pôle Système, Réseau et Sécurité Université Jean Monnet de Saint-Étienne - FRANCE - A: Yes. Q: Are you sure ? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email ? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone-recursion?
Yes. To explain my setup further, there is a view based on src-IPs for some clients, where recursion is turned on. The rest of the world gets non-recursive answers, e.g. with authoritative data, or refused. In case of that specfic forward zone, bind answers in the non-recursive case with a referal to itself (there is only one public IP), which is causing a loop, as there is no way to specify a different port in the DNS protocol (AFAIK) On Fri, Oct 01, 2010 at 11:25:31AM +0200, Kalman Feher wrote: This is the problem and the reason I agree with Kevin. The referral is correct behaviour. Your DNS set up is wrong. You have 2 choices and a third On 01.10.10 12:39, Joerg Dorchain wrote: Well, I could agree agree that wrong means not thought of by RfC-Designers and bind implementators (yet). probably it was not thought because it's wrong. less palatable option: 1. Make the other DNS software available on another IP. So normal DNS behaviour works. Hm, this is not too easy in practice, but of course optimal solution. IPv6 will help here, I hope. I don't think this will solve the problem, it will just be a workaround for it. 2. Add the zone as a slave within your authoritative view. (this option may be the easiest for your situation). Not feasible as it contains dynamically generated content, typically with a TTL of 0. this strongly indicates that there's something broken in your DNS. The DNS is not designed to provide anything that short-lived, the whole DNS architecture is based on cachind. Are you doing any kind of DNS-based load balancing? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Enter any 12-digit prime number to continue. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: GSS-TSIG and Active Directory
Updating to 9.7.2-P2 seems to be working. Of course it is not working exactly like we think it should. When we have a things set like this: deny DOMAIN ms-self * SRV ; grant DOMAIN ms-self * ANY; Nothing will update. When we set it like this: deny DOMAIN ms-self * SRV; grant DOMAIN ms-self * ANY; Things seem to work when a client reboots. When we try to add grants for the DCs like this: grant fqn of dc ms-self * ANY; grant fqn of dc ms-subdomain * ANY; deny DOMAIN ms-self * SRV; grant DOMAIN ms-self * ANY; The DCs cannot update their SRV records. _ Nicholas Miller, ITS, University of Colorado at Boulder On Oct 1, 2010, at 7:00 AM, Nicholas F Miller wrote: Thanks, I'll give it a try and see if things begin to work. _ Nicholas Miller, ITS, University of Colorado at Boulder On Sep 30, 2010, at 10:15 AM, Tony Finch wrote: On Thu, 30 Sep 2010, Nicholas F Miller wrote: Does anyone actually have GSS-TSIG working with an Active Directory? There are some GSS-TSIG interop fixes in 9.7.2. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind not starting
NS records must point to an A record. ns1 and ns2 .nsdomain.com do not have A records defined for them according to the zone file. -- John On 10/1/2010 12:14 AM, rams wrote: Hi, I have configured records as follows in bind. When we start the bind 9.7, bind is not starting. But bind is started successfully when commented below ns domains which are marked as RED. Could you please clarify me. *Note: Bind 9.6 is started successfully with the same below zone. * Error: zone nsdomain.com/IN http://nsdomain.com/IN: NS 'ns1.nsdomain.com http://ns1.nsdomain.com' has no address records (A or ) zone nsdomain.com/IN http://nsdomain.com/IN: not loaded due to errors. _default/nsdomain.com/IN http://nsdomain.com/IN: bad zone $ORIGIN nsdomain.com http://nsdomain.com. @ IN SOA dns1.dns.net http://dns1.dns.net. ppk.yahoo.com http://ppk.yahoo.com. ( 2009111903 ; serial 10800 ; refresh 3600 ; retry 2592000 ; expire 86400 ; minimum ) a.nsdomain.com http://a.nsdomain.com.86400INA1.1.1.1 a1.nsdomain.COM http://a1.nsdomain.COM.86400INFE80:: a1.nsdomain.com http://a1.nsdomain.com.86400INFE80:: a1.nsdomain.com http://a1.nsdomain.com.86400INA1.1.1.1 a1.nsdomain.com http://a1.nsdomain.com.86400INNS a1.nsdomain.com http://a1.nsdomain.com. a10.nsdomain.com http://a10.nsdomain.com.9IN NSns1.nu.moon. a11.nsdomain.com http://a11.nsdomain.com.9INNS abc.nsdomain.com http://abc.nsdomain.com. a12.nsdomain.com http://a12.nsdomain.com.86400INNS mx.nsdomain.com http://mx.nsdomain.com. a13.nsdomain.com http://a13.nsdomain.com.86400INNS cname.nsdomain.com http://cname.nsdomain.com. a13.nsdomain.com http://a13.nsdomain.com.86400INNS a.nsdomain.com http://a.nsdomain.com. a13.nsdomain.com http://a13.nsdomain.com.86400INNS mx.nsdomain.com http://mx.nsdomain.com. a14.nsdomain.com http://a14.nsdomain.com.2147483647INNS ns1.a14.nsdomain.com http://ns1.a14.nsdomain.com. a15.nsdomain.com http://a15.nsdomain.com.2147483647INNS ns1.a15.nsdomain.com http://ns1.a15.nsdomain.com. a2.nsdomain.com http://a2.nsdomain.com.86400INNS nsdomain.com http://nsdomain.com. a3.nsdomain.com http://a3.nsdomain.com.86400INNS a3.nsdomain.com http://a3.nsdomain.com. a3.nsdomain.com http://a3.nsdomain.com.86400INNS a2.nsdomain.com http://a2.nsdomain.com. a3.nsdomain.com http://a3.nsdomain.com.86400INNS a1.nsdomain.com http://a1.nsdomain.com. a3.nsdomain.com http://a3.nsdomain.com.86400INNS nsdomain.com http://nsdomain.com. a4.nsdomain.com http://a4.nsdomain.com.86400INNS a4.nsdomain.com http://a4.nsdomain.com. a4.nsdomain.com http://a4.nsdomain.com.86400INNS a4.nsdomain.com http://a4.nsdomain.com. a4.nsdomain.com http://a4.nsdomain.com.86400INNS a4.nsdomain.com http://a4.nsdomain.com. A5.NSDOMAIN.COM http://A5.NSDOMAIN.COM.86400INFE80:: a5.NSDOMAIN.com http://a5.NSDOMAIN.com.86400INFE80:: A5.nsdomain.com http://A5.nsdomain.com.86400INFE80:: a5.nsdomain.com http://a5.nsdomain.com.86400INFE80:: A5.NSDOMAIN.COM http://A5.NSDOMAIN.COM.86400INA 255.255.255.255 a5.nsdomain.COM http://a5.nsdomain.COM.86400INA 255.255.255.255 a5.NSDOMAIN.com http://a5.NSDOMAIN.com.86400INA 255.255.255.255 A5.nsdomain.com http://A5.nsdomain.com.86400INA 255.255.255.255 a5.nsdomain.com http://a5.nsdomain.com.86400INA 255.255.255.255 a5.nsdomain.com http://a5.nsdomain.com.86400INNS A5.NSDOMAIN.COM http://A5.NSDOMAIN.COM. a5.nsdomain.com http://a5.nsdomain.com.86400INNS a5.nsdomain.COM http://a5.nsdomain.COM. a5.nsdomain.com http://a5.nsdomain.com.86400INNS a5.NSDOMAIN.com http://a5.NSDOMAIN.com. a5.nsdomain.com http://a5.nsdomain.com.86400INNS A5.nsdomain.com http://A5.nsdomain.com. A6.NSDOMAIN.COM http://A6.NSDOMAIN.COM.86400INA 255.255.255.255 a6.nsdomain.COM http://a6.nsdomain.COM.86400INA 255.255.255.254 a6.NSDOMAIN.com http://a6.NSDOMAIN.com.86400INA 255.255.255.253 A6.nsdomain.com http://A6.nsdomain.com.86400INA 255.255.255.252 a6.nsdomain.com http://a6.nsdomain.com.86400INA 255.255.255.251 a6.nsdomain.com http://a6.nsdomain.com.86400INNS A6.NSDOMAIN.COM http://A6.NSDOMAIN.COM. a6.nsdomain.com http://a6.nsdomain.com.86400INNS a6.nsdomain.COM http://a6.nsdomain.COM. a6.nsdomain.com http://a6.nsdomain.com.86400INNS a6.NSDOMAIN.com http://a6.NSDOMAIN.com. a6.nsdomain.com http://a6.nsdomain.com.86400INNS A6.nsdomain.com http://A6.nsdomain.com.
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: GSS-TSIG and Active Directory
YES Brilliant Thanks Rob. I think it is working now. I have the update-policy setup as follows: grant d...@realm wildcard * ANY; grant d...@realm wildcard * ANY; grant dns_serv...@realm wildcard * ANY; deny REALM ms-self * SRV; grant REALM ms-self * ANY; If I understand things correctly I am allowing the DCs and DNS server to update any record type in the domain and any subdomains. The clients are allowed to update any of their own records except SRV, MX and NS. Do I even need to deny NS for ms-self? If it is truly working correctly, I wonder why I can't deny records. When I add to the deny statement it blocks A records as well. If try A6 it still allows records to be set by client machines. _ Nicholas Miller, ITS, University of Colorado at Boulder On Oct 1, 2010, at 12:12 PM, Rob Austein wrote: 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
Force Bind caching resolver to always obey DNSSSEC
Hello after the root zones are now DNSSEC signed we like to use DNSSEC at our caching resolvers. I have setup Bind 9.7.0-P1-1 at the border and basically it is working fine. What i have not managed is to alwawys force obeying DNSSEC signed zones for resolving eg. if i use dig +cdflag www.rhybar.cz the caching resolver ignores the invalid signed result set and delivers the A record. If i don't use the +cdflag the result is SERVFAIL (no result). We have set the following: dnssec-enable yes; dnssec-validation yes; managed-keys { ... };for the root zone Are there any settings to never return a result for invalid signed result sets? Many Thanks Andreas ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Force Bind caching resolver to always obey DNSSSEC
On 10/1/2010 4:26 PM, lst_ho...@kwsoft.de wrote: Hello after the root zones are now DNSSEC signed we like to use DNSSEC at our caching resolvers. I have setup Bind 9.7.0-P1-1 at the border and basically it is working fine. What i have not managed is to alwawys force obeying DNSSEC signed zones for resolving eg. if i use dig +cdflag www.rhybar.cz the caching resolver ignores the invalid signed result set and delivers the A record. If i don't use the +cdflag the result is SERVFAIL (no result). [..] Are there any settings to never return a result for invalid signed result sets? SERVFAIL is what is the correct response when data is invalid. I'm not sure what you actually want... If you never return a result, the user on the other end will continue to attempt to resolve the (bad) zone. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Force Bind caching resolver to always obey DNSSSEC
Zitat von Alan Clegg acl...@isc.org: On 10/1/2010 4:26 PM, lst_ho...@kwsoft.de wrote: Hello after the root zones are now DNSSEC signed we like to use DNSSEC at our caching resolvers. I have setup Bind 9.7.0-P1-1 at the border and basically it is working fine. What i have not managed is to alwawys force obeying DNSSEC signed zones for resolving eg. if i use dig +cdflag www.rhybar.cz the caching resolver ignores the invalid signed result set and delivers the A record. If i don't use the +cdflag the result is SERVFAIL (no result). [..] Are there any settings to never return a result for invalid signed result sets? SERVFAIL is what is the correct response when data is invalid. I'm not sure what you actually want... If you never return a result, the user on the other end will continue to attempt to resolve the (bad) zone. Sorry for being unclear. We want the SERVFAIL as it should be for invalid DNSSEC data *in all cases* eg. even if a client ask with the cdflag (checking disable) set. Many Thanks Andreas ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Force Bind caching resolver to always obey DNSSSEC
On 10/1/2010 4:50 PM, lst_ho...@kwsoft.de wrote: Sorry for being unclear. We want the SERVFAIL as it should be for invalid DNSSEC data *in all cases* eg. even if a client ask with the cdflag (checking disable) set. CD means don't check, so you can't by definition. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Auto signing ARM
I haven't seen any answers to Timothe's questions below, though I have been keeping an eye out for them. The documentation in this area is a bit thin... Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ On 20 Sep 2010, at 20:28, Timothe Litt l...@acm.org wrote: I'm trying to get named and my management tool cooperating with named on DNSSEC key management. I'm seeing behavior with auto-signing that doesn't strictly match the ARM and would like to know what's correct. I'm also not clear on what named expects for some cases. 4 questions after a little context: 9.7.1-P2 Consider this configuration snippet: View internal in { key-directory /... ... } zone xx.example.net in { auto-dnssec maintain; type master; file ... allow-transfer ... update policy { grant ... } } I run (This is a test, /dev/urandom isn't used in real life) dnssec-keygen -q -a NSEC3RSASHA1 -b 1024 -P now -A +3mo -r /dev/urandom -K /... xx.example.net. I get a Kxx.example.net+... file with all the right permissions. Now, according to the ARM: 4.9.5 DNSKEY rollovers via UPDATE It is possible to perform key rollovers via dynamic update. You need to add the K* files for the new keys so that named can find them. You can then ***add the new DNSKEY RRs via dynamic update***. named will then cause the zone to be signed with the new keys. When the signing is complete the private type records will be updated so that the last octet is non zero. But: if I DON'T add the keys by dynamic update, but instead issue an rndc sign xx.example.net in internal The new key shows up in the zone. As expected, nothing is signed. So, it seems that it is NOT necessary to insert the DNSKEY RRs via dynamic update. Either dynamic update or rndc wakes up named and causes a scan of the keys directory. 1) Before I decide whether to rely on it, is this a bug or a feature? Dynamic update is a bit less work - but avoids having the control channel open beyond the local host. So there are trade-offs. In the same area of the ARM, the 5011 section seems to be a good way to let the slave servers learn about key changes. The section talks about dnssec-signzone -S as the way to trigger distribution. 2) I would expect that a key to a dnssec-auto maintain zone via the dynamic update/rndc sign route would also satisfy the 5011 requirements. Is that correct? 3) If dnssec-revoke or dnssec-settime are invoked, I assume that rndc sign would trigger publication. If one would rather do everything with dynamic update, what's the simplest transaction that will trigger Re-scanning the changed key? Do I have to read the key file insert the key? That leaves the DS records for internally delegated zones. As best I can tell, I still need to find the parent zone and insert them via dynamic update. But: in the case where the parent zone is served by the same view in the same server, named has everything it needs to autogenerate DS record(s) when a DNSKEY is published and install it in the parent. Well, maybe which hash type(s) are desired, but that would be easy to put in a .conf file... 4) Shouldn't named handle this? - This communication may not represent my employer's views, if any, on the matters discussed. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Force Bind caching resolver to always obey DNSSSEC
Zitat von Alan Clegg acl...@isc.org: On 10/1/2010 4:50 PM, lst_ho...@kwsoft.de wrote: Sorry for being unclear. We want the SERVFAIL as it should be for invalid DNSSEC data *in all cases* eg. even if a client ask with the cdflag (checking disable) set. CD means don't check, so you can't by definition. AlanC That i was afraid of. It's a pitty that there is no way to save the downstream clients from stupid resolvers/downstream caches. At least for security relevant settings there should be a possibility to enforce the desired behaviour and not rely on the client. With the older Bind 9.4 as resolver the result even stay in the cache and later querys with cdflag not set deliever the invalid result until expired :-( Andreas ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
managed-keys-zone file not found
Hello While starting up bind I get the following 2 messages 01-Oct-2010 15:13:15.304 set up managed keys zone for view external, file '3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys' and 01-Oct-2010 15:13:15.309 managed-keys-zone ./IN/external: loading from master file 3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys failed: file not found the number is a hash of the view name (external) The zones in the view allow dynamic update. I have tried using managed-keys-directory option, but I cannot get rid of this message. What am I missing? thanks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Force Bind caching resolver to always obey DNSSSEC
In article mailman.265.1285967251.555.bind-us...@lists.isc.org, lst_ho...@kwsoft.de wrote: Zitat von Alan Clegg acl...@isc.org: On 10/1/2010 4:50 PM, lst_ho...@kwsoft.de wrote: Sorry for being unclear. We want the SERVFAIL as it should be for invalid DNSSEC data *in all cases* eg. even if a client ask with the cdflag (checking disable) set. CD means don't check, so you can't by definition. AlanC That i was afraid of. It's a pitty that there is no way to save the downstream clients from stupid resolvers/downstream caches. Since CD is not set by default, a stupid resolver that doesn't know about DNSSEC won't set it. Someone has to go out of their way to request this behavior. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone-recursion?
On Fri, Oct 01, 2010 at 05:39:16PM +0200, Matus UHLAR - fantomas wrote: On 01.10.10 12:39, Joerg Dorchain wrote: Well, I could agree agree that wrong means not thought of by RfC-Designers and bind implementators (yet). probably it was not thought because it's wrong. This point is getting religious now, IMHO. less palatable option: 1. Make the other DNS software available on another IP. So normal DNS behaviour works. Hm, this is not too easy in practice, but of course optimal solution. IPv6 will help here, I hope. I don't think this will solve the problem, it will just be a workaround for it. With IPv6, I see much better chances of having more than one address available, which would make the best architectural solution a practical one as well. 2. Add the zone as a slave within your authoritative view. (this option may be the easiest for your situation). Not feasible as it contains dynamically generated content, typically with a TTL of 0. this strongly indicates that there's something broken in your DNS. The DNS is not designed to provide anything that short-lived, the whole DNS architecture is based on cachind. Yes, DNS works best with caching. I know that this setup is a corner case and very individual (If would had two public IPs then I would be fine) To be a bit polemic, if you think it is wrong, TTL of 0 should be forbidden, I suppose. Are you doing any kind of DNS-based load balancing? No, then multiple A records or so would be just fine. Bye, Joerg signature.asc Description: Digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users