Menu
▾
▴
dnsjava-users — The dnsjava mailing list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(5) |
Feb
(1) |
Mar
(7) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2003 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
(5) |
May
(5) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
|
| 2004 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(13) |
Dec
|
| 2006 |
Jan
(3) |
Feb
(3) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(6) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
(4) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(2) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2008 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(13) |
Jun
(7) |
Jul
(2) |
Aug
(2) |
Sep
(2) |
Oct
(2) |
Nov
(3) |
Dec
(1) |
| 2010 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
(2) |
Oct
|
Nov
(12) |
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
(8) |
Jun
(6) |
Jul
|
Aug
|
Sep
(11) |
Oct
(8) |
Nov
(3) |
Dec
(2) |
| 2012 |
Jan
(9) |
Feb
(3) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(3) |
Mar
(6) |
Apr
|
May
(8) |
Jun
|
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2018 |
Jan
|
Feb
(3) |
Mar
(4) |
Apr
|
May
|
Jun
(2) |
Jul
(5) |
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
(2) |
| 2019 |
Jan
(2) |
Feb
(4) |
Mar
(4) |
Apr
|
May
(8) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2020 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(6) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
(3) |
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Hontvari J. <hon...@so...> - 2007-11-13 20:06:11
|
I am trying to configure a slave jnamed server. I can do an AXFR request
using DNSJAVA dig to the master server which is also a jnamed instance.
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 and
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 for
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, and
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.
|
|
From: Brian W. <bwe...@xb...> - 2007-08-31 17:50:37
|
On Fri, 31 Aug 2007, Marco Puggelli wrote: >> AXFR and IXFR are different enough from normal DNS queries that it >> doesn't make sense to expose them through the Resolver interface. AXFR >> originally was only possibly using a SimpleResolver, but when the >> ZoneTransferIn class was added, that functionality was deprecated >> (although it's still there), and IXFR was never added. >> >> The only reason why there's no getters for most of the SimpleResolver >> fields is because there's never been any need for them. Storing >> configuration things in a SimpleResolver so they don't need to be >> stored anywhere else and can be used by a different module isn't too >> convincing. > An example: if you need to implement some sort of dnsserver you would > have to load, for each zone, a nameservers list storing it somewhere for > later use (notify of changes to other ns, checks, updates and zone > transfers). > Which is the (almost) perfect solution? An ExtendedResolver, but this > way we cannot perform a zone transfer from one of its SimpleResolvers, > we need to maintain an external replica of the original array of > nameservers (each need at least an address, a port and a local address), > I see that a bit redundant. A DNS server needs to store more information than a list of namservers for each slave zone, and the object that manages the slave zone should keep track of such things. Storing things in an ExtendedResolver just because it happens to store the same fields for a completely different purpose is bad design. > so, I agree with you that there is normally no need to retrieve most of > the SimpleResolver fields, but since it's an object that represent a > nameserver, it should be possible to use it to perform not only simple > queries but zone tranfers also (sure, implemented externally, but using > its parameters). I thought that the two methods were the least invasive > solution. SimpleResolver is not an object that represents a name server. It's an implementation of an interface which performs DNS queries, specifically an implementation that sends all queries to a single server. There's a reason why the Resolver interface and its implementations are named as they are - they're objects representing (stub) resolvers, not name servers. Brian |
|
From: Marco P. <mp...@gm...> - 2007-08-31 17:27:03
|
>
>> hi, what do you think about adding those two new method to
>> SimpleResolver, in order to perform zone transfers using the resolver
>> parameters?
>>
>> public ZoneTransferIn
>> newAXFR(Name zone) {
>> ZoneTransferIn xfrin= ZoneTransferIn.newAXFR(zone, address, tsig);
>> xfrin.setTimeout((int)(getTimeout() / 1000));
>> xfrin.setLocalAddress(this.localAddress);
>> return xfrin;
>> }
>>
>> public ZoneTransferIn
>> newIXFR(Name zone, long serial, boolean fallback)
>> {
>> ZoneTransferIn xfrin=ZoneTransferIn.newIXFR(zone, serial, fallback,
>> address, tsig);
>> xfrin.setTimeout((int)(getTimeout() / 1000));
>> xfrin.setLocalAddress(this.localAddress);
>> return xfrin;
>> }
>>
>> this would be nice especially because SimpleResolver currently has no
>> getters for its parameters (why?) and they would have to be stored
>> externally to instantiate a ZoneTransferIn.
>>
>> I don't know if it would be opportune to also add two methods like
>> those to ExtendedResolver too, after all a simple iteration across
>> its SimpleResolvers could be enough
>>
>> cheers
>
>
> Please don't use the horrible sourceforge forums for questions like
> this; use the mailing list.
done :)
>
> AXFR and IXFR are different enough from normal DNS queries that it
> doesn't make sense to expose them through the Resolver interface. AXFR
> originally was only possibly using a SimpleResolver, but when the
> ZoneTransferIn class was added, that functionality was deprecated
> (although it's still there), and IXFR was never added.
>
> The only reason why there's no getters for most of the SimpleResolver
> fields is because there's never been any need for them. Storing
> configuration things in a SimpleResolver so they don't need to be
> stored anywhere else and can be used by a different module isn't too
> convincing.
An example: if you need to implement some sort of dnsserver you would
have to load, for each zone, a nameservers list storing it somewhere for
later use (notify of changes to other ns, checks, updates and zone
transfers).
Which is the (almost) perfect solution? An ExtendedResolver, but this
way we cannot perform a zone transfer from one of its SimpleResolvers,
we need to maintain an external replica of the original array of
nameservers (each need at least an address, a port and a local address),
I see that a bit redundant.
so, I agree with you that there is normally no need to retrieve most of
the SimpleResolver fields, but since it's an object that represent a
nameserver, it should be possible to use it to perform not only simple
queries but zone tranfers also (sure, implemented externally, but using
its parameters). I thought that the two methods were the least invasive
solution.
|
|
From: Brian W. <bwe...@xb...> - 2007-07-18 09:06:44
|
On Wed, 18 Jul 2007, Stefano Bagnara wrote: > Brian Wellington ha scritto: >>> 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? >> >> I don't know what 194.246.118.118 is, but when I query it, it's not >> doing recursion. dnsjava's Lookup class is a stub resolver, so it >> should only be sending queries to servers that perform recursion. If I >> instead send the query to a server that does perform recursion, I get >> the desired MX record. > > Maybe I'm confusing iterative vs recursive terms. > > I tried googling this but I didn't find an answer: > > is a server allowed to reply non-recursively to a recursive question? Yes. There is no such thing as a recursive question - there is a question where recursion is desired. There's no way to require recursion. > what does a client should (have to) do when a server replies without the > "ra" flag? There's nothing a client can do. A client which is incapable of performing recursion itself should not be configured to point at servers which do not perform recursion. Anything else is a configuration error on the client. > Should we keep resolving the data to the NS server received? > > If so, can you suggest an approach to the problem using dnsjava? Continuing the resolution would be the correct thing to do if you were writing a name server. From the context of a client wishing to lookup MX records, I believe the right thing to do is simply fail. > Would this behavior be defined "iterative" resolution or iterative vs > recursive both describe only server side resolution? I'm not really sure how iterative resolution would differ from recursive resolution. There are basically two kinds of resolvers - full resolvers and stub resolvers. A full resolver would use the complete resolution algorithm, talking to authoritative name servers and following NS records. A stub resolver would ask a full resolver to do the recursion for it. Pretty much every client application uses a stub resolver. It's possible to have a full resolver that's not part of a caching name server, but I don't know of any. > What do other other clients do wrt non recursive servers? They would generally fail to perform the desired lookups. Brian |
|
From: Stefano B. <sou...@ba...> - 2007-07-18 07:52:03
|
Brian Wellington ha scritto: >> 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? > > I don't know what 194.246.118.118 is, but when I query it, it's not > doing recursion. dnsjava's Lookup class is a stub resolver, so it > should only be sending queries to servers that perform recursion. If I > instead send the query to a server that does perform recursion, I get > the desired MX record. Maybe I'm confusing iterative vs recursive terms. I tried googling this but I didn't find an answer: is a server allowed to reply non-recursively to a recursive question? what does a client should (have to) do when a server replies without the "ra" flag? Should we keep resolving the data to the NS server received? If so, can you suggest an approach to the problem using dnsjava? Would this behavior be defined "iterative" resolution or iterative vs recursive both describe only server side resolution? What do other other clients do wrt non recursive servers? Thank you again, Stefano |
|
From: Brian W. <bwe...@xb...> - 2007-07-18 00:37:56
|
On Wed, 18 Jul 2007, Stefano Bagnara wrote: >> 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). >> > 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: Good catch. Yes, that looks like a problem. > 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): > > [snip] > > You say that dig defaults to recursive queries. Instead dnsjava Lookup > does not support recursive resolution, right? The terminology you're using here is a bit confusing. The standard unix dig, dnsjava's dig program, and the dnsjava Lookup class all behave the same way - they set the recursion desired bit on queries, meaning that they are requesting that the server perform a recursive lookup. None of them performs recursive resolution themselves. > 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? I don't know what 194.246.118.118 is, but when I query it, it's not doing recursion. dnsjava's Lookup class is a stub resolver, so it should only be sending queries to servers that perform recursion. If I instead send the query to a server that does perform recursion, I get the desired MX record. Brian |
|
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 |
|
From: Brian W. <bwe...@xb...> - 2007-07-17 22:02:57
|
On Tue, 17 Jul 2007, Stefano Bagnara wrote: > Hi all, > > my limited dns knowledge don't let me to reach a conclusion about this > issue. > > > 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 > ---------------- > > if I ask any type I get 2 NS records > ---------------- > # host -a zunft-oberstrass.ch. 194.246.118.118 > Trying "zunft-oberstrass.ch" > Using domain server: > Name: 194.246.118.118 > Address: 194.246.118.118#53 > Aliases: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61311 > ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;zunft-oberstrass.ch. IN ANY > > ;; ANSWER SECTION: > zunft-oberstrass.ch. 49631 IN NS ns2.nameserver.ch. > zunft-oberstrass.ch. 49631 IN NS ns1.nameserver.ch. > > ;; AUTHORITY SECTION: > zunft-oberstrass.ch. 49631 IN NS ns2.nameserver.ch. > zunft-oberstrass.ch. 49631 IN NS ns1.nameserver.ch. > > Received 112 bytes from 194.246.118.118#53 in 11 ms > -------------------- > > If I ask the MX to one of the delegated NS I found an answer. > -------------------- > # host -t mx zunft-oberstrass.ch. ns2.nameserver.ch. > Using domain server: > Name: ns2.nameserver.ch. > Address: 217.71.81.4#53 > Aliases: > > zunft-oberstrass.ch mail is handled by 10 mail.zunft-oberstrass.ch. > -------------------- > > > Now, the same thing using unix dig: > ---------------------- > # dig @194.246.118.118 zunft-oberstrass.ch. mx > > ; <<>> DiG 9.3.2 <<>> @194.246.118.118 zunft-oberstrass.ch. mx > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52236 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;zunft-oberstrass.ch. IN MX > > ;; AUTHORITY SECTION: > zunft-oberstrass.ch. 49470 IN NS ns2.nameserver.ch. > zunft-oberstrass.ch. 49470 IN NS ns1.nameserver.ch. > > ;; Query time: 10 msec > ;; SERVER: 194.246.118.118#53(194.246.118.118) > ;; WHEN: Tue Jul 17 11:03:38 2007 > ;; MSG SIZE rcvd: 84 > -------------------------- > 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 > ; java dig 0.0 > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31604 > ;; flags: qr rd ra ; qd: 1 an: 1 au: 2 ad: 2 > ;; QUESTIONS: > ;; zunft-oberstrass.ch., type = MX, class = IN > > ;; ANSWERS: > zunft-oberstrass.ch. 3516 IN MX 10 mail.zunft-oberstrass.ch. > > ;; AUTHORITY RECORDS: > zunft-oberstrass.ch. 86316 IN NS ns1.nameserver.ch. > zunft-oberstrass.ch. 86316 IN NS ns2.nameserver.ch. > > ;; ADDITIONAL RECORDS: > mail.zunft-oberstrass.ch. 3516 IN A 195.129.94.130 > mail.zunft-oberstrass.ch. 3516 IN A 195.129.94.194 > > ;; Message size: 137 bytes > ;; Query time: 138 ms > -------------------- > 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 |
|
From: Stefano B. <sou...@ba...> - 2007-07-17 21:49:43
|
Hi all, my limited dns knowledge don't let me to reach a conclusion about this issue. 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 ---------------- if I ask any type I get 2 NS records ---------------- # host -a zunft-oberstrass.ch. 194.246.118.118 Trying "zunft-oberstrass.ch" Using domain server: Name: 194.246.118.118 Address: 194.246.118.118#53 Aliases: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61311 ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;zunft-oberstrass.ch. IN ANY ;; ANSWER SECTION: zunft-oberstrass.ch. 49631 IN NS ns2.nameserver.ch. zunft-oberstrass.ch. 49631 IN NS ns1.nameserver.ch. ;; AUTHORITY SECTION: zunft-oberstrass.ch. 49631 IN NS ns2.nameserver.ch. zunft-oberstrass.ch. 49631 IN NS ns1.nameserver.ch. Received 112 bytes from 194.246.118.118#53 in 11 ms -------------------- If I ask the MX to one of the delegated NS I found an answer. -------------------- # host -t mx zunft-oberstrass.ch. ns2.nameserver.ch. Using domain server: Name: ns2.nameserver.ch. Address: 217.71.81.4#53 Aliases: zunft-oberstrass.ch mail is handled by 10 mail.zunft-oberstrass.ch. -------------------- Now, the same thing using unix dig: ---------------------- # dig @194.246.118.118 zunft-oberstrass.ch. mx ; <<>> DiG 9.3.2 <<>> @194.246.118.118 zunft-oberstrass.ch. mx ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52236 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;zunft-oberstrass.ch. IN MX ;; AUTHORITY SECTION: zunft-oberstrass.ch. 49470 IN NS ns2.nameserver.ch. zunft-oberstrass.ch. 49470 IN NS ns1.nameserver.ch. ;; Query time: 10 msec ;; SERVER: 194.246.118.118#53(194.246.118.118) ;; WHEN: Tue Jul 17 11:03:38 2007 ;; MSG SIZE rcvd: 84 -------------------------- 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 ; java dig 0.0 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31604 ;; flags: qr rd ra ; qd: 1 an: 1 au: 2 ad: 2 ;; QUESTIONS: ;; zunft-oberstrass.ch., type = MX, class = IN ;; ANSWERS: zunft-oberstrass.ch. 3516 IN MX 10 mail.zunft-oberstrass.ch. ;; AUTHORITY RECORDS: zunft-oberstrass.ch. 86316 IN NS ns1.nameserver.ch. zunft-oberstrass.ch. 86316 IN NS ns2.nameserver.ch. ;; ADDITIONAL RECORDS: mail.zunft-oberstrass.ch. 3516 IN A 195.129.94.130 mail.zunft-oberstrass.ch. 3516 IN A 195.129.94.194 ;; Message size: 137 bytes ;; Query time: 138 ms -------------------- 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)? Thank you, Stefano |
|
From: Ben A. <ben...@st...> - 2007-06-25 11:10:13
|
Hello there I would greatly appreciate a small amount of your time to assist with my doctoral research at The University of Newcastle. The research concerns open source licensing and we're seeking developers working on Java projects. The research is supervised, ethics-approved, anonymous and results will be freely available. Participation will also provide a custom licensing report for your project. To learn more, please visit: http://licensing-research.newcastle.edu.au Thanks for reading this email, and I hope you'll consider participating. Best regards Ben Alex (My apologies for being off-topic; this list will not be emailed again) |
|
From: Brian W. <bwe...@xb...> - 2007-06-21 17:20:26
|
On Thu, 21 Jun 2007, Enrico Fustinoni wrote: > we are using dnsjava 2.0.3 with java 1.6 on linux (kernel version 2.6) > and we get this 2 errors: > > [class java.lang.InternalError] msg=unable to get address of epoll > functions This error seems to indicate that it's a problem with Java itself. > No problems with java 1.5 and java 1.6 on windows 2003 > > > > Unfortunately we need to use java 1.6 . Have you some suggestions or > workaround ? Not really, If the JVM doesn't work, there's no way a program using it can. Brian |
|
From: Enrico F. <enr...@re...> - 2007-06-21 12:16:14
|
Hy all, we are using dnsjava 2.0.3 with java 1.6 on linux (kernel version 2.6) and we get this 2 errors: =20 =20 [class java.lang.InternalError] msg=3Dunable to get address of epoll functions , pre-2.6 kernel? > sun.nio.ch.EPollArrayWrapper.init(Native Method) > sun.nio.c h.EPollArrayWrapper.<clinit>(EPollArrayWrapper.java:227) > sun.nio.ch.EPollSelec torImpl.<init>(EPollSelectorImpl.java:52) > sun.nio.ch.EPollSelectorProvider.ope nSelector(EPollSelectorProvider.java:18) > java.nio.channels.Selector.open(Selec tor.java:209) > org.xbill.DNS.Client.<init>(Client.java:21) > org.xbill.DNS.UDPC lient.<init>(UDPClient.java:14) > org.xbill.DNS.UDPClient.sendrecv(UDPClient.jav a:57) > org.xbill.DNS.SimpleResolver.send(SimpleResolver.java:213) > org.xbill.D NS.ExtendedResolver$Resolution.start(ExtendedResolver.java:93) > org.xbill.DNS.E xtendedResolver.send(ExtendedResolver.java:357) > org.xbill.DNS.Lookup.lookup(Lo okup.java:450) > org.xbill.DNS.Lookup.resolve(Lookup.java:502) > org.xbill.DNS.L ookup.run(Lookup.java:514)... =20 =20 [class java.lang.NoClassDefFoundError] msg=3DCould not initialize class sun.ni o.ch.EPollArrayWrapper > sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.j ava:52) > sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.ja va:18) > java.nio.channels.Selector.open(Selector.java:209) > org.xbill.DNS.Clie nt.<init>(Client.java:21) > org.xbill.DNS.UDPClient.<init>(UDPClient.java:14) > org.xbill.DNS.UDPClient.sendrecv(UDPClient.java:57) > org.xbill.DNS.SimpleResolv er.send(SimpleResolver.java:213) > org.xbill.DNS.ExtendedResolver$Resolution.sta rt(ExtendedResolver.java:93) > org.xbill.DNS.ExtendedResolver.send(ExtendedResol ver.java:357) > org.xbill.DNS.Lookup.lookup(Lookup.java:450) > org.xbill.DNS.Loo kup.resolve(Lookup.java:502) > org.xbill.DNS.Lookup.run(Lookup.java:514)... =20 No problems with java 1.5 and java 1.6 on windows 2003 =20 Unfortunately we need to use java 1.6 . Have you some suggestions or workaround ?=20 =20 Thank you =20 Enrico Fustinoni |
|
From: Brian W. <bwe...@xb...> - 2007-04-26 20:27:02
|
On Thu, 26 Apr 2007, Norman wrote: >> I don't know exactly what you mean by a "switch". As far as I know, >> there's no standard or nonstandard way to figure out what the OS uses >> other than DNS to do hostname resolution, and no way to ask the OS to >> attempt alternative methods of hostname resolution without also doing >> DNS queries. >> >> If what you're asking for is simply the ability to parse /etc/hosts, >> that would be possible, but wouldn't be useful on systems with have >> other ways of configuring static DNS data, and I'm pretty sure Windows >> systems don't have /etc/hosts files. > > Yes parsing the file whould be enough here. For sure there are other > places for other OS'es. So maybe we on our own to write some wrapper to > do the stuff. I haven't had much time to work on dnsjava recently, so if you want something soon, you'd probably want to write it yourself. I'd be happy to accept patches, of course. Brian |
|
From: Norman <nm...@sp...> - 2007-04-26 20:15:58
|
Brian Wellington schrieb: > On Thu, 26 Apr 2007, Norman Maurer wrote: > >> we using dnsjava in our project ( james.apache.org), and it works great. >> But sometimes we need to resolv "localhost". This is not possible with >> dnsjava, because it not take care about /etc/hosts etc. So we have to >> resolv such lookups with InetAddress usage. >> >> Is it planned to resolv this kind of stuff ? Maybe be able to enable it >> via a "switch" ? > > I don't know exactly what you mean by a "switch". As far as I know, > there's no standard or nonstandard way to figure out what the OS uses > other than DNS to do hostname resolution, and no way to ask the OS to > attempt alternative methods of hostname resolution without also doing > DNS queries. > > If what you're asking for is simply the ability to parse /etc/hosts, > that would be possible, but wouldn't be useful on systems with have > other ways of configuring static DNS data, and I'm pretty sure Windows > systems don't have /etc/hosts files. > > Brian Yes parsing the file whould be enough here. For sure there are other places for other OS'es. So maybe we on our own to write some wrapper to do the stuff. Thx Norman > > > |
|
From: Brian W. <bwe...@xb...> - 2007-04-26 19:14:55
|
On Thu, 26 Apr 2007, Norman Maurer wrote: > we using dnsjava in our project ( james.apache.org), and it works great. > But sometimes we need to resolv "localhost". This is not possible with > dnsjava, because it not take care about /etc/hosts etc. So we have to > resolv such lookups with InetAddress usage. > > Is it planned to resolv this kind of stuff ? Maybe be able to enable it > via a "switch" ? I don't know exactly what you mean by a "switch". As far as I know, there's no standard or nonstandard way to figure out what the OS uses other than DNS to do hostname resolution, and no way to ask the OS to attempt alternative methods of hostname resolution without also doing DNS queries. If what you're asking for is simply the ability to parse /etc/hosts, that would be possible, but wouldn't be useful on systems with have other ways of configuring static DNS data, and I'm pretty sure Windows systems don't have /etc/hosts files. Brian |
|
From: Norman M. <no...@ap...> - 2007-04-26 14:09:52
|
Hi all, we using dnsjava in our project ( james.apache.org), and it works great. But sometimes we need to resolv "localhost". This is not possible with dnsjava, because it not take care about /etc/hosts etc. So we have to resolv such lookups with InetAddress usage. Is it planned to resolv this kind of stuff ? Maybe be able to enable it via a "switch" ? Thx Norman |
|
From: Brian W. <Bri...@no...> - 2007-03-16 17:55:04
|
On Fri, 16 Mar 2007, Rob Podolski wrote:
> Hi,
>
> I want to use a specified (external) public name server to resolve any
> given URL into its IP address(es) yielding also the TTL from the name
> server. I managed to do this using JNDI, but couldn't get the TTL.
> Then I found dnsjava so would like to give it a try.
>
> Would the following work?? I've tried it but can't vouch for the TTL
> coming back upon successive tries.
>
> SimpleResolver res = new SimpleResolver(<public name server ip address>);
> Lookup lookup = new Lookup(<my url>, Type.A);
> lookup.setResolver(res);
>
> Record [] records = lookup.run();
> ARecord aRec = null;
> for (int iRec = 0; iRec < records.length; iRec++) {
> aRec = (ARecord) records[iRec];
> System.out.println(aRec.getAddress() );
> }
> System.out.println(aRec.getTTL() );
>
> Does this look right? Any help would be gratefully received.
I haven't tested it, but it looks right. You probably want a check that
lookup.run() doesn't return null, but that's about the only thing I'd
change.
Brian
|
|
From: Rob P. <rob...@ya...> - 2007-03-16 12:19:19
|
Hi,
I want to use a specified (external) public name server to resolve any given URL into its IP address(es) yielding also the TTL from the name server. I managed to do this using JNDI, but couldn't get the TTL. Then I found dnsjava so would like to give it a try.
Would the following work?? I've tried it but can't vouch for the TTL coming back upon successive tries.
SimpleResolver res = new SimpleResolver(<public name server ip address>);
Lookup lookup = new Lookup(<my url>, Type.A);
lookup.setResolver(res);
Record [] records = lookup.run();
ARecord aRec = null;
for (int iRec = 0; iRec < records.length; iRec++) {
aRec = (ARecord) records[iRec];
System.out.println(aRec.getAddress() );
}
System.out.println(aRec.getTTL() );
Does this look right? Any help would be gratefully received.
Rob.
---------------------------------
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. |
|
From: <og...@og...> - 2006-10-26 20:18:41
|
At 15:51 26/10/2006, Sreenivasa Mulakala wrote:
>Brian,
>
>I am sorry to hear this.
>
>Actually I am able to add the entry. I did read your examples. I grabbed the
>code from there only.
>
>Here is the code I am using
>
> Name zoneName = Name.fromString(zone);
> Name host = Name.fromString("www.junk.com", zoneName);
> Update update = new Update(zoneName);
> update.add(host, Type.PTR, 3600, ipAddress);
^^^^^^^^^^^^
Fourth parameter (RDATA) specifies an address you need to change this
to the name you want.
Olafur
|
|
From: Sreenivasa M. <mul...@ho...> - 2006-10-26 19:51:41
|
Brian,
I am sorry to hear this.
Actually I am able to add the entry. I did read your examples. I grabbed the
code from there only.
Here is the code I am using
Name zoneName = Name.fromString(zone);
Name host = Name.fromString("www.junk.com", zoneName);
Update update = new Update(zoneName);
update.add(host, Type.PTR, 3600, ipAddress);
org.xbill.DNS.Resolver res = new SimpleResolver("10.240.2.21");
res.setTCP(true);
Message response = res.send(update);
Here are the results
Expected one
1 PTR v000f9fd9a094.vo.test.net.
Got like this
PTR 195.187.195.1
Thanks in advance
Regards
Sri
>From: Brian Wellington <bwe...@xb...>
>To: Sreenivasa Mulakala <mul...@ho...>
>CC: dns...@li...
>Subject: Re: DNSJAVA Help
>Date: Thu, 26 Oct 2006 12:29:51 -0700 (PDT)
>
>I'm sorry, but I'm not going to help you if you persist in not reading the
>example code. There's absolutely no reason for you to be constructing byte
>arrays manually to create DNS records when there are perfectly good methods
>to create records from either Strings or native objects.
>
>Brian
|
|
From: Brian W. <bwe...@xb...> - 2006-10-26 19:29:55
|
I'm sorry, but I'm not going to help you if you persist in not reading the example code. There's absolutely no reason for you to be constructing byte arrays manually to create DNS records when there are perfectly good methods to create records from either Strings or native objects. Brian |
|
From: Sreenivasa M. <mul...@ho...> - 2006-10-26 19:26:54
|
Hello Brain, Here is the entry The SOA is 195.187.24.in-addr.arpa IN SOA lab-a.lab.test.net. abuse.test.net. ( 2006101700 ; serial 7200 ; refresh (2 hours) 600 ; retry (10 minutes) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) Here are some sample entries 1 PTR ool-18bbc301.static.goog.net. 10 PTR ool-18bbc30a.static.goog.net. 100 PTR ool-18bbc364.static.goog.net. 101 PTR ool-18bbc365.static.goog.net. 102 PTR ool-18bbc366.static.goog.net. Could you please tell me what I should be doing wrong. For me record is not getting created in the first place. It is returning null. When I try to debug there is a exception like wireparseexception below Here is the data I am passing [-61, -69, -61, 1] in byte array. public Name(DNSInput in) throws WireParseException { int len, pos, currentpos; Name name2; boolean done = false; byte [] label = new byte[MAXLABEL + 1]; boolean savedState = false; while (!done) { len = in.readU8(); switch (len & LABEL_MASK) { case LABEL_NORMAL: if (getlabels() >= MAXLABELS) throw new WireParseException("too many labels"); if (len == 0) { append(emptyLabel, 0, 1); done = true; } else { label[0] = (byte)len; in.readByteArray(label, 1, len); append(label, 0, 1); } break; case LABEL_COMPRESSION: pos = in.readU8(); pos += ((len & ~LABEL_MASK) << 8); if (Options.check("verbosecompression")) System.err.println("currently " + in.current() + ", pointer to " + pos); if (pos >= in.current()) throw new WireParseException("bad compression"); When I do a nsupdate and works for these 1.195.187.24.in-addr.arpa 600 IN PTR www.junk.com. Thanks in advance -Sri >From: Brian Wellington <bwe...@xb...> >To: Sreenivasa Mulakala <mul...@ho...> >CC: dns...@li... >Subject: Re: DNSJAVA Help >Date: Thu, 26 Oct 2006 11:01:45 -0700 (PDT) > >On Thu, 26 Oct 2006, Sreenivasa Mulakala wrote: > >>I am having trouble in adding a row to DNS which is BIND 9.2.5. >> >>I am able to ping the server. >> >>When I run the program which is below. Nothing goes on to wire atleast. >>The >>code is not contacting the server for update or add. >> >>Could you please advice me on what could be wrong. >> >>Thanks & Regards >>Sri >> >> System.setProperty("sun.net.spi.nameservice.nameservers","192.168.2.3"); >> System.setProperty("sun.net.spi.nameservice.provider.1", "dns,sun"); >> System.setProperty("sun.net.spi.nameservice.provider.2", "dns,dnsjava"); >> >> >> >> public Record addDNSEntry(String zone, int dnsClass, long ttl, String >>ipAddress ){ >> String = "ool-18bbc301.arpa.net." >> >> Message msg = new Message(); >> Record record = null; >> >> try{ >> System.out.println("Trying to update the record"); >> >> byte[] ipaddressbytearray = Address.toByteArray("195.187.24.1", >>Address.IPv4); >> >> >> record = Record.newRecord(new Name(zone), Type.A, DClass.IN, ttl, >>ipaddressbytearray.length, ipaddressbytearray); >> >> msg.addRecord(record,Section.ADDITIONAL); >> log.info("The Entry is updated"); >> }catch(TextParseException tpe){ >> log.error(" OOOPs In TextParseException of add DNS entry : "); >> log.error(tpe.getMessage()); >> }catch(Exception ioe){ >> log.error("OOPS In Exception of add DNS entry : "); >> log.error(ioe.getMessage()); >> } >> return record; >> } > >You're building a message and never sending it. See the example of using >dynamic update at http://www.dnsjava.org/examples.html. > >Brian |
|
From: Brian W. <bwe...@xb...> - 2006-10-26 18:02:03
|
On Thu, 26 Oct 2006, Sreenivasa Mulakala wrote:
> I am having trouble in adding a row to DNS which is BIND 9.2.5.
>
> I am able to ping the server.
>
> When I run the program which is below. Nothing goes on to wire atleast. The
> code is not contacting the server for update or add.
>
> Could you please advice me on what could be wrong.
>
> Thanks & Regards
> Sri
>
> System.setProperty("sun.net.spi.nameservice.nameservers","192.168.2.3");
> System.setProperty("sun.net.spi.nameservice.provider.1", "dns,sun");
> System.setProperty("sun.net.spi.nameservice.provider.2", "dns,dnsjava");
>
>
>
> public Record addDNSEntry(String zone, int dnsClass, long ttl, String
> ipAddress ){
> String = "ool-18bbc301.arpa.net."
>
> Message msg = new Message();
> Record record = null;
>
> try{
> System.out.println("Trying to update the record");
>
> byte[] ipaddressbytearray = Address.toByteArray("195.187.24.1",
> Address.IPv4);
>
>
> record = Record.newRecord(new Name(zone), Type.A, DClass.IN, ttl,
> ipaddressbytearray.length, ipaddressbytearray);
>
> msg.addRecord(record,Section.ADDITIONAL);
> log.info("The Entry is updated");
> }catch(TextParseException tpe){
> log.error(" OOOPs In TextParseException of add DNS entry : ");
> log.error(tpe.getMessage());
> }catch(Exception ioe){
> log.error("OOPS In Exception of add DNS entry : ");
> log.error(ioe.getMessage());
> }
> return record;
> }
You're building a message and never sending it. See the example of using
dynamic update at http://www.dnsjava.org/examples.html.
Brian
|
|
From: Sreenivasa M. <mul...@ho...> - 2006-10-26 17:08:24
|
Hello Guys,
I am having trouble in adding a row to DNS which is BIND 9.2.5.
I am able to ping the server.
When I run the program which is below. Nothing goes on to wire atleast. The
code is not contacting the server for update or add.
Could you please advice me on what could be wrong.
Thanks & Regards
Sri
System.setProperty("sun.net.spi.nameservice.nameservers","192.168.2.3");
System.setProperty("sun.net.spi.nameservice.provider.1", "dns,sun");
System.setProperty("sun.net.spi.nameservice.provider.2", "dns,dnsjava");
public Record addDNSEntry(String zone, int dnsClass, long ttl, String
ipAddress ){
String = "ool-18bbc301.arpa.net."
Message msg = new Message();
Record record = null;
try{
System.out.println("Trying to update the record");
byte[] ipaddressbytearray = Address.toByteArray("195.187.24.1",
Address.IPv4);
record = Record.newRecord(new Name(zone), Type.A, DClass.IN, ttl,
ipaddressbytearray.length, ipaddressbytearray);
msg.addRecord(record,Section.ADDITIONAL);
log.info("The Entry is updated");
}catch(TextParseException tpe){
log.error(" OOOPs In TextParseException of add DNS entry : ");
log.error(tpe.getMessage());
}catch(Exception ioe){
log.error("OOPS In Exception of add DNS entry : ");
log.error(ioe.getMessage());
}
return record;
}
|
|
From: <Ale...@no...> - 2006-09-07 13:15:27
|
Hi - In case anybody is interested, we have published an extension to dnsjava that uses non-blocking sockets, and does not create a new thread for each new query. Where possible, it streams all DNS traffic over single port, rather than opening a new port for each query. The code is an add-on to dnsjava - it does not change dnsjava at all; it simply provides a new NonblockingResolver which can be used instead of a SimpleResolver, and defines a new ResponseQueue for completed queries (rather than using the existing callback method). Details, and the download link, are available here : http://blog.nominet.org.uk/tech/Java/2006/08/08/Nonblocking-extensions-to-dnsjava.html Please let me know if you have any questions or issues with this code. Thanks! Alex. |
26 messages has been excluded from this view by a project administrator.
