dnsjava-users — The dnsjava mailing list

Re: Flags.AD missing on DNSSEC response header

[Christian M. <dcm...@gm...>]

Hi Brian

> > I've testing dnsjava lib with DNSsec and it seems that the AD flag  
> > (authenticated data) within a response is not recognized correctly.
> >
> > Here is the header section of a response I've received asking  
> > nameserver a.ns.se for A records of google.se (for testing purposes):
> >
> >  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24516
> >  ;; flags: qr ; qd: 1 an: 0 au: 6 ad: 1
> >  ;; QUESTIONS:
> >  ;;    google.se., type = A, class = IN
> >  [...]
> >
> > But asking response's org.xbill.DNS.Message header for Flag.AD fails:
> >
> >  org.xbill.DNS.Message response = ...
> >  response.getHeader().getFlag(org.xbill.DNS.Flags.AD); // returns  
> > "false"
> 
> Unless I'm missing something, this is because the AD bit isn't set.
> 
> > Asking header for other flags (like Flags.QR in this example)  
> > succeeds, so what's going wrong here? Is it a bug or am I missing  
> > something?
> 
> The QR flag is set.  There are no other flags set, so asking for any  
> other one will return false.
> 
> Is it possible that you're misreading the dig ouptut?  The "ad" in  
> there refers to the count of records in the additional section, not a  
> flag.

Indeed, you're right! Sorry for any inconvenience and thanks for opening my eyes.
But what the hell drives them to give different concepts the same abbreviation? Maybe checking attentiveness of the reader? ;-)

Christian
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re:

[Brian W. <bwe...@xb...>]

On Sep 30, 2009, at 1:27 AM, "Christian Möller" <dcm...@gm...>  
wrote:

> Hi,
>
> I've testing dnsjava lib with DNSsec and it seems that the AD flag  
> (authenticated data) within a response is not recognized correctly.
>
> Here is the header section of a response I've received asking  
> nameserver a.ns.se for A records of google.se (for testing purposes):
>
>  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24516
>  ;; flags: qr ; qd: 1 an: 0 au: 6 ad: 1
>  ;; QUESTIONS:
>  ;;    google.se., type = A, class = IN
>  [...]
>
> But asking response's org.xbill.DNS.Message header for Flag.AD fails:
>
>  org.xbill.DNS.Message response = ...
>  response.getHeader().getFlag(org.xbill.DNS.Flags.AD); // returns  
> "false"

Unless I'm missing something, this is because the AD bit isn't set.

> Asking header for other flags (like Flags.QR in this example)  
> succeeds, so what's going wrong here? Is it a bug or am I missing  
> something?

The QR flag is set.  There are no other flags set, so asking for any  
other one will return false.

Is it possible that you're misreading the dig ouptut?  The "ad" in  
there refers to the count of records in the additional section, not a  
flag.
>

Brian

None

[Christian M. <dcm...@gm...>]

Hi,

I've testing dnsjava lib with DNSsec and it seems that the AD flag (authenticated data) within a response is not recognized correctly.

Here is the header section of a response I've received asking nameserver a.ns.se for A records of google.se (for testing purposes):

  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24516
  ;; flags: qr ; qd: 1 an: 0 au: 6 ad: 1 
  ;; QUESTIONS:
  ;;	google.se., type = A, class = IN
  [...]

But asking response's org.xbill.DNS.Message header for Flag.AD fails:

  org.xbill.DNS.Message response = ...
  response.getHeader().getFlag(org.xbill.DNS.Flags.AD); // returns "false"

Asking header for other flags (like Flags.QR in this example) succeeds, so what's going wrong here? Is it a bug or am I missing something?

Greetings

Christian
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: Max zone transfer

[Luis S. <lui...@gm...>]

Ok,
sorry, found the answer. The record counters (for example, ANCOUNT) present
on the message have that limitation (unsigned int 16) .

On Thu, Aug 20, 2009 at 4:53 PM, Luis Silva <lui...@gm...> wrote:

> Hi all!
>
> I'm trying to send 500k records in a AXFR response, but I'm receiving the
> following error message:
>
> DNS section count cannot be incremented --
> org.xbill.DNS.Header.incCount(Header.java:218)
> org.xbill.DNS.Message.addRecord(Message.java:157)
> Is there any limitation in the DNS protocol related with the max size in a
> zone transfer?
>
> Thanks,
> LS
>
>
>

Max zone transfer

[Luis S. <lui...@gm...>]

Hi all!

I'm trying to send 500k records in a AXFR response, but I'm receiving the
following error message:

DNS section count cannot be incremented --
org.xbill.DNS.Header.incCount(Header.java:218)
org.xbill.DNS.Message.addRecord(Message.java:157)
Is there any limitation in the DNS protocol related with the max size in a
zone transfer?

Thanks,
LS

reading dig parameters

[bond_shukla <sam...@gm...>]

Hi I am new to dnsworld. Just now i have started using this library, i have
one query ,from command line i am sending one dig query 

   ex: dig @localhost -p 53 abcd.com +tcp

My Java program is reading these parameters using ServerSocket.
BufferedReader br = new BufferedReader(new InputStreamReader(socket
					.getInputStream()));

Now the problem is i get these paramerers in encrypted form, so i am not
able to send abcd.com to DNS server. Can some one pls tell me with example
how can i decrypt or any other alternate solution.

Thanks in advance


-- 
View this message in context: http://www.nabble.com/reading-dig-parameters-tp24698221p24698221.html
Sent from the dnsjava-users mailing list archive at Nabble.com.

Re: OSGi and Maven

[Robert B. D. <rob...@gm...>]

On Mon, Jun 8, 2009 at 8:56 PM, Robert Burrell
Donkin<rob...@gm...> wrote:
> On Mon, Jun 8, 2009 at 8:02 PM, Brian Wellington<bwe...@xb...> wrote:
>> On Sun, 7 Jun 2009, Robert Burrell Donkin wrote:
>>
>>> firstly, kudos for dnsjava :-)
>>>
>>> i'd like to be able to use dnsjava more easily downstream in maven and
>>> OSGi environments. for maven this means uploading releases to the
>>> central repository. for OSGi this means including some additional meta
>>> data in the META-INF.
>>>
>>> the easiest way to achieve both would be to create a suitable maven
>>> build for the current release and then maintain it in addition to the
>>> existing ant one.  there are two ways i could go about this: either
>>> forking downstream the source of each release with added maven build
>>> or by supplying patches for an upstream maven build here and then
>>> arranging for a maven synchronization repository.
>>
>> If I added stuff to the dnsjava repository for every external framework that
>> wanted it, there would be a ton of what would end up unmaintained code that
>> people would report bugs to me about.
>>
>> As there aren't very many releases (there hasn't been one in almost 18
>> months, and aren't likely to be more than one in the near future), forking
>> downstream for each release doesn't seem like all that much work.
>
> fine

i've created a suitable project
(http://sourceforge.net/projects/dnsjava-osgi/
https://www.ohloh.net/p/dnsjavaosgi), set up a synchronizing
repository for Maven
(http://repo1.maven.org/maven2/net/sf/dnsjava-osgi/dnsjava-osgi/) and
an OSGi enabled build process. this means that the major work is now
done and supporting other releases should be easy.

another digit is prefixed to the dnsjava release number to indicate
the repackaging version, for example 2.0.6.1 is the second repackaged
release of 2.0.6.

downstream users should now be able to declare

<dependency>
  <groupId>net.sf.dnsjava-osgi</groupId>
  <artifactId>dnsjava-osgi</artifactId>
  <version>2.0.6.1</version>
<dependency>

if maven users want to use dnsjava 2.0.6

if anyone else wants to volunteer to help maintain further releases,
i'd be happy to grant karma. just contact me off list.

- robert

Re: Small patch for dnsjnio compatibility

[Brian W. <bwe...@xb...>]

On Fri, 12 Jun 2009, Stefano Bagnara wrote:

> Brian Wellington ha scritto:
>> On Mon, 8 Jun 2009, Al...@no... wrote:
>>
>>> I'd like to sound you out on a small potential patch for dnsjava. The
>>> patch would allow dnsjnio to exist in its own namespace, and not to have
>>> to declare classes in the org.xbill.DNS package (an ugly hack which is
>>> starting to get in the way).
>>>
>>> Basically, the patch would involve changing the access of some classes in
>>> the org.xbill.DNS package.
>>>
>>> If you thought you might be able to include such a patch, I'd happily
>>> knock one up against the latest dnsjava code (or the 2.0.6 release -
>>> whichever was easiest for you) and submit it before the next dnsjava
>>> release. Does this sound reasonable?
>>
>> Without knowing what the changes are, it's hard to say.
>>
>> Brian
>
> Hi Brian,
>
> maybe a small list is better than a diff in this case. It is all about
> package visibility to be changed to public in order to allow usage in
> different packages.
>
> dnsjnio needs all of this to be made public:
>
> DClass.check method
> Type.check method

These both look reasonable.

> Mnemonic class (for the Mnemonic.toInteger(dclass) usage)

This certainly isn't needed.  It's an internal optimization, and external 
code can just use "new Integer(dclass)".

> Message.TSIG_VERIFIED field
> Message.tsigState (we need to set this to TSIG_VERIFIED in a custom
> resolver)

I'm not sure if it's better to make the fields public or to add 
setSigned() and setVerified() accessors.  It really doesn't make sense to 
export Message.TSIG_VERIFIED and not the other constants.

Brian

Re: Small patch for dnsjnio compatibility

[Stefano B. <sou...@ba...>]

Brian Wellington ha scritto:
> On Mon, 8 Jun 2009, Al...@no... wrote:
> 
>> I'd like to sound you out on a small potential patch for dnsjava. The
>> patch would allow dnsjnio to exist in its own namespace, and not to have
>> to declare classes in the org.xbill.DNS package (an ugly hack which is
>> starting to get in the way).
>>
>> Basically, the patch would involve changing the access of some classes in
>> the org.xbill.DNS package.
>>
>> If you thought you might be able to include such a patch, I'd happily
>> knock one up against the latest dnsjava code (or the 2.0.6 release -
>> whichever was easiest for you) and submit it before the next dnsjava
>> release. Does this sound reasonable?
> 
> Without knowing what the changes are, it's hard to say.
> 
> Brian

Hi Brian,

maybe a small list is better than a diff in this case. It is all about
package visibility to be changed to public in order to allow usage in
different packages.

dnsjnio needs all of this to be made public:

DClass.check method
Type.check method
Mnemonic class (for the Mnemonic.toInteger(dclass) usage)
Message.TSIG_VERIFIED field
Message.tsigState (we need to set this to TSIG_VERIFIED in a custom
resolver)

Do you think this is feasible? I can provide a diff if you think that
they can be made public.

Stefano

Re: OSGi and Maven

[Robert B. D. <rob...@gm...>]

On Mon, Jun 8, 2009 at 8:02 PM, Brian Wellington<bwe...@xb...> wrote:
> On Sun, 7 Jun 2009, Robert Burrell Donkin wrote:
>
>> firstly, kudos for dnsjava :-)
>>
>> i'd like to be able to use dnsjava more easily downstream in maven and
>> OSGi environments. for maven this means uploading releases to the
>> central repository. for OSGi this means including some additional meta
>> data in the META-INF.
>>
>> the easiest way to achieve both would be to create a suitable maven
>> build for the current release and then maintain it in addition to the
>> existing ant one.  there are two ways i could go about this: either
>> forking downstream the source of each release with added maven build
>> or by supplying patches for an upstream maven build here and then
>> arranging for a maven synchronization repository.
>
> If I added stuff to the dnsjava repository for every external framework that
> wanted it, there would be a ton of what would end up unmaintained code that
> people would report bugs to me about.
>
> As there aren't very many releases (there hasn't been one in almost 18
> months, and aren't likely to be more than one in the near future), forking
> downstream for each release doesn't seem like all that much work.

fine

- robert

Re: Small patch for dnsjnio compatibility

[Brian W. <bwe...@xb...>]

On Mon, 8 Jun 2009, Al...@no... wrote:

> I'd like to sound you out on a small potential patch for dnsjava. The
> patch would allow dnsjnio to exist in its own namespace, and not to have
> to declare classes in the org.xbill.DNS package (an ugly hack which is
> starting to get in the way).
>
> Basically, the patch would involve changing the access of some classes in
> the org.xbill.DNS package.
>
> If you thought you might be able to include such a patch, I'd happily
> knock one up against the latest dnsjava code (or the 2.0.6 release -
> whichever was easiest for you) and submit it before the next dnsjava
> release. Does this sound reasonable?

Without knowing what the changes are, it's hard to say.

Brian

Re: OSGi and Maven

[Brian W. <bwe...@xb...>]

On Sun, 7 Jun 2009, Robert Burrell Donkin wrote:

> firstly, kudos for dnsjava :-)
>
> i'd like to be able to use dnsjava more easily downstream in maven and
> OSGi environments. for maven this means uploading releases to the
> central repository. for OSGi this means including some additional meta
> data in the META-INF.
>
> the easiest way to achieve both would be to create a suitable maven
> build for the current release and then maintain it in addition to the
> existing ant one.  there are two ways i could go about this: either
> forking downstream the source of each release with added maven build
> or by supplying patches for an upstream maven build here and then
> arranging for a maven synchronization repository.

If I added stuff to the dnsjava repository for every external framework 
that wanted it, there would be a ton of what would end up unmaintained 
code that people would report bugs to me about.

As there aren't very many releases (there hasn't been one in almost 18 
months, and aren't likely to be more than one in the near future), forking 
downstream for each release doesn't seem like all that much work.

Brian

Small patch for dnsjnio compatibility

[<Al...@no...>]

Hi - 

I'd like to sound you out on a small potential patch for dnsjava. The 
patch would allow dnsjnio to exist in its own namespace, and not to have 
to declare classes in the org.xbill.DNS package (an ugly hack which is 
starting to get in the way).

Basically, the patch would involve changing the access of some classes in 
the org.xbill.DNS package.

If you thought you might be able to include such a patch, I'd happily 
knock one up against the latest dnsjava code (or the 2.0.6 release - 
whichever was easiest for you) and submit it before the next dnsjava 
release. Does this sound reasonable?

Thanks,


Alex.

OSGi and Maven

[Robert B. D. <rob...@gm...>]

hi

firstly, kudos for dnsjava :-)

i'd like to be able to use dnsjava more easily downstream in maven and
OSGi environments. for maven this means uploading releases to the
central repository. for OSGi this means including some additional meta
data in the META-INF.

the easiest way to achieve both would be to create a suitable maven
build for the current release and then maintain it in addition to the
existing ant one.  there are two ways i could go about this: either
forking downstream the source of each release with added maven build
or by supplying patches for an upstream maven build here and then
arranging for a maven synchronization repository.

opinions?

- robert

RE: NSEC3 and NSEC3PARAM records

[Brian W. <bwe...@xb...>]

On Thu, 28 May 2009, Jack Tavares wrote:

> Can I take a look at the patches?
>
> I might be able to do what is needed.
> My time is tight as well, so I can't promise anything.

I just committed support based on the patches I received a while ago.  I 
can't guarantee that everything works (I had to make a lot of changes), 
but some basic tests pass.

There's still a few more things that need to get finished before a release 
can be done, but hopefully that can be in a few days.  If you want to 
check the current code out of cvs and make sure it's working, that would 
be very helpful.

Thanks,
Brian

RE: NSEC3 and NSEC3PARAM records

[Jack T. <j.t...@F5...>]

Can I take a look at the patches?

I might be able to do what is needed.
My time is tight as well, so I can't promise anything.

--
Jack Tavares
Reminder: I am at GMT+2, 10 hours AHEAD of Seattle.
My workweek is Sunday-Thursday.
Email sent to me Thursday afternoon (PST) may not be viewed until Sunday morning (GMT+2).


________________________________
From: Brian Wellington [bwe...@xb...]
Sent: Thursday, May 07, 2009 19:32
To: Jack Tavares
Cc: dns...@li...
Subject: Re: NSEC3 and NSEC3PARAM records

On Thu, 7 May 2009, Jack Tavares wrote:

> Hello -
>
> I recently upgraded to 2.0.6 to get DNSSEC support.
>
> While doing so I noticed that NSEC3 and NSEC3PARAM records
> do not appear to be supported (RFC5155).
>
> Are there any plans to do so in the near future?

I have patches to add support, but haven't had time yet to get them into a
state where they can be committed.

Brian

Re: NXDOMAIN

[Brian W. <bwe...@xb...>]

On Fri, 8 May 2009, rwagnes wrote:

> I guess my question is.. what name does not exist?  What is it looking for?

Whatever the value of zoneName is.

Brian

Re: NXDOMAIN

[rwagnes <eli...@ne...>]

I guess my question is.. what name does not exist?  What is it looking for?

Brian Wellington wrote:
> 
> On Fri, 8 May 2009, rwagnes wrote:
> 
>> What exactly would cause the NXDOMAIN exception to be thrown?  This is my
>> code:
>>
>> ZoneTransferIn xfr = ZoneTransferIn.newAXFR(zoneName, hostName, 53,
>> null);
>> List zone = xfr.run();
>>
>> org.xbill.DNS.ZoneTransferException: NXDOMAIN
>>        at org.xbill.DNS.ZoneTransferIn.fail(ZoneTransferIn.java:320)
>>        at org.xbill.DNS.ZoneTransferIn.doxfr(ZoneTransferIn.java:494)
>>        at org.xbill.DNS.ZoneTransferIn.run(ZoneTransferIn.java:532)
>>
>> --zoneName is a valid domain controller..
> 
> I don't know what "domain controller" means, as it's not a DNS term. 
> This exception means that the server returned an NXDOMAIN (name does not 
> exist) error to the zone transfer request.
> 
> Brian
> 
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> dnsjava-users mailing list
> dns...@li...
> https://lists.sourceforge.net/lists/listinfo/dnsjava-users
> 
> 

-- 
View this message in context: http://www.nabble.com/NXDOMAIN-tp23450460p23450933.html
Sent from the dnsjava-users mailing list archive at Nabble.com.

Re: NXDOMAIN

[Brian W. <bwe...@xb...>]

On Fri, 8 May 2009, rwagnes wrote:

> What exactly would cause the NXDOMAIN exception to be thrown?  This is my
> code:
>
> ZoneTransferIn xfr = ZoneTransferIn.newAXFR(zoneName, hostName, 53, null);
> List zone = xfr.run();
>
> org.xbill.DNS.ZoneTransferException: NXDOMAIN
>        at org.xbill.DNS.ZoneTransferIn.fail(ZoneTransferIn.java:320)
>        at org.xbill.DNS.ZoneTransferIn.doxfr(ZoneTransferIn.java:494)
>        at org.xbill.DNS.ZoneTransferIn.run(ZoneTransferIn.java:532)
>
> --zoneName is a valid domain controller..

I don't know what "domain controller" means, as it's not a DNS term. 
This exception means that the server returned an NXDOMAIN (name does not 
exist) error to the zone transfer request.

Brian

NXDOMAIN

[rwagnes <eli...@ne...>]

What exactly would cause the NXDOMAIN exception to be thrown?  This is my
code:

ZoneTransferIn xfr = ZoneTransferIn.newAXFR(zoneName, hostName, 53, null);
List zone = xfr.run();

org.xbill.DNS.ZoneTransferException: NXDOMAIN
        at org.xbill.DNS.ZoneTransferIn.fail(ZoneTransferIn.java:320)
        at org.xbill.DNS.ZoneTransferIn.doxfr(ZoneTransferIn.java:494)
        at org.xbill.DNS.ZoneTransferIn.run(ZoneTransferIn.java:532)

--zoneName is a valid domain controller..

Thanks.
-- 
View this message in context: http://www.nabble.com/NXDOMAIN-tp23450460p23450460.html
Sent from the dnsjava-users mailing list archive at Nabble.com.

Re: DSRecord uses base16 encoding, while DNSKEYRecord uses base 64...

[Olafur G. <og...@og...>]

Yes, base16 is defined for DS digest in RFC4034 section 5.3
DNSKEY public key is base64 as defined in RFC4034 section 2.2

         Olafur



At 09:23 07/05/2009, Jack Tavares wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
> 
>boundary="_000_4B18A8F75A6384449755BC7784073E93603B776C29exch11olympus_"
>
>I had assumed that DSRecord would use the same encoding for
>the digest as DNSKEYRecord uses for the key.
>
>Is base16 the correct encoding there?
>
>Thanks
>
>
>--
>Jack Tavares
>------------------------------------------------------------------------------
>The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>production scanning environment may not be a perfect world - but thanks to
>Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
>Series Scanner you'll get full speed at 300 dpi even with all image
>processing features enabled. http://p.sf.net/sfu/kodak-com
>_______________________________________________
>dnsjava-users mailing list
>dns...@li...
>https://lists.sourceforge.net/lists/listinfo/dnsjava-users

Re: NSEC3 and NSEC3PARAM records

[Brian W. <bwe...@xb...>]

On Thu, 7 May 2009, Jack Tavares wrote:

> Hello -
>
> I recently upgraded to 2.0.6 to get DNSSEC support.
>
> While doing so I noticed that NSEC3 and NSEC3PARAM records
> do not appear to be supported (RFC5155).
>
> Are there any plans to do so in the near future?

I have patches to add support, but haven't had time yet to get them into a 
state where they can be committed.

Brian

RE: DSRecord uses base16 encoding, while DNSKEYRecord uses base 64...

[Jack T. <j.t...@F5...>]

Thanks. I saw that about 30 seconds after I posted my email.
Thank you.

--
Jack Tavares
________________________________________
From: Olafur Gudmundsson [og...@og...]
Sent: Thursday, May 07, 2009 17:13
To: Jack Tavares; dns...@li...
Subject: Re: DSRecord uses base16 encoding, while DNSKEYRecord uses  base 64...

Yes, base16 is defined for DS digest in RFC4034 section 5.3
DNSKEY public key is base64 as defined in RFC4034 section 2.2

         Olafur



At 09:23 07/05/2009, Jack Tavares wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
>
>boundary="_000_4B18A8F75A6384449755BC7784073E93603B776C29exch11olympus_"
>
>I had assumed that DSRecord would use the same encoding for
>the digest as DNSKEYRecord uses for the key.
>
>Is base16 the correct encoding there?
>
>Thanks
>
>
>--
>Jack Tavares
>------------------------------------------------------------------------------
>The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>production scanning environment may not be a perfect world - but thanks to
>Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
>Series Scanner you'll get full speed at 300 dpi even with all image
>processing features enabled. http://p.sf.net/sfu/kodak-com
>_______________________________________________
>dnsjava-users mailing list
>dns...@li...
>https://lists.sourceforge.net/lists/listinfo/dnsjava-users

DSRecord uses base16 encoding, while DNSKEYRecord uses base 64...

[Jack T. <j.t...@F5...>]

I had assumed that DSRecord would use the same encoding for
the digest as DNSKEYRecord uses for the key.

Is base16 the correct encoding there?

Thanks


--
Jack Tavares

NSEC3 and NSEC3PARAM records

[Jack T. <j.t...@F5...>]

Hello -

I recently upgraded to 2.0.6 to get DNSSEC support.

While doing so I noticed that NSEC3 and NSEC3PARAM records
do not appear to be supported (RFC5155).

Are there any plans to do so in the near future?

Thanks.

--
Jack Tavares