View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005812 | GNUnet | GNS | public | 2019-07-20 13:13 | 2019-07-24 20:41 |
Reporter | rexxnor | Assigned To | schanzen | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | won't fix | ||
Product Version | Git master | ||||
Target Version | 0.11.6 | Fixed in Version | 0.11.6 | ||
Summary | 0005812: Unable to resolve non-public records in GNS | ||||
Description | When adding a record to namestore without the public flag the record is not resolvable using gnunet-gns. Adding a record with the public flag works as intended. | ||||
Steps To Reproduce | Add an identity "foo" $ gnunet-identity -C foo Add a record without the public flag $ gnunet-namestore -a -z foo -n test -e 3600s -t A -V 1.1.1.1 Add a record with the public flag $ gnunet-namestore -a -z foo -n test2 -e 3600s -t A -V 1.1.1.1 -p Test both records: $ gnunet-gns -t A -u test.foo -> Does not terminate $ gnunet-gns -t A -u test2.foo test2.foo: Got `A' record: 1.1.1.1 | ||||
Tags | No tags attached. | ||||
|
I am unable to reproduce this: bash-5.0# gnunet-identity -C foo bash-5.0# gnunet-namestore -a -z foo -n test -e 3600s -t A -V 1.1.1.1 bash-5.0# gnunet-gns -u test.foo test.foo: Got `A' record: 1.1.1.1 bash-5.0# gnunet-namestore -a -z foo -n test -e 3600s -t A -V 1.1.1.1 -p bash-5.0# gnunet-gns -u test.foo test.foo: Got `A' record: 1.1.1.1 Got `A' record: 1.1.1.1 |
|
I debugged both programs and came to this: $ gdb --args gnunet-gns -t A -u test.foo GNU gdb (GDB) 8.3 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from gnunet-gns... (gdb) run Starting program: /usr/local/bin/gnunet-gns -t A -u test.foo [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". ^C Program received signal SIGINT, Interrupt. 0x00007ffff75b7e0b in select () from /usr/lib/libc.so.6 (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x00007ffff75b7e0b in select () from /usr/lib/libc.so.6 (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x00007ffff75b7e0b in select () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff75b7e0b in select () from /usr/lib/libc.so.6 #1 0x00007ffff7f7dbd6 in GNUNET_NETWORK_socket_select (rfds=rfds@entry=0x100007e70, wfds=wfds@entry=0x100007f00, efds=efds@entry=0x0, timeout=...) at network.c:1850 #2 0x00007ffff7f8d8d0 in select_loop (context=0x7fffffffd880, sh=0x100020ad0) at scheduler.c:2340 #3 GNUNET_SCHEDULER_run (task=task@entry=0x7ffff7f83e40 <program_main>, task_cls=task_cls@entry=0x7fffffffd930) at scheduler.c:732 #4 0x00007ffff7f844ef in GNUNET_PROGRAM_run2 (argc=<optimized out>, argv=0x100005b80, binaryName=<optimized out>, binaryHelp=<optimized out>, options=<optimized out>, task=<optimized out>, task_cls=<optimized out>, run_without_scheduler=<optimized out>) at program.c:329 #5 0x00007ffff7f8490f in GNUNET_PROGRAM_run (argc=<optimized out>, argv=<optimized out>, binaryName=<optimized out>, binaryHelp=<optimized out>, options=<optimized out>, task=<optimized out>, task_cls=0x0) at program.c:369 #6 0x00000001000013e9 in main (argc=<optimized out>, argv=<optimized out>) at gnunet-gns.c:285 (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x00007ffff75b7e0b in select () from /usr/lib/libc.so.6 (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x00007ffff75b7e0b in select () from /usr/lib/libc.so.6 (gdb) quit A debugging session is active. Inferior 1 [process 14470] will be killed. Quit anyway? (y or n) y $ gdb --args gnunet-gns -t A -u test2.foo GNU gdb (GDB) 8.3 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from gnunet-gns... (gdb) run Starting program: /usr/local/bin/gnunet-gns -t A -u test2.foo [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". test2.foo: Got `A' record: 1.1.1.1 [Inferior 1 (process 14486) exited normally] (gdb) quit |
|
In order so see what is happening, we would need the DEBUG log of the GNS and namecache service, presumably. I still cannot reproduce even with a name which only contains private records. |
|
Also, can you provide a gnunet-namestore -D -z foo output? The behaviour you are describing should never happen for local TLDs/egos. |
|
I used the global postif option to achieve the debug logs: gnunet-config -s arm -o GLOBAL_POSTFIX -V "-l $LOGDIR/{}-logs -L DEBUG" Namecache is disabled in my configuration as it provides a speed boost for Ascension. This was the result when resolving the two records (I resolved test2 twice): $ gnunet-gns -t A -u test.foo # stopped after a few seconds (running with timeout=2 yields nothing different in the logs) ^C $ gnunet-gns -t A -u test2.foo test2.foo: Got `A' record: 1.1.1.1 $ cat namestore-logs gns-logs namecache-logs Jul 23 15:52:23-809399 namestore-sqlite-30946 INFO Sqlite database running Jul 23 15:52:23-734426 gns-30938 WARNING Namecache disabled Jul 23 15:52:27-286498 gns-30938 INFO Resolution succeeded for `test2' in zone D5YP1D8MTMB4A8Y7WGDPBZBEA6GC4T81ARNN949QCSKVQY15HQ3G, got 1 records Jul 23 15:54:54-291297 gns-30938 INFO Resolution succeeded for `test2' in zone D5YP1D8MTMB4A8Y7WGDPBZBEA6GC4T81ARNN949QCSKVQY15HQ3G, got 1 records Jul 23 15:52:23-816790 namecache-sqlite-30950 INFO Sqlite database running I agree that this behaviour should never occur. $ gnunet-namestore -D -z foo foobar: AAAA: 2002:: (1 h) PUBLIC A: 1.1.1.1 (1 h) PUBLIC test: A: 1.1.1.1 (end of time) PRIVATE test2: A: 1.1.1.1 (end of time) PUBLIC |
|
Well if you disable namecache, then GNS will always hit the DHT and never look into name{store/cache}. Since your private record is never published in the DHT, it cannot be resolved. This is expected behaviour. |
|
Interesting. I had this disabled for some time now. After reactivating it and readding the records it works. Okay so I'm a bit confused now in a more general sense. From what I have gathered I assumed that disabling namecache would only influence the events that actually use the DHT. After all the documentation states that: "The NAMECACHE subsystem is responsible for caching (encrypted) resolution results of the GNU Name System (GNS)" I would assume that it is _only_ a cache. Why would a _private_ record be published/interact in/with the DHT? Assuming that the flags are part of the record and every record is published with those flags into the DHT I see a few problems. This would mean that a client could resolve the record and get an answer even though it is private. What if a client ignores the public flag? |
|
>> "I would assume that it is _only_ a cache." It is only a cache. For GNS results. grothoff at some point changed the design so that namestore also uses the cache (and even puts private records into it). Might not have been the best design decision. >> "Why would a _private_ record be published/interact in/with the DHT?" It wouldn't. That's why you cannot resolve it. The thing is that namestore puts private records into the local cache. The private records are never published. I agree that it is kind of inconsistent how it behaves. Also, I thought that GNS honours local private records even if namecache is disabled. While this could be changed, it would require to add this namestore fallback to the GNS resolver. |
|
We should leave this bug open. It is not clear that disabling the namecache has this side effect. |
|
I agree that this behavior was indeed unexpected and the bug should be left open. Also I could swear that this used to work in the past... Maybe there was a regression a few weeks ago? |
|
Nope. The disabling of the namestore was introduces around mid 2018. This has been the behaviour since then. What the namecache should (IMO) actually do: Check namestore on cache miss and (potentially) cache the record block. Instead of having the namestore put _every_ record into the namecache by default. Maybe I take a look at this some time. |
|
Disabling namecache WILL have a side effect on (local) name resolution. It is "more" than just a cache, as GNS cannot see local (private) records "directly" but ONLY via the namecache. This is per design and the true raison d'etre for Namecache. Otherwise it wouldn't be important, as the DHT has a cache already! So any normal user who simply disables namecache is indeed in trouble (TM), and it is a bad idea (TM) to do so, except if you know what you are doing AND are obsessed with performance (i.e. someone migrating TLDs to GNS). |
|
Closing this. |
Date Modified | Username | Field | Change |
---|---|---|---|
2019-07-20 13:13 | rexxnor | New Issue | |
2019-07-20 18:42 | schanzen | Assigned To | => schanzen |
2019-07-20 18:42 | schanzen | Status | new => assigned |
2019-07-20 18:42 | schanzen | Status | assigned => feedback |
2019-07-20 18:42 | schanzen | Note Added: 0014708 | |
2019-07-20 20:03 | rexxnor | Note Added: 0014710 | |
2019-07-20 20:03 | rexxnor | Status | feedback => assigned |
2019-07-20 20:40 | schanzen | Note Added: 0014711 | |
2019-07-20 20:43 | schanzen | Note Added: 0014712 | |
2019-07-23 16:00 | rexxnor | Note Added: 0014729 | |
2019-07-23 17:27 | schanzen | Note Added: 0014733 | |
2019-07-23 17:47 | rexxnor | Note Added: 0014734 | |
2019-07-23 18:04 | schanzen | Note Added: 0014735 | |
2019-07-23 18:05 | schanzen | Note Edited: 0014735 | |
2019-07-23 18:06 | schanzen | Note Added: 0014736 | |
2019-07-23 18:33 | rexxnor | Note Added: 0014737 | |
2019-07-23 18:52 | schanzen | Note Added: 0014738 | |
2019-07-23 19:16 | Christian Grothoff | Note Added: 0014739 | |
2019-07-24 00:02 | schanzen | Status | assigned => resolved |
2019-07-24 00:02 | schanzen | Resolution | open => won't fix |
2019-07-24 00:02 | schanzen | Note Added: 0014744 | |
2019-07-24 20:40 | Christian Grothoff | Fixed in Version | => 0.11.6 |
2019-07-24 20:40 | Christian Grothoff | Target Version | => 0.11.7 |
2019-07-24 20:40 | Christian Grothoff | Status | resolved => closed |
2019-07-24 20:41 | Christian Grothoff | Target Version | 0.11.7 => 0.11.6 |