dns-over-https: Error when trying to resolve www.netflix.com

Since some days ago, resolving www.netflix.com through dns-over-https fails for some unknown reason. It doesn’t seem to be an upstream problem and all other domains I try work as expected.

I’m running version 2.3.2 on Arch Linux.

Upstream is configured like this:

bootstrap = [
    # CloudFlare's resolver, bad ECS, good DNSSEC
    "1.1.1.1:53",
    "1.0.0.1:53",
]

When using the host command, I get this:

> host www.netflix.com
;; Got bad packet: unexpected end of input
512 bytes
00 1a 83 80 00 01 00 06 00 00 00 01 03 77 77 77          .............www
07 6e 65 74 66 6c 69 78 03 63 6f 6d 00 00 01 00          .netflix.com....
01 03 77 77 77 07 6e 65 74 66 6c 69 78 03 63 6f          ..www.netflix.co
6d 00 00 05 00 01 00 00 01 2b 00 18 03 77 77 77          m........+...www
06 64 72 61 64 69 73 07 6e 65 74 66 6c 69 78 03          .dradis.netflix.
63 6f 6d 00 03 77 77 77 06 64 72 61 64 69 73 07          com..www.dradis.
6e 65 74 66 6c 69 78 03 63 6f 6d 00 00 05 00 01          netflix.com.....
00 00 00 3b 00 2b 03 77 77 77 09 65 75 2d 77 65          ...;.+.www.eu-we
73 74 2d 31 08 69 6e 74 65 72 6e 61 6c 06 64 72          st-1.internal.dr
61 64 69 73 07 6e 65 74 66 6c 69 78 03 63 6f 6d          adis.netflix.com
00 03 77 77 77 09 65 75 2d 77 65 73 74 2d 31 08          ..www.eu-west-1.
69 6e 74 65 72 6e 61 6c 06 64 72 61 64 69 73 07          internal.dradis.
6e 65 74 66 6c 69 78 03 63 6f 6d 00 00 05 00 01          netflix.com.....
00 00 00 3b 00 4a 2c 61 70 69 70 72 6f 78 79 2d          ...;.J,apiproxy-
77 65 62 73 69 74 65 2d 6e 6c 62 2d 70 72 6f 64          website-nlb-prod
2d 33 2d 61 63 31 31 30 66 36 61 65 34 37 32 62          -3-ac110f6ae472b
38 35 61 03 65 6c 62 09 65 75 2d 77 65 73 74 2d          85a.elb.eu-west-
31 09 61 6d 61 7a 6f 6e 61 77 73 03 63 6f 6d 00          1.amazonaws.com.
2c 61 70 69 70 72 6f 78 79 2d 77 65 62 73 69 74          ,apiproxy-websit
65 2d 6e 6c 62 2d 70 72 6f 64 2d 33 2d 61 63 31          e-nlb-prod-3-ac1
31 30 66 36 61 65 34 37 32 62 38 35 61 03 65 6c          10f6ae472b85a.el
62 09 65 75 2d 77 65 73 74 2d 31 09 61 6d 61 7a          b.eu-west-1.amaz
6f 6e 61 77 73 03 63 6f 6d 00 00 01 00 01 00 00          onaws.com.......
00 3b 00 04 36 4a 49 1f 2c 61 70 69 70 72 6f 78          .;..6JI.,apiprox
79 2d 77 65 62 73 69 74 65 2d 6e 6c 62 2d 70 72          y-website-nlb-pr
6f 64 2d 33 2d 61 63 31 31 30 66 36 61 65 34 37          od-3-ac110f6ae47
32 62 38 35 61 03 65 6c 62 09 65 75 2d 77 65 73          2b85a.elb.eu-wes
74 2d 31 09 61 6d 61 7a 6f 6e 61 77 73 03 63 6f          t-1.amazonaws.co
6d 00 00 01 00 01 00 00 00 3b 00 04 03 fb 32 95          m........;....2.
2c 61 70 69 70 72 6f 78 79 2d 77 65 62 73 69 74          ,apiproxy-websit
65 2d 6e 6c 62 2d 70 72 6f 64 2d 33 2d 61 63 31          e-nlb-prod-3-ac1
31 30 66 36 61 65 34 37 32 62 38 35 61 03 65 6c          10f6ae472b85a.el

But everything seems fine when asking upstream directly:

> host www.netflix.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

www.netflix.com is an alias for www.dradis.netflix.com.
www.dradis.netflix.com is an alias for www.eu-west-1.internal.dradis.netflix.com.
www.eu-west-1.internal.dradis.netflix.com is an alias for apiproxy-website-nlb-prod-2-b4de62b516adfbbf.elb.eu-west-1.amazonaws.com.
apiproxy-website-nlb-prod-2-b4de62b516adfbbf.elb.eu-west-1.amazonaws.com has address 18.200.8.190
apiproxy-website-nlb-prod-2-b4de62b516adfbbf.elb.eu-west-1.amazonaws.com has address 54.155.246.232
apiproxy-website-nlb-prod-2-b4de62b516adfbbf.elb.eu-west-1.amazonaws.com has address 54.73.148.110
apiproxy-website-nlb-prod-2-b4de62b516adfbbf.elb.eu-west-1.amazonaws.com has IPv6 address 2a05:d018:76c:b683:e1fe:9fbf:c403:57f1
apiproxy-website-nlb-prod-2-b4de62b516adfbbf.elb.eu-west-1.amazonaws.com has IPv6 address 2a05:d018:76c:b684:b233:ac1f:be1f:7
apiproxy-website-nlb-prod-2-b4de62b516adfbbf.elb.eu-west-1.amazonaws.com has IPv6 address 2a05:d018:76c:b685:c898:aa3a:42c7:9d21

The only unusual thing I see about Netflix is the rather long list of results. Could imagine there is a limit on message size in dns-over-https which is exceeded because of that.