Category: Network

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.

So, when we connect project members to our networks, we enroll the interface on our side into our NMS for accounting. Every project member or end user can make use of up to 600GB of transit each month before being placed into a lower QoS bucket. Or so that it how things are supposed to work.

Our NMS applied its updates on its own daily not needing any real oversight from our team until about four days ago. An update failed to apply correctly which resulted in a complete failure of accounting and a mix up of interface names not matching with their respective subnets. So, in a nutshell, there was zero traffic accounting for about four days because none of the data that was accounted was correct.

This has been sorted out as of this morning and everyone’s monthly usage was reset.

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.