[dns-operations] 答复: DNS forwarder behavior on response with cname

[Davey Song(宋林健)]

Thanks Mukund. I will look into that document. 

But I'm not convinced by the txt you quote. Because the forwarder or proxy most probably receive records from the cache of the upstream resolver. I mean the AD bit will never set in the response received by the forwarder from upstream resolver. How a forwarder is expected to receive a authoritative answers from authoritative server. In my test case, the local resolver receive 2 cname records and one A record from 114.114.114.114. It query again to 114.114.114.114 for A query of the cname. It makes no sense.

Davey
> -----邮件原件-----
> 发件人: Mukund Sivaraman [mailto:muks at mukund.org]
> 发送时间: 2018年12月7日 17:29
> 收件人: Davey Song(宋林健)
> 抄送: dns-operations at dns-oarc.net
> 主题: Re: [dns-operations] DNS forwarder behavior on response with cname
> 
> On Fri, Dec 07, 2018 at 04:06:29PM +0800, Davey Song(宋林健) wrote:
> > Hi folks,
> >
> >
> >
> > I noticed my local resolver (set forwarder for . ) send queries for
> > cname after it received a response which contains cname in answer section.
> >
> > For example when I dig A www.youku.com @my local resolver . It returns
> > two cname RR and A RR in answer section. It is observed that local
> > resolver sent a A query on the first cname :
> > ipv6-aserver-heyi.m.taobao.com. The local resolver response the client
> > only after it got answer from the cname response. It definite
> > introduces a delay in between. Is it normal ?  which RFC specify this or is it a
> implementation consideration? For what purpose ?
> 
> See RFC 2181 section 5.4.1:
> 
>    Note that the answer section of an authoritative answer normally
>    contains only authoritative data.  However when the name sought is an
>    alias (see section 10.1.1) only the record describing that alias is
>    necessarily authoritative.  Clients should assume that other records
>    may have come from the server's cache.  Where authoritative answers
>    are required, the client should query again, using the canonical name
>    associated with the alias.
> 
> 		Mukund