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

Costantino Andrea (Con) andrea.costantino at h3g.it
Fri Dec 7 10:46:02 UTC 2018


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.




More information about the dns-operations mailing list