Option "notify no" also disabled query log?

[Drunkard Zhang]

Hi, all. I'm using bind-9.7.2-P3, and I want to get query log, I
pasted related configuration below:

options {
directory "/var/";
forward only;
#listen-on port 53 { 10.198.2.249; 127.0.0.1; };
forwarders {
8.8.8.8;
};
pid-file "file-named.pid";
dump-file "file-dumpfile";
statistics-file "file-stat";
max-cache-size 3000M;
notify no;
allow-query { any; };
max-ncache-ttl 600;
max-cache-ttl 86400;
recursive-clients 100;
tcp-clients 50;
interface-interval 0;
cleaning-interval 3600;
version "GW DNS";
recursion yes;
};
channel query_log {
syslog local1;
severity info;
print-category no;
print-severity no;
print-time no;
};
category queries { query_log; };

But there's no output in syslog, after change "notify no" to "notify
yes", logging via syslog works great. So I wondering is this a
intended behavior, or it's a bug. This was not mentioned in arm9.7, so
I'm asking here.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "can't validate existing negative responses (not a zone cut)" messages

[Chris Thompson]

On Oct 3 2010, I wrote:


Since upgrading our main recursive nameservers to BIND 9.7.2-P2 (and
using a trust anchor for the root and lookaside via dlv.isc.org) I am
seeing a scatter of warning messages like this:

Oct  1 19:47:19 dnssec: warning: validating @1c29d580:
 115.197.101.95.IN-ADDR.ARPA PTR:
 can't validate existing negative responses (not a zone cut)

[...]

What do they mean, exactly? And should I be worrying about them?
They all seem to refer to PTR records (not all of them for IP
addresses in 95.101/16, but many of them are).


There were some followups, but we never got anything from ISC.

After upgrading to BIND 9.7.2-P3, they appear to have gone away, so
I presume one of the changes (maybe 2970) has fixed them.

--
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: "can't validate existing negative responses (not a zone cut)" messages

[Mark Andrews]

In message , Chris Tho
mpson writes:
> On Oct 3 2010, I wrote:
> 
> >Since upgrading our main recursive nameservers to BIND 9.7.2-P2 (and
> >using a trust anchor for the root and lookaside via dlv.isc.org) I am
> >seeing a scatter of warning messages like this:
> >
> >Oct  1 19:47:19 dnssec: warning: validating @1c29d580:
> >  115.197.101.95.IN-ADDR.ARPA PTR:
> >  can't validate existing negative responses (not a zone cut)
> [...]
> >What do they mean, exactly? And should I be worrying about them?
> >They all seem to refer to PTR records (not all of them for IP
> >addresses in 95.101/16, but many of them are).
> 
> There were some followups, but we never got anything from ISC.
> 
> After upgrading to BIND 9.7.2-P3, they appear to have gone away, so
> I presume one of the changes (maybe 2970) has fixed them.

It would be part of change 2968.

2968.   [security]  Named could fail to prove a data set was insecure
before marking it as insecure.  One set of conditions
that can trigger this occurs naturally when rolling
DNSKEY algorithms.

CVE-2010-3614, VU#837744. [RT #22309]

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Problems with Bind-Kerberos-Windows-Linux

[Jürgen Dietl]

Hello,

I am trying to allow the DNS-Client to do dynamic updates at the DNS-Server
using BIND. I want to use Kerberos as the security protocol. For that I have
a small test lab with a client, 3 Kerberos Server and one Suse Linux
DNS-Server. The 3 Kerberos-Server are emulated with using VM-Ware.



The Kerberos-Client gets the TGT from the Kerberos-Server. As I understand
it should use this TGT for requesting further services via an AP-Request.



Cached TGT:



ServiceName: krbtgt

TargetName: krbtgt

FullServiceName: xxxgsstsig

DomainName: TEST.LOC

TargetDomainName: TEST.LOC

AltTargetDomainName: TEST.LOC

TicketFlags: 0x40e0

KeyExpirationTime: 1/1/1601 1:00:00

StartTime: 12/6/2010 4:18:37

EndTime: 12/6/2010 14:18:37

RenewUntil: 12/10/2010 17:18:37

TimeSkew: 1/1/1601 1:00:00



I have read that there is a special mode called User-To-User Mode. This mode
enables the client to ask for a service direct without asking for a TGT
before.  I found out that my client use this special user-to-user mode. I
don’t know why.



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

mechToken:
6082047d06092a864886f71201020201006e82046c308204...

krb5_blob:
6082047d06092a864886f71201020201006e82046c308204...

KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 -
Kerberos 5)

krb5_tok_id: KRB5_AP_REQ (0x0001)

Kerberos AP-REQ

Pvno: 5

MSG Type: AP-REQ (14)

Padding: 0

APOptions: 2000 (Mutual required)

0...      
 = reserved: RESERVED bit off

.0..      
 = Use Session Key: Do NOT use the session key to encrypt the ticket

..1.      
 = Mutual required: MUTUAL authentication is REQUIRED

Ticket

Tkt-vno: 5

Realm: TEST.LOC

Server Name (Service and Instance):
DNS/scdns14p.test.loc

Name-type: Service and Instance
(2)

Name: DNS

Name: scdns14p.test.loc

enc-part des-cbc-md5

Encryption type: des-cbc-md5 (3)

Kvno: 3

enc-part:
bfd012cc83e2e0050400b56aa8dd50a2404896871830e9f0...

Authenticator des-cbc-md5

Encryption type: des-cbc-md5 (3)

Authenticator data:
249c7a63fd5d9c84137f9dbdfa7810e04fe0d6a5b0cd...



Is this a wanted behavior?



The client has an entry in the AD with DNS/test@test.loc. The Client,
DNS-Server, Kerberos-Server all have a copy of the krb5.keytab. If I do a
kinit -k -t c:\krb5.keytab DNS/test@test.loc then all seem to be ok.  I
get this message from the DNSserver: 03-Dec-2010 10:42:00.451 general: debug
3: gss cred: "DNS/test@test.loc", GSS_C_ACCEPT, 4294962027. But when the
client do it from its own I get this message from the DNS-Server:
03-Dec-2010 10:42:00.451 general: debug 3: failed gss_accept_sec_context:
GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
information, Minor = Wrong principal in request.



I have installed Bind V 9.7.2 (so the newest) and all PCs are running NTP
for time synchronisation.



Any help would be greatly appreciated



Cheers,

Juergen
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems with Bind-Kerberos-Windows-Linux

[Phil Mayers]

On 12/06/2010 02:20 PM, Jürgen Dietl wrote:

I have read that there is a special mode called User-To-User Mode. This
mode enables the client to ask for a service direct without asking for a


That's not quite how u2u works.


TGT before. I found out that my client use this special user-to-user
mode. I don’t know why.


No. Your client is using SPNego and offering u2u as a *possible* 
mechanism to be negotiated.



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




Is this a wanted behavior?


Yes. That's how spnego works. I'm willing to bet the server does not 
actually *pick* u2u - but the client can do it, so offers it during 
negotiation.


I can't help you with your wider question I'm afraid; I don't really 
understand what you're asking. But the user2user stuff is a red herring 
and can be ignored.

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

Re: Problems with Bind-Kerberos-Windows-Linux

[Jürgen Dietl]

Hello Phil,
thanx for your answer.I dont know really what the server offers because I
dont get a valid response:



Frame 2475: 168 bytes on wire (1344 bits), 168 bytes captured (1344 bits)
Ethernet II, Src: xx, Dst: Vmware_x
Internet Protocol, Src: , Dst: 
Transmission Control Protocol, Src Port: domain (53), Dst Port: 60357
(60357), Seq: 1, Ack: 1390, Len: 114
Domain Name System (response)
[Request In: 2473]
[Time: 0.001913000 seconds]
Length: 112
Transaction ID: 0x43cf
Flags: 0x8080 (Standard query response, No error)
1...    = Response: Message is a response
.000 0...   = Opcode: Standard query (0)
 .0..   = Authoritative: Server is not an authority for
domain
 ..0.   = Truncated: Message is not truncated
 ...0   = Recursion desired: Don't do query recursively
  1...  = Recursion available: Server can do recursive
queries
  .0..  = Z: reserved (0)
  ..0.  = Answer authenticated: Answer/authority portion
was not authenticated by the server
  ...0  = Non-authenticated data: Unacceptable
    = Reply code: No error (0)
Questions: 1
Answer RRs: 1
Authority RRs: 0
Additional RRs: 0
Queries
788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d: type TKEY,
class IN
Name: 788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d
Type: TKEY (Transaction Key)
Class: IN (0x0001)
Answers
788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d: type TKEY,
class ANY
Name: 788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d
Type: TKEY (Transaction Key)
Class: ANY (0x00ff)
Time to live: 0 time
Data length: 26
Algorithm name: gss-tsig
Signature inception: Jan  1, 1970 01:00:00.0
Mitteleuropäische Zeit
Signature expiration: Jan  1, 1970 01:00:00.0
Mitteleuropäische Zeit
Mode: GSSAPI
Error: *Bad key*

The Log-File from the DNS-SUSE-Server tells me "wrong principal". Is there a
way to find out what principal it expects?

thanx a lot,
cheers,
Juergen




>  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*)
>>
>
>
>> Is this a wanted behavior?
>>
>
> Yes. That's how spnego works. I'm willing to bet the server does not
> actually *pick* u2u - but the client can do it, so offers it during
> negotiation.
>
> I can't help you with your wider question I'm afraid; I don't really
> understand what you're asking. But the user2user stuff is a red herring and
> can be ignored.
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
No. Your client is using SPNego and offering u2u as a *possible* mechanism
to be negotiated.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems with Bind-Kerberos-Windows-Linux

[Phil Mayers]

On 12/06/2010 03:18 PM, Jürgen Dietl wrote:


The Log-File from the DNS-SUSE-Server tells me "wrong principal". Is
there a way to find out what principal it expects?


You can configure it:

tkey-domain "YOUR.DOMAIN";
tkey-gssapi-credential "DNS/hostname.your.domain";

(I've never managed to make this work under bind, FWIW. Even when I did 
get the kerberos working, the ms-self ACL turns out to be useless in a 
disjoint domain environment)

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

Re: Problems with Bind-Kerberos-Windows-Linux

[Jürgen Dietl]

Hello Phil
thanx again for your answer. So I read between the lines that even if there
were bugfixes for GSSTSIG in Bind V. 9.7.2 - it dont work. So we have to
wait until MS follow the standards? :-)

Forgive me but what is a disjoint domain environment?

thanx a lot,
cheers,
Juergen


2010/12/6 Phil Mayers 

> On 12/06/2010 03:18 PM, Jürgen Dietl wrote:
>
>  The Log-File from the DNS-SUSE-Server tells me "wrong principal". Is
>> there a way to find out what principal it expects?
>>
>
> You can configure it:
>
>tkey-domain "YOUR.DOMAIN";
>tkey-gssapi-credential "DNS/hostname.your.domain";
>
> (I've never managed to make this work under bind, FWIW. Even when I did get
> the kerberos working, the ms-self ACL turns out to be useless in a disjoint
> domain environment)
>
> ___
> 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

GSSTSIG - Can we do it? Do it REALLY work since Version 9.7.2? Still a bug?

[Jürgen Dietl]

Hello,

when you read my post before I try to make GSSTSIG run in a testlab
environment with 1 Windows Kerberos-Client, 3 x Kerberos-Server (VMWare) and
1 x DNS-BIND-LINUX-Server (Suse).

Bind-Version: 9.7.2

I do this now the 3rd week. I was reading a lot of books and manuals, doing
a lot of configuration and sniffering etc. I looked in google for hours but
I could not find anyone that says - yes it works.

So my general question to the whole community: Is there anybody outside in
the world that can anwer this - Can we do it? Yes, we can! Then please gimme
a hint.

Have nice day,
cheers,
Juergen
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Fwd: Problems with Bind-Kerberos-Windows-Linux

[Jürgen Dietl]

Hello Nevarez,
grats for sending it from your iPhone :-) But is there any message missing?
thanx a lot and have a nice day
cheers,
Juergen


-- Forwarded message --
From: Nevarez, Noe (DNSLB-NETWORKS) 
Date: 2010/12/6
Subject: Re: Problems with Bind-Kerberos-Windows-Linux
To: Jürgen Dietl 




Regards,

Noe N.
HP Hostmaster

Sent from my iPhone.

On Dec 6, 2010, at 10:02 AM, "Jürgen Dietl" mailto:juergen.di...@googlemail.com>> wrote:

Hello Phil
thanx again for your answer. So I read between the lines that even if there
were bugfixes for GSSTSIG in Bind V. 9.7.2 - it dont work. So we have to
wait until MS follow the standards? :-)

Forgive me but what is a disjoint domain environment?

thanx a lot,
cheers,
Juergen


2010/12/6 Phil Mayers <
p.may...@imperial.ac.uk>
On 12/06/2010 03:18 PM, Jürgen Dietl wrote:

The Log-File from the DNS-SUSE-Server tells me "wrong principal". Is
there a way to find out what principal it expects?

You can configure it:

  tkey-domain "YOUR.DOMAIN";
  tkey-gssapi-credential "DNS/hostname.your.domain";

(I've never managed to make this work under bind, FWIW. Even when I did get
the kerberos working, the ms-self ACL turns out to be useless in a disjoint
domain environment)

___
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: Problems with Bind-Kerberos-Windows-Linux

[Sergiu Bivol]

> The client has an entry in the AD with DNS/test@test.loc. The Client,
> DNS-Server, Kerberos-Server all have a copy of the krb5.keytab. If I do a
> kinit -k -t c:\krb5.keytab DNS/test@test.loc then all seem to be ok.  I
> get this message from the DNSserver: 03-Dec-2010 10:42:00.451 general: debug
> 3: gss cred: "DNS/test@test.loc", GSS_C_ACCEPT, 4294962027. But when the
> client do it from its own I get this message from the DNS-Server:
> 03-Dec-2010 10:42:00.451 general: debug 3: failed gss_accept_sec_context:
> GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> information, Minor = Wrong principal in request.

Normally you need 2 kerberos principals, one for the DNS Server, one for the 
client. 

If kinit above works on the DNS Server box, and you can see these messages at 
startup BIND is configured correctly.
27-Sep-2010 18:26:47.860 acquiring credentials for DNS/test.loc
27-Sep-2010 18:26:47.860 gss cred: "DNS/test@test.loc", GSS_C_ACCEPT, 
4294967295

You still need to configure update-policy to allow your client to update DNS, 
but that is another issue.

A GSS-TSIG-enabled DNS client would request TGT (as a different Kerberos 
user/principal), then TGS to use the DNS Service identified by the 
DNS/test@test.log service principal. With this it should be able to update 
the DNS server, as long as DNS Server validates the client's ticket and the 
policy allows the update.

I hope your understanding is the same, it just wasn't clear from your message.

Regards
Sergiu

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

Re: Problems with Bind-Kerberos-Windows-Linux

[Phil Mayers]

On 12/06/2010 04:01 PM, Jürgen Dietl wrote:

Hello Phil
thanx again for your answer. So I read between the lines that even if
there were bugfixes for GSSTSIG in Bind V. 9.7.2 - it dont work. So we
have to wait until MS follow the standards? :-)


That's not what I said.



Forgive me but what is a disjoint domain environment?


domain: EXAMPLE.COM
hostname: host.subdomain.example.com

Bind seems to have trouble in this case.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems with Bind-Kerberos-Windows-Linux

[Jürgen Dietl]

Hello Serjiu,
many thanx for your hint. This I was asking me too for some time. Because
the TGT is for the client name (principal) that is logged in at the moment
and the service should be always for the same principal name on any client.
So yes I will need to define 2 principals.

You wrote:
You still need to configure update-policy to allow your client to update
DNS, but that is another issue.

Do you mean the policy in the active directory? Btw. did you try to do it
your own and succeeded?


thanx a lot,
cheers,
Juergen


2010/12/6 Sergiu Bivol 

> > The client has an entry in the AD with DNS/test@test.loc. The
> Client,
> > DNS-Server, Kerberos-Server all have a copy of the krb5.keytab. If I do a
> > kinit -k -t c:\krb5.keytab DNS/test@test.loc then all seem to be ok.
>  I
> > get this message from the DNSserver: 03-Dec-2010 10:42:00.451 general:
> debug
> > 3: gss cred: "DNS/test@test.loc", GSS_C_ACCEPT, 4294962027. But when
> the
> > client do it from its own I get this message from the DNS-Server:
> > 03-Dec-2010 10:42:00.451 general: debug 3: failed gss_accept_sec_context:
> > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide
> more
> > information, Minor = Wrong principal in request.
>
> Normally you need 2 kerberos principals, one for the DNS Server, one for
> the client.
>
> If kinit above works on the DNS Server box, and you can see these messages
> at startup BIND is configured correctly.
> 27-Sep-2010 18:26:47.860 acquiring credentials for DNS/test.loc
> 27-Sep-2010 18:26:47.860 gss cred: "DNS/test@test.loc", GSS_C_ACCEPT,
> 4294967295
>
> You still need to configure update-policy to allow your client to update
> DNS, but that is another issue.
>
> A GSS-TSIG-enabled DNS client would request TGT (as a different Kerberos
> user/principal), then TGS to use the DNS Service identified by the
> DNS/test@test.log service principal. With this it should be able to
> update the DNS server, as long as DNS Server validates the client's ticket
> and the policy allows the update.
>
> I hope your understanding is the same, it just wasn't clear from your
> message.
>
> Regards
> Sergiu
>
> ___
> 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: Option "notify no" also disabled query log?

[Kevin Oberman]

> From: Drunkard Zhang 
> Date: Mon, 6 Dec 2010 16:54:31 +0800
> Sender: bind-users-bounces+oberman=es@lists.isc.org
> 
> Hi, all. I'm using bind-9.7.2-P3, and I want to get query log, I
> pasted related configuration below:
> 
> options {
> directory "/var/";
> forward only;
> #listen-on port 53 { 10.198.2.249; 127.0.0.1; };
> forwarders {
> 8.8.8.8;
> };
> pid-file "file-named.pid";
> dump-file "file-dumpfile";
> statistics-file "file-stat";
> max-cache-size 3000M;
> notify no;
> allow-query { any; };
> max-ncache-ttl 600;
> max-cache-ttl 86400;
> recursive-clients 100;
> tcp-clients 50;
> interface-interval 0;
> cleaning-interval 3600;
> version "GW DNS";
> recursion yes;
> };
logging {
channel query_log {
syslog local1;
severity info;
print-category no;
print-severity no;
print-time no;
};
category queries { query_log; };
};
> 
> But there's no output in syslog, after change "notify no" to "notify
> yes", logging via syslog works great. So I wondering is this a
> intended behavior, or it's a bug. This was not mentioned in arm9.7, so
> I'm asking here.
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Private Zones and Deligation bind9.7.2

[Martin McCormick]

Barry Margolin writes:

> Do you have recursion enabled on your server?

A good question. I have never explisitly disabled it and
it appears to be on.

We have an allow-query list based on ACL's so that
callers from inside our networks get both recursive and
nonrecursive lookups. Spammer1.somewhereelse.com looking up
poorsucker.hooville.org gets nothing but can still spam us since
all our zones allow anyone to do lookups against their zone
data. The problem is that lookups to this private zone are
still coming from the networks that should allow full
functionality.  the config for this private zone is:

zone "r.ds" {
type master;
file "/etc/namedb/master/r.ds.zone";
allow-update {
key updsrv;
 };
allow-query { any; };
#a list of slaves
include "/etc/zoneconfigs/stwnotify";
notify yes;
};

In the global named.conf file, I do not set any
directives regarding recursion. The characters "recur" do not
even appear in the file so I always assumed recursion was turned
on. Status checks on a busy day usually show 50 to 100 recursive
clients active at any given time but I think you may have
possibly hit on what is biting me.

Martin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Private Zones and Deligation bind9.7.2

[Jay Ford]

On Mon, 6 Dec 2010, Martin McCormick wrote:

the config for this private zone is:

zone "r.ds" {
type master;
file "/etc/namedb/master/r.ds.zone";
   allow-update {
key updsrv;
};
   allow-query { any; };
#a list of slaves
include "/etc/zoneconfigs/stwnotify";
notify yes;
};


You configured this server to be master for the r.ds zone, which tells this
server that it is authoritative for names in that zone.  If it gets a query
for a resource record in that zone which it doesn't know, it will answer
authoritatively with a negative answer (either NXDOMAIN if the name doesn't
exist at all, or NOERROR with no "answer" data if the name exists but not
with the queried type).  NS records in a zone don't cause an authoritative
server to send queries elsewhere, because the server knows the answer by
virtue of being authoritative for the zone.

The NS records you list will direct *other* resolvers which see those NS
records to send queries for names in r.ds to the targets of the NS records,
but any queries for names in r.ds which end up at your server will get
handled as described above.

What you probably want to do is add something like the following to the 
parent "ds" zone:

   r   IN  NS  stwrdc02.r.ds.
   IN  NS  stwrdc03.r.ds.
   stwrdc02.r  IN  A   192.168.1.1
   stwrdc03.r  IN  A   192.168.1.2
then get rid of the r.ds zone definition on your server.

Your subject line includes "private".  What is it that's private about this
situation?


Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems with Bind-Kerberos-Windows-Linux

[Chris Buxton]

On Dec 6, 2010, at 9:00 AM, Jürgen Dietl wrote:

> Hello Serjiu,
> many thanx for your hint. This I was asking me too for some time. Because the 
> TGT is for the client name (principal) that is logged in at the moment and 
> the service should be always for the same principal name on any client. So 
> yes I will need to define 2 principals. 
> 
> You wrote:
> You still need to configure update-policy to allow your client to update DNS, 
> but that is another issue.
> 
> Do you mean the policy in the active directory? Btw. did you try to do it 
> your own and succeeded?

No, he meant the update-policy statement in named.conf, which sets who can 
update what in the zone.

Chris Buxton
BlueCat Networks
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Private Zones and Deligation bind9.7.2

[Chris Buxton]

On Dec 6, 2010, at 9:30 AM, Martin McCormick wrote:

> Barry Margolin writes:
> 
>> Do you have recursion enabled on your server?
> 
>   A good question. I have never explisitly disabled it and
> it appears to be on.

The default ACL for allow-recursion is { localhost; localnets; }. That means it 
will work for clients on the same networks as your server, but not for other 
networks.

In your options or view statement, add this:

allow-recursion { localhost; network1; networks2; [...] };

Instead of "network1", put in the definition of the allowed network, such as 
"10/8" or "192.168.0/24". You can also use a named ACL, such as one defined 
with the "acl" statement.

Regards,
Chris Buxton
BlueCat Networks
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

named-checkzone error "NSEC node already exists"

[jim]

Hi,

Running BIND 9.7.0-P2-RedHat-9.7.0-5.P2.el6

New setup/install and attempting to setup DNSSEC and clean any dirty data.
Got the zone signed and ran named-checkzone against it and got the following
(11) times:
 addnode: NSEC node already exists
The .signed loads but want to have clean before going live and not sure how
to narrow down where these eleven duplicates are coming from?
See these repeated eleven times in debug.log for each start of named,
running debug of 3
   06-Dec-2010 14:43:39.266 database: warning: addnode: NSEC node already
exists


Sorry, some more stupid questions on DNSSEC that I'm just confused about.

 1) Do I sign my n.n.n.in-addr.arpa zone just like my domain.edu?

   # dnssec-keygen -r /dev/urandom n.n.n.in-addr.arpa
   # dnssec-keygen -f KSK -r /dev/urandom n.n.n.in-addr.arpa
   # named-checkzone -t /var/named n.n.n.in-addr.arpa dns.net.domain
  runs OK
   # dnssec-signzone -g -k Kn.n.n.in-addr.arpa.+005+33126.key -o
n.n.n.in-addr.arpa dns.net-iup Kn.n.n.in-addr.arpa.+005+24720.key


2) After I have my island of security setup and working, register the KSK
public key with educause correct?

3) After registered with educause should I stop reading in
/etc/named.iscdlv.key?

thanks!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Private Zones and Deligation bind9.7.2 solved

[Martin McCormick]

Thanks to two list members, I immediately realized what
I needed to do to make this work correctly.

After setting up an authoritative zone for ds, I put in
the NS and A records for the master server and then put in the A
and NS records for r as a deligated zone. It all works fine,
now. Many thanks.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: named-checkzone error "NSEC node already exists"

[Mark Andrews]

In message , jim 
writes:
> --===8614228914376772213==
> Content-Type: multipart/alternative; boundary=00163630e869ed2ed50496c3d6e6
> 
> --00163630e869ed2ed50496c3d6e6
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi,
> 
> Running BIND 9.7.0-P2-RedHat-9.7.0-5.P2.el6

Upgrade.
 
> New setup/install and attempting to setup DNSSEC and clean any dirty data.
> Got the zone signed and ran named-checkzone against it and got the following
> (11) times:
>  addnode: NSEC node already exists
> The .signed loads but want to have clean before going live and not sure how
> to narrow down where these eleven duplicates are coming from?
> See these repeated eleven times in debug.log for each start of named,
> running debug of 3
>06-Dec-2010 14:43:39.266 database: warning: addnode: NSEC node already
> exists

Ignore it.  It's a artifact of the rbt implementation.  The warning has been
removed in newer versions.
 
> Sorry, some more stupid questions on DNSSEC that I'm just confused about.
> 
>  1) Do I sign my n.n.n.in-addr.arpa zone just like my domain.edu?
> 
># dnssec-keygen -r /dev/urandom n.n.n.in-addr.arpa
># dnssec-keygen -f KSK -r /dev/urandom n.n.n.in-addr.arpa
># named-checkzone -t /var/named n.n.n.in-addr.arpa dns.net.domain
>   runs OK
># dnssec-signzone -g -k Kn.n.n.in-addr.arpa.+005+33126.key -o
> n.n.n.in-addr.arpa dns.net-iup Kn.n.n.in-addr.arpa.+005+24720.key

Yes.  A zone is a zone.  There is nothing special about "reverse" zones as
far as the DNS is concerned.  It the users of the DNS that treat it as special.
 
> 2) After I have my island of security setup and working, register the KSK
> public key with educause correct?

You register the zones with there parents.  If educause is one of the parents
then yes, for that zone.
 
> 3) After registered with educause should I stop reading in
> /etc/named.iscdlv.key?

Publishing signed zones is independent of validating responses.  I
would stop using dlv when it stops giving a benefit.  At the moment there
are still lots of zones that can only be validated using dlv.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Private Zones and Deligation bind9.7.2

[Barry Margolin]

In article ,
 Jay Ford  wrote:

> On Mon, 6 Dec 2010, Martin McCormick wrote:
> > the config for this private zone is:
> >
> > zone "r.ds" {
> > type master;
> > file "/etc/namedb/master/r.ds.zone";
> >allow-update {
> > key updsrv;
> > };
> >allow-query { any; };
> > #a list of slaves
> > include "/etc/zoneconfigs/stwnotify";
> > notify yes;
> > };
> 
> You configured this server to be master for the r.ds zone, which tells this
> server that it is authoritative for names in that zone.  If it gets a query
> for a resource record in that zone which it doesn't know, it will answer
> authoritatively with a negative answer (either NXDOMAIN if the name doesn't
> exist at all, or NOERROR with no "answer" data if the name exists but not
> with the queried type).  NS records in a zone don't cause an authoritative
> server to send queries elsewhere, because the server knows the answer by
> virtue of being authoritative for the zone.

That's not true.  NS records delimit the extent of the authority, and 
tell it that some other server is authoritative for the subdomain.  So 
as long as recursion is enabled, and the query is recursive, the server 
should follow the delegation.

> 
> The NS records you list will direct *other* resolvers which see those NS
> records to send queries for names in r.ds to the targets of the NS records,
> but any queries for names in r.ds which end up at your server will get
> handled as described above.
> 
> What you probably want to do is add something like the following to the 
> parent "ds" zone:
> r   IN  NS  stwrdc02.r.ds.
> IN  NS  stwrdc03.r.ds.
> stwrdc02.r  IN  A   192.168.1.1
> stwrdc03.r  IN  A   192.168.1.2
> then get rid of the r.ds zone definition on your server.
> 
> Your subject line includes "private".  What is it that's private about this
> situation?

The situation isn't private, the zones are, i.e. they're only accessible 
to his internal users.

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

Fwd: Problems with Bind-Kerberos-Windows-Linux

[Jürgen Dietl]

Hello Sergiu,
I tried to put in 2 credential Entries in the named.conf:

tkey-gssapi-credential "DNS/test.loc"; (that was in before)
tkey-gssapi-credential "USER/test.loc", (new entry)
tkey-domain "TEST.LOC";

The system didnt like the second entry for the user. So how can I put in 2
credentials, or maybe where to put them?

Another problem with 2 Principal name is that the User Principal is of
course different on any pc.

Thanx a lot for your help,
cheers,


-- Forwarded message --
From: Sergiu Bivol 
Date: 2010/12/6
Subject: Re: Problems with Bind-Kerberos-Windows-Linux
To: "bind-users@lists.isc.org" 


> The client has an entry in the AD with DNS/test@test.loc. The Client,
> DNS-Server, Kerberos-Server all have a copy of the krb5.keytab. If I do a
> kinit -k -t c:\krb5.keytab DNS/test@test.loc then all seem to be ok.
 I
> get this message from the DNSserver: 03-Dec-2010 10:42:00.451 general:
debug
> 3: gss cred: "DNS/test@test.loc", GSS_C_ACCEPT, 4294962027. But when
the
> client do it from its own I get this message from the DNS-Server:
> 03-Dec-2010 10:42:00.451 general: debug 3: failed gss_accept_sec_context:
> GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide
more
> information, Minor = Wrong principal in request.

Normally you need 2 kerberos principals, one for the DNS Server, one for the
client.

If kinit above works on the DNS Server box, and you can see these messages
at startup BIND is configured correctly.
27-Sep-2010 18:26:47.860 acquiring credentials for DNS/test.loc
27-Sep-2010 18:26:47.860 gss cred: "DNS/test@test.loc", GSS_C_ACCEPT,
4294967295

You still need to configure update-policy to allow your client to update
DNS, but that is another issue.

A GSS-TSIG-enabled DNS client would request TGT (as a different Kerberos
user/principal), then TGS to use the DNS Service identified by the
DNS/test@test.log service principal. With this it should be able to
update the DNS server, as long as DNS Server validates the client's ticket
and the policy allows the update.

I hope your understanding is the same, it just wasn't clear from your
message.

Regards
Sergiu

___
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