Menu
▾
▴
Re: ns delegation, unix dig vs dnsjava dig vs dnsjava Lookup
|
From: Stefano B. <sou...@ba...> - 2007-07-17 23:23:45
|
Brian Wellington ha scritto: > On Tue, 17 Jul 2007, Stefano Bagnara wrote: >> [...] >> If I ask MX servers for that domain to that server, no MX found. >> -------------------- >> # host -t mx zunft-oberstrass.ch. 194.246.118.118 >> Using domain server: >> Name: 194.246.118.118 >> Address: 194.246.118.118#53 >> Aliases: >> >> zunft-oberstrass.ch has no MX record >> ---------------- >> [...] >> Now, the same thing using unix dig: >> ---------------------- >> # dig @194.246.118.118 zunft-oberstrass.ch. mx >> [...] >> -------------------------- >> So, no MX record found, but it returns the 2 NS like "host" did. >> >> >> Now dnsjava dig command line: >> -------------------- >> #java -cp dnsjava-2.0.3.jar dig @194.246.118.118 zunft-oberstrass.ch. mx >> [...] >> -------------------- >> It finds the MX record!! >> >> Can anyone explain me why there is such a difference and if this is a >> result of a buggy server or where is the problem? >> >> Is this only a difference between "recursive" client (dnsjava dig) and >> "non recursive" client (unix dig)? > > Something's very strange here. Both the standard unix dig and dnsjava's > dig default to recursive queries - this can be been by the fact that > both answers have the RD (recursion desired) bit set. For some reason, > only the answer from dnsjava's dig has the RA (recursion available) bit > set. I'm seeing the same responses, but I can't think of any good reason > why that would happen. > > I tried adding the +qr option to the standard dig, and the -q option to > dnsjava's dig, which causes the queries to be printed as well as the > responses, but all that shows is that the queries are identical (except > for query id). > > Brian So this is more weird than I thought :-/ After more "digging" ;-) I think I found a bug in dnsjava dig. If you call it without the full type/class specification (MX IN at the end and some more ignored parameters) then it throws a silently caught ArrayIndexOutOfBoundException while processing arguments. This way it never sets the server and will use your default server :-). So I think this is a bug you can easily fix in your dig. Once you fix that bug or simply add "MX IN -q somethingelse" the results are different: dnsjavadig @194.246.118.118 zunft-oberstrass.ch. MX IN -q somethingelse ------------------------------------ ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41629 ;; flags: rd ; qd: 1 an: 0 au: 0 ad: 0 ;; QUESTIONS: ;; zunft-oberstrass.ch., type = MX, class = IN ;; ANSWERS: ;; AUTHORITY RECORDS: ;; ADDITIONAL RECORDS: ;; Message size: 0 bytes ; java dig 0.0 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41629 ;; flags: qr rd ; qd: 1 an: 0 au: 8 ad: 9 ;; QUESTIONS: ;; zunft-oberstrass.ch., type = MX, class = IN ;; ANSWERS: ;; AUTHORITY RECORDS: ch. 53210 IN NS CCTLD.TIX.ch. ch. 53210 IN NS CH1.DNSNODE.NET. ch. 53210 IN NS MERAPI.SWITCH.ch. ch. 53210 IN NS DOMREG.NIC.ch. ch. 53210 IN NS TULKU.NIC.AR. ch. 53210 IN NS SEC3.APNIC.NET. ch. 53210 IN NS DNS.PRINCETON.EDU. ch. 53210 IN NS RIP.PSG.COM. ;; ADDITIONAL RECORDS: CH1.DNSNODE.NET. 104859 IN A 194.146.106.10 DNS.PRINCETON.EDU. 11256 IN A 128.112.129.15 MERAPI.SWITCH.ch. 53924 IN A 130.59.211.10 MERAPI.SWITCH.ch. 97654 IN AAAA 2001:620:0:0:0:0:0:5 TULKU.NIC.AR. 2628 IN A 200.16.97.77 DOMREG.NIC.ch. 97654 IN A 130.59.1.80 DOMREG.NIC.ch. 97654 IN AAAA 2001:620:0:0:0:0:0:4 RIP.PSG.COM. 112056 IN A 147.28.0.39 SEC3.APNIC.NET. 87520 IN A 202.12.28.140 ;; Message size: 418 bytes ;; Query time: 147 ms ---------------------- Too bad this is again different from the previous unix dig result :-/ so I repeated the unix dig test and now it is different than before and is equal to dnsjava dig: # dig +qr @194.246.118.118 zunft-oberstrass.ch. mx ------------------------------------- ; <<>> DiG 9.3.2 <<>> +qr @194.246.118.118 zunft-oberstrass.ch. mx ; (1 server found) ;; global options: printcmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27790 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;zunft-oberstrass.ch. IN MX ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27790 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9 ;; QUESTION SECTION: ;zunft-oberstrass.ch. IN MX ;; AUTHORITY SECTION: ch. 53084 IN NS DNS.PRINCETON.EDU. ch. 53084 IN NS DOMREG.NIC.ch. ch. 53084 IN NS RIP.PSG.COM. ch. 53084 IN NS SEC3.APNIC.NET. ch. 53084 IN NS MERAPI.SWITCH.ch. ch. 53084 IN NS CCTLD.TIX.ch. ch. 53084 IN NS CH1.DNSNODE.NET. ch. 53084 IN NS TULKU.NIC.AR. ;; ADDITIONAL SECTION: CH1.DNSNODE.NET. 104733 IN A 194.146.106.10 DNS.PRINCETON.EDU. 11130 IN A 128.112.129.15 MERAPI.SWITCH.ch. 53798 IN A 130.59.211.10 MERAPI.SWITCH.ch. 97528 IN AAAA 2001:620::5 TULKU.NIC.AR. 2502 IN A 200.16.97.77 DOMREG.NIC.ch. 97528 IN A 130.59.1.80 DOMREG.NIC.ch. 97528 IN AAAA 2001:620::4 RIP.PSG.COM. 111930 IN A 147.28.0.39 SEC3.APNIC.NET. 87394 IN A 202.12.28.140 ;; Query time: 7 msec ;; SERVER: 194.246.118.118#53(194.246.118.118) ;; WHEN: Wed Jul 18 01:16:10 2007 ;; MSG SIZE rcvd: 418 ------------------------------- Now, back to my problem I have another domain that currently reproduce the previous behaviour (even if this time the 2 dig results are equals): dig @194.246.118.118 uudial.ch. MX IN -q somethingelse -------------------------------- ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51629 ;; flags: rd ; qd: 1 an: 0 au: 0 ad: 0 ;; QUESTIONS: ;; uudial.ch., type = MX, class = IN ;; ANSWERS: ;; AUTHORITY RECORDS: ;; ADDITIONAL RECORDS: ;; Message size: 0 bytes ; java dig 0.0 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51629 ;; flags: qr rd ; qd: 1 an: 1 au: 2 ad: 3 ;; QUESTIONS: ;; uudial.ch., type = MX, class = IN ;; ANSWERS: uudial.ch. 143 IN MX 10 mail.messaging.ch. ;; AUTHORITY RECORDS: uudial.ch. 39743 IN NS dns2.agrinet.ch. uudial.ch. 39743 IN NS dns1.agrinet.ch. ;; ADDITIONAL RECORDS: mail.messaging.ch. 2249 IN A 81.221.254.195 dns1.agrinet.ch. 3354 IN A 81.221.250.11 dns2.agrinet.ch. 3354 IN A 81.221.252.11 ;; Message size: 152 bytes ;; Query time: 146 ms -------------------------------- You say that dig defaults to recursive queries. Instead dnsjava Lookup does not support recursive resolution, right? We use dnsjava to lookup MX records for SMTP delivery: what do you think is the behavior required by DNS+SMTP specification? Currently we simply run the Lookup using the dnsservers configured by the user (or the one autodiscovered by dnsjava) and take its result as is. In this "uudial.ch." domain and 194.246.118.118 configuration the dnsjava "Lookup" does not return the MX record: is this intended? Should we do something different? Can you answer this or give me a pointer to some doc I can read about? Thank you very much! Stefano |
