We have been working with the LIR on setting up PTR for our ‘2602:f992:f3::/48’ network and this feature is now working correctly. Lookups will be answered by our name servers, meaning our default and member set records will now be returned. If you have a service on your subnet or a machine that needs reverse DNS name set, reach out to our support desk and let them know.
Category: Core
Information about how the board is doing, changes they bring to the table and things that have been successfully actioned by the board.
We poked the LIR a while back about our leased network range, 2602:f992:f3::/48, about getting the reverse DNS support added in and we were met with some technical issues the prevent them from delegating the zone to us.
Since then, our team has spent some time working on getting an understanding how to create and manage the reverse zone within our name servers. As of this evenin’, you can query our name servers directly to get the PTR record information for this zone from us. As configured, it probably is of little use to anyone, but the information is there and does resolve.
You can test this yourself by doing “nslookup -q=ptr 2602:f992:f3::1 multi.dns.marbledfennec.net” and you should get the result “1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.f.0.0.2.9.9.f.2.0.6.2.ip6.arpa name = icmp6.catos.furrix.zone.” back from our servers.
Our secondary server may return SERVFAIL for next 10-15 minutes as our zone updates need to transfer.
Our secondary server has transferred the zone in and is responding now.
I apologize for the off and on interruptions in name server services today. I have been working away at figuring out why DoH has not be working right and why portions of dns2.marbledfennec.net have not been working right.
Turns out that some of my tooling/scripts which I use to make configuring things easier also allow me to forget to go back and edit those config files once they are in place. For dns2, this meant that the config called for IP addresses that were not present on that system, meaning the name server couldn’t bind port 443, 5353 or 9001. Due to me working on the servers in tandem usually, I did not catch the error for about a week of trying to figure out what was going on. It finally stuck out to me when I did a netstat and saw missing entries. This has been fixed and dns2 should be full service now.
The other issue that was at hand was that our DoH, or DNS over HTTPS, setup was not done correctly and the certs were invalid for these servers. The certs have been updated and also include support for “multi.dns.marbledfennec.net” for allowing clients to hop between servers to spread the load a little bit. DoH appears to be working properly now.
We won’t be doing away with the dns or dns2 names because they are used for telling which server is which, but we do prefer that our end users start using “multi.dns.marbledfennec.net” in their networks to help make use of both of our name servers.