1753124 - Address not found error returned for d_.gitlab.io

Status: NEW

(Core :: Networking, defect, P3)

Description

[Ksenia Berezina [:ksenia]]

We've received a report in https://github.com/webcompat/web-bugs/issues/98965 where an error is returned when visiting http://d_.gitlab.io/prereq_graph

To reproduce visit http://d_.gitlab.io/prereq_graph in Firefox for Android and observe the result

Expected:
The site contents are displayed

Actual:
"Address not found" error
(wonder whether this is happening because of an underscore in the domain name?)

The error is not reproducible on Firefox desktop or on Chrome for Android.

Comment 1

[Emily Toop (:fluffyemily)]

This needs investigating to determine if this is GeckoView or Fenix.

Comment 2

[[:owlish] 🦉 PST]

This is definitely not Fenix - in fact, the load failure occurs in Gecko even before this reaches GV. I'm not sure why it works on desktop but not on mobile - either there's a bug, or some sort of #ifdef ANDROID kind of logic somewhere. Investigating further.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dveditz, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Daniel Veditz [:dveditz]]

The CSP error is coming from the UI and isn't the cause of being unable to load the site (it's probably from that "Not Found" page -- inline scripts aren't allowed in system-privileged UI).

It's broken on Focus also, though that's not a surprise given owlish says the failure is below GV.

The problem does appear to be the trailing underscore: https://d_.egold.com fails the same way, while https://d_d.gitlab.io/ "works" (it connects and gets redirected to a sign-in page). Technically the domain name rules say the last character of a domain label should be a number or letter, but then again the same rules say the underscore is NEVER valid. Clearly the real world has only a passing acquaintance with these rules

The labels must [...] start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen.

I can believe the android name resolver that we call has different rule exceptions from the ones on other systems, but then how does Chrome work on android? Do they implement their own DNS resolver and skip the platform?

Someone on the networking team will need to track this down, and they'll know the de facto rules, not just what rfc1034 says.

Comment 5

[Valentin Gosu [:valentin] (he/him)]

I remember seeing another bug with the same cause a while back.
At the time, Chrome also had the same issue (if you disabled DNS preloading, which used DoH). When DoH is enabled in Firefox, the page also loads.
The problem was getaddrinfo implementation on Android. Not sure why it works now in Chrome (maybe they're using a different resolver, although it doesn't look so from the code).

Comment 6

[Dennis Schubert [:denschub]]

This is a valid issue, but not very critical from a WebCompat point at the moment.