DNS query type HTTPS(TYPE65) will cause the ECS of the CNAME record type to become invalid [181593657]

Verified

Customer Issue

Status Update

No update yet.

Description

jo...@gmail.com

created issue #1

Mar 2, 2021 09:40AM

Description

Suppose we set the following record for example.com:

typehttps	CNAME	test1.example.com.	# match view 8.8.8.0/24
typehttps	CNAME	test2.example.com.	# match other views (default)
test1		A	8.8.8.8
test2		A	8.8.4.4

While send a query of type HTTPS (TYPE65) use domain typehttps.example.com with ECS 8.8.8.0/24 to Google Public DNS, such as:

dig @8.8.8.8 typehttps.example.com +subnet=8.8.8.0/24 TYPE65

Google Public DNS send query to authoritative name servers won't include an ECS options, so the authoritative name servers will response the wrong CNAME answer test2.example.com, then response it to client, like this:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 8.8.8.0/24/0
;; QUESTION SECTION:
;typehttps.example.com.           IN      TYPE65

;; ANSWER SECTION:
typehttps.example.com.    600     IN      CNAME   test2.example.com.

;; AUTHORITY SECTION:
example.com.              600     IN      SOA     xxxxxxxx

Because it not include ECS in query and response, Google Public DNS treat the answer as global /0 scope and cache it. Then the A, AAAA, CNAME, or others type of query with ECS 8.8.8.0/24 will also get the wrong response until the TTL expires.

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 8.8.8.0/24/0
;; QUESTION SECTION:
;typehttps.example.com.           IN      A

;; ANSWER SECTION:
typehttps.example.com.	599	IN	CNAME	test2.example.com.
test2.example.com	600	IN	A	8.8.4.4

Reference

DNS SVCB and HTTPSSVC follow CNAME in draft-ietf-dnsop-svcb-httpssvc-03#section-4.2.

Other issue

The query type of MX and CAA has the same issue.

Comments

jo...@gmail.com <jo...@gmail.com> #2Mar 3, 2021 07:37AM

This will seriously affect the geo-located scheduling of CDN, especially when using multiple different CDNs, because they will set different CNAME RR in different regions.

Message last modified on Mar 4, 2021 01:39PM

rs...@nextdns.io <rs...@nextdns.io> #3Mar 13, 2021 04:07AM

We are reproducing this issue on our auth. I can provide tcpdump if needed.

I'm not sure it is linked, but it seems to also make the sending of ECS by google flapping. We get no ECS on other qtypes once every 5-10 queries.

lu...@google.com <lu...@google.com> Mar 18, 2021 04:26PM

Assigned to lu...@google.com.

lu...@google.com <lu...@google.com> #4Mar 19, 2021 07:16PM

The typehttps.example.com and test(1|2).exmple.com no longer exist. Would it possible to set them up again so that we can verify the behavior? Thanks

rs...@nextdns.io <rs...@nextdns.io> #5Mar 19, 2021 10:32PM

You can reproduce with

steering.nextdns.io.

jo...@gmail.com <jo...@gmail.com> #6Mar 22, 2021 03:26PM

The typehttps.example.com and test(1|2).exmple.com just as an example, not an actual domain name.

And now I have set up the actual test domain name and record according to the example, you can use the domain typehttps.dnsov.net and test(1|2).dnsov.net reproduce this problem.

pu...@google.com <pu...@google.com> #7Mar 25, 2021 09:05PM

There has been recent discussion on support for ECS with SVCB/HTTPS record types in the IETF. The proposed text change is at

https://github.com/MikeBishop/dns-alt-svc/pull/308. The main suggestion is for a recursive resolver that supports TargetName resolution to specify ECS option with /0 for SVCB/HTTPS queries. This is because the resolver will make separate queries for the A/AAAA records (which can include ECS).

Also note that ECS does not apply to A/AAAA records in the Additional section (see paragraph 6 in

https://tools.ietf.org/html/rfc7871#section-7.3.1). SVCB/HTTPS/MX records have A/AAAA in the additional section.

Question: At what level in a registered domain do you apply the CNAMEs described in this bug? At zone apex or lower? Zone apex CNAME will not work well with Google Public DNS since that is disallowed by the definition of CNAME.

rs...@nextdns.io <rs...@nextdns.io> #8Mar 25, 2021 10:24PM

In our case, the CNAME is not at the apex. Here is an example:

dns.nextdns.io. 300 IN CNAME

steering.nextdns.io.

steering.nextdns.io. 60 IN HTTPS 1

dns1.steering.nextdns.io. alpn="h2" ipv4hint=37.252.225.79 ipv6hint=2a00:11c0:2:998::3

steering.nextdns.io. 60 IN HTTPS 1

dns2.steering.nextdns.io. alpn="h2" ipv4hint=193.168.204.73 ipv6hint=2a0e:9900:0:1::1:2

The

steering.nextdns.io domain is the one making use of ECS for steering.

jo...@gmail.com <jo...@gmail.com> #9Mar 26, 2021 07:14AM

The CNAME is also not at the zone apex in our case.

This suggestion seems to be helpful, just need to pay attention to the CNAME is also part of the HTTPS record when the project is implemented.

Message last modified on Mar 26, 2021 08:04AM

lu...@google.com <lu...@google.com> #10Apr 1, 2021 08:04PM

We enabled ECS for HTTPS and SVCB types and should be live by this Friday. We are still evaluating ECS behavior of other relevant qtypes.

rs...@nextdns.io <rs...@nextdns.io> #11Apr 1, 2021 08:08PM

Just to be clear, did you enable ECS with zero or non-zero scope for HTTPS/SVCB?

lu...@google.com <lu...@google.com> #12Apr 1, 2021 08:18PM

To be explicit, Google public DNS will accept/cache non-zero scope ECS responses for HTTPS/SVCB. Previously they are always cached globally (zero scope).

rs...@nextdns.io <rs...@nextdns.io> #13Apr 1, 2021 08:23PM

Thank you.

jo...@gmail.com <jo...@gmail.com> #14Apr 2, 2021 08:25AM

Thanks for your work, and i test it work correctly now.

pu...@google.com <pu...@google.com> May 10, 2021 09:57PM

Verified by pu...@google.com.

Issue 181593657

Description

Description

Reference

Other issue

Issue summary

Comments

jo...@gmail.com <jo...@gmail.com> #2Mar 3, 2021 07:37AM

rs...@nextdns.io <rs...@nextdns.io> #3Mar 13, 2021 04:07AM

lu...@google.com <lu...@google.com> Mar 18, 2021 04:26PM

lu...@google.com <lu...@google.com> #4Mar 19, 2021 07:16PM

rs...@nextdns.io <rs...@nextdns.io> #5Mar 19, 2021 10:32PM

jo...@gmail.com <jo...@gmail.com> #6Mar 22, 2021 03:26PM

pu...@google.com <pu...@google.com> #7Mar 25, 2021 09:05PM

rs...@nextdns.io <rs...@nextdns.io> #8Mar 25, 2021 10:24PM

jo...@gmail.com <jo...@gmail.com> #9Mar 26, 2021 07:14AM

lu...@google.com <lu...@google.com> #10Apr 1, 2021 08:04PM

rs...@nextdns.io <rs...@nextdns.io> #11Apr 1, 2021 08:08PM

lu...@google.com <lu...@google.com> #12Apr 1, 2021 08:18PM

rs...@nextdns.io <rs...@nextdns.io> #13Apr 1, 2021 08:23PM

jo...@gmail.com <jo...@gmail.com> #14Apr 2, 2021 08:25AM

pu...@google.com <pu...@google.com> May 10, 2021 09:57PM

Add comment

Issue metadata