Wildcard zone file entries always respond with a zero TTL

[GeldornOfDragonhill]

Describe the bug
Wildcard zone file entries always respond with a zero TTL.

To Reproduce
Simple zone file (test.local.zone) to reproduce the issue

$TTL 120
@ IN SOA ns.test.local. nobody.localhost. (2022120201 3600 1800 604800 60)
ns IN A 127.0.0.1
simple IN A 10.0.0.1
*.wc IN A 10.0.0.2

Sample program

#[tokio::main]
async fn main() {
    let mut catalog = Catalog::new();

    let config = FileConfig {
        zone_file_path: "test.local.zone".to_string()
    };

    let zone_name = LowerName::from_str("test.local.").unwrap();

    let authority = FileAuthority::try_from_config(Name::from(zone_name.clone()), ZoneType::Primary, false,None, &config).unwrap();
    catalog.upsert(zone_name, Box::new(Arc::new(authority)) as Box<dyn AuthorityObject>);

    let mut server_future = ServerFuture::new(catalog);
    let udp_socket = UdpSocket::bind(SocketAddr::from_str("0.0.0.0:1153").unwrap()).await.unwrap();
    server_future.register_socket(udp_socket);

    server_future.block_until_done().await.unwrap();
}

dig queries

# The simple entry responds as expected
> dig +noall +answer a simple.test.local @127.0.0.1 -p 1153
simple.test.local.	120	IN	A	10.0.0.1

# The wildcard entry responds with zero
> dig +noall +answer a x.wc.test.local @127.0.0.1 -p 1153
x.wc.test.local.	0	IN	A	10.0.0.2

Expected behavior
Wildcard zone file entries should have the same TTL as normal zone file entries.

Version:
Crate: [trust-dns-server]
Version: [0.22.0]

[darnuria]

Hello! Thanks for the report. I am just an occasional contributor.

I will try to dig into it tomorrow at least try to reproduce it in Test. :)

Sorry for the quick-send edited to say hello!

[darnuria]

Began to make a minimal test case.

I choose to remove server stuff. What is clear $TTL is not applied everywhere, will continue to dig in.
#1850

As a reference : https://bind9.readthedocs.io/en/v9_18_4/chapter3.html#term-0

Think I found a fix #1850

[darnuria]

@GeldornOfDragonhill We added a test case reproducing your issue and pin-pointed the problem, if it persist please feel free to reopen! :)

[GeldornOfDragonhill]

@darnuria Seems to work as expected now, thank you.

[darnuria]

Great. :)
Thanks also to @bluejekyll for the review!