Clarification on delegated NS
Hi , When I created delegated NS record. Bind 9.7.1 p3 is giving SERVFAIL , when i queried for NS delegated record with NS. Could you please clarify me or is it bug in 9.7? Thanks Regards, Ramesh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clarification on delegated NS
In message aanlkti=nfu6avy5tnbcc2wyrp0fckh1gskgzl4o8a...@mail.gmail.com, rams writes: Hi , When I created delegated NS record. Bind 9.7.1 p3 is giving SERVFAIL , when i queried for NS delegated record with NS. Could you please clarify me or is it bug in 9.7? To see a delegation you need to do: dig +norec ns zone @parent Thanks Regards, Ramesh -- 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
per-zone-recursion?
Hello, I am puzzled with a bind config for a kind of dns-reverse-proxy situation. I have a server with only one public IP addresse, bind running on port 53 of it. This bind serves examples.net. A subdomain dynsub.example.net should be served on some other software answering DNS request with dynamically generated answers. I can create a forward zone like this zone dynsup.example.net { type forward; forward only; forwarders { 127.0.0.1 port 5353; }; }; which works fine in the way that it forwards all queries to and all answers from the other DNS software running on port 5353, but - this is problem - only if the view with the statement allows recursion. For several reasons I do not want to answer all queries for all domains recursivly, just those for that one zone. When I turn recursion off, bind answers with a referal to itself (glue records work ;-), which in this case is not helpful. Does anybody have an idea on how I can persuade bind to answer only this zone recusivly? TIA, Joerg signature.asc Description: Digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How does BIND 9 scale with multithreading?
On 29.09.10 10:43, Jonathan Petersson wrote: I did some benchmarking on this about 1.5 yrs ago, here's a graph representing the results: http://sedoss.com/bind.png on how many processors was this ran? -- 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. To Boot or not to Boot, that's the question. [WD1270 Caviar] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How does BIND 9 scale with multithreading?
1 QuadCore Intel i7 920 on Fedora 11 x86_64 (can't remember the exact kernel version) with and without hyperthreading and overclocked ranging between 2.8 and 3.4GHz On Thu, Sep 30, 2010 at 2:03 PM, Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 29.09.10 10:43, Jonathan Petersson wrote: I did some benchmarking on this about 1.5 yrs ago, here's a graph representing the results: http://sedoss.com/bind.png on how many processors was this ran? -- 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. To Boot or not to Boot, that's the question. [WD1270 Caviar] ___ 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: When does BIND send queries with DO flag enabled?
Thanks. It took a long time to sort out the root cause because EDNS0 (dig @host record.sample +edns=0) caused no problems, only +dnssec caused failures. The business partner has already fixed their firewall (allow_dnssec_bit=1 on CheckPoint), but I wanted to understand the root cause in order to proactively prevent future problems. Kalman - thanks I'll check the mailing list history. I did that before posting, but couldn't find the right set of keywords to find the chain you're referencing. Kevin (et.al.) - apologies for the legal notice. It's added at our SMTP gateway, so not something I can control on a per-message basis either. If I could get to my webmail account (also blocked) I'd send from there. Welcome to corporate environments... -Original Message- From: Evan Hunt [mailto:e...@isc.org] Sent: 2010, September, 29 7:25 PM To: Taylor, Gord Cc: bind-us...@isc.org Subject: Re: When does BIND send queries with DO flag enabled? Can someone explain when BIND sets DO flag and when it won't? Most of my client workstations are XPSP3, and NONE of the queries coming from those clients have DO flag set. The DO bit is part of the EDNS option record, and some servers (and more to the point, some firewalls) are broken and don't understand EDNS. When BIND doesn't initially get an answer to a query, it retries in different ways, and eventually (on the third try, if I recall correctly) it tries omitting the EDNS option. No EDNS means no DO bit, and I'm pretty sure that's what you're seeing on the trace. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courriel peut contenir des renseignements protégés et confidentiels. Lexpéditeur ne renonce pas aux droits et obligations qui sy rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements quil contient par une personne autre que le destinataire désigné est interdite. Si vous recevez ce courriel par erreur, veuillez men aviser immédiatement, par retour de courriel ou par un autre moyen. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: When does BIND send queries with DO flag enabled?
On Thu, 30 Sep 2010, Taylor, Gord wrote: The business partner has already fixed their firewall (allow_dnssec_bit=1 on CheckPoint) Just in case anyone else is worried about interop problems, I note that allow_dnssec_bit=1 is the default setting. A CheckPoint firewall administrator has to deliberately change a correct default in order to cause this kind of serious breakage. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
GSS-TSIG and Active Directory
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? _ Nicholas Miller, ITS, University of Colorado at Boulder ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: GSS-TSIG and Active Directory
On Thu, 30 Sep 2010, Nicholas F Miller wrote: Does anyone actually have GSS-TSIG working with an Active Directory? There are some GSS-TSIG interop fixes in 9.7.2. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: GSS-TSIG and Active Directory
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: tkey-gssapi-credential
Sorry, I spent most of the last two weeks locked in a conference room and mostly off net, still catching up. At Mon, 27 Sep 2010 07:54:54 -0600, Nicholas F Miller wrote: DNS Standard query TKEY 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e Queries 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class IN Additional records 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class ANY Algorithm name: gss-tsig Signature inception: Sep 27, 2010 07:26:04.0 Mountain Daylight Time Signature expiration: Sep 28, 2010 07:26:04.0 Mountain Daylight Time Mode: GSSAPI GSS-API Generic Security Service Application Program Interface OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation) Simple Protected Negotiation negTokenInit mechTypes: 3 items MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5) MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5) MechType: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - User to User) krb5_blob: KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5) Kerberos AP-REQ Realm: FQN of DOMAIN Server Name (Service and Instance): DNS/fqn of the DNS server DNS Standard query response TKEY Queries 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class IN Answers 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class ANY Algorithm name: gss-tsig Signature inception: Dec 31, 1969 17:00:00.0 Mountain Standard Time Signature expiration: Dec 31, 1969 17:00:00.0 Mountain Standard Time Mode: GSSAPI Error: Bad key The nameserver appears to be rejecting the GSSAPI negotiation due to some basic failure, there are too many possibilities (all of which the protocol lumps into BADKEY, sigh) to guess which. In theory named should have logged something like failed gss_accept_sec_context: blah where blah is the output of gss_error_tostring(); if there really is no such message (ie, it's not just lost under all the noise), this may indicate that you're somehow getting an impossible GSSAPI failure, ie, something that we don't ever expect to fail, so we're handling it via a RETERR() wrapper around an API call, or something like that (in which case said error clearly is not impossible and probably needs to be handled differently). The timestamps in the response is just the Unix epoch. I don't recall offhand whether that's what TKEY is supposed to return in this mode if there's no signature, but if not this would be consistent with the theory that something is erroring out early in processing. FWIW, here's the ktpass incantation that's worked for me in the past: C:\ ktpass -out foo.keytab -princ DNS/foo.example@example.org -pass * -mapuser f...@example.org where foo.keytab is the filename for the new keytab, DNS/foo.example@example.org is the principal name, and f...@example.org is the Active Directory user account. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone-recursion?
Per-zone recursion control doesn't exist in BIND, because frankly it doesn't make sense. 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). 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? 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. - Kevin On 9/30/2010 5:09 AM, Joerg Dorchain wrote: Hello, I am puzzled with a bind config for a kind of dns-reverse-proxy situation. I have a server with only one public IP addresse, bind running on port 53 of it. This bind serves examples.net. A subdomain dynsub.example.net should be served on some other software answering DNS request with dynamically generated answers. I can create a forward zone like this zone dynsup.example.net { type forward; forward only; forwarders { 127.0.0.1 port 5353; }; }; which works fine in the way that it forwards all queries to and all answers from the other DNS software running on port 5353, but - this is problem - only if the view with the statement allows recursion. For several reasons I do not want to answer all queries for all domains recursivly, just those for that one zone. When I turn recursion off, bind answers with a referal to itself (glue records work ;-), which in this case is not helpful. Does anybody have an idea on how I can persuade bind to answer only this zone recusivly? TIA, Joerg ___ 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
Bind not starting
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.86400INNSa1.nsdomain.com. a10.nsdomain.com.9INNSns1.nu.moon. a11.nsdomain.com.9INNSabc.nsdomain.com. a12.nsdomain.com.86400INNSmx.nsdomain.com. a13.nsdomain.com.86400INNScname.nsdomain.com. a13.nsdomain.com.86400INNSa.nsdomain.com. a13.nsdomain.com.86400INNSmx.nsdomain.com. a14.nsdomain.com.2147483647INNSns1.a14.nsdomain.com. a15.nsdomain.com.2147483647INNSns1.a15.nsdomain.com. a2.nsdomain.com.86400INNSnsdomain.com. a3.nsdomain.com.86400INNSa3.nsdomain.com. a3.nsdomain.com.86400INNSa2.nsdomain.com. a3.nsdomain.com.86400INNSa1.nsdomain.com. a3.nsdomain.com.86400INNSnsdomain.com. a4.nsdomain.com.86400INNSa4.nsdomain.com. a4.nsdomain.com.86400INNSa4.nsdomain.com. a4.nsdomain.com.86400INNSa4.nsdomain.com. A5.NSDOMAIN.COM.86400INFE80:: a5.NSDOMAIN.com.86400INFE80:: A5.nsdomain.com.86400INFE80:: a5.nsdomain.com.86400INFE80:: A5.NSDOMAIN.COM.86400INA255.255.255.255 a5.nsdomain.COM.86400INA255.255.255.255 a5.NSDOMAIN.com.86400INA255.255.255.255 A5.nsdomain.com.86400INA255.255.255.255 a5.nsdomain.com.86400INA255.255.255.255 a5.nsdomain.com.86400INNSA5.NSDOMAIN.COM. a5.nsdomain.com.86400INNSa5.nsdomain.COM. a5.nsdomain.com.86400INNSa5.NSDOMAIN.com. a5.nsdomain.com.86400INNSA5.nsdomain.com. A6.NSDOMAIN.COM.86400INA255.255.255.255 a6.nsdomain.COM.86400INA255.255.255.254 a6.NSDOMAIN.com.86400INA255.255.255.253 A6.nsdomain.com.86400INA255.255.255.252 a6.nsdomain.com.86400INA255.255.255.251 a6.nsdomain.com.86400INNSA6.NSDOMAIN.COM. a6.nsdomain.com.86400INNSa6.nsdomain.COM. a6.nsdomain.com.86400INNSa6.NSDOMAIN.com. a6.nsdomain.com.86400INNSA6.nsdomain.com. a6.nsdomain.com.86400INNSa6.nsdomain.com. A7.NSDOMAIN.COM.86400IN2001::1001 a7.nsdomain.COM.86400IN2001:: a7.NSDOMAIN.com.86400INFEA0:: A7.nsdomain.com.86400INFE90:: a7.nsdomain.com.86400INFE80:: a7.nsdomain.com.86400INNSA7.NSDOMAIN.COM. a7.nsdomain.com.86400INNSa7.nsdomain.COM. a7.nsdomain.com.86400INNSa7.NSDOMAIN.com. a7.nsdomain.com.86400INNSA7.nsdomain.com. a7.nsdomain.com.86400INNSa7.nsdomain.com. a8.nsdomain.com.0INNSns1.nu.moon. a9.nsdomain.com.100INNSns1.nu.moon. cname.nsdomain.com.86400INCNAMEnsdomain.com. mx.nsdomain.com.86400INMX10 nsdomain.com. net.nsdomain.com.86400INNSns3.dns.net.nsdomain.com. net.nsdomain.com.86400INNSns2.dns.net.nsdomain.com. net.nsdomain.com.86400INNSns1.dns.net.nsdomain.com. ns1.dns.net.nsdomain.com.86400IN 2001:0DCE:2000:0002::::0130 ns1.dns.net.nsdomain.com.86400INA202.46.190.130 ns2.dns.net.nsdomain.com.86400IN 2001:0DCE:2000:0002::::0130 ns2.dns.net.nsdomain.com.86400INA202.46.191.130 ns3.dns.net.nsdomain.com.86400INA203.97.8.250 *;nsdomain.com.86400INNSns2.nsdomain.com. ;nsdomain.com.86400INNSns1.nsdomain.com.* nsdomain.com.86400INNSdns2.dns.net. nsdomain.com.86400INNSdns1.dns.net. ;End of file: 1285827330 Thanks Regards, Ramesh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users