Re: Bind not starting

2010-10-01 Thread Stephane Bortzmeyer
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

2010-10-01 Thread Matus UHLAR - fantomas
 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?

2010-10-01 Thread Kalman Feher



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

2010-10-01 Thread rams
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

2010-10-01 Thread Stephane Bortzmeyer
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?

2010-10-01 Thread Joerg Dorchain
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

2010-10-01 Thread Nicholas F Miller
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

2010-10-01 Thread Nicholas F Miller
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

2010-10-01 Thread Nicholas F Miller
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 ?

2010-10-01 Thread Magali Bernard

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 ?

2010-10-01 Thread Chris Thompson

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

2010-10-01 Thread Rob Austein
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 ?

2010-10-01 Thread Magali Bernard

 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?

2010-10-01 Thread Matus UHLAR - fantomas
   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

2010-10-01 Thread Nicholas F Miller
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

2010-10-01 Thread John Wingenbach
 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

2010-10-01 Thread Rob Austein
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

2010-10-01 Thread Nicholas F Miller
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

2010-10-01 Thread lst_hoe02

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

2010-10-01 Thread Alan Clegg
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

2010-10-01 Thread lst_hoe02

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

2010-10-01 Thread Alan Clegg
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

2010-10-01 Thread Tony Finch
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

2010-10-01 Thread lst_hoe02

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

2010-10-01 Thread Jack Tavares
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

2010-10-01 Thread Barry Margolin
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?

2010-10-01 Thread Joerg Dorchain
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