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)

41 Branch
defect

Tracking

()

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
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.
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]
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.