Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000024 [MyDNS-NG] Global crash always 2009-05-26 12:42 2014-08-07 21:48
Reporter wiese View Status public  
Assigned To howardwilkinson
Priority normal Resolution unable to reproduce  
Status closed   Product Version
Summary 0000024: Recursive timeout problems
Description We use since many years the "original" MyDNS.
We want to switch now to MyDNS-NG. One of the main reasons is
that we can use it as "resolver" with a backend dns resolver.


MyDNS-NG works fine with it's own zones. When it got started/restarted,
it connects smoothly to the recursive dns resolver (dnscache)
and replies the query:

>nslookup www.ripe.net
Server: ns1.trabia.net
Address: 2a01:320:32::10

Non-authoritative answer:
Name: aquila-www.ripe.net
Addresses: 2001:610:240:11::c100:1319
          193.0.19.25
Aliases: www.ripe.net


After some minutes/some queries, MyDNS doesn't likes
to make recursive queries anymore:

C:\Users\Sven Wiese>nslookup www.ripe.net
Server: ns1.trabia.net
Address: 2a01:320:32::10

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to ns1.trabia.net timed-out

Sometimes it gives an answer, but this is very rarely.
After a restart of MyDNS-NG, its working again, for some
minutes/queries. And then it again begins to timeout.

This problem appears with IPv4 AND IPv6.
Additional Information Installed:
MyDNS-NG 1.2.8.27 (from source)
dnscache (djbdns) (with aptitude from debian)


mydns.conf:
listen = 194.169.204.10
listen = 2a01:320:32::10

recursive = 127.0.0.1
recursive-timeout = 2
recursive-retries = 3
recursive-algorithm = linear


dnscache:
Is bounded to lo interface,
that MyDNS-NG can connect to it.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0000067)
wiese (reporter)
2009-06-17 07:22

Mmm

Looks like no one maintains this anymore.
Sad.
(0000068)
howardwilkinson (administrator)
2009-06-28 11:47

Can you check that the recursor is responding when this happens please i.e. issue the queries directly against the cache.

Also, can you compile with debug and switch full debugging on. You will get massive amounts of output but if you can catch the messages around the failure that will be helpful.

If you run large numbers of repeated recursive queries (i.e. for the same record) does the failure 1) happen? 2) happen faster or slower 3) Show up in the same way

Does the rate of query have any impact on the failure?

I have a alpha release about ready to go out which has more comprehensive and targetable debugging could you run this to see if you get the same behaviour?

Finally, are the recursive requests over UDP or TCP? The recursor is currently written to preserve the request unless it gets truncation when it will try TCP if is is not already TCP. As we do not yet support EDNS0, this may be the cause as this code path is not well exercised?
(0000212)
jameno123 (administrator)
2014-08-07 21:48

If this issue is still occurring with the latest release (1.2.8.31) please re-open and comment. Otherwise closing this bug for inactivity and being unable to reproduce the explained results.

- Issue History
Date Modified Username Field Change
2009-05-26 12:42 wiese New Issue
2009-06-17 07:22 wiese Note Added: 0000067
2009-06-28 10:18 jorge Status new => assigned
2009-06-28 10:18 jorge Assigned To => howardwilkinson
2009-06-28 11:47 howardwilkinson Note Added: 0000068
2014-08-07 21:48 jameno123 Note Added: 0000212
2014-08-07 21:48 jameno123 Status assigned => closed
2014-08-07 21:48 jameno123 Resolution open => unable to reproduce


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker