Problem with cname target pointing to wildcard A record

Mark Andrews Mark_Andrews at isc.org
Tue Aug 22 23:08:03 UTC 2006


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> If we do
> 
> dig 1.2.3.4.blackholes.five-ten-sg.com a
> 
> we should get both a CNAME record, and the resulting A record, from any of
> the authoratative dns servers, or from any dns server that will do
> recursion for us. At least that is my understanding of correct operation.
> 
> 1.2.3.4.blackholes.five-ten-sg.com. 86400 IN CNAME
> 4.3.208.65.dsl-verizon.net.misc.spam.blackholes.five-ten-sg.com.
> 
> 4.3.208.65.dsl-verizon.net.misc.spam.blackholes.five-ten-sg.com. 864000
> IN A 127.0.0.2
> 
> That A record is actually a wildcard
> *.misc.spam.blackholes.five-ten-sg.com
> 
> This works on all the BIND servers, but is currently failing on some
> authoratative Windows dns servers. In particular, if you try that dig
> above on ns2.five-ten-sg.com, it only returns the CNAME record.
> 
> If the target of the CNAME is not a wildcard, it seems to work
> properly.
> 
> dig 1.2.14.58.blackholes.five-ten-sg.com a @ns2.five-ten-sg.com
> 
> returns both the CNAME and the A record, since 'china.spam' is not a
> wildcard.
> 
> Is there any known workaround for this on Windows, or is this difference
> between BIND and Windows dns allowed by the dns spec?
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> 
> iD8DBQFE60JCL6j7milTFsERAjvvAJ99W7H7SGU6VtF7GvNIQkT8KVbCxgCghljC
> x8vEIJ74KKg3wT6VUaJeg2c=
> =S+qT
> -----END PGP SIGNATURE-----

	File a bug report with Microsoft.  They are not following
	step 3a correctly.

	Note: Wildcard CNAME's are to also to restart processing
	when the query type is not CNAME.  This has been clarified
	by RFC 4592.

	Mark

	RFC 1034 as modified by RFC 4592.

   1. Set or clear the value of recursion available in the response
      depending on whether the name server is willing to provide
      recursive service.  If recursive service is available and
      requested via the RD bit in the query, go to step 5,
      otherwise step 2.

   2. Search the available zones for the zone which is the nearest
      ancestor to QNAME.  If such a zone is found, go to step 3,
      otherwise step 4.

   3. Start matching down, label by label, in the zone.  The
      matching process can terminate several ways:

         a. If the whole of QNAME is matched, we have found the
            node.

            If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

            Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.

         b. If a match would take us out of the authoritative data,
            we have a referral.  This happens when we encounter a
            node with NS RRs marking cuts along the bottom of a
            zone.

            Copy the NS RRs for the subzone into the authority
            section of the reply.  Put whatever addresses are
            available into the additional section, using glue RRs
            if the addresses are not available from authoritative
            data or the cache.  Go to step 4.

         c. If at some label, a match is impossible (i.e., the
            corresponding label does not exist), look to see if a
            the "*" label exists.

            If the "*" label does not exist, check whether the name
            we are looking for is the original QNAME in the query
            or a name we have followed due to a CNAME.  If the name
            is original, set an authoritative name error in the
            response and exit.  Otherwise just exit.

	    If the "*" label does exist, match RRs at that node
	    against QTYPE.  If any match, copy them into the answer
	    section, but set the owner of the RR to be QNAME, and
	    not the node with the "*" label.

	    If the data at the source of synthesis is a CNAME, and
	    QTYPE doesn't match CNAME, copy the CNAME RR into the
	    answer section of the response changing the owner name
	    to the QNAME, change QNAME to the canonical name in the
	    CNAME RR, and go back to step 1.

	    Go to step 6.

   4. Start matching down in the cache.  If QNAME is found in the
      cache, copy all RRs attached to it that match QTYPE into the
      answer section.  If there was no delegation from
      authoritative data, look for the best one from the cache, and
      put it in the authority section.  Go to step 6.

   5. Using the local resolver or a copy of its algorithm (see
      resolver section of this memo) to answer the query.  Store
      the results, including any intermediate CNAMEs, in the answer
      section of the response.

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.


	RFC 4592

3.3.3.  Type Matching

   RFC 1034 concludes part 'c' with this:

   #            If the "*" label does not exist, check whether the name
   #            we are looking for is the original QNAME in the query
   #            or a name we have followed due to a CNAME.  If the name
   #            is original, set an authoritative name error in the
   #            response and exit.  Otherwise just exit.
   #
   #            If the "*" label does exist, match RRs at that node
   #            against QTYPE.  If any match, copy them into the answer
   #            section, but set the owner of the RR to be QNAME, and
   #            not the node with the "*" label.  Go to step 6.

   The final paragraph covers the role of the QTYPE in the lookup
   process.

   Based on implementation feedback and similarities between part 'a'
   and part 'c', a change to this passage has been made.

   The change is to add the following text to part 'c' prior to the
   instructions to "go to step 6":

      If the data at the source of synthesis is a CNAME, and QTYPE
      doesn't match CNAME, copy the CNAME RR into the answer section of
      the response changing the owner name to the QNAME, change QNAME to
      the canonical name in the CNAME RR, and go back to step 1.

   This is essentially the same text in part 'a' covering the processing
   of CNAME RRSets.

--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email training at isc.org.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list