Comments (3)
I think you're raising a very relevant issue here 👍
Currently, the Resolver
only resolves hostnames to IPv4 addresses (A
and CNAME
), while the ExecutorInterface
allows you to execute arbitrary queries. As such, I believe this issue to be twofold:
How can we configure the Resolver
to resolve to IPv6 addresses? How can I explicitly set this and eventually how can this be determined automatically? Is IPv6 preferred over IPv4 and are even both supported? The most common usage of this is likely with the higher-level Connector
, which is why I've justed created reactphp/socket#116.
Other than the default resolve()
method, there's also the question on how to execute "special queries", such as MX
or SRV
. These do not really fit with the existing resolve()
interface which only resolve with one random record as a result, while MX
and SRV
actually need access to all results to implement a fallback strategy (such as trying highest priority first etc.). As such, I believe it's probably best to either add a new API for these more advanced queries or maybe even keep this within the ExecutorInterface
only.
I'm curious what others think about this, what other projects offer similar APIs? 👍
from dns.
I'd also be interested in how to determine IPv6 support / route-ability for amphp/socket#35.
For the second issue I'd recommend to have separate query
and resolve
methods as amphp/dns
has and as the DNS RFC suggests. Multiple records might also be useful for A
/ AAAA
with a retry mechanism in the Connector
.
I'd probably remove either Resolver
or Executor
, but there's no definite need for it. Doesn't really matter whether they're two methods or two classes where one uses the other.
from dns.
@clue How can we configure the Resolver to resolve to IPv6 addresses? How can I explicitly set this and eventually how can this be determined automatically? Is IPv6 preferred over IPv4 and are even both supported? The most common usage of this is likely with the higher-level Connector, which is why I've justed created reactphp/socket#116.
Other than the default resolve() method, there's also the question on how to execute "special queries", such as MX or SRV. These do not really fit with the existing resolve() interface which only resolve with one random record as a result, while MX and SRV actually need access to all results to implement a fallback strategy (such as trying highest priority first etc.). As such, I believe it's probably best to either add a new API for these more advanced queries or maybe even keep this within the ExecutorInterface only.
We now have support for the most relevant resource record types (RRs) such as A
, AAAA
, MX
, TXT
, SRV
etc. (see #31).
The current $resolver->resolve($host)
is limited to IPv4, only looks up A
records (and obeys CNAME
records accordingly) and only returns one random record value. As such, this is pretty much the async equivalent of the (mostly deprecated) gethostbyname()
function.
It is my understanding that we should add a new method which supports passing an explicit record type (such as AAAA
) and return the full array of all record values. I would suggest adding a new $resolver->resolveAll($host, $type)
method (very much similar to what @WyriHaximus suggested in #67). As such, this would be pretty much the async equivalent of the more modern getaddrinfo()
function (see also https://www.akkadia.org/drepper/userapi-ipv6.html) or PHP's dns_get_record()
.
For the reference: Node.js uses dedicated method names (such as resolveA()
, resolve6()
, etc.) instead of accepting a type parameter. Given our current APIs, I would suggest using a single new method which requires a type parameter instead of adding new methods for each type (new record record types are still added occasionally). Similarly, this method should only return the record values, for example the IP for A
/AAAA
queries and a structure with priority and target for MX
queries. Its query type and meta data such as TTL should not be included. This also implies that it is not suited for ANY
(also known as *
wildcard) queries as results would be rather meaningless without knowing its resource type. As such, I would suggest rejecting ANY
queries and instead looking into a dedicated resolveAny()
method eventually which should include at least the answer type and value (arguably out of scope in this discussion).
Once the resolveAll()
method is in, we can explicitly query IPv6 (AAAA
) or IPv4 (A
) record values. It is my understanding that this library SHOULD NOT provide a way to automatically decide which type of query it should send. Instead, it should be left up to higher-level consumers of this API to query the appropriate type. For our Socket component, this means that it will likely start querying both types simultaneously and then try both address types following the "happy eyeballs algorithm" (see reactphp/socket#116 for more details).
Once this is supported in our Socket component, we may want to add some configuration options to disable either protocol type (there's no reliable way to detect IPv6 support) and also deprecate the then unused $resolver->resolve($host)
method.
from dns.
Related Issues (20)
- Support extended DNS (EDNS0)
- PHP Fatal error: Maximum function nesting level of '256' reached, aborting! Protocol/Parser.php on line 293 HOT 14
- DNS Cache is not used when the type of the response record is CNAME HOT 3
- Gate way issue Discord HOT 1
- Roadmap to stable v1.0.0 HOT 4
- Ask host OS for DNS service address at startup, if none given by caller HOT 3
- getting ttl value HOT 1
- querying for SOA but got CNAME instead of empty answer or error HOT 2
- Connection to DNS server lost HOT 1
- Support DNS search domain list (resolve local hostname to FQDN) HOT 3
- Question: I like the pure PHP DNS client. Can I use it without the $loop in a non-PHP react project? HOT 1
- Exceptions constantly thrown in debugger HOT 12
- Test failure because f integer overflow on 32-bit system HOT 1
- Question using protocol classes directly HOT 4
- Mark current version as stable / memory limit exceeded HOT 1
- How to use reactdns in a waiting (sync) mode? HOT 3
- How to store data in array when doing resolveAll()? HOT 2
- Failure modes HOT 8
- Roadmap to reactphp/dns v3
- Consider supporting advanced DNS config (nsswitch,conf, hosts.conf, resolv.conf options and ENV variables etc.) HOT 1
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.