Google doesn't resolve CNAME to cdn in aws

[Rodrigo Ribeiro]

Hi,

We have several domains with CNAME pointing to AWS cdn, which are not resolving by Google DNS.

This is limitation on the size of the response that is truncating, that we identified through the tests of https://dnsviz.net/

;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.

This is already known to us, but we will fix this in the future.

We need our nameservers below to be whitelisted so the domains resolve by Google DNS:

ns1.dominios.uol.com.br
ns2.dominios.uol.com.br
ns3.dominios.uol.com.br

[Saeksun Khamsan]

thank you

ในวันที่ วันพฤหัสบดีที่ 18 สิงหาคม ค.ศ. 2022 เวลา 22 นาฬิกา 03 นาที 47 วินาที UTC+7 Rodrigo Ribeiro เขียนว่า:

[Rodrigo Ribeiro]

Hello,

Any update on this matter?

[Rodrigo Ribeiro]

Hello,

Any update on this matter?Hello,

Any update on this matter?

Em quinta-feira, 18 de agosto de 2022 às 12:03:47 UTC-3, Rodrigo Ribeiro escreveu:

[pun...@google.com]

We have rolled out an update which retries over TCP in case of malformed and truncated UDP responses. This should fix the resolution problem for your name servers assuming they support TCP.

If there is still a problem, please file a ticket following instructions at https://developers.google.com/speed/public-dns/groups#issues. Provide examples of a domain which is consistently broken with dig output.

Can you also share with us the name of the DNS server software you are using?

Thanks.

[Rodrigo Ribeiro]

Hello,

We noticed that the frequency of problems has reduced, but it still returns an error on https://dnsviz.net/ and the alert that the UDP playload has exceeded.

Here we release the check via TCP, but there is also a size limitation, even in this protocol.

We are using power dns, but without DNSSEC support.

The domains below are all a CNAME to the AWS CDN:

www.sobrancelhasparklagos.com.br
www.belezachiconline.com.br
www.emporiosaudeesabor.com.br
www.planetasweetie.com.br

--
You received this message because you are subscribed to a topic in the Google Groups "public-dns-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/public-dns-discuss/eB61rvvh_18/unsubscribe.
To unsubscribe from this group and all its topics, send an email to public-dns-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/public-dns-discuss/fe16ce54-5425-4f73-b803-017558887276n%40googlegroups.com.

--

Rodrigo Ribeiro

Cel: 11 95349-3396

E-mail: ribe...@gmail.com

[Viktor Dukhovni]

Are you still seeing any issues with queries via 8.8.8.8 or 8.8.4.4?  If so, can you post some example failures seen via "dig"?  The issues seen via DNSViz were:

* Known broken support for empty non-terminals (ENTs) at AWS. This does not affect Google Public DNS, which for now (along with many other resolvers) tolerates the AWS misbehaviour.  You could switch to a DNS operator that implements ENTs correctly, if you wish.

* An spurious report of an MTU issue between DNSViz and G-ROOT when resolving the DS records for .BR. This was likely transient packet loss. The actual reply "BR. IN DS ?" from the G-ROOT  is only ~400 bytes.

* Mostly harmless glue AAAA records for one of the nameservers of "vtech.com"

The DNSViz data for the reported domain was 21 days old: https://dnsviz.net/d/www.sobrancelhasparklagos.com.br/YvV8Iw/dnssec/

Refreshing the DNSViz data eliminates the spurious MTU issue.  None of the issues are related to Google Public DNS. What actual problem are you trying to solve? Please show some queries to Google Public DNS and corresponding responses, that occur with some regularity and produce unwanted results.

You received this message because you are subscribed to the Google Groups "public-dns-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public-dns-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/public-dns-discuss/CA%2B%3DVqKtCoWW%3DmQfH6ZzPRtOhbPSZEPS6CyqpBvkDkwvzRfyTcA%40mail.gmail.com.

--

    Viktor.