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

Davey Song(宋林健) ljsong at biigroup.cn
Mon Dec 10 01:25:40 UTC 2018


No. the forwarder's cname-double-check behavior has nothing to do with minimal-response clause. I tested it.

Davey

> -----邮件原件-----
> 发件人: dns-operations [mailto:dns-operations-bounces at dns-oarc.net] 代表
> Costantino Andrea (Con)
> 发送时间: 2018年12月7日 18:46
> 收件人: dns-operations at dns-oarc.net
> 主题: [dns-operations] R: 答复: DNS forwarder behavior on response with
> cname
> 
> It's bind normal behaviour unless you set
> 
>         minimal-responses yes;
> 
> in option clauses.
> 
> Ciao,
> A.
> 
> 
> -----Messaggio originale-----
> Da: dns-operations <dns-operations-bounces at dns-oarc.net> Per conto di
> Davey Song(???)
> Inviato: venerdì 7 dicembre 2018 11:12
> A: 'Mukund Sivaraman' <muks at mukund.org>
> Cc: dns-operations at dns-oarc.net
> Oggetto: [dns-operations] 答复: DNS forwarder behavior on response with
> cname
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> ________________________________
> 
> CONFIDENTIAL: This E-mail and any attachment are confidential and may
> contain reserved information. If you are not one of the named recipients,
> please notify the sender immediately. Moreover, you should not disclose the
> contents to any other person, or should the information contained be used for
> any purpose or stored or copied in any form.
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations






More information about the dns-operations mailing list