Some programs can't resolve #26
Comments
|
Thanks - can you make the simplest possible test server that still fails? On 2/04/2014, at 8:50 pm, Sergio Álvarez notifications@github.com wrote:
|
|
I can try, give me a moment. |
|
I simplified the script: require 'rubygems'
require 'rubydns'
require 'rubydns/system'
UPSTREAM_JME = RubyDNS::Resolver.new([[:tcp, "172.16.22.3", 53]])
etc_hosts = RubyDNS::System::Hosts.local()
RubyDNS::run_server() do
match(//) do |transaction|
@logger.info "TEST #{transaction}"
in_local = etc_hosts.lookup(transaction.name())
if in_local
@logger.debug "Dominio en local #{in_local}"
transaction.respond!(in_local)
elsif /^(.*)\-([a-z]+)(\-([0-9a-z\.]+))?\.mov$/.match(transaction.name())
@logger.debug "Dominio nuevo enjuto1"
transaction.respond!("10.10.20.48") # enjuto1
else
logger.debug "npi, UPSTREAM_JME"
transaction.passthrough!(UPSTREAM_JME)
end
end
endI test it with TEST 1 Log: Perfect. TEST 2 Log: This command in other machine with a "normal" DNS works fine, the only difference is the DNS server used. In addition, Thank you! |
|
Can I access the DNS server that the script is using for upstream requests from New Zealand? e.g. is it public or private? Can you try using Google's DNS, 8.8.8.8? If that still has issues, it is a bug in RubyDNS and I'll sort it out. |
|
Try this server: |
|
I am just wondering if it is something to do with only providing :tcp for the upstream connection - I haven't tested this case I don't think. |
|
Okay great. I won't have time to look at this until the weekend, but thanks for reporting the issue, I will sort it out. |
|
Wait wait! I pasted the wrong log: This is the correct, no changes: Log: |
|
@xergio Did you try my very simple test case using Google's DNS? I've tried that script locally and haven't had any problems running |
|
Yes, I've test it again: Command output: Commands like |
|
What is the output of |
|
|
So, I don't have the exact same version of Ruby or Linux, but I've run my laptop (Mac OS X 10.9) through the simple google DNS server listed above for 12 hours and haven't had any issues. I'm using Ruby 1.9.3-p448 installed by RVM for this test to match the same version of Ruby. In particular, I've tried ntpdate and had no issues. That doesn't mean there isn't a problem, it just means I've failed to reproduce it so far. I'll try my linux box tonight. |
|
Ok, I think there are something wrong in the network (in my work). I'm going to try 2 thing:
But now I have to run to my work, it's too late! Thank you for your patience, you are awesome ^^ |
|
Ok, ruby 2.1.1 have the same issue: Log: I suspect the network is doing something with the packets. Usually the sysadmins enable some "security profiles" in the firewall and I think this is another case. I'm gona try this issue in my home. |
|
You should try enabling UDP for the upstream connection - currently it is rewriting all requests into TCP requests - perhaps there is something going on with the TCP requests which isn't affecting UDP requests? |
|
I've just test it in my home, no firewall, no extrange configurations, with a virtual machine installed from the scratch. Same build, debian 7, ruby 1.9.3, resolv.conf to 127.0.0.1, and your script. Can't resolve hostnames, for example So, isn't a "ntpdate issue", there are more programs failing to resolve hostnames with this simple example. All they report the same error: I don't know, I'm confused. |
|
Okay, I'll try this setup to see if I can reproduce the issue. |
|
If your script respond the IP statically with For example: root@pupu:~# cat dns-simple.rb
require 'rubygems'
require 'rubydns'
require 'rubydns/system'
GOOGLE = RubyDNS::Resolver.new([[:tcp, "8.8.8.8", 53]])
RubyDNS::run_server() do
otherwise do |transaction|
@logger.info "Upstream: #{transaction}"
#transaction.passthrough!(GOOGLE)
transaction.respond!("150.214.94.5")
end
endNow I execute It works!! Log: I don't know why this show and error, I think that is becouse Sorry, I'm not a Ruby expert, I cant make tests easily wit the library code.. :( |
|
The error occurs because you are matching all requests including IPv6 but responding with only IPv4. If you request MX record or CNAME, you'll also have issues :D |
|
Okay so I just tried this on my linux dev box which is running the latest arch linux and it worked perfectly. Are you able to send me a copy of the VM? |
|
|
I was using the latest version of event machine, I think v1.0.3? |
Of course! give me 5 minutes and I'll get you a link to download the full VM (~1GB). The "disk" is a .vmdk, from VMware, but it works in Virtualbox as well. Some setups: |
|
Ok, the links: Single disk: http://files.xrg.es/Debian%207%2064-bit.vmdk If you have problems using the disk, I've exported the VM to OVF format, links:
I cant create the VM with virtualbox too if you want, here in my work (I use Linux here). It takes only 5-10 mins of my time. All the files are in http://files.xrg.es/ , this server are in my home, so the download can be a bit slow :/ |
|
Oh, I forgot. For the VM, user: |
|
Okay, I have VMware so the vmdk should be fine, thanks, I am downloading now. |
|
I'm checking the code. I saw that resolver.rb have some debug that I dont see in the output. I added some debug extra to your example: GOOGLE = RubyDNS::Resolver.new([[:tcp, "8.8.8.8", 53]], {:logger => Logger.new($stderr)})Now this is the output for a single request: I hope this will be useful. |
|
Oh, I forced an error. Line This |
|
v0.7.1 fixes that bug, thanks for reporting it. Can you try again and see if you get an error message? The number in the square brackets is the message ID as it travels through the resolver. It seems strange to me that for the same request there are different response lengths: There is a special function in RubyDNS for logging bad messages - I don't think it is useful in this case, but can you try prepending to your script: The log file would get any bad packets - this can be very high volume so it isn't a good idea to use it in production. I also have the VM so I will take a look at it today. |
|
Okay the bug was reproduced in the VM, now I'll take a closer look. Sent from my phone.
|
|
Good news! I hope you will find the problem (or my problem). I'll test the fix in a moment, is not critical. I forced it hacking the code, so it's not a common usage of the library. |
|
Managed to reproduce the issue with relative ease: Now just need to figure out what is going wrong.. |
|
Okay, think I found the issue. On some versions of glibc(?) the resolver fails to work correctly if the result of the DNS query isn't advertised to be recursive. Simply add this to the block which includes recursive lookups: Not sure why this causes so much trouble on this particular combination, but it does. Perhaps we should include a warning if the user does |
ioquatix
added a commit
that referenced
this issue
Apr 11, 2014
|
My bad, the first commit, the fix was commented out :D |
|
Excelent! Now all is working as intended. Great job! I'll make more tests this weekend with my original script. Thank you very much for you patience. |
This was referenced Jul 10, 2014
ioquatix
added a commit
that referenced
this issue
Oct 23, 2014
This was referenced Jan 28, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi. I'm having an issue with some programs like "svn", "ntpdate", or "telnet". This programs can't resolve any host, while "ping", "host", "dig" or many other can.
My setup is:
The script i've created is very simple, I can attach it if needed. Is something like follows:
As I said, all works fine except for some programs, I cant understand why "svn" cant resolve and "ping" can.
Thank you!
The text was updated successfully, but these errors were encountered: