Regarding the issue I wrote about, I don't think that it is specific to=20
jnamed.
Moving the mentioned condition two lines down, so that it will follow the=
List records =3D xfrin.run();
line, does solve the problem. But this may not be the optimal solution.
This bug was introduced by the bugfix of the issue [ 1565317 ]=20
Zone.fromXFR Bug.
Before that fix the Zone.fromXFR verified the query type, which is=20
obviously already availabe before the query runs. After that fix was=20
applied the query result became the verified value. This new=20
verification fails, because the result is not availabe at that point.=20
By moving the verification, as I suggested above, the transfer is first=20
run and only then queried about the result type. So it will not fail.
I think the analysis of the issue 1565317 was wrong, but please note=20
that I have zero experience in this area. It says that it should be=20
possible to create a zone from an IXFR query if the result was finally=20
an AXFR type result for whatever reason. This seems to be right, but the =
proposed fix doesn't consider that the fromXFR method will itself run=20
the query. In other words it must receive a ZoneTransferIn object which=20
is not yet run. I guess it is not possible to know beforehand that a=20
remote server will return an AXFR type response on an IXFR request.=20
Therefore it is incorrect to pass a ZoneTransferIn object with an IXFR=20
query. This is exactly what the original code verified, so the code=20
change should be reverted. To propose a correct solution to the issue=20
1565317, undestanding the actual use case were necessary. Among others=20
it may be the introduction of a new function (and constructor) which=20
receives an already run ZoneTransferIn object.
Brian Wellington =EDrta:
> On Tue, 13 Nov 2007, Hontvari Jozsef wrote:
>
>> I am trying to configure a slave jnamed server. I can do an AXFR reque=
st
>> using DNSJAVA dig to the master server which is also a jnamed instance=
=2E
>> The slave jnamed instance cannot start.
>>
>> This condition throws the exception in Zone.fromXFR
>>
>> if (!xfrin.isAXFR())
>> throw new IllegalArgumentException("zones can only be " +
>> "created from AXFRs");
>>
>> As I understand the javadoc of isAXFR() it is related to the answer
>> message. However following the short code with and without debugger an=
d
>> I cannot see anywhere that a message was sent at all at this point.
>>
>> Btw. I have been successfully using jnamed as a locale dnsbl server fo=
r
>> a year. Now I plan to setup a master slave configuration for our
>> *unused* domains. I know you don't recommend it for production uses, a=
nd
>> this is not really production. DNS servers are required for the
>> registration of the domains, and I don't want to install two bind
>> instances. It would open a new attack vector for a small benefit.
>
> Sorry, but the documentation clearly states:
>
> jnamed should not be used for production, and should probably
> not be used for testing. If the above documentation is not=20
> enough,
> please do not ask for more, because it really should not be use=
d.
>
> Brian
>
|
