Comments (7)
I fundamentally disagree with this.
There ought to be one global configuration for all programs, in /etc/resolv.conf for Linux - or the Windows equivalent (TODO: add support for it!).
If you need special nameservers, this is not to be done on a program-level, but either on a host-wide level, or, for specific cases, in the individual query or resolve calls.
The sole point of the classes is overriding the current implementation, not to carry state. State shall be fully transparent to the outside. There may be other caching behavior (e.g. a DNS implementation using shared memory for cache), or a mock for testing a library directly using the DNS. But it shouldn't carry process-wide options.
This also has the big advantage of us not having problems with different parts of the application fighting for different configured nameservers or a similar mess.
from dns.
There ought to be one global configuration for all programs, in /etc/resolv.conf for Linux - or the Windows equivalent (TODO: add support for it!).
That one will still be the same.
If you need special nameservers, this is not to be done on a program-level, but either on a host-wide level, or, for specific cases, in the individual query or resolve calls.
Sure, that's why I said:
If anyone needs a different resolver, they should just go ahead and create a new resolver object with the nameserver as argument and execute their query then.
They should use $resolver->query
, not Amp\Dns\query
which executes with the global resolver.
The sole point of the classes is overriding the current implementation, not to carry state.
Why should it? It's not really about state, but rather about configuration.
Suppose we have a DNS resolver that works by querying an HTTP API instead of using the DNS protocol. That resolver wouldn't be able to use other nameservers.
This also has the big advantage of us not having problems with different parts of the application fighting for different configured nameservers or a similar mess.
That will still be the same. Just the way you're querying alternative nameservers will change from Amp\Dns\resolve
with $options["nameserver"]
to (new DnsResolver("8.8.8.8"))->query(...)
.
But it shouldn't carry process-wide options.
They don't. The accessor stores that process-wide state, not the classes.
from dns.
Suppose we have a DNS resolver that works by querying an HTTP API instead of using the DNS protocol. That resolver wouldn't be able to use other nameservers.
This custom DNS resolver would be a standalone entity and not related to our DNS resolver, nor should it implement our interface.
That will still be the same. Just the way you're querying alternative nameservers will change from Amp\Dns\resolve with $options["nameserver"] to (new DnsResolver("8.8.8.8"))->query(...).
They can trivially wrap it in a class { public $nameserver; function query($q, $t) { \Amp\query($q, $t, ["options" => $this->nameserver]); } ... } and similar. That's not the task of this global DNS abstraction.
from dns.
Why do we even have these classes then? I see no reason to have the nameserver as an option to query
.
from dns.
The only reasons is being able to change internal details (e.g. shared memory DNS caching etc.) or mocking (in tests).
No other reason.
from dns.
Ok, I'll ask differently: What's the reason to keep nameserver
as an option to Amp\Dns\query
? Why shouldn't you just create a new resolver instance with the nameserver passed as argument?
from dns.
a) the other options are also still options. No point in making one option instance specific and the others not??
b) Creating a new instance for every different option is probably only slow and clumsy and you end up with a bunch of objects flying around (given you don't want to re-establish yourself the connection to the server each time etc.)
c) keeping options localized to the individual calls keeps code readable (less cognitive overhead), i.e. only use non-defaults where necessary.
d) If every instance of the class using DNS is going to instantiate its own DNSResolver (to the same nameserver), that's much more resource intensive [more watchers, more connections, ...].
from dns.
Related Issues (20)
- Too many time to resolve localhost domain HOT 7
- getting could not load the system's DNS configuration, using synchronous, blocking fallback error HOT 9
- Incomplete packet error (still exists) HOT 1
- Could Not Resolve Host HOT 3
- Backport queue errors on closure
- Rename Record and Resolver as well?
- Amp\Dns\resolve misses optional Cancellation parameter
- Async example? HOT 1
- Resolution where NDots > 1 failing
- Remove amphp/file dependency
- Bump the minimum version of amphp/uri HOT 4
- DNS resolution not working on Kubernetes HOT 5
- Subtype 'Too many redirects' DnsException HOT 1
- CreateProcess failed, error 193 HOT 6
- Libdns bug HOT 5
- Are dotless domains valid? HOT 3
- DNS frequently fails on Windows HOT 3
- Incomplete packet error HOT 4
- etc/resolve ndots set to 1 HOT 1
- Ignore ServFail / NxDomain for search list, e.g. in Kubernetes cluster HOT 9
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 dns.