Web Assets don't cache DNS, causing excessive DNS queries can lead to failures
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
## Bevy version and features
Bevy 0.17.2, features: `bevy_dev_tools`, `dynamic_linking`, `http`, `https`, `track_location`
## \[Optional\] Relevant system information
Os: EndeavourOS
Using: NetworkManger with dnsmasq resolver
DNS Server: Unbound with local, stub and forward zones
## What you did
Tried loading a grid of 1040 different PNGs from the same https domain.
## What went wrong
A good number of the PNGs never finished loading with the error:
```
ERROR bevy_asset::server: Encountered an I/O error while loading asset: unexpected error while loading asset https://example.com/img329.png: io: failed to lookup address information: Temporary failure in name resolution
```
## Additional information
Since this seemed odd, I checked the DNS server where I noticed a surprising amount of requests. That caused me to look at tcpdump using:
,
`sudo tcpdump -l -nn port 53 and src host | grep '[+] A[?] example.com' | nl`
Which prints all outgoing A record dns queries querying for example.com with line numbers. And indeed:
```
1046 15:33:03.429826 IP 192.168.178.111.51068 > 192.168.178.2.53: 4799+ A? example.com. (34)
1047 15:33:03.430279 IP 192.168.178.111.38595 > 192.168.178.2.53: 63990+ A? example.com. (34)
```
Bevy makes 1047 DNS requests to load 1040 tiles. I'm not sure where the extra 7 come from, but that's hardly relevant. This is an excessive number of DNS queries for a single domain. And loading many assets from a single domain is likely a very common use case for web assets.
This is why I strongly suspect that the amount of queries just overloads the DNS server, causing the errors.
(I'll have to have a look at my Unbound config tho, as it should be able to handle even this amount.)
Contributor guide
Research direction
Start in the bevy_asset::server loading path and reproduce the issue by loading a grid of 1040 PNGs from one HTTPS domain while monitoring DNS queries. Trace how web asset requests resolve the host, then verify that repeated loads do not cause excessive DNS lookups and that all assets finish loading without temporary name-resolution failures.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100