Option notify no also disabled query log?
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
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
In message prayer.1.3.3.1012061052110.14...@hermes-2.csi.cam.ac.uk, 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
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
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
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
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
GSSTSIG - Can we do it? Do it REALLY work since Version 9.7.2? Still a bug?
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
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) noe.neva...@hp.com Date: 2010/12/6 Subject: Re: Problems with Bind-Kerberos-Windows-Linux To: Jürgen Dietl juergen.di...@googlemail.com Regards, Noe N. HP Hostmaster Sent from my iPhone. On Dec 6, 2010, at 10:02 AM, Jürgen Dietl juergen.di...@googlemail.com 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 mailto:p.may...@imperial.ac.uk p.may...@imperial.ac.ukmailto: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 mailto:bind-users@lists.isc.orgbind-users@lists.isc.orgmailto: bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users https://lists.isc.org/mailman/listinfo/bind-users ATT1..txt ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems with Bind-Kerberos-Windows-Linux
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
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 sbi...@bluecatnetworks.com 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?
From: Drunkard Zhang gongfan...@gmail.com
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
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
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
named-checkzone error NSEC node already exists
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
