strange response to the DS request

[Mark Andrews]

In message <CAJE_bqc-QFMa_Mi=j1+npauT1U3DeYMFd=_Be8Wf4QBwwQswUw at mail.gmail.com>
, =?UTF-8?B?56We5piO6YGU5ZOJ?= writes:
> At Fri, 4 Mar 2016 14:07:03 +0900,
> Manabu Sonoda <manabu-s at iij.ad.jp> wrote:
> 
> > I find the the strange response to the DS request.
> > That response answer type is CNAME.
> >
> > This can happen if Child and Parent zone in same nameserver and
> > Parent zone does not have NS recode for Child zone and
> > Parent zone have CNAME recode with the same name as Child zone.
> 
> Do you mean, for example, if you configure a BIND 9 named as follows:
> 
> - master zone 'example.com' which has the following CNAME:
>   www.example.com'. CNAME www.example.net.
> - master zone 'www.example.com'
> 
> and send a query for www.example.com/DS, then named returns the above
> CNAME?
> 
> If so, I agree it looks odd, and we might say it's against Section
> 2.2.1.2 of RFC3658 (if we superficially applied this section the answer
> would be NOERROR-NODATA with the SOA of www.example.com).

No.  The algorithm stops at step 1.  Example.com "holds" the DS
if it existed.

   1) If the nameserver is authoritative for the zone that holds the DS
      RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent"
      zone), the response contains the DS RR set as an authoritative
      answer.

There is nothing strange here beyond a missing delegation.
 
> But I'd say it's not specific to CNAME.  if you include
> www.example.com/AAAA in the example.com zone instead of CNAME, the
> response to www.example.com/DS will be NOERROR-NODATA but with the SOA
> for example.com, not www.example.com.  It might look less odd, but
> would still be considered broken.
> 
> Also, if you configure named as follows instead:
> 
> - master zone 'example.com' which has the following CNAME:
>   www.zzz.example.com'. DNAME www.example.net.
> - master zone 'www.zzz.example.com'
> 
> and send a query for www.zzz.example.com/DS, named will return the
> DNAME.  This is another example to show it's not CNAME specific.
> 
> I'm not sure whether we should do something about it, though.  As you
> pointed out, the configuration is already so broken: there's even no
> delegation from the parent (or ancestor) to the child zone, so I'm not
> sure if we can define any valid behavior in such a case based on
> RFC3658 or any other standard document.
> 
> So I'm wondering: is this something odd you just happen to find in a
> test environment or something, or is there any practical issue because
> of that?
> 
> --
> JINMEI, Tatuya
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org