View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0006069GNUnetotherpublic2020-01-30 11:322020-07-09 09:17
Reporterrexxnor Assigned Toschanzen  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product VersionGit master 
Target Version0.13.0Fixed in Version0.13.0 
Summary0006069: dns2gns bridge weird behaviour (returning all A/AAAA records in every case)
DescriptionWhen using a dns2gns as a resolver to resolve records in GNS via regular DNS there are a few problems.

I wrote a test script in src/gns/ in commit 015cd279b to highlight the issue.

When executing the script there are a few nslookup commands being executed.
I expect to see the adresses configured to appear once, however in some cases the dns2gns bridge returns the same address multiple times.
It seems that nslookup does an A record lookup and gets all A records including AAAA records from the dns2gns server.
nslookup does a separate AAAA lookup and again gets all A and AAAA records from the DNS server.

Another thing I noticed was that the order in which the records are returned is always the same.
Usually in DNS, the DNS server will return them in some kind of random order (so that round-robin DNS works).

Furthermore the second test in the file resolves the record using another DNS server. Compared to the results of the GNS lookup, it only ever shows a single IPv4 and IPv6 address for a host. This is not the case for any resolved GNS record because of the issue above.

Lastly, dig fails to resolve records entirely (see additional info). No idea why and I have not troubleshooted it.
Steps To ReproduceSimple using the test:
$ cd src/gns/
$ bash test_dns2gns.sh


If you want to verify this in general:

Add the following to your gnunet.conf file:

[dns2gns]
OPTIONS = -d 1.1.1.1 -p 5353

Start your GNUnet peer and start dns2gns with:
$ gnunet-arm -I dns2gns

Add a zone and a few records, then resolve using
$ nslookup -port=5353 <label>.<zonename> 127.0.0.1
Additional InformationFrom a running setup that made me notice the issue:

$ gnunet-namestore -D -z foo
www:
    A: 4.4.4.4 (1 h) PRIVATE
    A: 3.3.3.3 (1 h) PRIVATE
    A: 2.2.2.2 (1 h) PRIVATE
    AAAA: dead::beef (1 h) PUBLIC
    A: 1.1.1.1 (1 h) PUBLIC

$ nslookup www.foo ::1
Server: ::1
Address: ::1#53

Non-authoritative answer:
Name: www.foo
Address: 4.4.4.4
Name: www.foo
Address: 3.3.3.3
Name: www.foo
Address: 2.2.2.2
Name: www.foo
Address: dead::beef
Name: www.foo
Address: 1.1.1.1
Name: www.foo
Address: 4.4.4.4
Name: www.foo
Address: 3.3.3.3
Name: www.foo
Address: 2.2.2.2
Name: www.foo
Address: dead::beef
Name: www.foo
Address: 1.1.1.1

With host:
$ host www.foo
www.foo has address 4.4.4.4
www.foo has address 3.3.3.3
www.foo has address 2.2.2.2
www.foo has IPv6 address dead::beef
www.foo has address 1.1.1.1
www.foo has address 4.4.4.4
www.foo has address 3.3.3.3
www.foo has address 2.2.2.2
www.foo has IPv6 address dead::beef
www.foo has address 1.1.1.1
www.foo has address 4.4.4.4
www.foo has address 3.3.3.3
www.foo has address 2.2.2.2
www.foo has IPv6 address dead::beef
www.foo has address 1.1.1.1

host with record type specified:
$ $ host -t A www.foo
www.foo has address 4.4.4.4
www.foo has address 3.3.3.3
www.foo has address 2.2.2.2
www.foo has IPv6 address dead::beef
www.foo has address 1.1.1.1
$ host -t AAAA www.foo
www.foo has address 4.4.4.4
www.foo has address 3.3.3.3
www.foo has address 2.2.2.2
www.foo has IPv6 address dead::beef
www.foo has address 1.1.1.1


With dig:
dig @127.0.0.1 www.foo
;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
;; Connection to 127.0.0.1#53(127.0.0.1) for www.foo failed: connection refused.

TagsNo tags attached.

Activities

schanzen

2020-02-03 13:40

administrator   ~0015303

The behaviour for nslookup and host is to be expected.
GNS always returns all records under the name _if_ the requested record type is among them.

DNS allows to return any records from a query. You need to check/filter yourself usually.
Now you could argue that the dns2gns server should filter the records according to type like gnunet-gns.c does.
But I am not sure if this is a good idea. So the behaviour is different from most other name servers, but it still compliant.
If you want, you could change this in the implementation. But sometimes you actually _want_ to also return other records in addition to the IP address.

The dig thing might actually be a bug in dns2gns. Maybe it even crashed? As it ends with a "connection refused".

rexxnor

2020-02-04 19:18

reporter   ~0015304

As long as the behavior is still compliant it is fine in my book. I was not sure if that was compliant.

About the dig thing:
It seems as the message is too long for some reason (I have no idea how that is only a problem with dig) and it tries TCP which is not implemented in dns2gns.

schanzen

2020-05-09 21:26

administrator   ~0015872

Is this still an issue?

Christian Grothoff

2020-06-03 10:38

manager   ~0016226

I think rexxnor is _probably_ right to call for randomizing the order and removing duplicate entries.

I would not filter by record type, *unless* the client is _not_ on loopback and the resulting message would be too big for a single UDP packet.

Here, we should ideally _also_ check the (E)DNS settings and if (E)DNS is not specified, stick to the 512-byte maximum (and first filter only DNSSEC Records if (E)DNS is not specified _and_ the reply gets too big).

schanzen

2020-06-21 22:18

administrator   ~0016331

This is fixed in d6d7bf7df..612704d69
For the result filtering feature, I opened https://bugs.gnunet.org/view.php?id=6401

schanzen

2020-07-09 09:17

administrator   ~0016414

0.13.0 released

Issue History

Date Modified Username Field Change
2020-01-30 11:32 rexxnor New Issue
2020-02-03 13:40 schanzen Note Added: 0015303
2020-02-03 13:40 schanzen Status new => acknowledged
2020-02-04 19:18 rexxnor Note Added: 0015304
2020-04-24 10:31 schanzen Fixed in Version => 0.13.0
2020-04-24 10:31 schanzen Target Version => 0.13.0
2020-05-09 21:26 schanzen Assigned To => schanzen
2020-05-09 21:26 schanzen Status acknowledged => feedback
2020-05-09 21:26 schanzen Note Added: 0015872
2020-06-01 00:49 Adminknox Issue cloned: 0006293
2020-06-01 00:52 Adminknox Issue cloned: 0006334
2020-06-03 10:38 Christian Grothoff Note Added: 0016226
2020-06-21 22:18 schanzen Status feedback => resolved
2020-06-21 22:18 schanzen Resolution open => fixed
2020-06-21 22:18 schanzen Note Added: 0016331
2020-07-09 09:17 schanzen Note Added: 0016414
2020-07-09 09:17 schanzen Status resolved => closed