Does nsupdate reformat reverse zone files - dns

Question

When I run nsupdate to add PTR record "update add 1.1.10.10.in-addr.arpa. 86400 PTR test.example.com" , the 10.10.in-addr.arpa reverse zone prints that record as below which is what I would expect. 10.10.in-addr.arpa is a /16 zone so I have 2 octets in the host section (1.1).
$ORIGIN .
$TTL 3600 ; 1 hour
10.10.in-addr.arpa IN SOA ns1.example.com. admin.example.com. (
3 ; serial
3600 ; refresh (1 hour)
600 ; retry (10 minutes)
1209600 ; expire (2 weeks)
)
NS ns1.example.com.
$ORIGIN 10.10.in-addr.arpa.
1.1 PTR test.example.com.
However, if I run nsupdate with an additional PTR record, "update add 2.1.10.10.in-addr.arpa. 86400 PTR test2.example.com" ,then the 10.10.in-addr.arpa zone file is reformatted to a /24 zone with only 1 octet in the host section. Like this:
$ORIGIN .
$TTL 3600 ; 1 hour
10.10.in-addr.arpa IN SOA ns1.example.com. admin.example.com. (
4 ; serial
3600 ; refresh (1 hour)
600 ; retry (10 minutes)
1209600 ; expire (2 weeks)
3600 ; minimum (1 hour)
)
NS ns1.example.com.
$ORIGIN 1.10.10.in-addr.arpa.
1 PTR test.example.com.
2 PTR test2.example.com.
If I manually add the same PTR records to the zone files then the 10.10.in-addr.arpa reverse zone remains as expected with 2 octets in the host section.
So the issue is related to nsupdate and how it formats the zone files
What I would like to know is:
Is this nsupdate formatting of reverse zone files expected?
If yes, is there a way to manipulate the entry so that it maintains the format based on the the number of octets in the reverse zone as shown in the test.example.com example.