Open
Bug 1226550
Opened 10 years ago
Updated 3 years ago
fails to perform NAPTR and SRV lookups for ICE servers, just looks for A/AAAA records
Categories
(Core :: WebRTC: Networking, defect, P4)
Tracking
()
NEW
backlog | webrtc/webaudio+ |
People
(Reporter: daniel, Unassigned)
Details
(Whiteboard: [spec])
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0 Iceweasel/41.0.1
Build ID: 20151005010732
Steps to reproduce:
The DNS has NAPTR and SRV records for TURN associated with fedrtc.org
My script (on a WebRTC page) sets the ICE server name to fedrtc.org
Actual results:
tcpdump shows Firefox making A and AAAA queries for fedrtc.org.
tcpdump does not show it making any NAPTR or SRV queries
Expected results:
Firefox should have queried the NAPTR and then SRV records and discovered the correct TURN server name, port and transport tuple.
The expected resolution mechanism is described in RFC 5928:
https://tools.ietf.org/html/rfc5928
Also reported to Chrome:
https://code.google.com/p/chromium/issues/detail?id=559115
Comment 2•10 years ago
|
||
Seems like a networking related issue. Move bug to WebRTC: Networking component. Please advise.
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core
There has been some more discussion in the Chrome bug tracker about the justification for this.
Summarizing the key points:
- if a NAPTR exists and the browser uses the A/AAAA record instead (current behavior), it is potentially connecting to the wrong server
- if somebody is using TURN over TLS then the CN or subjectAltName in the TURN server's certificate will match the name associated with their NAPTR, not the name associated with their A/AAAA records, so the TLS client (Firefox TURN client) will be unable to verify the certificate if it hasn't started the resolution process using the NAPTR.
- a partial workaround (not dealing with the certificate issue, only helpful for TURN over UDP) is for a server-side script to do the NAPTR and SRV lookups and send SRV records to the JavaScript, this could be done using AJAX or something. The JavaScript code would then pass those names and port numbers to the WebRTC stack as the ICE server configuration.
Comment 4•10 years ago
|
||
Chrome also considers it to be a spec-compliance issue, but low priority.
Status: UNCONFIRMED → NEW
backlog: --- → webrtc/webaudio+
Rank: 35
Ever confirmed: true
Priority: -- → P3
Whiteboard: [spec]
Comment 5•8 years ago
|
||
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•