| Age | Commit message (Collapse) | Author |
|---|
|
Since all types and class names live in the DNS namespace, we don't
need to spell it out twice each time.
|
|
This allows other code to use the DNSPacket class, e.g. when sent
over IPC.
|
|
|
|
This was done with CLion's automatic rename feature and with:
find . -name ClientConnection.h
| rename 's/ClientConnection\.h/ConnectionFromClient.h/'
find . -name ClientConnection.cpp
| rename 's/ClientConnection\.cpp/ConnectionFromClient.cpp/'
|
|
|
|
This encapsulates what our multi-client IPC servers typically do on
startup:
1. Create a Core::LocalServer
2. Take over a listening socket file descriptor from SystemServer
3. Set up an accept handler for incoming connections
IPC::MultiServer does all this for you! All you have to do is provide
the relevant client connection type as a template argument.
|
|
This adds a FileWatcher to the LookupServer which watches '/etc/hosts'
for changes during runtime and reloads its contents. If the file is
deleted, m_etc_hosts will be cleared.
Since we now need to access '/etc/hosts' later during runtime, it needs
to be unveiled with read permissions.
|
|
|
|
The implementation is extremely basic, and is far from fully conforming
to the spec. Among other things, it does not really work in case there
are multiple network adapters.
Nevertheless, it works quite well for the simple case! You can now do
this on your host machine:
$ ping courage.local
and same on your Serenity box:
$ ping host-machine-name.local
|
|
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
|
|
LookupServer can now itself server as a DNS server! To service DNS clients, it
uses the exact same lookup logic as it does for LibIPC clients. Namely, it will
synthesize records for data from /etc/hosts on its own (you can use this to
configure host names for your domain!), and forward other questions to
configured upstream DNS servers. On top of that, it implements its own caching,
so once a DNS resource record has been obtained from an upstream server,
LookupServer will cache it locally for faster future lookups.
The DNS server part of LookupServer is disabled by default, because it requires
you to run it as root (for it to bind to the port 53) and on boot, and we don't
want either by default. If you want to try it, modify SystemServer.ini like so:
[LookupServer]
Socket=/tmp/portal/lookup
SocketPermissions=666
Priority=low
KeepAlive=1
User=root
BootModes=text,graphical
and enable server mode in LookupServer.ini like so:
[DNS]
Nameservers=...
EnableServer=1
If in the future we implement socket takeover for IP sockets, these limitations
may be lifted.
|
|
This way, we propagate proper TTL. None of the callers currently care, though.
|
|
...just like we store m_lookup_cache, in other words.
This immediately lets us match on types: for instance we will now only resolve
1.0.0.127.in-addr.arpa to localhost if asked for type PTR, not for type A. In
the future, this could also let us have the same /etc/hosts name resolve
to *multiple* addresses.
|
|
DNSName can now take care of case conversion when comparing using traits.
It still intentionally doesn't implement operator ==; you have to explicitly
decide whether you want case-sensitive or case-insensitive comparison.
This change makes caches (and /etc/hosts) case-transparent: we will now match
domains if they're the same except for the case.
|
|
We should only cache RRs (which we represent as instances of DNSAnswer), now
which questions generated them.
|
|
This is a wrapper around a string representing a domain name (such as
"example.com"). It never has a trailing dot.
For now, this class doesn't do much except wrap the raw string. Subsequent
commits will add or move more functionality to it.
|
|
They're really the same thing: a DNS packet can contain both questions and
answers, and there's a single bit in the header that determines whether the
packet represents a query or a response. It'll be simpler for us to represent
both types of packets using the same class.
This class can be both serialized and deserialized to/from a raw DNS packet.
|
|
The ad-hoc IPC we were doing with LookupServer was kinda gross. With this,
LookupServer is a regular IPC server. In the future, we want to add more APIs
for LookupServer to talk to its clients (such as DHCPClient telling LookupServer
about the DNS server discovered via DHCP, and DNS-SD client browsing for
services), which calls for a more expressive IPC format; this is what LibIPC is
perfect for.
While the LookupServer side is using the regular LibIPC mechanics and patterns,
the LibC side has to hand-roll LibIPC format serialization without actually
using LibIPC. We might be able to get rid of this in the future, but for now it
has to be like that. The good news is the format is not that bad at all.
|
|
|
|
|
|
|
|
|
