fails to perform NAPTR and SRV lookups for ICE servers, just looks for A/AAAA records




3 years ago
3 months ago


(Reporter: daniel, Unassigned)


41 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [spec])



3 years ago
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

My script (on a WebRTC page) sets the ICE server name to

Actual results:

tcpdump shows Firefox making A and AAAA queries for

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:

Comment 1

3 years ago
Also reported to Chrome:
Seems like a networking related issue. Move bug to WebRTC: Networking component. Please advise.
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core

Comment 3

3 years ago
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.
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
You need to log in before you can comment on or make changes to this bug.