< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index |
Scott, Thanks; that is what I expected as well. It is actually fairly simple to duplicate. If you remove the DNS entries from Windows, start reciprocate, and then add the Windows DNS, then you will see that the stack is unable to respond to a message that contains an FQDN in the contact header. Mike From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin Hi Mike, I've never noticed this before, but then again I've never really tested it. I suspect the problem lies somewhere in the forked ares library. Scott On Thu, Jun 27, 2013 at 2:16 PM, Mike Hubbard <mike.hubbard@xxxxxxx> wrote: Hello, We have a customer who is running the reciprocate stack (I believe their version is 1.8.6) in our product on Windows. The customer is running the stack on one segment of the network, e.g. 10.10.1.100, and the primary and secondary DNS servers are on a different segment, e.g. 10.10.0.2 and 10.10.0.3. The customer experienced a primary DNS failure, however in Windows the secondary DNS was still responding fine. Eventually they got the primary DNS server back online, but the reciprocate stack was unable to recover until it was restarted, i.e. no calls were processed from the time the primary DNS failed until the primary DNS was restored and the stack restarted. Has anyone experienced this type of problem before? Mike
|