View Issue Details

IDProjectCategoryView StatusLast Update
0003325GNUnetGNSpublic2014-04-08 16:41
ReporterschanzenAssigned ToChristian Grothoff 
PriorityhighSeveritymajorReproducibilityhave not tried
Status closedResolutionfixed 
Product VersionSVN HEAD 
Target Version0.10.1Fixed in Version0.10.1 
Summary0003325: GNS lookups never time out
DescriptionLookup non existing label in your own zone. It will hang forever because DHT lookups have no timeout.
TagsNo tags attached.


Christian Grothoff

2014-02-16 15:24

manager   ~0008104

So why is this a problem? I don't see a problem with this in gnunet-gns, but it might be a problem in the NSS plugin if the standard requires the plugin to time out. In general, I'm fine with a DHT 'get' hanging, as any timeout is arbitrary. But if there is an "expected" timeout in NSS, we should of course realize that.


2014-02-16 15:34

manager   ~0008105

I see this as a problem:
I lookup a record that does not exist in my zone. gnunet-gns should not hang. This is defined behaviour im my opinion. A DHT lookup should never happen anyway.

Also it should be possible to "miss" in general. Not just "wait". Right now gns either has a result. or hangs? this is bad design.
And note that (I hope!) this is only an issue where we lookup nonexistant recods in locally manged zones where DHT should be irrelevant.

Program X always tries to lookup AAAA record for resolution.
If lookup fails fallback to A.

If gethostbyname is used then gns will hand forver on the AAAA lookup.
The program will have to create it's own timeout handling only for gns.

NSS does not force any timeouts... and we could implements that in the plugin but... that's not really the correct place to to that IMO.

Christian Grothoff

2014-02-16 15:38

manager   ~0008108

If it is our own zone (only), I agree that we should terminate 'instantly'. Also, if there is only an A record and AAAA is asked for (or vice versa), we should return immediately. I'll look into those. Still, the DHT-timeout case where there simply was no response found, that is another issue.


2014-02-16 15:39

manager   ~0008109

Yeat I think I miscommunicated the original issue. The thing is that it's impossible right now for the GNS resolver to "return immediately" as it has no concept of the "maste-zone"

Christian Grothoff

2014-02-16 15:55

manager   ~0008110

SVN 32351 ensures that GNS never uses the DHT if we only lookup in the master zone (only for gnunet-gns).

Christian Grothoff

2014-02-16 16:04

manager   ~0008111

SVN 32354 ensures that if GNS finds any (non-expired) block (even if all the records have the wrong record type) in the namecache, it won't even bother to go to the DHT.

Christian Grothoff

2014-02-16 16:10

manager   ~0008112

SVN 32357 adds a timeout option (-T) to gnunet-gns, which can be used by the NSS plugin if it wants to force a particular timeout on the child process. Note that NXDOMAIN on the master zone and "no matching record found" should already create a response, so I'm not sure this is required. Still, having the option seemed to make sense in general.


2014-02-16 21:38

manager   ~0008116

Fixed a small bug in gns api to make this work.

_however_ the problem is only band aided I think.
Looking up test.doesnotexist.gnu will hang again, eventhough it should not. I guess we can use the timeout then but... we really shouldn't have to.

Christian Grothoff

2014-02-17 00:21

manager   ~0008117

True; the issue is that right now the gnunet-service-gns doesn't even know if it is looking up a value for which the local peer is the origin. I guess we could change the API to pass that information through from the client...


2014-02-17 19:59

manager   ~0008122

The problem with fix is also: + records in remote zones are never reolved if it's the first label: ex. myfriend.gnu (A record)

I think it might make sense to move functionality into gnunet-gns:

if master zone is used:

lookup first label non cached;
1. No result
   -> fail
2. Result exists
   -> return result (if applicable, i.e. single label and not PKEY)
   -> resolve again non cached

Christian Grothoff

2014-03-04 12:28

manager   ~0008127

Ok, this should now be fixed in SVN 32499: I added an enum value to indicate that the top-level request is in the master zone, so even if there is foo.invalid.gnu, invalid.gnu won't go to the DHT anymore.

Christian Grothoff

2014-03-04 12:28

manager   ~0008128

Please let me know if it is better now (could not test reasonably well on this system).

Christian Grothoff

2014-03-05 15:37

manager   ~0008133

Tested it now, seems to work fine (for master zone).

Issue History

Date Modified Username Field Change
2014-02-14 21:25 schanzen New Issue
2014-02-14 21:25 schanzen Status new => assigned
2014-02-14 21:25 schanzen Assigned To => Matthias Wachs
2014-02-14 21:29 schanzen Assigned To Matthias Wachs => Christian Grothoff
2014-02-16 15:22 Christian Grothoff Target Version => 0.10.1
2014-02-16 15:24 Christian Grothoff Note Added: 0008104
2014-02-16 15:24 Christian Grothoff Status assigned => feedback
2014-02-16 15:34 schanzen Note Added: 0008105
2014-02-16 15:34 schanzen Status feedback => assigned
2014-02-16 15:38 Christian Grothoff Note Added: 0008108
2014-02-16 15:39 schanzen Note Added: 0008109
2014-02-16 15:55 Christian Grothoff Note Added: 0008110
2014-02-16 16:04 Christian Grothoff Note Added: 0008111
2014-02-16 16:10 Christian Grothoff Note Added: 0008112
2014-02-16 16:35 Christian Grothoff Status assigned => feedback
2014-02-16 21:38 schanzen Note Added: 0008116
2014-02-16 21:38 schanzen Status feedback => assigned
2014-02-17 00:21 Christian Grothoff Note Added: 0008117
2014-02-17 19:59 schanzen Note Added: 0008122
2014-03-04 12:28 Christian Grothoff Note Added: 0008127
2014-03-04 12:28 Christian Grothoff Note Added: 0008128
2014-03-04 12:28 Christian Grothoff Status assigned => feedback
2014-03-05 15:37 Christian Grothoff Note Added: 0008133
2014-03-05 15:37 Christian Grothoff Status feedback => resolved
2014-03-05 15:37 Christian Grothoff Fixed in Version => 0.10.1
2014-03-05 15:37 Christian Grothoff Resolution open => fixed
2014-04-08 16:41 Christian Grothoff Status resolved => closed