It’s been way too long since I wrote something here, but no writing does not equal no coding :)

I’ve finished of several quite large subsystems in mdnsd, including the cache and the record database (which is used for self-claimed records). This means that it’s able to receive and cache records, and able to read self-claimed records off a configuration file and add them to its database.

The configuration file is quite simple, while still being flexible enough to allow more advanced configurations, it’s however a bit different from a regular DNS configuration as the namespace in mDNS is quite flat.
This is a sample that claims a A record, AAAA record and PTR records for each address;

# A zone is only a way to avoid duplicate typing,
# one could have skipped it and simply
# used $(hostname).local. as the rrset.
zone "local." {
# A rrset holds a name and one or more resources, a
# resource type can hold multiple data sets
rrset "$(hostname)" {
alt = "$(hostname)-$(ifname)";
# This is a resource for the IN type A with the data set to $(ifaddrs4)
res A { data = "$(ifaddrs4)"; }
res AAAA { data = "$(ifaddrs6)"; }
}
}
rrset "$(ifaddrs4)" {
res PTR { data = "$(hostname).local."; }
}
rrset "$(ifaddrs6)" {
res PTR { data = "$(hostname).local."; }
}

(It’s supposed to be white spaces in there but they seem to disappear)

This also demonstrates the quite nifty variable systems that is in place. A variable will be expanded to one or more lines of data, this data is context aware, which means that putting $(ifaddr4) as a rrset name will result in a in-addr.arpa-domain while setting $(ifaddr4) as a resource data on a IN resource will encode it into a regular (binary) ip-address.
On our imaginary host foobar with the interface foo0, which has two ipv4 addresses (10.0.0.1, 10.0.0.2) and one ipv6 address (fe80::20a:5eff:fe5c:f5d7), the above configuration would result in the following;

foobar.local. IN A 10.0.0.1
foobar.local. IN A 10.0.0.2
foobar.local. IN AAAA fe80::20a:5eff:fe5c:f5d7
1.0.0.10.in-addr.arpa. IN PTR foobar.local.
2.0.0.10.in-addr.arpa. IN PTR foobar.local.
7.d.5.f.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.a.5.e.f.f.f.e.5.c.f.5.d.7.ip6.arpa. IN PTR foobar.local.

The records will automatically adjust to any changes to the interface configuration.

Any settings that should only be set on a specific interface can be wrapped inside a interface “foo0″ {} statement.
Note how one configuration line expands into several real records.

Next up will be some sort of output queue and routines to send responses (packet construction routines are already in place in the low-level stack).

Comments are closed.