Menu
▾
▴
dnsjava-users
|
From: Deven P. <dev...@gm...> - 2012-01-04 16:40:19
|
Hello,
I am attempting to use dnsjava to perform a zone transfer from
UltraDNS. I have verified that the zone transfers are allowed and
working from Ultra by using:
dig @<Ultra IP> mydomain.com. AXFR
I get good results from the dig command, but when I try to use the
dnsjava library, I get the following:
java.io.EOFException
at org.xbill.DNS.TCPClient._recv(Unknown Source)
at org.xbill.DNS.TCPClient.recv(Unknown Source)
at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source)
at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source)
at org.xbill.DNS.ZoneTransferIn.run(Unknown Source)
at com.zanclus.dns.InboundWorker.run(InboundWorker.java:432)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
As best I can tell, the zone transfer connection is getting closed from
Ultra's side before the byte count has been fulfilled. The data is
complete, but I cannot access it because the Exception does not allow it
to be stored and returned in the ZoneTransferIn object. Any suggestions
on how to work around Ultra's broken protocol?
Thanks,
Deven
|
|
From: Brian W. <bwe...@xb...> - 2012-01-04 19:11:00
|
On Jan 4, 2012, at 8:41 AM, Deven Phillips wrote: > Hello, > > I am attempting to use dnsjava to perform a zone transfer from > UltraDNS. I have verified that the zone transfers are allowed and > working from Ultra by using: > > dig @<Ultra IP> mydomain.com. AXFR > > I get good results from the dig command, but when I try to use the > dnsjava library, I get the following: > > java.io.EOFException > at org.xbill.DNS.TCPClient._recv(Unknown Source) > at org.xbill.DNS.TCPClient.recv(Unknown Source) > at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) > at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) > at org.xbill.DNS.ZoneTransferIn.run(Unknown Source) > at com.zanclus.dns.InboundWorker.run(InboundWorker.java:432) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:636) > > As best I can tell, the zone transfer connection is getting closed from > Ultra's side before the byte count has been fulfilled. The data is > complete, but I cannot access it because the Exception does not allow it > to be stored and returned in the ZoneTransferIn object. Any suggestions > on how to work around Ultra's broken protocol? If the problem was that not all the bytes were delivered, then the dig command would also fail, since dig also attempts to read full DNS messages before parsing them. So would any other authoritative server attempting to act as a secondary, so I'm dubious that that's the problem you're seeing. You could try using the callback-based interface to AXFR in dnsjava 2.1.3 and see if you receive the entire contents before an Exception is raised; if that still doesn't work, I'm not sure what to tell you. If UltraDNS's servers aren't obeying the protocol, I don't see how any AXFR client would work, as dnsjava isn't doing anything all that different. Brian |
|
From: Deven P. <dev...@gm...> - 2012-01-04 22:21:06
Attachments:
smime.p7s
|
Well, the same code is working flawlessly against BIND servers, unbound servers, and MSDNS servers. So it definitely appears to be something specific to UltraDNS and their XFR implementation. If I were to send you a pcap, do you think you could see if there is something I am missing? Thanks, Deven On 01/04/2012 02:10 PM, Brian Wellington wrote: > On Jan 4, 2012, at 8:41 AM, Deven Phillips wrote: > >> Hello, >> >> I am attempting to use dnsjava to perform a zone transfer from >> UltraDNS. I have verified that the zone transfers are allowed and >> working from Ultra by using: >> >> dig @<Ultra IP> mydomain.com. AXFR >> >> I get good results from the dig command, but when I try to use the >> dnsjava library, I get the following: >> >> java.io.EOFException >> at org.xbill.DNS.TCPClient._recv(Unknown Source) >> at org.xbill.DNS.TCPClient.recv(Unknown Source) >> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) >> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) >> at org.xbill.DNS.ZoneTransferIn.run(Unknown Source) >> at com.zanclus.dns.InboundWorker.run(InboundWorker.java:432) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >> at java.lang.Thread.run(Thread.java:636) >> >> As best I can tell, the zone transfer connection is getting closed from >> Ultra's side before the byte count has been fulfilled. The data is >> complete, but I cannot access it because the Exception does not allow it >> to be stored and returned in the ZoneTransferIn object. Any suggestions >> on how to work around Ultra's broken protocol? > If the problem was that not all the bytes were delivered, then the dig command would also fail, since dig also attempts to read full DNS messages before parsing them. So would any other authoritative server attempting to act as a secondary, so I'm dubious that that's the problem you're seeing. > > You could try using the callback-based interface to AXFR in dnsjava 2.1.3 and see if you receive the entire contents before an Exception is raised; if that still doesn't work, I'm not sure what to tell you. If UltraDNS's servers aren't obeying the protocol, I don't see how any AXFR client would work, as dnsjava isn't doing anything all that different. > > Brian |
|
From: Brian W. <bwe...@xb...> - 2012-01-04 22:31:45
|
On Jan 4, 2012, at 2:20 PM, Deven Phillips wrote: > Well, the same code is working flawlessly against BIND servers, unbound servers, and MSDNS servers. So it definitely appears to be something specific to UltraDNS and their XFR implementation. If I were to send you a pcap, do you think you could see if there is something I am missing? I can definitely believe there's something wrong with UltraDNS's servers. A pcap would probably help, but if you could provide a specific zone and IP address which are exhibiting the problem, that would be even better. Brian > Thanks, > > Deven > > On 01/04/2012 02:10 PM, Brian Wellington wrote: >> On Jan 4, 2012, at 8:41 AM, Deven Phillips wrote: >> >>> Hello, >>> >>> I am attempting to use dnsjava to perform a zone transfer from >>> UltraDNS. I have verified that the zone transfers are allowed and >>> working from Ultra by using: >>> >>> dig @<Ultra IP> mydomain.com. AXFR >>> >>> I get good results from the dig command, but when I try to use the >>> dnsjava library, I get the following: >>> >>> java.io.EOFException >>> at org.xbill.DNS.TCPClient._recv(Unknown Source) >>> at org.xbill.DNS.TCPClient.recv(Unknown Source) >>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) >>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) >>> at org.xbill.DNS.ZoneTransferIn.run(Unknown Source) >>> at com.zanclus.dns.InboundWorker.run(InboundWorker.java:432) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>> at java.lang.Thread.run(Thread.java:636) >>> >>> As best I can tell, the zone transfer connection is getting closed from >>> Ultra's side before the byte count has been fulfilled. The data is >>> complete, but I cannot access it because the Exception does not allow it >>> to be stored and returned in the ZoneTransferIn object. Any suggestions >>> on how to work around Ultra's broken protocol? >> If the problem was that not all the bytes were delivered, then the dig command would also fail, since dig also attempts to read full DNS messages before parsing them. So would any other authoritative server attempting to act as a secondary, so I'm dubious that that's the problem you're seeing. >> >> You could try using the callback-based interface to AXFR in dnsjava 2.1.3 and see if you receive the entire contents before an Exception is raised; if that still doesn't work, I'm not sure what to tell you. If UltraDNS's servers aren't obeying the protocol, I don't see how any AXFR client would work, as dnsjava isn't doing anything all that different. >> >> Brian > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox_______________________________________________ > dnsjava-users mailing list > dns...@li... > https://lists.sourceforge.net/lists/listinfo/dnsjava-users |
|
From: Deven P. <dev...@gm...> - 2012-01-04 22:31:58
Attachments:
smime.p7s
ultradns.pcap
|
Brian,
Unfortunately, the zone I am testing against belongs to a client
and I cannot give you access to perform the XFR on that zone. The best I
can do is the pcap. I have attached it here.
Deven
On 01/04/2012 05:25 PM, Brian Wellington wrote:
> On Jan 4, 2012, at 2:20 PM, Deven Phillips wrote:
>
>> Well, the same code is working flawlessly against BIND servers, unbound servers, and MSDNS servers. So it definitely appears to be something specific to UltraDNS and their XFR implementation. If I were to send you a pcap, do you think you could see if there is something I am missing?
> I can definitely believe there's something wrong with UltraDNS's servers. A pcap would probably help, but if you could provide a specific zone and IP address which are exhibiting the problem, that would be even better.
>
> Brian
>
>> Thanks,
>>
>> Deven
>>
>> On 01/04/2012 02:10 PM, Brian Wellington wrote:
>>> On Jan 4, 2012, at 8:41 AM, Deven Phillips wrote:
>>>
>>>> Hello,
>>>>
>>>> I am attempting to use dnsjava to perform a zone transfer from
>>>> UltraDNS. I have verified that the zone transfers are allowed and
>>>> working from Ultra by using:
>>>>
>>>> dig @<Ultra IP> mydomain.com. AXFR
>>>>
>>>> I get good results from the dig command, but when I try to use the
>>>> dnsjava library, I get the following:
>>>>
>>>> java.io.EOFException
>>>> at org.xbill.DNS.TCPClient._recv(Unknown Source)
>>>> at org.xbill.DNS.TCPClient.recv(Unknown Source)
>>>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source)
>>>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source)
>>>> at org.xbill.DNS.ZoneTransferIn.run(Unknown Source)
>>>> at com.zanclus.dns.InboundWorker.run(InboundWorker.java:432)
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>>> at java.lang.Thread.run(Thread.java:636)
>>>>
>>>> As best I can tell, the zone transfer connection is getting closed from
>>>> Ultra's side before the byte count has been fulfilled. The data is
>>>> complete, but I cannot access it because the Exception does not allow it
>>>> to be stored and returned in the ZoneTransferIn object. Any suggestions
>>>> on how to work around Ultra's broken protocol?
>>> If the problem was that not all the bytes were delivered, then the dig command would also fail, since dig also attempts to read full DNS messages before parsing them. So would any other authoritative server attempting to act as a secondary, so I'm dubious that that's the problem you're seeing.
>>>
>>> You could try using the callback-based interface to AXFR in dnsjava 2.1.3 and see if you receive the entire contents before an Exception is raised; if that still doesn't work, I'm not sure what to tell you. If UltraDNS's servers aren't obeying the protocol, I don't see how any AXFR client would work, as dnsjava isn't doing anything all that different.
>>>
>>> Brian
>>
>> ------------------------------------------------------------------------------
>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>> infrastructure or vast IT resources to deliver seamless, secure access to
>> virtual desktops. With this all-in-one solution, easily deploy virtual
>> desktops for less than the cost of PCs and save 60% on VDI infrastructure
>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox_______________________________________________
>> dnsjava-users mailing list
>> dns...@li...
>> https://lists.sourceforge.net/lists/listinfo/dnsjava-users
|
|
From: Brian W. <bwe...@xb...> - 2012-01-05 05:55:46
|
On Jan 4, 2012, at 2:31 PM, Deven Phillips wrote: > Brian, > > Unfortunately, the zone I am testing against belongs to a client and I cannot give you access to perform the XFR on that zone. The best I can do is the pcap. I have attached it here. Hmm. I just wrote some code that imports the data from the pcap file, converts it into a list of DNS messages, and uses that list of messages instead of contacting the authoritative server. The AXFR completed with no errors. Looking at the pcap, there appear to be 3 zone transfer attempts. First, an IXFR. Second, an AXFR that is immediately rejected. Third, another AXFR. I was using the responses from the third AXFR attempt. Is that correct? Brian > On 01/04/2012 05:25 PM, Brian Wellington wrote: >> On Jan 4, 2012, at 2:20 PM, Deven Phillips wrote: >> >>> Well, the same code is working flawlessly against BIND servers, unbound servers, and MSDNS servers. So it definitely appears to be something specific to UltraDNS and their XFR implementation. If I were to send you a pcap, do you think you could see if there is something I am missing? >> I can definitely believe there's something wrong with UltraDNS's servers. A pcap would probably help, but if you could provide a specific zone and IP address which are exhibiting the problem, that would be even better. >> >> Brian >> >>> Thanks, >>> >>> Deven >>> >>> On 01/04/2012 02:10 PM, Brian Wellington wrote: >>>> On Jan 4, 2012, at 8:41 AM, Deven Phillips wrote: >>>> >>>>> Hello, >>>>> >>>>> I am attempting to use dnsjava to perform a zone transfer from >>>>> UltraDNS. I have verified that the zone transfers are allowed and >>>>> working from Ultra by using: >>>>> >>>>> dig @<Ultra IP> mydomain.com. AXFR >>>>> >>>>> I get good results from the dig command, but when I try to use the >>>>> dnsjava library, I get the following: >>>>> >>>>> java.io.EOFException >>>>> at org.xbill.DNS.TCPClient._recv(Unknown Source) >>>>> at org.xbill.DNS.TCPClient.recv(Unknown Source) >>>>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) >>>>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) >>>>> at org.xbill.DNS.ZoneTransferIn.run(Unknown Source) >>>>> at com.zanclus.dns.InboundWorker.run(InboundWorker.java:432) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>>>> at java.lang.Thread.run(Thread.java:636) >>>>> >>>>> As best I can tell, the zone transfer connection is getting closed from >>>>> Ultra's side before the byte count has been fulfilled. The data is >>>>> complete, but I cannot access it because the Exception does not allow it >>>>> to be stored and returned in the ZoneTransferIn object. Any suggestions >>>>> on how to work around Ultra's broken protocol? >>>> If the problem was that not all the bytes were delivered, then the dig command would also fail, since dig also attempts to read full DNS messages before parsing them. So would any other authoritative server attempting to act as a secondary, so I'm dubious that that's the problem you're seeing. >>>> >>>> You could try using the callback-based interface to AXFR in dnsjava 2.1.3 and see if you receive the entire contents before an Exception is raised; if that still doesn't work, I'm not sure what to tell you. If UltraDNS's servers aren't obeying the protocol, I don't see how any AXFR client would work, as dnsjava isn't doing anything all that different. >>>> >>>> Brian >>> >>> ------------------------------------------------------------------------------ >>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >>> infrastructure or vast IT resources to deliver seamless, secure access to >>> virtual desktops. With this all-in-one solution, easily deploy virtual >>> desktops for less than the cost of PCs and save 60% on VDI infrastructure >>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox_______________________________________________ >>> dnsjava-users mailing list >>> dns...@li... >>> https://lists.sourceforge.net/lists/listinfo/dnsjava-users > > <ultradns.pcap> |
|
From: Deven P. <dev...@gm...> - 2012-01-05 23:32:50
Attachments:
smime.p7s
|
The first is the IXFR from dnsjava, which as you said is rejected. The second is the AXFR fallback from dnsjava and that too fails. The final one is the AXFR initiated from "dig" and it works fine... The strange part is that I do zone transfers from BIND and MSDNS and others every day with the same code. What's different about Ultra? Thanks for looking into this!! Deven On 01/05/2012 12:55 AM, Brian Wellington wrote: > On Jan 4, 2012, at 2:31 PM, Deven Phillips wrote: > >> Brian, >> >> Unfortunately, the zone I am testing against belongs to a client and I cannot give you access to perform the XFR on that zone. The best I can do is the pcap. I have attached it here. > Hmm. I just wrote some code that imports the data from the pcap file, converts it into a list of DNS messages, and uses that list of messages instead of contacting the authoritative server. The AXFR completed with no errors. > > Looking at the pcap, there appear to be 3 zone transfer attempts. First, an IXFR. Second, an AXFR that is immediately rejected. Third, another AXFR. I was using the responses from the third AXFR attempt. Is that correct? > > Brian > > >> On 01/04/2012 05:25 PM, Brian Wellington wrote: >>> On Jan 4, 2012, at 2:20 PM, Deven Phillips wrote: >>> >>>> Well, the same code is working flawlessly against BIND servers, unbound servers, and MSDNS servers. So it definitely appears to be something specific to UltraDNS and their XFR implementation. If I were to send you a pcap, do you think you could see if there is something I am missing? >>> I can definitely believe there's something wrong with UltraDNS's servers. A pcap would probably help, but if you could provide a specific zone and IP address which are exhibiting the problem, that would be even better. >>> >>> Brian >>> >>>> Thanks, >>>> >>>> Deven >>>> >>>> On 01/04/2012 02:10 PM, Brian Wellington wrote: >>>>> On Jan 4, 2012, at 8:41 AM, Deven Phillips wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I am attempting to use dnsjava to perform a zone transfer from >>>>>> UltraDNS. I have verified that the zone transfers are allowed and >>>>>> working from Ultra by using: >>>>>> >>>>>> dig @<Ultra IP> mydomain.com. AXFR >>>>>> >>>>>> I get good results from the dig command, but when I try to use the >>>>>> dnsjava library, I get the following: >>>>>> >>>>>> java.io.EOFException >>>>>> at org.xbill.DNS.TCPClient._recv(Unknown Source) >>>>>> at org.xbill.DNS.TCPClient.recv(Unknown Source) >>>>>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) >>>>>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) >>>>>> at org.xbill.DNS.ZoneTransferIn.run(Unknown Source) >>>>>> at com.zanclus.dns.InboundWorker.run(InboundWorker.java:432) >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>>>>> at java.lang.Thread.run(Thread.java:636) >>>>>> >>>>>> As best I can tell, the zone transfer connection is getting closed from >>>>>> Ultra's side before the byte count has been fulfilled. The data is >>>>>> complete, but I cannot access it because the Exception does not allow it >>>>>> to be stored and returned in the ZoneTransferIn object. Any suggestions >>>>>> on how to work around Ultra's broken protocol? >>>>> If the problem was that not all the bytes were delivered, then the dig command would also fail, since dig also attempts to read full DNS messages before parsing them. So would any other authoritative server attempting to act as a secondary, so I'm dubious that that's the problem you're seeing. >>>>> >>>>> You could try using the callback-based interface to AXFR in dnsjava 2.1.3 and see if you receive the entire contents before an Exception is raised; if that still doesn't work, I'm not sure what to tell you. If UltraDNS's servers aren't obeying the protocol, I don't see how any AXFR client would work, as dnsjava isn't doing anything all that different. >>>>> >>>>> Brian >>>> ------------------------------------------------------------------------------ >>>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >>>> infrastructure or vast IT resources to deliver seamless, secure access to >>>> virtual desktops. With this all-in-one solution, easily deploy virtual >>>> desktops for less than the cost of PCs and save 60% on VDI infrastructure >>>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox_______________________________________________ >>>> dnsjava-users mailing list >>>> dns...@li... >>>> https://lists.sourceforge.net/lists/listinfo/dnsjava-users >> <ultradns.pcap> |
|
From: Brian W. <bwe...@xb...> - 2012-01-05 23:41:26
|
On Jan 5, 2012, at 3:32 PM, Deven Phillips wrote: > The first is the IXFR from dnsjava, which as you said is rejected. The second is the AXFR fallback from dnsjava and that too fails. The final one is the AXFR initiated from "dig" and it works fine... The strange part is that I do zone transfers from BIND and MSDNS and others every day with the same code. What's different about Ultra? The IXFR isn't being rejected by the authoritative server. I'm not sure what the client's doing with it, though. The AXFR is being rejected. My guess is that what's happening is that the UltraDNS server is closing the connection after the IXFR completes, rather than leaving the connection open for more requests (as it should do). This should be easy to test, by attempting to do an AXFR in the first place, rather than attempting to do an IXFR and falling back to AXFR. I (obviously) can't test this theory without being able to send queries to the UltraDNS server. If this is the case, it should be possible to change the code to establish a new connection when falling back to AXFR. > Thanks for looking into this!! Let's hope there's a solution… Brian > On 01/05/2012 12:55 AM, Brian Wellington wrote: >> On Jan 4, 2012, at 2:31 PM, Deven Phillips wrote: >> >>> Brian, >>> >>> Unfortunately, the zone I am testing against belongs to a client and I cannot give you access to perform the XFR on that zone. The best I can do is the pcap. I have attached it here. >> Hmm. I just wrote some code that imports the data from the pcap file, converts it into a list of DNS messages, and uses that list of messages instead of contacting the authoritative server. The AXFR completed with no errors. >> >> Looking at the pcap, there appear to be 3 zone transfer attempts. First, an IXFR. Second, an AXFR that is immediately rejected. Third, another AXFR. I was using the responses from the third AXFR attempt. Is that correct? >> >> Brian >> >> >>> On 01/04/2012 05:25 PM, Brian Wellington wrote: >>>> On Jan 4, 2012, at 2:20 PM, Deven Phillips wrote: >>>> >>>>> Well, the same code is working flawlessly against BIND servers, unbound servers, and MSDNS servers. So it definitely appears to be something specific to UltraDNS and their XFR implementation. If I were to send you a pcap, do you think you could see if there is something I am missing? >>>> I can definitely believe there's something wrong with UltraDNS's servers. A pcap would probably help, but if you could provide a specific zone and IP address which are exhibiting the problem, that would be even better. >>>> >>>> Brian >>>> >>>>> Thanks, >>>>> >>>>> Deven >>>>> >>>>> On 01/04/2012 02:10 PM, Brian Wellington wrote: >>>>>> On Jan 4, 2012, at 8:41 AM, Deven Phillips wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am attempting to use dnsjava to perform a zone transfer from >>>>>>> UltraDNS. I have verified that the zone transfers are allowed and >>>>>>> working from Ultra by using: >>>>>>> >>>>>>> dig @<Ultra IP> mydomain.com. AXFR >>>>>>> >>>>>>> I get good results from the dig command, but when I try to use the >>>>>>> dnsjava library, I get the following: >>>>>>> >>>>>>> java.io.EOFException >>>>>>> at org.xbill.DNS.TCPClient._recv(Unknown Source) >>>>>>> at org.xbill.DNS.TCPClient.recv(Unknown Source) >>>>>>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) >>>>>>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source) >>>>>>> at org.xbill.DNS.ZoneTransferIn.run(Unknown Source) >>>>>>> at com.zanclus.dns.InboundWorker.run(InboundWorker.java:432) >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>>>>>> at java.lang.Thread.run(Thread.java:636) >>>>>>> >>>>>>> As best I can tell, the zone transfer connection is getting closed from >>>>>>> Ultra's side before the byte count has been fulfilled. The data is >>>>>>> complete, but I cannot access it because the Exception does not allow it >>>>>>> to be stored and returned in the ZoneTransferIn object. Any suggestions >>>>>>> on how to work around Ultra's broken protocol? >>>>>> If the problem was that not all the bytes were delivered, then the dig command would also fail, since dig also attempts to read full DNS messages before parsing them. So would any other authoritative server attempting to act as a secondary, so I'm dubious that that's the problem you're seeing. >>>>>> >>>>>> You could try using the callback-based interface to AXFR in dnsjava 2.1.3 and see if you receive the entire contents before an Exception is raised; if that still doesn't work, I'm not sure what to tell you. If UltraDNS's servers aren't obeying the protocol, I don't see how any AXFR client would work, as dnsjava isn't doing anything all that different. >>>>>> >>>>>> Brian >>>>> ------------------------------------------------------------------------------ >>>>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >>>>> infrastructure or vast IT resources to deliver seamless, secure access to >>>>> virtual desktops. With this all-in-one solution, easily deploy virtual >>>>> desktops for less than the cost of PCs and save 60% on VDI infrastructure >>>>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox_______________________________________________ >>>>> dnsjava-users mailing list >>>>> dns...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/dnsjava-users >>> <ultradns.pcap> > > |
|
From: Deven P. <dev...@gm...> - 2012-01-23 22:49:30
|
Brian,
Sorry, I was away on vacation for a while. I will try to see if
running the AXFR first will resolve the issue for Ultra and let you know
the result.
Deven
On 01/05/2012 06:41 PM, Brian Wellington wrote:
> On Jan 5, 2012, at 3:32 PM, Deven Phillips wrote:
>
>> The first is the IXFR from dnsjava, which as you said is rejected. The second is the AXFR fallback from dnsjava and that too fails. The final one is the AXFR initiated from "dig" and it works fine... The strange part is that I do zone transfers from BIND and MSDNS and others every day with the same code. What's different about Ultra?
> The IXFR isn't being rejected by the authoritative server. I'm not sure what the client's doing with it, though. The AXFR is being rejected.
>
> My guess is that what's happening is that the UltraDNS server is closing the connection after the IXFR completes, rather than leaving the connection open for more requests (as it should do). This should be easy to test, by attempting to do an AXFR in the first place, rather than attempting to do an IXFR and falling back to AXFR. I (obviously) can't test this theory without being able to send queries to the UltraDNS server. If this is the case, it should be possible to change the code to establish a new connection when falling back to AXFR.
>
>> Thanks for looking into this!!
> Let's hope there's a solution…
>
> Brian
>
>
>> On 01/05/2012 12:55 AM, Brian Wellington wrote:
>>> On Jan 4, 2012, at 2:31 PM, Deven Phillips wrote:
>>>
>>>> Brian,
>>>>
>>>> Unfortunately, the zone I am testing against belongs to a client and I cannot give you access to perform the XFR on that zone. The best I can do is the pcap. I have attached it here.
>>> Hmm. I just wrote some code that imports the data from the pcap file, converts it into a list of DNS messages, and uses that list of messages instead of contacting the authoritative server. The AXFR completed with no errors.
>>>
>>> Looking at the pcap, there appear to be 3 zone transfer attempts. First, an IXFR. Second, an AXFR that is immediately rejected. Third, another AXFR. I was using the responses from the third AXFR attempt. Is that correct?
>>>
>>> Brian
>>>
>>>
>>>> On 01/04/2012 05:25 PM, Brian Wellington wrote:
>>>>> On Jan 4, 2012, at 2:20 PM, Deven Phillips wrote:
>>>>>
>>>>>> Well, the same code is working flawlessly against BIND servers, unbound servers, and MSDNS servers. So it definitely appears to be something specific to UltraDNS and their XFR implementation. If I were to send you a pcap, do you think you could see if there is something I am missing?
>>>>> I can definitely believe there's something wrong with UltraDNS's servers. A pcap would probably help, but if you could provide a specific zone and IP address which are exhibiting the problem, that would be even better.
>>>>>
>>>>> Brian
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Deven
>>>>>>
>>>>>> On 01/04/2012 02:10 PM, Brian Wellington wrote:
>>>>>>> On Jan 4, 2012, at 8:41 AM, Deven Phillips wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I am attempting to use dnsjava to perform a zone transfer from
>>>>>>>> UltraDNS. I have verified that the zone transfers are allowed and
>>>>>>>> working from Ultra by using:
>>>>>>>>
>>>>>>>> dig @<Ultra IP> mydomain.com. AXFR
>>>>>>>>
>>>>>>>> I get good results from the dig command, but when I try to use the
>>>>>>>> dnsjava library, I get the following:
>>>>>>>>
>>>>>>>> java.io.EOFException
>>>>>>>> at org.xbill.DNS.TCPClient._recv(Unknown Source)
>>>>>>>> at org.xbill.DNS.TCPClient.recv(Unknown Source)
>>>>>>>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source)
>>>>>>>> at org.xbill.DNS.ZoneTransferIn.doxfr(Unknown Source)
>>>>>>>> at org.xbill.DNS.ZoneTransferIn.run(Unknown Source)
>>>>>>>> at com.zanclus.dns.InboundWorker.run(InboundWorker.java:432)
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>>>>>>> at java.lang.Thread.run(Thread.java:636)
>>>>>>>>
>>>>>>>> As best I can tell, the zone transfer connection is getting closed from
>>>>>>>> Ultra's side before the byte count has been fulfilled. The data is
>>>>>>>> complete, but I cannot access it because the Exception does not allow it
>>>>>>>> to be stored and returned in the ZoneTransferIn object. Any suggestions
>>>>>>>> on how to work around Ultra's broken protocol?
>>>>>>> If the problem was that not all the bytes were delivered, then the dig command would also fail, since dig also attempts to read full DNS messages before parsing them. So would any other authoritative server attempting to act as a secondary, so I'm dubious that that's the problem you're seeing.
>>>>>>>
>>>>>>> You could try using the callback-based interface to AXFR in dnsjava 2.1.3 and see if you receive the entire contents before an Exception is raised; if that still doesn't work, I'm not sure what to tell you. If UltraDNS's servers aren't obeying the protocol, I don't see how any AXFR client would work, as dnsjava isn't doing anything all that different.
>>>>>>>
>>>>>>> Brian
>>>>>> ------------------------------------------------------------------------------
>>>>>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>>>>>> infrastructure or vast IT resources to deliver seamless, secure access to
>>>>>> virtual desktops. With this all-in-one solution, easily deploy virtual
>>>>>> desktops for less than the cost of PCs and save 60% on VDI infrastructure
>>>>>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox_______________________________________________
>>>>>> dnsjava-users mailing list
>>>>>> dns...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/dnsjava-users
>>>> <ultradns.pcap>
>>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X