Opened 15 years ago
Closed 11 years ago
#189 closed enhancement (fixed)
DNS resolver
Reported by: | Jakub Jermář | Owned by: | Jiri Svoboda |
---|---|---|---|
Priority: | major | Milestone: | 0.6.0 |
Component: | helenos/net/other | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | #405 | |
See also: |
Description (last modified by )
Implement the client support for the DNS protocol so that HelenOS can resolve DNS queries. It would be sufficient if the support was first delivered only in the form of a Stub Resolver, as defined by RFC 1123 in 6.1.3.1.
It is reasonable to expect this ticket to deliver the DNS resolver functionality in some sort of a library that other networking code and applications can use.
Change History (8)
comment:1 by , 15 years ago
Description: | modified (diff) |
---|
comment:2 by , 14 years ago
comment:3 by , 14 years ago
Milestone: | 0.5.0 → 0.5.1 |
---|
comment:4 by , 13 years ago
Depends on: | → #405 |
---|
comment:5 by , 13 years ago
Milestone: | 0.5.0 → 0.5.1 |
---|
comment:6 by , 12 years ago
Owner: | set to |
---|---|
Status: | new → accepted |
comment:8 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Merged in mainline,1818. dnsrsrv (service), dnsres (resolution utility) and dnscfg (configuration utility). Plus HelenOS utilities that take an IP adress as argument fixed to accept host name, too.
Future work:
- recursive querying
- domain search list
- lazy decompression
It would seem better in line with HelenOS design for the resolver to be a service. The resolver is likely to implement some form of caching eventually. The cache would be a shared cache (if we resolve hostname A on behalf of one task, no need to resolve it again on behalf of another task). This is easier and more elegantly achieved if there is one central resolver with applications calling it via IPC, rather than having the resolver distributed into the applications and communicating via, say, the file system.