a small addon to SimpleResolver

[Marco P. <mp...@gm...>]

>
>> hi, what do you think about adding those two new method to 
>> SimpleResolver, in order to perform zone transfers using the resolver 
>> parameters?  
>>  
>> public ZoneTransferIn 
>> newAXFR(Name zone) { 
>> ZoneTransferIn xfrin= ZoneTransferIn.newAXFR(zone, address, tsig); 
>> xfrin.setTimeout((int)(getTimeout() / 1000)); 
>> xfrin.setLocalAddress(this.localAddress); 
>> return xfrin; 
>> } 
>>  
>> public ZoneTransferIn 
>> newIXFR(Name zone, long serial, boolean fallback) 
>> { 
>> ZoneTransferIn xfrin=ZoneTransferIn.newIXFR(zone, serial, fallback, 
>> address, tsig); 
>> xfrin.setTimeout((int)(getTimeout() / 1000)); 
>> xfrin.setLocalAddress(this.localAddress); 
>> return xfrin; 
>> } 
>>  
>> this would be nice especially because SimpleResolver currently has no 
>> getters for its parameters (why?) and they would have to be stored 
>> externally to instantiate a ZoneTransferIn. 
>>  
>> I don't know if it would be opportune to also add two methods like 
>> those to ExtendedResolver too, after all a simple iteration across 
>> its SimpleResolvers could be enough 
>>  
>> cheers
>
>
> Please don't use the horrible sourceforge forums for questions like 
> this; use the mailing list.

done :)

>  
> AXFR and IXFR are different enough from normal DNS queries that it 
> doesn't make sense to expose them through the Resolver interface. AXFR 
> originally was only possibly using a SimpleResolver, but when the 
> ZoneTransferIn class was added, that functionality was deprecated 
> (although it's still there), and IXFR was never added. 
>  
> The only reason why there's no getters for most of the SimpleResolver 
> fields is because there's never been any need for them. Storing 
> configuration things in a SimpleResolver so they don't need to be 
> stored anywhere else and can be used by a different module isn't too 
> convincing.
An example: if you need to implement some sort of dnsserver you would 
have to load, for each zone, a nameservers list storing it somewhere for 
later use (notify of changes to other ns, checks, updates and zone 
transfers).
Which is the (almost) perfect solution? An ExtendedResolver, but this 
way we cannot perform a zone transfer from one of its SimpleResolvers, 
we need to maintain an external replica of the original array of 
nameservers (each need at least an address, a port and a local address), 
I see that a bit redundant.

so, I agree with you that there is normally no need to retrieve most of 
the SimpleResolver fields, but since it's an object that represent a 
nameserver, it should be possible to use it to perform not only simple 
queries but zone tranfers also (sure, implemented externally, but using 
its parameters). I thought that the two methods were the least invasive 
solution.