Authority can depend on client source ipnet

[dxfgg17]

I thought it could be useful to answer differently to clients depending on their source ip network.

There is no breaking change (existing functions still work the same way) but I added the two following functions in the catalog.rs file:

pub fn upsert_for_ipnet(
    &mut self,
    ipnet: IpNet,
    name: LowerName,
    authority: Box<dyn AuthorityObject>,
)

pub fn remove_for_ipnet(
    &mut self,
    ipnet: &IpNet,
    name: &LowerName,
) -> Option<Box<dyn AuthorityObject>>

Now, authorities are stored like this:

authorities: vec![(None, HashMap::new())],

There is a small performance overhead when adding an AuthorityObject because the vector has to be sorted to have at the first position the smallest IpNet and last position the biggest one (which is None, corresponding to all networks and to the current behaviour, all networks).

If this is not a wanted behavior or functionnalty feel free to delete this, I won't be offended it was just something I needed :)

[bluejekyll]

Thanks for the PR and the suggestion. I think this is a good addition, I need to spend some time reviewing this, but as a feature I think it's a good idea. BIND calls this "views" for what it's worth, and it would be good for us to think through what the config will look like for this as well.

[bluejekyll]

I left a lot of questions, I still want to think through the implications of this, but just seeking to have a conversation about some of this for now.

[bluejekyll]

A question I have here is if we should consider the EDNS client_addr as well (this isn't supported in Trust-DNS yet, but might be in the future) So I just want to think through what that would look like. It seems like we could trigger similar logic here based on that IP as well.

[dxfgg17]

Yes I'm sure this would be possibe but I really don't know anything about EDNS protocol. Is everything ready so it can be implemented now, even if not supported yet by trust dns?

[bluejekyll]

I want to think about this change here and the additional functions. It seems we could maybe fix this a little differently by maybe passing an object that has these parameters rather than creating alternative function names?

We have the request object, but I think that has a bunch of optionals that makes it unwieldy... so maybe we need a lookup object that has non-optional data in it that could be used for the authority lookup?

[dxfgg17]

I don't know what is best for the crate. My first intention was to avoid any breaking change so the pull request would have a chance to be accepted. I still believe this is a niche feature and doesn't worth changing the function signature...