Re: named’s “/dev/random error on AIX
Can't see what you posted.. can you post as a text? From subject message it appears that you see /dev/random failure in syslog. What is the impact? Do you see issues in dnssec-keygen etc? On Jan 8, 10:47 pm, Fuhua Zhang harr...@21cn.com wrote: This is a multi-part message in MIME format. --===1396204079421272685== Content-Type: multipart/alternative; boundary==_NextPart_000_007A_01C97250.199BA270 This is a multi-part message in MIME format. --=_NextPart_000_007A_01C97250.199BA270 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 TXkgQUlYNS4zIHN5c3Rlcm0gZG9lcyBoYXZlIGEgL2Rldi9yYW5kb20gYW5kIC9kZXYvdXJhbmRv baO6DQoNCmRuczg6LyNjZCAvZGV2DQpkbnM4Oi9kZXYjbHMgLWwgKnJhbmQqDQpjcnctci0tci0t ICAgIDEgcm9vdCAgICAgc3lzdGVtICAgICAgIDM5LCAgMCBEZWMgMTYgMTM6NDIgcmFuZG9tDQpj cnctci0tci0tICAgIDEgcm9vdCAgICAgc3lzdGVtICAgICAgIDM5LCAgMSBEZWMgMTYgMTM6NDIg dXJhbmRvbQ0KDQphbmQNCg0KdHpkbnM4Oi8jb2RtZ2V0IEN1RHZEciB8IGdyZXAgLXAgcmFuZG9t DQpDdUR2RHI6DQogICAgICAgIHJlc291cmNlID0gImRkaW5zIg0KICAgICAgICB2YWx1ZTEgPSAi cmFuZG9tIg0KICAgICAgICB2YWx1ZTIgPSAiMzkiDQogICAgICAgIHZhbHVlMyA9IA0KDQp0aGUg ZXJyb3IgbWVzc2FnZXMgc3RpbGwgY2FtZSBvdXQgYXMgZm9sbG93czoNCg0KZG5zODojLi9uYW1l ZCAtZyAtZCA5OQ0KLi4uLg0KMDktSmFuLTIwMDkgMTE6NDE6NDYuOTU0IHNldCBtYXhpbXVtIHN0 YWNrIHNpemUgdG8gMjE0NzQ4MzY0NjogWW91IG11c3QgdXNlIHRoZSBrZXlib2FyZCB0byBjcmVh dGUgZW50cm9weSwgc2luY2UgeW91ciBzeXN0ZW0gaXMgbGFja2luZw0KIC9kZXYvcmFuZG9tIChv ciBlcXVpdmFsZW50KQ0KDQoNCjA5LUphbi0yMDA5IDExOjQxOjQ2Ljk1NCBzZXQgbWF4aW11bSBk YXRhIHNpemUgdG8gMjE0NzQ4MzY0NzogWW91IG11c3QgdXNlIHRoZSBrZXlib2FyZCB0byBjcmVh dGUgZW50cm9weSwgc2luY2UgeW91ciBzeXN0ZW0gaXMgbGFja2luZw0KIC9kZXYvcmFuZG9tIChv ciBlcXVpdmFsZW50KQ0KDQoNCjA5LUphbi0yMDA5IDExOjQxOjQ2Ljk1NCBzZXQgbWF4aW11bSBj b3JlIHNpemUgdG8gMjE0NzQ4MzY0NzogWW91IG11c3QgdXNlIHRoZSBrZXlib2FyZCB0byBjcmVh dGUgZW50cm9weSwgc2luY2UgeW91ciBzeXN0ZW0gaXMgbGFja2luZw0KIC9kZXYvcmFuZG9tIChv ciBlcXVpdmFsZW50KQ0KDQoNCjA5LUphbi0yMDA5IDExOjQxOjQ2Ljk1NCBzZXQgbWF4aW11bSBv cGVuIGZpbGVzIHRvIC0xOiBZb3UgbXVzdCB1c2UgdGhlIGtleWJvYXJkIHRvIGNyZWF0ZSBlbnRy b3B5LCBzaW5jZSB5b3VyIHN5c3RlbSBpcyBsYWNraW5nDQogL2Rldi9yYW5kb20gKG9yIGVxdWl2 YWxlbnQpDQoNCi4uLi4NCg0KMDktSmFuLTIwMDkgMTE6NDE6NDcuMTMzIGxvYWRfY29uZmlndXJh dGlvbjogWW91IG11c3QgdXNlIHRoZSBrZXlib2FyZCB0byBjcmVhdGUgZW50cm9weSwgc2luY2Ug eW91ciBzeXN0ZW0gaXMgbGFja2luZw0KIC9kZXYvcmFuZG9tIChvciBlcXVpdmFsZW50KQ0KDQp0 aGFua3MuDQpoYXJyeQ0K --=_NextPart_000_007A_01C97250.199BA270 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC41NzMwLjEzIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0KPEJP RFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+DQo8RElWPjxGT05UIHNpemU9 Mj5NeSBBSVg1LjMgc3lzdGVybSBkb2VzIGhhdmUgPC9GT05UPjxGT05UIHNpemU9Mz5hIA0KL2Rl di9yYW5kb20mbmJzcDthbmQgL2Rldi91cmFuZG9to7o8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ZG5zODovI2NkIC9kZXY8QlI+ZG5zODovZGV2I2xz IC1sIA0KKnJhbmQqPEJSPmNydy1yLS1yLS0mbmJzcDsmbmJzcDsmbmJzcDsgMSByb290Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0Kc3lzdGVtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDM5LCZuYnNwOyAwIERlYyAxNiAxMzo0MiANCnJhbmRvbTxCUj5jcnctci0tci0tJm5i c3A7Jm5ic3A7Jm5ic3A7IDEgcm9vdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnN5c3RlbSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzOSwmbmJzcDsgMSBEZWMgMTYgMTM6 NDIgDQp1cmFuZG9tPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YW5kPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+dHpkbnM4Oi8jb2Rt Z2V0IEN1RHZEciB8IGdyZXAgLXAgDQpyYW5kb208QlI+Q3VEdkRyOjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzb3VyY2UgPSANCiJkZGlucyI8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhbHVlMSA9IA0KInJhbmRv bSI8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhbHVlMiA9 IA0KIjM5IjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFs dWUzID0gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+dGhlIGVycm9yIG1lc3NhZ2VzIHN0aWxsIGNhbWUgb3V0IGFz IGZvbGxvd3M6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PEJSPmRuczg6Iy4vbmFt ZWQgLWcgLWQgOTk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4uLi4uPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+MDktSmFuLTIwMDkgMTE6NDE6NDYuOTU0IHNldCBtYXhp bXVtIHN0YWNrIHNpemUgdG8gMjE0NzQ4MzY0NjogDQpZb3UgbXVzdCB1c2UgdGhlIGtleWJvYXJk IHRvIGNyZWF0ZSBlbnRyb3B5LCBzaW5jZSB5b3VyIHN5c3RlbSBpcyANCmxhY2tpbmc8QlI+Jm5i c3A7L2Rldi9yYW5kb20gKG9yIGVxdWl2YWxlbnQpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjxGT05UIHNpemU9Mj4NCjxESVY+PEJSPjA5LUphbi0y MDA5IDExOjQxOjQ2Ljk1NCBzZXQgbWF4aW11bSBkYXRhIHNpemUgdG8gMjE0NzQ4MzY0NzogWW91
Re: Issues in delegating to subdomain owned by other company
On 10.01.09 14:04, blrmaani wrote: When we delegate a subdomain, should the nameserver to which we delegate be AUTHORITATIVE? yes What happens if the nameserver to which we delegate the subdomain is a NON-AUTHORITATIVE nameserver (eg., cache-only name server ). ? Could this be the reason for failure? yes -- 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. I just got lost in thought. It was unfamiliar territory. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issues in delegating to subdomain owned by other company
In message 937b61bf-c12f-4498-b20c-8cd5613bd...@z1g2000yqn.googlegroups.com, blrmaani writes: I have configured my named (BIND-9) to delegate a subdomain owned by our partner company. The queries in the subdomain are failing intermittently. Our partner company IT team is not ready to reveal their DNS configuration. When we delegate a subdomain, should the nameserver to which we delegate be AUTHORITATIVE? Not should, MUST be authoritative. It MUST return responses with aa set in the flags to non-reqursive queries for names within the delegated namespace or it MUST return a referral to nameservers which in turn are authoritative for the sub-delegated namespace. Note: queries for the SOA record at the delegation MUST return the SOA record with aa set. There is no horizontal delegation in the DNS. What happens if the nameserver to which we delegate the subdomain is a NON-AUTHORITATIVE nameserver (eg., cache-only name server ). ? It won't work. Could this be the reason for failure? Yes. Any comments? Cheers Maani ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem resolving www.lmsintl.com
Apisa, Kathy (US - MABS) wrote: I am running bind 9,4.2-P2 You'll want to upgrade that to 9.4.3-P1 for better security, performance, etc. on windows and can resolve all external Domains names Really? You've tried them ALL? :) with the exception of www.lmsintl.com http://www.lmsintl.com/ Doing a “dig www.lmsintl.com http://www.lmsintl.com/ +trace returns the proper address If I do a ping or nslookup on www.lmsintl.com http://www.lmsintl.com/ I get an error can’t find www.lmsintl.com http://www.lmsintl.com/: server failed therefore I am unable to access their website. This indicates that there is a problem with your system's resolver. Can you paste the output of the commands that are failing? FWIW, I have no problems resolving that host and the domain appears to be configured correctly. www is a cname to lmsintl.com, but that shouldn't cause the problems you're seeing. hth, Doug ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issues in delegating to subdomain owned by other company
In article gkb7mt$lt...@sf1.isc.org, blrmaani blrma...@gmail.com wrote: Thanks.. so if I dig further deeper on this it appears that the the query being sent to the subdomain's nameserver is NON-RECURSIVE. So, if the resource-records are already cached on the subdomain's nameserver (assuming non-authoritative nameserver here), then the queries are responded else the queries FAIL (SERVFAIL?). Is this assumption correct.. Correct. One way to fix this would be to add a forwarder for the subdomain on my nameserver to prevent any changes on partner company's nameserver. Any other approaches? A forwarder won't help. The queries sent from other nameservers to your nameserver are non-recursive as well. Forwarders are only followed when recursing. A forwarder entry will only help with recursive queries coming from your own users. cheers Maani. On Jan 10, 5:19 pm, Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 10.01.09 14:04, blrmaani wrote: When we delegate a subdomain, should the nameserver to which we delegate be AUTHORITATIVE? yes What happens if the nameserver to which we delegate the subdomain is a NON-AUTHORITATIVE nameserver (eg., cache-only name server ). ? Could this be the reason for failure? yes -- 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. I just got lost in thought. It was unfamiliar territory. ___ bind-users mailing list bind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-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
Re: BIND Security Advisory (CVE-2009-0025; Severity: Low)
At Thu, 8 Jan 2009 09:10:42 -0500, David Coulthart wrote: Would someone be able to provide some more details as to what particular configurations of BIND this affects? My interpretation is it only impacts recursive nameservers that have DNSSEC validation enabled. And not even all of those. It only affects DSA signatures (RSA is not affected), and only if an attacker can provoke a rather peculiar error condition. The root problem, which was also behind the recent OpenSSL release, is that a couple of the low-level OpenSSL libcrypto library functions that deal with DSA signatures return a tri-state value rather than a boolean: 1 == success, 0 == bad signature, -1 == other failure (eg, malloc() failure). The corresponding RSA functions return boolean values, this is a peculiarity of the DSA routines. Due to the, um, minimal nature of the OpenSSL internals documentation, a lot of code that calls the OpenSSL DSA was not checking the error returns correctly, and was misinterpreting other errors as success. Among others, affected code included both a few routines in BIND's DNSSEC code and portions of OpenSSL itself (if you look closely at the recent OpenSSL release, you'll see that there were a bunch of little changes in libssl to fix this). So an attacker trying to exploit this vulnerablity would have to provoke an other error while the victim was validating a DSA signature. This is pretty freaking unlikely, hence the Severity: low rating on the BIND security advisory, but as nobody can prove that this can't be done and BIND really wasn't checking the return code correctly, it seemed best to handle the fix as a security issue. Speaking in terms of BIND config options, the dnssec-validation option would need to be set to yes (so just having the default of dnssec-enable set to yes isn't enough to make the server vulnerable). Is this a correct interpretation? Vulnerable in this case means could be tricked into believing DNSSEC signatures that should not have passed validation. That is, we're not talking about named crashing here, we're talking about a security mechanism not working as expected due to a bug. If you don't have DNSSEC validation enabled you presumably have no expectation that DNSSEC signatures will be checked correctly, so, indeed, you are not affected, in that without DNSSEC there are easier ways to feed you bad data. At Fri, 09 Jan 2009 15:37:27 -0500, Steve Shockley wrote: The OpenSSL vulnerability affects DSA and ECDSA certificates; an attacker is able to bypass validation of the certificate. Since DNSSEC uses ECDSA, this means an attacker could use a forged certificate in a man-in-the-middle attack. s/certificate/RRSIG/ (DNSSEC doesn't use certificates). If you're not using DNSSEC, then this vulnerability doesn't really affect you, since you already have no way of knowing if a MITM attack is occurring. Exactly. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
