View Issue Details

IDProjectCategoryView StatusLast Update
0005812GNUnetGNSpublic2019-07-24 20:41
Reporterrexxnor Assigned Toschanzen  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionwon't fix 
Product VersionGit master 
Target Version0.11.6Fixed in Version0.11.6 
Summary0005812: Unable to resolve non-public records in GNS
DescriptionWhen 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 ReproduceAdd 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
TagsNo tags attached.

Activities

schanzen

2019-07-20 18:42

administrator   ~0014708

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

rexxnor

2019-07-20 20:03

reporter   ~0014710

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

schanzen

2019-07-20 20:40

administrator   ~0014711

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.

schanzen

2019-07-20 20:43

administrator   ~0014712

Also, can you provide a gnunet-namestore -D -z foo output? The behaviour you are describing should never happen for local TLDs/egos.

rexxnor

2019-07-23 16:00

reporter   ~0014729

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

schanzen

2019-07-23 17:27

administrator   ~0014733

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.

rexxnor

2019-07-23 17:47

reporter   ~0014734

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?

schanzen

2019-07-23 18:04

administrator   ~0014735

Last edited: 2019-07-23 18:05

>> "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.

schanzen

2019-07-23 18:06

administrator   ~0014736

We should leave this bug open. It is not clear that disabling the namecache has this side effect.

rexxnor

2019-07-23 18:33

reporter   ~0014737

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?

schanzen

2019-07-23 18:52

administrator   ~0014738

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.

Christian Grothoff

2019-07-23 19:16

manager   ~0014739

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).

schanzen

2019-07-24 00:02

administrator   ~0014744

Closing this.

Issue History

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