connect call failing with EINPROGRESS error code.
Hi, I am new to socket programming. Please help me with a situation. The function call connect (non -blocking) is failing with setting the errorcode as 36 (EINPROGRESS). I have checked all the relative things. They are set properly. ::connect(sd, ((struct sockaddr*) (void*) &(proxyDataPtr->remoteAddr)), sizeof(struct sockaddr)) Please help me with the solution to handle this situation. or some clues, what could be the problem !! Thanks in advance. Best Regards Richi =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
USADOTGOV.NET Root Problems?
Does anyone know if there have been problems with the USADOTGOV.NET root name servers today? We've had people complaining about resolving RADAR.WEATHER.GOV and several systems in the NOAA.GOV domain. If you query for the NS resource records, you only receive the ANSWER section. The ADDITIONAL section with the addresses is missing. -- Merton Campbell Crockett m.c.crock...@roadrunner.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: . SOA: got insecure response
In message <19526.43429.234698.104...@hadron.switch.ch>, Alexander Gall writes: > On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen > said: > > > Hello, > > Since enabling the root TA in my resolver, I keep seeing from time to time: > > > 21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: . > > SOA: attempting insecurity proof > > 21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: . > > SOA: insecurity proof failed > > 21-Jul-2010 08:52:27.929 dnssec: info: validating @0x134fe7e8: . SOA: > > got insecure response; parent indicates it should be secure > > I've seen this for various top-level domains for which I have trust > anchors configure as well. I could never track this down either, but I > suspect it has nothing to do with the authoritative servers. > > -- > Alex Named has to deal with multually incompatible senarios. DNSSEC which requires EDNS and nameservers and firewalls which drop EDNS requests so named has to turn off EDNS to get answers back. Occasionally a set of answers will take too long to get back to named or are lost due to network problems and named will fallback to issuing plain DNS queries which will of course fail validation if the zone is secure and you have a trusted path from a trust anchor to that zone. Named will normally re-issue the queries and get a answer that can be validated as it tries again to use EDNS. This will happen more often if you have network equipment that is blocking large DNS responses (>512 or network MTU) but still lets through EDNS responses. If you see this you should also look for congested network paths and paths with long delays. Mark > > Otherwise validation just works fine and mostly I see these: > > validating @0x134fe7e8: . SOA: marking as secure, noqname proof not needed > > > Following an earlier comment on this list by Mark Andrews ( > > http://www.mail-archive.com/bind-users@lists.isc.org/msg04276.html ) > > I've checked the answers given by the 13 root instances (ipv4 and 6), > > and all answer to "dig . soa +dnssec" just fine. > > > Trying to capture . SOA queries from the resolver (by a crude > > tcpdump/grep) failed to show something useful. > > > Any idea what could be the reason for these messages, and how to > > confirm/retrace the events that lead to such messages? Could it be that > > lame auth server with a local (unsigned) copy of the root zone triggers > > this? > > > best regards, > > Gilles > > > -- > > Fondation RESTENA - DNS-LU > > 6, rue Coudenhove-Kalergi > > L-1359 Luxembourg > > tel: (+352) 424409 > > fax: (+352) 422473 > > ___ > > 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 -- 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
IPv6 Records on an IPv4 Network
This is admittedly not a bind question, but it has become a major nag factor and I am not sure what to recommend. We delegate our Microsoft Active Directory zone to Microsoft domain controllers and they have stuffed their zone with about 750 AAA records and all are publicly visible if one does a lookup. even the top level of the AD domain has 10 IPv6 responses, one for each controller. The AD admins say that IPv6 is turned off and that the work stations register IPv6 addresses automatically and so forth, but the final truth is that they are there, however they got there, and other systems will get the records when they try to resolve the host name. Recently, there was a Microsoft update which appears to cause the resolvers on these Windows7 systems to favor IPv6 records first and now I am getting reports of timeouts from Windows boxes looking up other Windows boxes. What I am asking the list is whether or not anybody knows of a way to get the Microsoft controllers to ignore the IPv6 registrations. Having 0 IPv6 records would probably solve the problem until the day we get a IPv6 allocation and make our nework IPv6 capable. As of now, it is a down right nuisance. I am running bind in its default mode where it could handle both IPv4 and IPv6 addresses, but we have no IPv6 addresses at all in the zones that we do not delegate. I believe that if I ran bind in IPv4-only mode, it would make no difference because the problem zone is delegated. If I am wrong about that, please let me know. In best IT tradition, I am hearing "Do something!" and it seems to me that there is nothing I can do as the zone is delegated. Thanks for any constructive ideas or references which will help the AD folks get rid of those IPv6 records for now. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Telecommunications Services Group ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Questions regarding global MX and NS records
On 7/21/2010 2:01 PM, Kevin Darcy wrote: On 7/21/2010 1:15 PM, Atkins, Brian (GD/VA-NSOC) wrote: After specifying MX records for a 2nd tier domain, is it necessary to restate the MX records for a new $ORIGIN? For example, if I have: $ORIGIN . ... IN MX 10 mx1.example.com. IN MX 10 mx2.example.com. IN MX 10 mx3.example.com. IN MX 10 mx4.example.com. Do I also need to do the following?: $ORIGIN blah.example.com. MX10mx1.example.com. MX10mx2.example.com. MX10mx3.example.com. MX10mx4.example.com. Or is the first statement sufficient to cover all sub-domains as long as the MX records are the same? No, those MX records are owned by different names (example.com and blah.example.com). It is possible to create wildcard MX records (*.example.com) but there are serious caveats to doing that, since some MTAs don't handle wildcard MX matching very well. Also, if you have a wildcard in a zone, then you'll never get an NXDOMAIN for a query of any name in that part of the namespace hierarchy, because the names in such queries will be "matched" by the wildcard, even if the lookup is some type other than MX. This might have implications in terms of support/troubleshooting procedures, caching efficiency, etc. Personally I'm a fan of using wildcards where they make sense, but you have to be *very* careful with them. Go in with your eyes open. Also, I have a number of records that I redirect to a GSLB device and have 1,000+ records that I delegate to the devices as follows: $ORIGIN blah.example.com. www NS gss1.example.com. NS gss2.example.com. Is there a more efficient method of doing this, eliminating the need to do this for every sub-domain? Perhaps a forward statement in the conf file? No, forwarding doesn't work here. The queries you're getting for this are predominantly *non-recursive*, and non-recursive queries are never forwarded. We choose to use aliases for this, e.g. lb.example.com. ns gss1.lb.example.com. lb.example.com. ns gss2.lb.example.com. www1.example.com cname www1.lb.example.com. www2.example.com. cname www2.lb.example.com. www3.example.com. cname www3.lb.example.com. etc. This means we only need 1 record (the CNAME) for each website, rather than a delegation per website. Also, aliasing things this way allows the GSS to respond sanely with SOA/NS records for the delegated zone (lb.example.com), when the GSS is configured properly to proxy non-A queries to the servers of a "shadow" version of the zone. If you delegate each name individually to the GSS, you don't get proper SOA/NS record responses (unless you were to configure "shadow" versions for *all* 1,000+ of those zones, but that's way too much work). Why do you care whether the GSS has access to SOA records for any given zone? Because SOAs are required for proper negative caching. See RFC 2308. (Whoops, I forgot a trailing period in one of the example lines above). Another benefit of aliasing out each name, instead of delegating each one individually, is that you avoid a lot of "sub-delegation" ugliness if you have multiple sets of load-balancers, and you want to *nest* names, using diverse sets of load-balancers, within their own application-defined hierarchies, e.g. ; 2 distinct sets of load-balancers, production and pre-production production-loadbalancers.example.com. ns gss1.example.com. production-loadbalancers.example.com. ns gss2.example.com. preprod-loadbalancers.example.com. ns gss3.example.com. preprod-loadbalancers.example.com. ns gss4.example.com. ; Production website for customer support, using production load-balancers support.example.com. cname support-website.production-loadbalancers.example.com. ; Pre-production website for customer support, using preprod load-balancers preprod.support.example.com. cname support-website.preprod-loadbalancers.example.com. (Sure, if you can convince your app people to *not* use a DNS-label-based hierarchy, e.g. by embedding *within* a label, e.g. preprod-support.example.com, then that's another way to avoid the ugliness, but oftentimes there are application dependences on DNS names, e.g. SSL certificates, and in any case why impose an unnecessary naming limitation?) - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Questions regarding global MX and NS records
On 7/21/2010 1:15 PM, Atkins, Brian (GD/VA-NSOC) wrote: After specifying MX records for a 2nd tier domain, is it necessary to restate the MX records for a new $ORIGIN? For example, if I have: $ORIGIN . ... IN MX 10 mx1.example.com. IN MX 10 mx2.example.com. IN MX 10 mx3.example.com. IN MX 10 mx4.example.com. Do I also need to do the following?: $ORIGIN blah.example.com. MX 10 mx1.example.com. MX 10 mx2.example.com. MX 10 mx3.example.com. MX 10 mx4.example.com. Or is the first statement sufficient to cover all sub-domains as long as the MX records are the same? No, those MX records are owned by different names (example.com and blah.example.com). It is possible to create wildcard MX records (*.example.com) but there are serious caveats to doing that, since some MTAs don't handle wildcard MX matching very well. Also, if you have a wildcard in a zone, then you'll never get an NXDOMAIN for a query of any name in that part of the namespace hierarchy, because the names in such queries will be "matched" by the wildcard, even if the lookup is some type other than MX. This might have implications in terms of support/troubleshooting procedures, caching efficiency, etc. Personally I'm a fan of using wildcards where they make sense, but you have to be *very* careful with them. Go in with your eyes open. Also, I have a number of records that I redirect to a GSLB device and have 1,000+ records that I delegate to the devices as follows: $ORIGIN blah.example.com. www NS gss1.example.com. NS gss2.example.com. Is there a more efficient method of doing this, eliminating the need to do this for every sub-domain? Perhaps a forward statement in the conf file? No, forwarding doesn't work here. The queries you're getting for this are predominantly *non-recursive*, and non-recursive queries are never forwarded. We choose to use aliases for this, e.g. lb.example.com. ns gss1.lb.example.com. lb.example.com. ns gss2.lb.example.com. www1.example.com cname www1.lb.example.com. www2.example.com. cname www2.lb.example.com. www3.example.com. cname www3.lb.example.com. etc. This means we only need 1 record (the CNAME) for each website, rather than a delegation per website. Also, aliasing things this way allows the GSS to respond sanely with SOA/NS records for the delegated zone (lb.example.com), when the GSS is configured properly to proxy non-A queries to the servers of a "shadow" version of the zone. If you delegate each name individually to the GSS, you don't get proper SOA/NS record responses (unless you were to configure "shadow" versions for *all* 1,000+ of those zones, but that's way too much work). Why do you care whether the GSS has access to SOA records for any given zone? Because SOAs are required for proper negative caching. See RFC 2308. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Questions regarding global MX and NS records
After doing some additional reading, I have another question related to
the MX records.
Using the forward and forwarders statements as follows I could
potentially remove the NS statements for the sub-domains which redirect
queries to the GSLB devices:
forward first;
forwarders { gss1; gss2; };
However, my understanding is that, when the question is asked by the
client, that the question is forwarded on to the servers in the
forwarders statement, but the response is received by the original BIND
server and it responds to the client. If that is the case, this will, to
some effect, negate the ability to GSLB.
Is that a correct statement?
Brian
-Original Message-
From: bind-users-bounces+brian.atkins2=va@lists.isc.org
[mailto:bind-users-bounces+brian.atkins2=va@lists.isc.org] On Behalf
Of Atkins, Brian (GD/VA-NSOC)
Sent: Wednesday, July 21, 2010 1:15 PM
To: bind-users@lists.isc.org
Subject: Questions regarding global MX and NS records
After specifying MX records for a 2nd tier domain, is it necessary to
restate the MX records for a new $ORIGIN? For example, if I have:
$ORIGIN .
...
IN MX 10 mx1.example.com.
IN MX 10 mx2.example.com.
IN MX 10 mx3.example.com.
IN MX 10 mx4.example.com.
Do I also need to do the following?:
$ORIGIN blah.example.com.
MX 10 mx1.example.com.
MX 10 mx2.example.com.
MX 10 mx3.example.com.
MX 10 mx4.example.com.
Or is the first statement sufficient to cover all sub-domains as long as
the MX records are the same?
Also, I have a number of records that I redirect to a GSLB device and
have 1,000+ records that I delegate to the devices as follows:
$ORIGIN blah.example.com.
www NS gss1.example.com.
NS gss2.example.com.
Is there a more efficient method of doing this, eliminating the need to
do this for every sub-domain? Perhaps a forward statement in the conf
file?
Brian
___
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
Questions regarding global MX and NS records
After specifying MX records for a 2nd tier domain, is it necessary to restate the MX records for a new $ORIGIN? For example, if I have: $ORIGIN . ... IN MX 10 mx1.example.com. IN MX 10 mx2.example.com. IN MX 10 mx3.example.com. IN MX 10 mx4.example.com. Do I also need to do the following?: $ORIGIN blah.example.com. MX 10 mx1.example.com. MX 10 mx2.example.com. MX 10 mx3.example.com. MX 10 mx4.example.com. Or is the first statement sufficient to cover all sub-domains as long as the MX records are the same? Also, I have a number of records that I redirect to a GSLB device and have 1,000+ records that I delegate to the devices as follows: $ORIGIN blah.example.com. www NS gss1.example.com. NS gss2.example.com. Is there a more efficient method of doing this, eliminating the need to do this for every sub-domain? Perhaps a forward statement in the conf file? Brian ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Maching characteristics
Hi Well i wonder this is the right place. What server characteristics you recomend me as minimum for a bind that will get about 1 req/sec Linux OS. LD ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND upgrade Solaris 10 SPARC
Hi All, I am a newbie in BIND. I want to ask for your help on how to upgrade the BIND version of my DNS. I am using Solaris 10 SPARC and my current BIND version is BIND 9.6.0-P1. I am planning to upgrade to the latest BIND version, BIND 9.7.1-P2. What are the requirements and procedure for the upgrade? If I plan to revert to my old BIND version, what are the steps? Thanks and Regards, Rock ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.7.1-P2 for Solaris 8, 9 and 10 released
> BIND 9.7.1-P2 is a maintenance release for BIND 9.7. > Just an FYI, there are SMF aware packages for bind 9.7.1-P2 avail from the Blastwave mirrors now. All world wide mirrors will sync within hours but the primary ( at ISC ) is at http://download.blastwave.org Please use pkgutil to fetch software packages. see : http://mail.opensolaris.org/pipermail/opensolaris-help/2010-July/019259.html http://mail.opensolaris.org/pipermail/opensolaris-help/2010-July/019260.html Thanks -- Dennis Clarke dclarke at opensolaris.ca <- Email related to the open source Solaris dclarke at blastwave.org <- Email related to open source for Solaris ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: . SOA: got insecure response
On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen said: > Hello, > Since enabling the root TA in my resolver, I keep seeing from time to time: > 21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: . > SOA: attempting insecurity proof > 21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: . > SOA: insecurity proof failed > 21-Jul-2010 08:52:27.929 dnssec: info: validating @0x134fe7e8: . SOA: > got insecure response; parent indicates it should be secure I've seen this for various top-level domains for which I have trust anchors configure as well. I could never track this down either, but I suspect it has nothing to do with the authoritative servers. -- Alex > Otherwise validation just works fine and mostly I see these: > validating @0x134fe7e8: . SOA: marking as secure, noqname proof not needed > Following an earlier comment on this list by Mark Andrews ( > http://www.mail-archive.com/bind-users@lists.isc.org/msg04276.html ) > I've checked the answers given by the 13 root instances (ipv4 and 6), > and all answer to "dig . soa +dnssec" just fine. > Trying to capture . SOA queries from the resolver (by a crude > tcpdump/grep) failed to show something useful. > Any idea what could be the reason for these messages, and how to > confirm/retrace the events that lead to such messages? Could it be that > lame auth server with a local (unsigned) copy of the root zone triggers > this? > best regards, > Gilles > -- > Fondation RESTENA - DNS-LU > 6, rue Coudenhove-Kalergi > L-1359 Luxembourg > tel: (+352) 424409 > fax: (+352) 422473 > ___ > 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
. SOA: got insecure response
Hello, Since enabling the root TA in my resolver, I keep seeing from time to time: 21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: . SOA: attempting insecurity proof 21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: . SOA: insecurity proof failed 21-Jul-2010 08:52:27.929 dnssec: info: validating @0x134fe7e8: . SOA: got insecure response; parent indicates it should be secure Otherwise validation just works fine and mostly I see these: validating @0x134fe7e8: . SOA: marking as secure, noqname proof not needed Following an earlier comment on this list by Mark Andrews ( http://www.mail-archive.com/bind-users@lists.isc.org/msg04276.html ) I've checked the answers given by the 13 root instances (ipv4 and 6), and all answer to "dig . soa +dnssec" just fine. Trying to capture . SOA queries from the resolver (by a crude tcpdump/grep) failed to show something useful. Any idea what could be the reason for these messages, and how to confirm/retrace the events that lead to such messages? Could it be that lame auth server with a local (unsigned) copy of the root zone triggers this? best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
