Kresd won't resolve www.horizon.tv

Software SW help
1

Hello,

I have troubles resolving www.horizon.tv using default kresd.

I have forwarding to provider set on. I have tried forward to cz-nic and not forward at all, but seems kresd can’t resolve.
When using dsnsmasq, resolving works.

I have TOS 5.0.3. Does anyone have problem with this or other versions?

FYI, packet capture shows:

   39  20.635527 00:21:85:1c:1a:0d 192.168.x.y 45036 192.168.x.1 53 DNS Standard query 0xb9e1 A www.horizon.tv OPT
   40  20.635527 00:21:85:1c:1a:0d 192.168.x.y 45036 192.168.x.1 53 DNS Standard query 0xb9e1 A www.horizon.tv OPT
   41  20.636040              a.b.c.d 38492 195.28.64.99 53 DNS Standard query 0xb79d DS hOrIzON.tV OPT
   42  20.638302              195.28.64.99 53 a.b.c.d 38492 DNS Standard query response 0xb79d DS hOrIzON.tV SOA ac1.nstld.com RRSIG RRSIG NSEC3 RRSIG NSEC3 OPT
   43  20.638702 04:f0:21:31:85:47 192.168.x.1 53 192.168.x.y 45036 DNS Standard query response 0xb9e1 Server failure A www.horizon.tv OPT
   44  20.638711 04:f0:21:31:85:47 192.168.x.1 53 192.168.x.y 45036 DNS Standard query response 0xb9e1 Server failure A www.horizon.tv OPT
   45  20.638714 04:f0:21:31:85:47 192.168.x.1 53 192.168.x.y 45036 DNS Standard query response 0xb9e1 Server failure A www.horizon.tv OPT
2

I tried many attempts in various modes but I’m unable to reproduce any problem (Omnia + 5.0.3). From your capture it seems that the packet 42 from your ISP’s resolver contained something that kresd doesn’t like, e.g. incorrect DNSSEC proof, but it seems hard to see what’s happening or to assign blame to any side until we have more information.

I think it would be best to get verbose logs from this failure, e.g. in this way: https://wiki.turris.cz/doc/en/howto/dnsdebug#gather_the_data

3

thanks for info and the hint. I have collected logs, it’s 1.3MB file.
do you recommend me posting it here or to turris/kresd support?

4

Right. The usual way is tech.support@turris.cz, as the huge logs might contain something sensitive. It would probably be enough to just cut the short moment of processing the failing request (and easier to check that it can be posted publicly), but you may not want to bother with that.

5

In the sent logs kresd never even gets to sending the packets above.

[plan]   plan 'tv.' type 'DNSKEY' uid [06001.06]                        
[iter]     'tv.' type 'DNSKEY' new uid was assigned .07, parent uid .05 
[hint]     <= answered from hints

Someone apparently defined address(es) for name tv. which by default clears everything on that name, including DNSKEY tv. There are reasons why DHCP names are nested under lan. by default.

OK, even lan. isn’t really officially reserved, but we would most likely know in advance if ICANN was about to delegate it.

6

aha… this is the reason:

root@blah:~# grep tv /etc/hosts
192.168.X.Y	tv.lan	tv

didn’t think of that. and I didn’t have the problem before, so that may be an issue with updated kresd. Yes, I to have this in /etc/config/resolver:

list hostname_config '/etc/hosts'

7

Yes, most likely triggered by fixing one bug in our behavior. If this is important, this particular problem should get worked around by one kresd config line

hints.use_nodata(false)
8

this causes other issues where AAAA and other requests return NXDOMAIN for hostnames in /etc/hosts iirc.

Also, this is in /etc/init.d/kresd:

echo "hints.use_nodata(true)" >> $CONFIGFILE

should I try to rewrite it or simply add the opeion above to
/etc/kresd/custom.conf?

Are you interested in me trying that? I can go with dnsmasq…

9

You can use that. Custom config is done after the generated one, so it will override the option. If you don’t have custom config already, there’s how: https://doc.turris.cz/doc/en/public/dns_knot_misc#adding_custom_configuration

Another way would be removing the top-level tv alias (tv.lan doesn’t cause problems here and apparently lan is in your automatic search list anyway).

10

yes, it works now…

with the side-effect kreds returns NXDOMAIN for non-A requests for hosts in /etc/hosts, for complete information… this is why we have use_nodata true