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

Status: NEW

Description

[daniel]

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

Comment 1

[daniel]

Also reported to Chrome:

https://code.google.com/p/chromium/issues/detail?id=559115

Comment 2

[Simona Badau [Away. Please needinfo? Alin Deac [:alindeac]]]

Seems like a networking related issue. Move bug to WebRTC: Networking component. Please advise.

Comment 3

[daniel]

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

[Randell Jesup [:jesup]]

Chrome also considers it to be a spec-compliance issue, but low priority.

Comment 5

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.