From: Deven P. <dev...@gm...> - 2012-01-04 22:31:58
|
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 |