|Summary:||ASTERISK-06154: SRV DNS lookup does not support CNAME records|
|Reporter:||Joachim Koenig (jojo61)||Labels:|
|Date Opened:||2006-01-21 08:02:33.000-0600||Date Closed:||2006-03-08 03:32:35.000-0600|
|Description:||when doing a dns srv lookup an getting the following answer:|
Internet Protocol, Src: 126.96.36.199 (188.8.131.52), Dst: 184.108.40.206 (220.127.116.11)
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 139
Identification: 0x9700 (38656)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 62
Protocol: UDP (0x11)
Header checksum: 0x6df3 [correct]
Bad : False
Source: 18.104.22.168 (22.214.171.124)
Destination: 126.96.36.199 (188.8.131.52)
User Datagram Protocol, Src Port: domain (53), Dst Port: 34684 (34684)
Domain Name System (response)
Transaction ID: 0x57b1
Flags: 0x8180 (Standard query response, No error)
Answer RRs: 1
Authority RRs: 1
Additional RRs: 0
_sip._udp.behrcor.dyndns.org: type SRV, class IN
Type: SRV (Service location)
Class: IN (0x0001)
_sip._udp.behrcor.dyndns.org: type CNAME, class IN, cname behrcor.dyndns.org
dyndns.org: type SOA, class IN, mname ns1.dyndns.org
then the answer is wrongly accepted, but the type ist not treated correctly.
The Type "CNAME" is ignored and the URL is thrown away. The call goes now to the last successfull SRV lookup with a Type SRV in the answer.
|Comments:||By: Olle Johansson (oej) 2006-01-24 05:06:33.000-0600|
Hmmm. What does the standards say about using CNAME here. I remember there was a discussion on whether or not to allow this a long time ago.
By: mikma (mikma) 2006-01-24 07:45:46.000-0600
_sip._udp.behrcor.dyndns.org in the above example is a CNAME RR that points to an A RR, that doesn't make much sense to me. It should be discarded as invalid.
A _sip._udp CNAME RR that instead points to a valid SRV record could be used, but I don't know if it's mandatory to support that.
By: Kevin P. Fleming (kpfleming) 2006-02-14 16:48:14.000-0600
I don't think there is any reason to support CNAME records as the direct result of the query. Just like MX records, they are top-level records used to find a service, and the record content requirements are well documented.
By: Joachim Koenig (jojo61) 2006-02-15 01:20:40.000-0600
I agree that it is not needed to accept CNAME records, but currently they are accepted and not treated correct. If a SRV DNS lookup returns a CNAME record than the answer accepted and no normal DNS lookup is made.
So we do not get any IP adress and so direct calls to such an URL do not work.
By: Olle Johansson (oej) 2006-03-08 02:56:05.000-0600
Checking with ENUM/DNS experts... Hopefully back soon.
By: Olle Johansson (oej) 2006-03-08 03:32:17.000-0600
"The domain name of the target host. There MUST be one or more
address records for this name, the name MUST NOT be an alias (in
the sense of RFC 1034 or RFC 2181)."
CNAME records is not permitted by the RFC. Case settled.