[SOLVED] Some IP addresses can not be resolved, others can

dns

#1

Since a few weeks, I’m sometimes having issues opening web pages. It loads … and loads … and loads …
Most times, cancelling loading the page and reloading (F5) helped.
Now, I’ve come across an issue where this does not work. Honestly, I’m not even sure if it’s the same root cause, but on the other hand, the above description may help complete the picture.

It occurs when I try to browse the mozilla addon page: The page itself opens, but only in plain old HTML without any styles, formatting, pictures, and so on. On the bottom of the browser window, I can see that it tries to resolve addons-amo.cdn.mozilla.net over and over again.

After seeing that, I ssh’ed to the router and tested to nslookup some addresses (see blockquotes below). As you can see, addons.mozilla.org resolves well, while addons-amo.cdn.mozilla.net only resolves when I specify a nameserver. The 80.69.96.12 is the nameserver of my provider, I copied it from the luci overview page (IPv4 WAN Status section). IPV6 is not available.

What’s really strange is the fact that it does not say “server could not find the address”, but “no server available”.

I’ve tried to follow the instructions in Debugging DNS problems on Omnia, but luci says that there is no available package named resolver-debug.

And now, I’m stuck …

root@turris:~# nslookup addons.mozilla.org
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: addons.mozilla.org
addons.mozilla.org canonical name = olympia.prod.mozaws.net
Name: olympia.prod.mozaws.net
Address 1: 34.209.177.23
Address 2: 52.10.178.149
Address 3: 52.35.71.140
addons.mozilla.org canonical name = olympia.prod.mozaws.net

root@turris:~# nslookup addons-amo.cdn.mozilla.net
;; connection timed out; no servers could be reached

root@turris:~# nslookup addons-amo.cdn.mozilla.net 80.69.96.12
Server: 80.69.96.12
Address: 80.69.96.12#53

Name: addons-amo.cdn.mozilla.net
addons-amo.cdn.mozilla.net canonical name = d11j15s5geoh80.cloudfront.net
Name: d11j15s5geoh80.cloudfront.net
Address 1: 54.230.202.87
Address 2: 54.230.202.154
Address 3: 54.230.202.177
Address 4: 54.230.202.232
addons-amo.cdn.mozilla.net canonical name = d11j15s5geoh80.cloudfront.net


#2

Do

opkg update

then try installing resolver-debug again.


#3

The “update lists” button there does exactly the same, I believe.

The error doesn’t happen for me, with forwarding or without it, even though the CDN does have some DNS issues. I’ll be looking forward to verbose logs from the event.


#4

I could install the package this way. thanks. After a first test, the log was very cluttered with requests from all PC’s on my home network.
I will do another test with only one PC connected and as few programs open as possible, so the log will (hopefully) only contain the request to be tested.

But I’ll need to wait for the right moment to do this :slight_smile:


#5

It should be enough to “filter” the log, e.g. find the failing name like in

2018-12-26 17:13:07 info kresd[25331]: [54502.04][iter]   'my.failing.name.' type 'AAAA' new uid was assigned .07, parent uid .00

and filter lines that contain 54502 (or just cut a few seconds around that point).


#6

OK, I’ve created a filtered log. It covers 5 seconds (from the nslookup to the timeout) and has 6450 lines … so it would not make sense to add it here as blockquote.
After about 150 lines, the pattern changes, but I’m still unsure which part is important and which I could cut off, so I’d prefer to share it as whole.

Can I create attachments here in the forum or can I upload it somewhere ?


#7

I don’t know about this forum being able to do it. Perhaps it’s easiest to send it to vladimir.cunat@nic.cz, which also lowers the risk of “privacy leak” (some names and likely addresses are visible in there).


#8

Yes, this is probably the easiest way. e-mail was just sent.


#9

You use forwarding to some IPv4 addresses, probably the ISP’s DNS, and they reply SERVFAIL to queries for cdn.mozilla.net DS. Kresd won’t be able to forward with validation through such broken servers. Apparently they can’t handle these queries on CNAMEs (which are used often enough nowadays).


Kresd eats file handles for breakfast, lunch and dinner
#10

First of all, thank you for checking my log and finding the problem.

I just looked at my config in foris and I found the “Use forwarding” option. After disabling it, everything I tested so far is resolving normally.

I don’t remember if I enabled it myself of if it was enabled by default after the factory reset a few weeks ago. According to the docs, it looks like it’s enabled by default. Maybe it’s worth considering to change the default.


#11

I am just going to explain why in default is forwarding enabled. This is because of some ISPs that provide additional entries in their DNS servers. Those are required for their services such as TV streaming for example. Disabling forwarding in default would result in those queries to be resolved against upstream DNS servers and those additional entries are not recorded there. It makes sense to use forwarding but some ISP’s DNS servers are not configured correctly and because of that you might encounter problems with it with secure minded DNS resolver. Correct approach is not to change defaults but to explain ISPs that they should fix their network.


#12

Thank you for this explanation.

Unfortunately, I’m not deep enough into the DNS topic to be able to tell my ISP what exactly they are doing wrong, nor would I expect them to listen to me at all.