Open Bug 1239006 Opened 8 years ago Updated 3 years ago

TURN access : no CONNECT launched if the DNS resolution can't be done locally

Categories

(Core :: WebRTC: Networking, enhancement, P4)

Product:
Core
Component:
WebRTC: Networking
Version:
43 Branch
Type:
enhancement

Tracking

()

People

(Reporter: xavier.desnoeck, Unassigned)

References

Details

(Whiteboard: [necko-backlog]) 

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Steps to reproduce:

On a specific configuration of Desktop environment in a company, I don't have a local DNS resolution.
With a WebRTC test using a TURN server on port 443, the relay is not listed in the local candidates


Actual results:

The DNS resolution cannot be done locally so the HTTP CONNECT is never sent and therefore the relay never added to the local candidates.


Expected results:

Even if the DNS resolution isn't done locally, try to send the HTTP CONNECT request to the proxy (that should do the resolution).
Event if the resolution is added in /etc/hosts locally, send the CONNECT with the FQDN and not the IP address.
Component: Untriaged → Networking
Product: Firefox → Core
Someone can help to investigate on this problem to find a fix for future versions of Firefox ?
We are blocked for use of WebRTC inside our enterprise network configuration due to this problem...

Thanks

Xavier
Whiteboard: [necko-backlog]
The problem is still present on the version 47 and so I am still blocked on using WebRTC inside my company network when I try to make collaboration with external users...

Some can help me ?

Thanks

Xavier
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
For information, I faced a similar problem with a bank partner and it's DNS corporate VERY limited to corporate server resolution.

Chrome: OK WebRTC sends the TURN resolution to the PROXY.
Firefox: seems to try to resolve it locally instead of using the PROXY !?!?

Note: copying this also to https://bugzilla.mozilla.org/show_bug.cgi?id=1385030
Depends on: 1569183

Now that bug 1569183 has landed, the remaining work is to add some config to nICEr that allows DNS resolution to be delegated to the socket for certain types of socket, and then use this capability with NrSocketTcp. Eventually, we may want to delegate DNS resolution for all of the socket types, but that is beyond the scope of this bug.

Because this is only for NrSocketTcp, this will have no effect for non-e10s mode (which shouldn't be a problem in practice, as non-e10s hasn't been supported for some time), and will also have no effect for UDP (which should not make any difference; if we're in that restrictive a network, UDP won't be allowed anyway).

Assignee: nobody → docfaraday
Status: UNCONFIRMED → NEW
Type: defect → enhancement
Component: Networking → WebRTC: Networking
Ever confirmed: true
Priority: P3 → P2

Please note that this bug also strikes hard when the local DNS resolution does work: in this case, since the resolution is done beforehand, the CONNECT gets a numeric IP address instead of an FQDN; this is a show-stopper for many corporate proxies where only FQDNs are allowed in CONNECT. In our case this simply means "do not use Firefox" when deploying our large-scale WebRTC app. Any hope to up the prio ?

Additional, this is also a problem when using Proxy Auto-Config (proxy.pac-files).
The FindProxyForURL()-function there gets called for regular webtraffic with the FQDN, TURN-queries instead get called by their resolved IPs. This is a showstopper when e.g. using the PAC for accessing a different, dedicated proxy for webconf-traffic. I have to check all used IP-ranges of the used service like webex in the proxy.pac.

Hi,
What is the status of this task? We still can't use ICECANDIDATE via dns address. This task is already 5 years old and all other browsers already support it, even Edge

This should have been fixed by bug 1416220, in Firefox 87. Can you confirm?

Flags: needinfo?(kontakt)

This not work for us. In (In reply to Byron Campen [:bwc] from comment #11)

This should have been fixed by bug 1416220, in Firefox 87. Can you confirm?

This not work for us. In the mentioned bug they use TCP and DNS proxy. In our case it is UDP and no proxy, just address in hosts.
For tests i used line in hosts like

localIp mediagateway.somedomain.com

When I go to about:webrtc I see that the statistics for ICE are empty and the remote SDP indicates Candidate

a=candidate:1 1 udp 50 mediagateway.somedomain.com 7077 typ host generation 0
a=candidate:1 2 udp 49 mediagateway.somedomain.com 7077 typ host generation 0

I don't know if this is more problem with UDP or local dns address, hope this would help in investigation and will be fixed soon

Flags: needinfo?(kontakt)

We do not resolve IP addresses in remote candidates except for mDNS, I think. Dan?

Flags: needinfo?(dminor)

So that's for STUN/TURN servers only; we can't even parse FQDN-based candidates, much less resolve them:

https://searchfox.org/mozilla-central/rev/d7e344e956d9da2808ea33e1fe0f963ed10c142d/dom/media/webrtc/transport/third_party/nICEr/src/ice/ice_parser.c#204,220

So if we're resolving hostnames in ICE candidates, it would need to be happening before we feed them into nICEr, which is what we do for mDNS, but we do not do the same for FQDN.

So you gonna fix it in future? I tested this on all popular browsers and all expect firefox support this

Flags: needinfo?(docfaraday)

Eventually, yes. But it is not anywhere near the top of our list of priorities, since almost nobody actually uses FQDN in ICE candidates.

Flags: needinfo?(docfaraday)
Assignee: docfaraday → nobody
Severity: normal → S4
Priority: P2 → P4
You need to log in before you can comment on or make changes to this bug.