[Home]

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-0600Date Closed:2006-03-08 03:32:35.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:when doing a dns srv lookup an getting the following answer:

Internet Protocol, Src: 194.97.173.124 (194.97.173.124), Dst: 85.74.114.70 (85.74.114.70)
   Version: 4
   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]
       Good: True
       Bad : False
   Source: 194.97.173.124 (194.97.173.124)
   Destination: 85.74.114.70 (85.74.114.70)
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)
   Questions: 1
   Answer RRs: 1
   Authority RRs: 1
   Additional RRs: 0
   Queries
       _sip._udp.behrcor.dyndns.org: type SRV, class IN
           Name: _sip._udp.behrcor.dyndns.org
           Type: SRV (Service location)
           Class: IN (0x0001)
   Answers
       _sip._udp.behrcor.dyndns.org: type CNAME, class IN, cname behrcor.dyndns.org
   Authoritative nameservers
       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

RFC2782:

"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.