Comments (3)
This looks like 3 different issues:
The library should fall back to TCP when
EINVAL
is returned on UDP writes. (This also likely applies to QUIC connections.)
This makes sense to me. Want to send a PR? I think we have some code for fallback already so probably just involves adding io::ErrorKind::InvalidData
in a match arm somewhere.
Ideally it would be possible to force TCP with a simple call when configuring the resolver, such as:
Resolver::from_system_conf().force_proto(Protocol::Tcp)
.
I'm not sure this use case is important enough that we'd want to have specific API for it, but we recently discussed in #2188 that mutating the configuration returned from from_system_conf()
is generally pretty annoying, so I think we could discuss how we could improve on that.
It would also be nice if the library would let the host OS choose the ephemeral source port. Either by-default for
from_system_conf
resolvers or it should be easy to enable. It's quite possible that the host OS is configured to allow a range better (or more suitable in some setups) than what the library uses. Source port ranges and usage can also used for fingerprinting, this would reduce the effectiveness of such approaches.
I don't know that we can readily get this information? We use the resolv-conf crate on Linux, and from a quick look it doesn't to yield this information. It otherwise sounds reasonable, though.
from trust-dns.
This looks like 3 different issues:
Possibly 😅
This makes sense to me. Want to send a PR?
I'm unfortunately not familiar enough with Rust to contribute such changes.
I'm not sure this use case is important enough that we'd want to have specific API for it
Fair enough. It would be sufficient if ResolverConfig
would have something like get_name_servers
, then one could mutate those entries and replace them later with set_name_servers
. There's already add_name_server
, so those two would likely be generic enough.
I don't know that we can readily get this information?
I don't think there's an OS-agnostic way of getting this information. This shouldn't however be an obstacle in leaving it to the OS, which is not difficult, unless there's a strong need for otherwise.
from trust-dns.
I was just looking at this. First, I'm going to simplify the ResolveError, rather than having it wrap IO errors itself, it will always use the interior ProtoError for that, it simplifies some logic. Second, rather than being specific about the IO error, perhaps we always retry on TCP on any IO error... Thoughts?
I figure any IO error on UDP is worth promoting to TCP. That said, I think the complexity here, and the reason we're getting test failures in the other PR is there might be multiple UDP name servers to try before going to TCP. I'm trying to see if there is a good way to do with this scenario.
from trust-dns.
Related Issues (20)
- Missing point of contact for security issues HOT 3
- `IN` keyword is not accepted HOT 2
- Request for a wildcard with ANY returns nothing HOT 2
- Handle sockets that have been shut down HOT 5
- Make ```hickory_proto::quic::QuicClientStream``` clonable
- why hickory-proto 0.24.1 ring dependencies is still 0.16.20 HOT 4
- Not convenient to call bind_with_addr to make a AsyncResolver HOT 6
- Bind address in ResolverConfig does not take effort for AsyncResolver HOT 10
- `hickory-dns` responds to `dig A doesnotexist.fqdn.com.` with NOERROR instead of with NXDOMAIN HOT 6
- `hickory-dns` resolver does not honor the DO bit in client's queries HOT 2
- [RFC] DNSSEC validation: configuration syntax HOT 11
- [RFC] re-structure `named.toml` syntax to reject invalid configurations HOT 3
- 0.25 Release HOT 10
- Static build support (openssl + cross-compile) HOT 6
- `DnssecDnsHandle` does not appear to validate RRSIG's signature {inception,expiration} fields HOT 1
- malformed query can cause assertion failure at encoder.rs:234 HOT 1
- should `proto::rr::resource::Record.rdata` really be an `Option`? HOT 6
- `just clippy` does not catch warnings produced by `just dnssec-openssl` HOT 5
- DNS Resolver rotate feature HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from trust-dns.