Re: Bind not starting

[Stephane Bortzmeyer]

On Fri, Oct 01, 2010 at 09:44:42AM +0530,
 rams  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: per-zone-recursion?

[Joerg Dorchain]

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)
> 
> 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


signature.asc
Description: Digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind not starting

[Matus UHLAR - fantomas]

> On Fri, Oct 01, 2010 at 09:44:42AM +0530,
>  rams  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?

[Kalman Feher]

On 1/10/10 9:15 AM, "Joerg Dorchain"  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

[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

[Stephane Bortzmeyer]

On Fri, Oct 01, 2010 at 02:58:28PM +0530,
 rams  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?

[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

[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

[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.finchhttp://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

[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: 
>>   Server Name (Service and Instance): 
>> DNS/
>> 
>> 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 ?

[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 ?

[Tony Finch]

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.

DNSSEC validation on a resolver is fairly straightforward to set up now,
though people are still discovering the new mistakes they can make when
signing their zones so you may notice when your validating resolver
points this out...

managed-keys {
"." initial-key 257 3 8 "
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=
";
};

Tony.
-- 
f.anthony.n.finchhttp://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: Where is managed-keys.bind ?

[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

[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 ?

[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?

[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

[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  ms-self * SRV ;
grant  ms-self * ANY;

Nothing will update. When we set it like this:

deny  ms-self * SRV;
grant  ms-self * ANY;

Things seem to work when a client reboots.

When we try to add grants for the DCs like this:

grant  ms-self * ANY;
grant  ms-subdomain * ANY;
deny  ms-self * SRV;
grant  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.finchhttp://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

[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 : NS 'ns1.nsdomain.com 
' has no address records (A or )

zone nsdomain.com/IN : not loaded due to errors.
_default/nsdomain.com/IN : bad zone


$ORIGIN nsdomain.com .
@ IN SOA dns1.dns.net . ppk.yahoo.com 
. (

2009111903 ; serial
10800 ; refresh
3600 ; retry
2592000 ; expire
86400 ; minimum
)
a.nsdomain.com .86400INA1.1.1.1
a1.nsdomain.COM .86400INFE80::
a1.nsdomain.com .86400INFE80::
a1.nsdomain.com .86400INA1.1.1.1
a1.nsdomain.com .86400INNS 
a1.nsdomain.com .
a10.nsdomain.com .9IN
NSns1.nu.moon.
a11.nsdomain.com .9INNS 
abc.nsdomain.com .
a12.nsdomain.com .86400INNS 
mx.nsdomain.com .
a13.nsdomain.com .86400INNS 
cname.nsdomain.com .
a13.nsdomain.com .86400INNS 
a.nsdomain.com .
a13.nsdomain.com .86400INNS 
mx.nsdomain.com .
a14.nsdomain.com .2147483647INNS 
ns1.a14.nsdomain.com .
a15.nsdomain.com .2147483647INNS 
ns1.a15.nsdomain.com .
a2.nsdomain.com .86400INNS 
nsdomain.com .
a3.nsdomain.com .86400INNS 
a3.nsdomain.com .
a3.nsdomain.com .86400INNS 
a2.nsdomain.com .
a3.nsdomain.com .86400INNS 
a1.nsdomain.com .
a3.nsdomain.com .86400INNS 
nsdomain.com .
a4.nsdomain.com .86400INNS 
a4.nsdomain.com .
a4.nsdomain.com .86400INNS 
a4.nsdomain.com .
a4.nsdomain.com .86400INNS 
a4.nsdomain.com .

A5.NSDOMAIN.COM .86400INFE80::
a5.NSDOMAIN.com .86400INFE80::
A5.nsdomain.com .86400INFE80::
a5.nsdomain.com .86400INFE80::
A5.NSDOMAIN.COM .86400INA
255.255.255.255
a5.nsdomain.COM .86400INA
255.255.255.255
a5.NSDOMAIN.com .86400INA
255.255.255.255
A5.nsdomain.com .86400INA
255.255.255.255
a5.nsdomain.com .86400INA
255.255.255.255
a5.nsdomain.com .86400INNS 
A5.NSDOMAIN.COM .
a5.nsdomain.com .86400INNS 
a5.nsdomain.COM .
a5.nsdomain.com .86400INNS 
a5.NSDOMAIN.com .
a5.nsdomain.com .86400INNS 
A5.nsdomain.com .
A6.NSDOMAIN.COM .86400INA
255.255.255.255
a6.nsdomain.COM .86400INA
255.255.255.254
a6.NSDOMAIN.com .86400INA
255.255.255.253
A6.nsdomain.com .86400INA
255.255.255.252
a6.nsdomain.com .86400INA
255.255.255.251
a6.nsdomain.com .86400INNS 
A6.NSDOMAIN.COM .
a6.nsdomain.com .86400INNS 
a6.nsdomain.COM .
a6.nsdomain.com .86400INNS 
a6

Re: GSS-TSIG and Active Directory

[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

[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

[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

[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

[lst_hoe02]

Zitat von 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.


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

[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

[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.finchhttp://dotat.at/

On 20 Sep 2010, at 20:28, "Timothe Litt"  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

[lst_hoe02]

Zitat von 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



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

[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

[Barry Margolin]

In article ,
 lst_ho...@kwsoft.de wrote:

> Zitat von 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
> >
> 
> 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?

[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