No-round-robin option does not preserve order

Help
1

just added the "New no-round-robin option - suppresses round-robin ordering of DNS records and ensures answers are always served in the same order."

where are we supposed to see the result, dig result:

pi@raspberrypi:~ $ dig +short vrt.be
13.248.195.120
76.223.91.55
pi@raspberrypi:~ $ dig +short vrt.be
13.248.195.120
76.223.91.55
pi@raspberrypi:~ $ dig +short vrt.be
13.248.195.120
76.223.91.55
pi@raspberrypi:~ $ dig +short vrt.be
76.223.91.55
13.248.195.120
pi@raspberrypi:~ $ dig +short vrt.be
13.248.195.120
76.223.91.55

fourth query returns inverted result ...

2

Do you have the corresponding /var/log/pihole/pihole.log lines for us?

3

Try this very simple test script:

#!/bin/sh

first=$(dig +short vrt.be)
echo "$first"

i=0
while [ $i -lt 100 ]; do
  last=$(dig +short vrt.be)
  if [ "$first" != "$last" ]; then
    echo "$i: rotated"
    echo "$last"
  else
    echo "$i: OK"
  fi
  i=$(($i+1))
done

It comes back 100x times without any rotation for me. Note that I'm using the dnsmasq cache, this seems to work just fine. Your rotation will come from upstream because FTL has no way to remember the order of the replies last time with cache disabled. It will just forward without modification what it received from upstream.

4

new run, easier to find, thus can be replicated.

pi@raspberrypi:~ $ dig +short vrt.be
76.223.91.55
13.248.195.120
pi@raspberrypi:~ $ dig +short vrt.be
76.223.91.55
13.248.195.120
pi@raspberrypi:~ $ dig +short vrt.be
13.248.195.120
76.223.91.55
pi@raspberrypi:~ $ dig +short vrt.be
76.223.91.55
13.248.195.120
pi@raspberrypi:~ $ dig +short vrt.be
76.223.91.55
13.248.195.120

Nov 21 12:56:31 dnsmasq[16067]: 208 127.0.0.1/55694 query[A] vrt.be from 127.0.0.1
Nov 21 12:56:31 dnsmasq[16067]: 208 127.0.0.1/55694 forwarded vrt.be to 127.10.10.2#5552
Nov 21 12:56:31 dnsmasq[16067]: 208 127.0.0.1/55694 reply vrt.be is 76.223.91.55
Nov 21 12:56:31 dnsmasq[16067]: 208 127.0.0.1/55694 reply vrt.be is 13.248.195.120
Nov 21 12:56:32 dnsmasq[16067]: 209 127.0.0.1/47211 query[A] vrt.be from 127.0.0.1
Nov 21 12:56:32 dnsmasq[16067]: 209 127.0.0.1/47211 forwarded vrt.be to 127.10.10.2#5552
Nov 21 12:56:32 dnsmasq[16067]: 209 127.0.0.1/47211 reply vrt.be is 76.223.91.55
Nov 21 12:56:32 dnsmasq[16067]: 209 127.0.0.1/47211 reply vrt.be is 13.248.195.120
Nov 21 12:56:33 dnsmasq[16067]: 210 127.0.0.1/47015 query[A] vrt.be from 127.0.0.1
Nov 21 12:56:33 dnsmasq[16067]: 210 127.0.0.1/47015 forwarded vrt.be to 127.10.10.2#5552
Nov 21 12:56:33 dnsmasq[16067]: 210 127.0.0.1/47015 reply vrt.be is 13.248.195.120
Nov 21 12:56:33 dnsmasq[16067]: 210 127.0.0.1/47015 reply vrt.be is 76.223.91.55
Nov 21 12:56:34 dnsmasq[16067]: 211 127.0.0.1/40313 query[A] vrt.be from 127.0.0.1
Nov 21 12:56:34 dnsmasq[16067]: 211 127.0.0.1/40313 forwarded vrt.be to 127.10.10.2#5552
Nov 21 12:56:34 dnsmasq[16067]: 211 127.0.0.1/40313 reply vrt.be is 76.223.91.55
Nov 21 12:56:34 dnsmasq[16067]: 211 127.0.0.1/40313 reply vrt.be is 13.248.195.120
Nov 21 12:56:35 dnsmasq[16067]: 212 127.0.0.1/35754 query[A] vrt.be from 127.0.0.1
Nov 21 12:56:35 dnsmasq[16067]: 212 127.0.0.1/35754 forwarded vrt.be to 127.10.10.2#5552
Nov 21 12:56:35 dnsmasq[16067]: 212 127.0.0.1/35754 reply vrt.be is 76.223.91.55
Nov 21 12:56:35 dnsmasq[16067]: 212 127.0.0.1/35754 reply vrt.be is 13.248.195.120

127.10.10.2#5552 = unbound

5

Yeah, just as I assumed:

and

Your unbound replied in a different order.

6 
13.248.195.120
76.223.91.55
0: rotated
76.223.91.55
13.248.195.120
1: OK
2: OK
3: rotated
76.223.91.55
13.248.195.120
4: rotated
76.223.91.55
13.248.195.120
5: rotated
76.223.91.55
13.248.195.120
6: OK
7: OK
8: OK
9: OK
10: OK
11: OK
12: rotated
76.223.91.55
13.248.195.120
13: OK
14: rotated
76.223.91.55
13.248.195.120
15: OK
16: rotated
76.223.91.55
13.248.195.120
17: rotated
76.223.91.55
13.248.195.120
18: OK
19: rotated
76.223.91.55
13.248.195.120
20: OK
21: OK
22: OK
23: rotated
76.223.91.55
13.248.195.120
24: OK
25: OK
26: OK
27: OK
28: OK
29: rotated
76.223.91.55
13.248.195.120
30: OK
31: rotated
76.223.91.55
13.248.195.120
32: rotated
76.223.91.55
13.248.195.120
33: rotated
76.223.91.55
13.248.195.120
34: rotated
76.223.91.55
13.248.195.120
35: OK
36: OK
37: OK
38: rotated
76.223.91.55
13.248.195.120
39: rotated
76.223.91.55
13.248.195.120
40: rotated
76.223.91.55
13.248.195.120
41: rotated
76.223.91.55
13.248.195.120
42: rotated
76.223.91.55
13.248.195.120
43: rotated
76.223.91.55
13.248.195.120
44: rotated
76.223.91.55
13.248.195.120
45: rotated
76.223.91.55
13.248.195.120
46: rotated
76.223.91.55
13.248.195.120
47: OK
48: OK
49: rotated
76.223.91.55
13.248.195.120
50: OK
51: OK
52: OK
53: rotated
76.223.91.55
13.248.195.120
54: rotated
76.223.91.55
13.248.195.120
55: OK
56: rotated
76.223.91.55
13.248.195.120
57: rotated
76.223.91.55
13.248.195.120
58: OK
59: OK
60: OK
61: rotated
76.223.91.55
13.248.195.120
62: rotated
76.223.91.55
13.248.195.120
63: rotated
76.223.91.55
13.248.195.120
64: rotated
76.223.91.55
13.248.195.120
65: rotated
76.223.91.55
13.248.195.120
66: OK
67: OK
68: rotated
76.223.91.55
13.248.195.120
69: rotated
76.223.91.55
13.248.195.120
70: OK
71: rotated
76.223.91.55
13.248.195.120
72: OK
73: OK
74: rotated
76.223.91.55
13.248.195.120
75: OK
76: rotated
76.223.91.55
13.248.195.120
77: rotated
76.223.91.55
13.248.195.120
78: rotated
76.223.91.55
13.248.195.120
79: OK
80: rotated
76.223.91.55
13.248.195.120
81: rotated
76.223.91.55
13.248.195.120
82: OK
83: OK
84: rotated
76.223.91.55
13.248.195.120
85: OK
86: rotated
76.223.91.55
13.248.195.120
87: OK
88: OK
89: rotated
76.223.91.55
13.248.195.120
90: OK
91: OK
92: rotated
76.223.91.55
13.248.195.120
93: rotated
76.223.91.55
13.248.195.120
94: OK
95: rotated
76.223.91.55
13.248.195.120
96: rotated
76.223.91.55
13.248.195.120
97: rotated
76.223.91.55
13.248.195.120
98: OK
99: rotated
76.223.91.55
13.248.195.120
7

No offence intended, just an observation: Thus, useless option for users with unbound (or equivalent) as upstream?

8

No, this has nothing to do with unbound but solely with not using the dnsmasq cache. You could suggest clarifying the dnsmasq man page in this regard, running dnsmasq without cache is quite unusual (after all Simon Kelley calls it a "caching DNS resolver") and this was likely simply forgotten.

10

No. Our recommendation is (and always has been) to keep the pihole-FTL cache enabled with unbound.

Have you disabled the FTL/dnsmasq cache?

11

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.