Category: Core

Reached out to our data center about pointing the reverse zone for our main /48 to our name servers and they approved it. As of today, we are in control of the reverse zone meaning that we can now set records for our project members and end users.

We have also changed the way we set records for our members and users:

• For all members, when you are given access to a subnet from our project, your subnet will receive a PTR record on the ::0 address in the format <subnet-id>.<member-nickname>.<city>.<state/province>.<country>.<router>.furrix.zone. For example: ‘sub40-64.foxxo.jacksv.fl.us.ikus.furrix.zone’ would show that you have access to the subnet ‘2604:4300:f03:40::/64’ and you are based out Jacksonville, Florida.
• For our members who are sharing their access with another member, the suffix for PTR records will always be <device>.<shared-to-nickname>.<shared-from-nickname>.<city>.<state/province>.<country>.<router>.furrix.zone. For example: ‘slate.smol-dwagon.ty-dwagon.longv.tx.us.catos.furrix.zone’ would show that you are allowing another member to make use of your subnet, possibly for in network routing.
• Members are allowed to supply our network engineers with their own PTR prefixes, given that the chosen prefix makes sense and is not derogatory or otherwise. Device names, floor locations, etc are permitted. Be aware that PTR records are globally viewable.

A better example of the use of PTR records within our project is the record for ‘2604:4300:f03::’ which returns the following data: ’30f.0034.4062.kc.mo.us.furrix.zone’ – ’30f.0034.4062′ is our IPv6 prefix entered backwards which identifies our network. – ‘kc.mo.us’ stands for Kansas City, MO, US which identifies where our network core is operated out of – ‘furrix.zone’ identifies our project as the network operator.

As you can see, having support for this is a massive help to our volunteers when needing to check who is responsible for traffic on our network or for when project members or end users have a protocol or software stack that requires a record is set in order to function properly.

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.

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.