View Issue Details

IDProjectCategoryView StatusLast Update
0006069GNUnetotherpublic2020-02-04 19:18
ReporterrexxnorAssigned To 
PrioritynormalSeverityminorReproducibilityalways
Status acknowledgedResolutionopen 
Product VersionSVN HEAD 
Target VersionFixed in Version 
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

manager   ~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.

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