dnsjava-users — The dnsjava mailing list

SOARecord getSerial()

[Tom T. <tkt...@gm...>]

I would appreciate some assistance using the getSerial() method.  I am in
the process of learning Java
so please forgive my ignorance and clumsiness.  As you can see below I can
retrieve the SOA record, but I'm unsure
how to grab just the serial number field.

Thank you for your time and assistance.


import org.xbill.DNS.*;
import java.util.Iterator;
import java.net.UnknownHostException;

public class DNSTest1 {
    public static void main(String[] args) throws UnknownHostException,
TextParseException
    {

      SimpleResolver res = new SimpleResolver("192.168.22.187");
      Lookup lookup = new Lookup("mydomain.com", Type.SOA);
      lookup.setResolver(res);
      lookup.run();
      System.out.println(lookup.getAnswers()[0]);

    }
}

mydomain.com. 3600 IN SOA dns1.mydomain.com. abuse.mydomain.com. 326178217
10800 3600 1209600 3600

Re: Cancelling Lookup.run

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

On May 29, 2011, at 8:45 PM, Glenn Maynard wrote:

> Is it possible to asynchronously cancel a lookup?

No, this is not possible.

> Currently I'm running lookups from a worker thread; to cancel, I
> discard the thread, assuming it'll time out on its own eventually.
> I'd much prefer to abort the lookup properly, so the thread can be
> joined before continuing, rather than continuing to retry and time
> out.  (It would also eliminate the need for yet another worker
> thread.)


A lookup will eventually time out, so what you're doing should be safe.  I agree that the ability to do cancellation would be useful, but it would require some major internal changes to be possible.

Brian

Cancelling Lookup.run

[Glenn M. <gl...@ze...>]

Is it possible to asynchronously cancel a lookup?

Currently I'm running lookups from a worker thread; to cancel, I
discard the thread, assuming it'll time out on its own eventually.
I'd much prefer to abort the lookup properly, so the thread can be
joined before continuing, rather than continuing to retry and time
out.  (It would also eliminate the need for yet another worker
thread.)

-- 
Glenn Maynard

Re: Using the TSIG key to verify which client is sending the request

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

On May 26, 2011, at 12:17 PM, Luis Silva wrote:

> One of the parameter in the 
>> tsig.verify(query, in, length, null)
> 
> is the query. Is it possible to make the verification without the complete message?
> 
> Thanks,
> Luis

No, the signature is computed over the entire message, so you need the entire message to verify it.

Brian

> On Thu, May 26, 2011 at 6:18 PM, Brian Wellington <bwe...@xb...> wrote:
> 
> On May 26, 2011, at 7:23 AM, Luis Silva wrote:
> 
>> It worked, thanks.
>> 
>> I've checked the algorithm and it requires the analyses of the complete message. Is that correct?
> 
> I don't understand what you're asking.
> 
> Brian
> 
> 
>> On Wed, May 25, 2011 at 6:47 PM, Brian Wellington <bwe...@xb...> wrote:
>> 
>> On May 25, 2011, at 3:52 AM, Luis Silva wrote:
>> 
>> > I'm receiving in my DNS java server application a DNS query with a TSIG record. Is it possible to extract the TSIG key from this record and verifies the client based on the TSIG?
>> 
>> It is possible to extract the TSIG record from the message, using Message.getTSIG().  Mapping this to a key (comparing the name and algorithm) and verifying the signature can be done in your application.  There's code in jnamed which does this, and can be used for reference.
>> 
>>        TSIGRecord queryTSIG = query.getTSIG();
>>        TSIG tsig = null;
>>        if (queryTSIG != null) {
>>                tsig = (TSIG) TSIGs.get(queryTSIG.getName());
>>                if (tsig == null ||
>>                    tsig.verify(query, in, length, null) != Rcode.NOERROR)
>>                        return formerrMessage(in);
>>        }
>> 
>> Brian
>> 
> 
> 

Re: Using the TSIG key to verify which client is sending the request

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

One of the parameter in the

tsig.verify(query, in, length, null)

is the query. Is it possible to make the verification without the complete
message?

Thanks,
Luis


On Thu, May 26, 2011 at 6:18 PM, Brian Wellington <bwe...@xb...>wrote:

>
> On May 26, 2011, at 7:23 AM, Luis Silva wrote:
>
> It worked, thanks.
>
> I've checked the algorithm and it requires the analyses of the complete
> message. Is that correct?
>
>
> I don't understand what you're asking.
>
> Brian
>
>
> On Wed, May 25, 2011 at 6:47 PM, Brian Wellington <bwe...@xb...>wrote:
>
>>
>> On May 25, 2011, at 3:52 AM, Luis Silva wrote:
>>
>> > I'm receiving in my DNS java server application a DNS query with a TSIG
>> record. Is it possible to extract the TSIG key from this record and verifies
>> the client based on the TSIG?
>>
>> It is possible to extract the TSIG record from the message, using
>> Message.getTSIG().  Mapping this to a key (comparing the name and algorithm)
>> and verifying the signature can be done in your application.  There's code
>> in jnamed which does this, and can be used for reference.
>>
>>        TSIGRecord queryTSIG = query.getTSIG();
>>        TSIG tsig = null;
>>        if (queryTSIG != null) {
>>                tsig = (TSIG) TSIGs.get(queryTSIG.getName());
>>                if (tsig == null ||
>>                    tsig.verify(query, in, length, null) != Rcode.NOERROR)
>>                        return formerrMessage(in);
>>        }
>>
>> Brian
>
>
>
>

Re: Using the TSIG key to verify which client is sending the request

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

On May 26, 2011, at 7:23 AM, Luis Silva wrote:

> It worked, thanks.
> 
> I've checked the algorithm and it requires the analyses of the complete message. Is that correct?

I don't understand what you're asking.

Brian


> On Wed, May 25, 2011 at 6:47 PM, Brian Wellington <bwe...@xb...> wrote:
> 
> On May 25, 2011, at 3:52 AM, Luis Silva wrote:
> 
> > I'm receiving in my DNS java server application a DNS query with a TSIG record. Is it possible to extract the TSIG key from this record and verifies the client based on the TSIG?
> 
> It is possible to extract the TSIG record from the message, using Message.getTSIG().  Mapping this to a key (comparing the name and algorithm) and verifying the signature can be done in your application.  There's code in jnamed which does this, and can be used for reference.
> 
>        TSIGRecord queryTSIG = query.getTSIG();
>        TSIG tsig = null;
>        if (queryTSIG != null) {
>                tsig = (TSIG) TSIGs.get(queryTSIG.getName());
>                if (tsig == null ||
>                    tsig.verify(query, in, length, null) != Rcode.NOERROR)
>                        return formerrMessage(in);
>        }
> 
> Brian
> 

Re: Using the TSIG key to verify which client is sending the request

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

It worked, thanks.

I've checked the algorithm and it requires the analyses of the complete
message. Is that correct?

Again, many thanks,
Luis



On Wed, May 25, 2011 at 6:47 PM, Brian Wellington <bwe...@xb...>wrote:

>
> On May 25, 2011, at 3:52 AM, Luis Silva wrote:
>
> > I'm receiving in my DNS java server application a DNS query with a TSIG
> record. Is it possible to extract the TSIG key from this record and verifies
> the client based on the TSIG?
>
> It is possible to extract the TSIG record from the message, using
> Message.getTSIG().  Mapping this to a key (comparing the name and algorithm)
> and verifying the signature can be done in your application.  There's code
> in jnamed which does this, and can be used for reference.
>
>        TSIGRecord queryTSIG = query.getTSIG();
>        TSIG tsig = null;
>        if (queryTSIG != null) {
>                tsig = (TSIG) TSIGs.get(queryTSIG.getName());
>                if (tsig == null ||
>                    tsig.verify(query, in, length, null) != Rcode.NOERROR)
>                        return formerrMessage(in);
>        }
>
> Brian

Re: Using the TSIG key to verify which client is sending the request

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

On May 25, 2011, at 3:52 AM, Luis Silva wrote:

> I'm receiving in my DNS java server application a DNS query with a TSIG record. Is it possible to extract the TSIG key from this record and verifies the client based on the TSIG? 

It is possible to extract the TSIG record from the message, using Message.getTSIG().  Mapping this to a key (comparing the name and algorithm) and verifying the signature can be done in your application.  There's code in jnamed which does this, and can be used for reference.

        TSIGRecord queryTSIG = query.getTSIG();
        TSIG tsig = null;
        if (queryTSIG != null) {
                tsig = (TSIG) TSIGs.get(queryTSIG.getName());
                if (tsig == null ||
                    tsig.verify(query, in, length, null) != Rcode.NOERROR)
                        return formerrMessage(in);
        }

Brian

Using the TSIG key to verify which client is sending the request

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

Hi,

I'm receiving in my DNS java server application a DNS query with a TSIG
record. Is it possible to extract the TSIG key from this record and verifies
the client based on the TSIG?

Br,
Luis

Re: EDNS0 Client-Subnet

[Deven P. <de...@dn...>]

Looks like I may have found another bug in the EDNS0 handling. The 
payload size for the OPTRecord is not in network byte order. From what I 
can see it calls super() from within the OPTRecord constructor and that 
in turn assigns the payload size to the DClass field of Record. That 
whole thing makes no sense to me. Any suggestions?

Thanks,

Deven

On 03/24/2011 09:57 AM, Deven Phillips wrote:
> Nevermind, I found it again.
>
> Deven
>
> On 03/24/2011 09:54 AM, Deven Phillips wrote:
>> Brian,
>>
>>     I had to leave this code for a few days to take care of other 
>> things and now I cannot find where that checkU8() call was. Could you 
>> give me a clue?
>>
>> Thanks,
>>
>> Deven
>>
>> On 03/22/2011 01:29 PM, Brian Wellington wrote:
>>> On Mar 22, 2011, at 10:11 AM, Deven Phillips wrote:
>>>
>>>> I have been tracing through the code and the whole thing falls apart
>>>> with the TSIG verification. Because I am not trying to sign my
>>>> requests/responses the TSIG is null and returns Rcode.FORMERR. Is 
>>>> there
>>>> a simple way to get around this?
>>>>
>>>>
>>>> On 03/22/2011 09:58 AM, Deven Phillips wrote:
>>>>> Hello All,
>>>>>
>>>>>     New to the list and this may have been answered previously, but I
>>>>> didn't find it searching the archives.
>>>>>
>>>>> Our company is implementing
>>>>> http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01
>>>>>
>>>>> I am trying to add functionality to one of our Java debugging 
>>>>> tools to
>>>>> test this functionality, so I have set up a SimpleResolver and used
>>>>> the setEDNS() method. When I create the Option instance for the
>>>>> OPTRecord, I do it as follows:
>>>>>
>>>>> InetAddress address = null ;
>>>>> try {
>>>>>     address = InetAddress.getByName(sourceField.getText()) ;
>>>>>     int sourceMask = 32 ;
>>>>>     int scopeMask = 0 ;
>>>>>     byte[] family = new byte[2] ;
>>>>>     family[0] = 0x0 ;
>>>>>     family[1] = 0x1 ;
>>>>>     if (Inet4Address.class.isInstance(address)) {
>>>>>         family[1] = 0x1 ;
>>>>>     } else {
>>>>>         family[1] = 0x2 ;
>>>>>     }
>>>>>     ByteArrayOutputStream baos = new ByteArrayOutputStream() ;
>>>>>     baos.write(family) ;
>>>>>     baos.write(sourceMask) ;
>>>>>     baos.write(scopeMask) ;
>>>>>     baos.write(address.getAddress()) ;
>>>>>     System.out.println(new String(baos.toByteArray())) ;
>>>>>     Option clientSubnet = new Option(0x50fa, baos.toByteArray()) ;
>>>>>     ArrayList<Option>  options = new ArrayList<Option>() ;
>>>>>     options.add(clientSubnet) ;
>>>>>     resolver.setEDNS(0, baos.size(), 0, options);
>>>>> } catch (UnknownHostException uhe) {
>>>>>     System.out.println("Source address is set, but is not a valid
>>>>> hostname/IP.") ;
>>>>> }
>>>>>
>>>>> The problem is that when I attempt to perform the lookup, I get an 
>>>>> error:
>>>>>
>>>>> FORMERR
>>>>>
>>>>> As far as I can tell, the byte[] format is identical to the format
>>>>> specified in the RFC (not that DNSJava is checking) and certainly
>>>>> complies with the OPTRecord requirements. Any suggestions?
>>>>>
>>>>> Worst case scenario, I could just manually send my own message, but I
>>>>> hate to re-invent the wheel.
>>> There does appear to be a problem, but I have no idea what you're 
>>> seeing.  In attempting to run code using this code, I did find a 
>>> problem that the code constructing EDNS options (incorrectly) 
>>> expects the option code to be an 8-bit value, not a 16-bit value.  
>>> Thus, attempting to run your code failed with:
>>>
>>> Exception in thread "main" java.lang.IllegalArgumentException: 
>>> "option code" 20730 must be an unsigned 8 bit value
>>>
>>> After fixing that, I was able to send a query with the option, and 
>>> get back a response with the option.  No idea if the value is 
>>> correct, but nothing returned FORMERR.
>>>
>>> Unless you also fixed the size issue, there's no way that your code 
>>> should have been able to construct the option at all, let alone send 
>>> a packet containing it.  I also don't understand why you're talking 
>>> about TSIG; the first thing the TSIG verification code does is check 
>>> to see whether there should be a TSIG at all, and if not, return 
>>> success immediately.
>>>
>>> Brian
>>>
>>
>

Re: EDNS0 Client-Subnet

[Deven P. <de...@dn...>]

Nevermind, I found it again.

Deven

On 03/24/2011 09:54 AM, Deven Phillips wrote:
> Brian,
>
>     I had to leave this code for a few days to take care of other 
> things and now I cannot find where that checkU8() call was. Could you 
> give me a clue?
>
> Thanks,
>
> Deven
>
> On 03/22/2011 01:29 PM, Brian Wellington wrote:
>> On Mar 22, 2011, at 10:11 AM, Deven Phillips wrote:
>>
>>> I have been tracing through the code and the whole thing falls apart
>>> with the TSIG verification. Because I am not trying to sign my
>>> requests/responses the TSIG is null and returns Rcode.FORMERR. Is there
>>> a simple way to get around this?
>>>
>>>
>>> On 03/22/2011 09:58 AM, Deven Phillips wrote:
>>>> Hello All,
>>>>
>>>>     New to the list and this may have been answered previously, but I
>>>> didn't find it searching the archives.
>>>>
>>>> Our company is implementing
>>>> http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01
>>>>
>>>> I am trying to add functionality to one of our Java debugging tools to
>>>> test this functionality, so I have set up a SimpleResolver and used
>>>> the setEDNS() method. When I create the Option instance for the
>>>> OPTRecord, I do it as follows:
>>>>
>>>> InetAddress address = null ;
>>>> try {
>>>>     address = InetAddress.getByName(sourceField.getText()) ;
>>>>     int sourceMask = 32 ;
>>>>     int scopeMask = 0 ;
>>>>     byte[] family = new byte[2] ;
>>>>     family[0] = 0x0 ;
>>>>     family[1] = 0x1 ;
>>>>     if (Inet4Address.class.isInstance(address)) {
>>>>         family[1] = 0x1 ;
>>>>     } else {
>>>>         family[1] = 0x2 ;
>>>>     }
>>>>     ByteArrayOutputStream baos = new ByteArrayOutputStream() ;
>>>>     baos.write(family) ;
>>>>     baos.write(sourceMask) ;
>>>>     baos.write(scopeMask) ;
>>>>     baos.write(address.getAddress()) ;
>>>>     System.out.println(new String(baos.toByteArray())) ;
>>>>     Option clientSubnet = new Option(0x50fa, baos.toByteArray()) ;
>>>>     ArrayList<Option>  options = new ArrayList<Option>() ;
>>>>     options.add(clientSubnet) ;
>>>>     resolver.setEDNS(0, baos.size(), 0, options);
>>>> } catch (UnknownHostException uhe) {
>>>>     System.out.println("Source address is set, but is not a valid
>>>> hostname/IP.") ;
>>>> }
>>>>
>>>> The problem is that when I attempt to perform the lookup, I get an 
>>>> error:
>>>>
>>>> FORMERR
>>>>
>>>> As far as I can tell, the byte[] format is identical to the format
>>>> specified in the RFC (not that DNSJava is checking) and certainly
>>>> complies with the OPTRecord requirements. Any suggestions?
>>>>
>>>> Worst case scenario, I could just manually send my own message, but I
>>>> hate to re-invent the wheel.
>> There does appear to be a problem, but I have no idea what you're 
>> seeing.  In attempting to run code using this code, I did find a 
>> problem that the code constructing EDNS options (incorrectly) expects 
>> the option code to be an 8-bit value, not a 16-bit value.  Thus, 
>> attempting to run your code failed with:
>>
>> Exception in thread "main" java.lang.IllegalArgumentException: 
>> "option code" 20730 must be an unsigned 8 bit value
>>
>> After fixing that, I was able to send a query with the option, and 
>> get back a response with the option.  No idea if the value is 
>> correct, but nothing returned FORMERR.
>>
>> Unless you also fixed the size issue, there's no way that your code 
>> should have been able to construct the option at all, let alone send 
>> a packet containing it.  I also don't understand why you're talking 
>> about TSIG; the first thing the TSIG verification code does is check 
>> to see whether there should be a TSIG at all, and if not, return 
>> success immediately.
>>
>> Brian
>>
>

Re: EDNS0 Client-Subnet

[Deven P. <de...@dn...>]

Brian,

     I had to leave this code for a few days to take care of other 
things and now I cannot find where that checkU8() call was. Could you 
give me a clue?

Thanks,

Deven

On 03/22/2011 01:29 PM, Brian Wellington wrote:
> On Mar 22, 2011, at 10:11 AM, Deven Phillips wrote:
>
>> I have been tracing through the code and the whole thing falls apart
>> with the TSIG verification. Because I am not trying to sign my
>> requests/responses the TSIG is null and returns Rcode.FORMERR. Is there
>> a simple way to get around this?
>>
>>
>> On 03/22/2011 09:58 AM, Deven Phillips wrote:
>>> Hello All,
>>>
>>>     New to the list and this may have been answered previously, but I
>>> didn't find it searching the archives.
>>>
>>> Our company is implementing
>>> http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01
>>>
>>> I am trying to add functionality to one of our Java debugging tools to
>>> test this functionality, so I have set up a SimpleResolver and used
>>> the setEDNS() method. When I create the Option instance for the
>>> OPTRecord, I do it as follows:
>>>
>>> InetAddress address = null ;
>>> try {
>>>     address = InetAddress.getByName(sourceField.getText()) ;
>>>     int sourceMask = 32 ;
>>>     int scopeMask = 0 ;
>>>     byte[] family = new byte[2] ;
>>>     family[0] = 0x0 ;
>>>     family[1] = 0x1 ;
>>>     if (Inet4Address.class.isInstance(address)) {
>>>         family[1] = 0x1 ;
>>>     } else {
>>>         family[1] = 0x2 ;
>>>     }
>>>     ByteArrayOutputStream baos = new ByteArrayOutputStream() ;
>>>     baos.write(family) ;
>>>     baos.write(sourceMask) ;
>>>     baos.write(scopeMask) ;
>>>     baos.write(address.getAddress()) ;
>>>     System.out.println(new String(baos.toByteArray())) ;
>>>     Option clientSubnet = new Option(0x50fa, baos.toByteArray()) ;
>>>     ArrayList<Option>  options = new ArrayList<Option>() ;
>>>     options.add(clientSubnet) ;
>>>     resolver.setEDNS(0, baos.size(), 0, options);
>>> } catch (UnknownHostException uhe) {
>>>     System.out.println("Source address is set, but is not a valid
>>> hostname/IP.") ;
>>> }
>>>
>>> The problem is that when I attempt to perform the lookup, I get an error:
>>>
>>> FORMERR
>>>
>>> As far as I can tell, the byte[] format is identical to the format
>>> specified in the RFC (not that DNSJava is checking) and certainly
>>> complies with the OPTRecord requirements. Any suggestions?
>>>
>>> Worst case scenario, I could just manually send my own message, but I
>>> hate to re-invent the wheel.
> There does appear to be a problem, but I have no idea what you're seeing.  In attempting to run code using this code, I did find a problem that the code constructing EDNS options (incorrectly) expects the option code to be an 8-bit value, not a 16-bit value.  Thus, attempting to run your code failed with:
>
> Exception in thread "main" java.lang.IllegalArgumentException: "option code" 20730 must be an unsigned 8 bit value
>
> After fixing that, I was able to send a query with the option, and get back a response with the option.  No idea if the value is correct, but nothing returned FORMERR.
>
> Unless you also fixed the size issue, there's no way that your code should have been able to construct the option at all, let alone send a packet containing it.  I also don't understand why you're talking about TSIG; the first thing the TSIG verification code does is check to see whether there should be a TSIG at all, and if not, return success immediately.
>
> Brian
>

Re: EDNS0 Client-Subnet

[Deven P. <de...@dn...>]

I found exactly what you are talking about. I must have traced 
incorrectly. I'll try changing that checkU8() to checkU16().

Thanks,

Deven

On 03/22/2011 01:29 PM, Brian Wellington wrote:
> On Mar 22, 2011, at 10:11 AM, Deven Phillips wrote:
>
>> I have been tracing through the code and the whole thing falls apart
>> with the TSIG verification. Because I am not trying to sign my
>> requests/responses the TSIG is null and returns Rcode.FORMERR. Is there
>> a simple way to get around this?
>>
>>
>> On 03/22/2011 09:58 AM, Deven Phillips wrote:
>>> Hello All,
>>>
>>>     New to the list and this may have been answered previously, but I
>>> didn't find it searching the archives.
>>>
>>> Our company is implementing
>>> http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01
>>>
>>> I am trying to add functionality to one of our Java debugging tools to
>>> test this functionality, so I have set up a SimpleResolver and used
>>> the setEDNS() method. When I create the Option instance for the
>>> OPTRecord, I do it as follows:
>>>
>>> InetAddress address = null ;
>>> try {
>>>     address = InetAddress.getByName(sourceField.getText()) ;
>>>     int sourceMask = 32 ;
>>>     int scopeMask = 0 ;
>>>     byte[] family = new byte[2] ;
>>>     family[0] = 0x0 ;
>>>     family[1] = 0x1 ;
>>>     if (Inet4Address.class.isInstance(address)) {
>>>         family[1] = 0x1 ;
>>>     } else {
>>>         family[1] = 0x2 ;
>>>     }
>>>     ByteArrayOutputStream baos = new ByteArrayOutputStream() ;
>>>     baos.write(family) ;
>>>     baos.write(sourceMask) ;
>>>     baos.write(scopeMask) ;
>>>     baos.write(address.getAddress()) ;
>>>     System.out.println(new String(baos.toByteArray())) ;
>>>     Option clientSubnet = new Option(0x50fa, baos.toByteArray()) ;
>>>     ArrayList<Option>  options = new ArrayList<Option>() ;
>>>     options.add(clientSubnet) ;
>>>     resolver.setEDNS(0, baos.size(), 0, options);
>>> } catch (UnknownHostException uhe) {
>>>     System.out.println("Source address is set, but is not a valid
>>> hostname/IP.") ;
>>> }
>>>
>>> The problem is that when I attempt to perform the lookup, I get an error:
>>>
>>> FORMERR
>>>
>>> As far as I can tell, the byte[] format is identical to the format
>>> specified in the RFC (not that DNSJava is checking) and certainly
>>> complies with the OPTRecord requirements. Any suggestions?
>>>
>>> Worst case scenario, I could just manually send my own message, but I
>>> hate to re-invent the wheel.
> There does appear to be a problem, but I have no idea what you're seeing.  In attempting to run code using this code, I did find a problem that the code constructing EDNS options (incorrectly) expects the option code to be an 8-bit value, not a 16-bit value.  Thus, attempting to run your code failed with:
>
> Exception in thread "main" java.lang.IllegalArgumentException: "option code" 20730 must be an unsigned 8 bit value
>
> After fixing that, I was able to send a query with the option, and get back a response with the option.  No idea if the value is correct, but nothing returned FORMERR.
>
> Unless you also fixed the size issue, there's no way that your code should have been able to construct the option at all, let alone send a packet containing it.  I also don't understand why you're talking about TSIG; the first thing the TSIG verification code does is check to see whether there should be a TSIG at all, and if not, return success immediately.
>
> Brian
>

Re: EDNS0 Client-Subnet

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

On Mar 22, 2011, at 10:11 AM, Deven Phillips wrote:

> I have been tracing through the code and the whole thing falls apart 
> with the TSIG verification. Because I am not trying to sign my 
> requests/responses the TSIG is null and returns Rcode.FORMERR. Is there 
> a simple way to get around this?
> 
> 
> On 03/22/2011 09:58 AM, Deven Phillips wrote:
>> Hello All,
>> 
>>    New to the list and this may have been answered previously, but I 
>> didn't find it searching the archives.
>> 
>> Our company is implementing 
>> http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01
>> 
>> I am trying to add functionality to one of our Java debugging tools to 
>> test this functionality, so I have set up a SimpleResolver and used 
>> the setEDNS() method. When I create the Option instance for the 
>> OPTRecord, I do it as follows:
>> 
>> InetAddress address = null ;
>> try {
>>    address = InetAddress.getByName(sourceField.getText()) ;
>>    int sourceMask = 32 ;
>>    int scopeMask = 0 ;
>>    byte[] family = new byte[2] ;
>>    family[0] = 0x0 ;
>>    family[1] = 0x1 ;
>>    if (Inet4Address.class.isInstance(address)) {
>>        family[1] = 0x1 ;
>>    } else {
>>        family[1] = 0x2 ;
>>    }
>>    ByteArrayOutputStream baos = new ByteArrayOutputStream() ;
>>    baos.write(family) ;
>>    baos.write(sourceMask) ;
>>    baos.write(scopeMask) ;
>>    baos.write(address.getAddress()) ;
>>    System.out.println(new String(baos.toByteArray())) ;
>>    Option clientSubnet = new Option(0x50fa, baos.toByteArray()) ;
>>    ArrayList<Option> options = new ArrayList<Option>() ;
>>    options.add(clientSubnet) ;
>>    resolver.setEDNS(0, baos.size(), 0, options);
>> } catch (UnknownHostException uhe) {
>>    System.out.println("Source address is set, but is not a valid 
>> hostname/IP.") ;
>> }
>> 
>> The problem is that when I attempt to perform the lookup, I get an error:
>> 
>> FORMERR
>> 
>> As far as I can tell, the byte[] format is identical to the format 
>> specified in the RFC (not that DNSJava is checking) and certainly 
>> complies with the OPTRecord requirements. Any suggestions?
>> 
>> Worst case scenario, I could just manually send my own message, but I 
>> hate to re-invent the wheel.

There does appear to be a problem, but I have no idea what you're seeing.  In attempting to run code using this code, I did find a problem that the code constructing EDNS options (incorrectly) expects the option code to be an 8-bit value, not a 16-bit value.  Thus, attempting to run your code failed with:

Exception in thread "main" java.lang.IllegalArgumentException: "option code" 20730 must be an unsigned 8 bit value

After fixing that, I was able to send a query with the option, and get back a response with the option.  No idea if the value is correct, but nothing returned FORMERR.

Unless you also fixed the size issue, there's no way that your code should have been able to construct the option at all, let alone send a packet containing it.  I also don't understand why you're talking about TSIG; the first thing the TSIG verification code does is check to see whether there should be a TSIG at all, and if not, return success immediately.

Brian

Re: EDNS0 Client-Subnet

[Deven P. <de...@dn...>]

I have been tracing through the code and the whole thing falls apart 
with the TSIG verification. Because I am not trying to sign my 
requests/responses the TSIG is null and returns Rcode.FORMERR. Is there 
a simple way to get around this?

Thanks,

Deven

On 03/22/2011 09:58 AM, Deven Phillips wrote:
> Hello All,
>
>     New to the list and this may have been answered previously, but I 
> didn't find it searching the archives.
>
> Our company is implementing 
> http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01
>
> I am trying to add functionality to one of our Java debugging tools to 
> test this functionality, so I have set up a SimpleResolver and used 
> the setEDNS() method. When I create the Option instance for the 
> OPTRecord, I do it as follows:
>
> InetAddress address = null ;
> try {
>     address = InetAddress.getByName(sourceField.getText()) ;
>     int sourceMask = 32 ;
>     int scopeMask = 0 ;
>     byte[] family = new byte[2] ;
>     family[0] = 0x0 ;
>     family[1] = 0x1 ;
>     if (Inet4Address.class.isInstance(address)) {
>         family[1] = 0x1 ;
>     } else {
>         family[1] = 0x2 ;
>     }
>     ByteArrayOutputStream baos = new ByteArrayOutputStream() ;
>     baos.write(family) ;
>     baos.write(sourceMask) ;
>     baos.write(scopeMask) ;
>     baos.write(address.getAddress()) ;
>     System.out.println(new String(baos.toByteArray())) ;
>     Option clientSubnet = new Option(0x50fa, baos.toByteArray()) ;
>     ArrayList<Option> options = new ArrayList<Option>() ;
>     options.add(clientSubnet) ;
>     resolver.setEDNS(0, baos.size(), 0, options);
> } catch (UnknownHostException uhe) {
>     System.out.println("Source address is set, but is not a valid 
> hostname/IP.") ;
> }
>
> The problem is that when I attempt to perform the lookup, I get an error:
>
> FORMERR
>
> As far as I can tell, the byte[] format is identical to the format 
> specified in the RFC (not that DNSJava is checking) and certainly 
> complies with the OPTRecord requirements. Any suggestions?
>
> Worst case scenario, I could just manually send my own message, but I 
> hate to re-invent the wheel.
>
> Thanks,
>
> Deven Phillips
> Systems Programmer
> DNS.com

EDNS0 Client-Subnet

[Deven P. <de...@dn...>]

Hello All,

     New to the list and this may have been answered previously, but I 
didn't find it searching the archives.

Our company is implementing 
http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01

I am trying to add functionality to one of our Java debugging tools to 
test this functionality, so I have set up a SimpleResolver and used the 
setEDNS() method. When I create the Option instance for the OPTRecord, I 
do it as follows:

InetAddress address = null ;
try {
     address = InetAddress.getByName(sourceField.getText()) ;
     int sourceMask = 32 ;
     int scopeMask = 0 ;
     byte[] family = new byte[2] ;
     family[0] = 0x0 ;
     family[1] = 0x1 ;
     if (Inet4Address.class.isInstance(address)) {
         family[1] = 0x1 ;
     } else {
         family[1] = 0x2 ;
     }
     ByteArrayOutputStream baos = new ByteArrayOutputStream() ;
     baos.write(family) ;
     baos.write(sourceMask) ;
     baos.write(scopeMask) ;
     baos.write(address.getAddress()) ;
     System.out.println(new String(baos.toByteArray())) ;
     Option clientSubnet = new Option(0x50fa, baos.toByteArray()) ;
     ArrayList<Option> options = new ArrayList<Option>() ;
     options.add(clientSubnet) ;
     resolver.setEDNS(0, baos.size(), 0, options);
} catch (UnknownHostException uhe) {
     System.out.println("Source address is set, but is not a valid 
hostname/IP.") ;
}

The problem is that when I attempt to perform the lookup, I get an error:

FORMERR

As far as I can tell, the byte[] format is identical to the format 
specified in the RFC (not that DNSJava is checking) and certainly 
complies with the OPTRecord requirements. Any suggestions?

Worst case scenario, I could just manually send my own message, but I 
hate to re-invent the wheel.

Thanks,

Deven Phillips
Systems Programmer
DNS.com

Re: Dealing with unresponsive servers

[Louis M. <lo...@ma...>]

On 24 Dec 2010, at 01:05 , David Blacka wrote:

> I think your plan sounds like exactly what I would do in your place.  You are just running into a lack of a feature in ExtendedResolver (which I think is shared by most system resolver libraries).

Hi David,

Thanks for the feedback.

If I like the outcome, I'll chat to my client (who is paying for my time on this) about contributing the work back to the dnsjava project, perhaps as patches to ExtendedResolver.  I think they are likely to agree to this.

--
Louis Mandelstam
# man 8 consulting_

Re: Dealing with unresponsive servers

[David B. <da...@ve...>]

On Dec 23, 2010, at 12:30 PM, Louis Mandelstam wrote:

> On the assumption that an existing solution is not available, I am preparing to implement a replacement for ExtendedResolver that tracks the RTT on each SimpleResolver in its set and uses this to select the fastest SimpleResolver (and consider an unresponsive server "very slow").  I'm taking this approach to avoid having to modify dnsjava itself so that I do not need to maintain a fork of dnsjava with my project.

> I'd be interested in any comments or suggestions regarding the above.

I think your plan sounds like exactly what I would do in your place.  You are just running into a lack of a feature in ExtendedResolver (which I think is shared by most system resolver libraries).

--
David Blacka                          <da...@ve...> 
Principal Engineer    Verisign Platform Product Development

Dealing with unresponsive servers

[Louis M. <lo...@ma...>]

Hi,

I'm working on a project with a time- and reliability-sensitive ENUM resolution requirement.  I'm already using dnsjava for this with good effect (thanks), using an ExtendedResolver with a set of DNS servers (they happen to be authoritative for the queries I send) which I specifically define - i.e. I'm not using the system default resolvers.   I'll typically have exactly two servers, but certainly always more than one.

I'm currently using dnsjava-2.0.8.

If both servers are responding, all is fine.  However if one server is not responding (unreachable), then I can currently choose between:

1. with load balancing disabled, either my application is not affected since it always asks the working server, or every query is delayed by the timeout period, before the remaining server is queried and we proceed;

2. with load balancing enabled, every second query is slowed down by the timeout;

For even a low timeout setting, neither situation is workable in my project - I'd rather have the unresponsive server be excluded from queries than hold up processing continually.  My first question then: is there already a recommended solution to this?  I checked some of the listed applications that make use of dnsjava and didn't spot any of them taking steps to avoid the above.

On the assumption that an existing solution is not available, I am preparing to implement a replacement for ExtendedResolver that tracks the RTT on each SimpleResolver in its set and uses this to select the fastest SimpleResolver (and consider an unresponsive server "very slow").  I'm taking this approach to avoid having to modify dnsjava itself so that I do not need to maintain a fork of dnsjava with my project.

I'd be interested in any comments or suggestions regarding the above.

Regards,


--
Louis Mandelstam
# man 8 consulting_

Re: DNSSEC

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

On Nov 24, 2010, at 4:37 AM, mod63 wrote:

> Brian Wellington wrote:
>> 
>> On Nov 23, 2010, at 1:50 AM, mod63 wrote:
>> 
>>> Brian Wellington wrote:
>>>> 
>>>> 
>>>> On Nov 22, 2010, at 5:04 AM, mod63 wrote:
>>>> 
>>>>> 
>>>>> Hi there,
>>>>> 
>>>>> I’m currently working on a project that requires DNSSEC, the current
>>>>> situation is basically that I get a request from a client and based on
>>>>> that
>>>>> I generate a response i.e. Message object and send it of to the client,
>>>>> very
>>>>> basic stuff, the problem is I need to add DNSSEC to that, and that’s
>>>>> where
>>>>> I’m currently stuck.
>>>>> 
>>>>> I couldn’t find any good resources about the subject and the
>>>>> explanation
>>>>> in
>>>>> the dnsjava documentation wasn’t adequate
>>>>> 
>>>>> Any help would be appreciated; I need to resolve this problem as
>>>>> quickly
>>>>> as
>>>>> possible.
>>>> 
>>>> If you want to write a DNSSEC-compliant name server, there is no
>>>> resource
>>>> better than the DNSSEC RFCs.  There are a whole lot of them, but the
>>>> important ones are probably 4034 and 4035.
>>>> 
>>>> You're not going to find much in the dnsjava documentation, as dnsjava
>>>> doesn't include a DNSSEC-compliant name server.  I think the library is
>>>> complete enough that one could be written, but it definitely would not
>>>> be
>>>> trivial, and would likely take a considerable amount of time.
>>> 
>>> Thank you for the fast reply.
>>> 
>>> The javadns documentation for version 2.1.0 contains additional methods
>>> not
>>> mentions in the online documentation such as the DNSSEC.sign() method
>>> which
>>> returns a RRSIGRecord, could you please clarify this, whats the state of
>>> the
>>> implementation?can it be used or modified?
>> 
>> The online documentation was outdated; I just updated it to point at the
>> current release.
>> 
>> The implementation is complete (to the best of my knowledge), but as David
>> said, the implementation only contains the low-level routines needed to
>> build an authoritative server with DNSSEC support.
>> 
>> Brian
> 
> I got a little bit confused by your responses so hers what we’ve done so far
> 
> We have a Message object which is the response we are sending back to the
> client; we need to add DNSSEC to it.
> 
> DNSSEC
> 1) Initialize all the values needed to create a RRSIGRecord(name, algorithm,
> ttl  ,etc).
> 
> 3) Read a private key from a file and generate PrivateKey object
> 
> 4) Read a public  key from a file and generate  PublicKey object
> 
> 4) Create a DNSKEYRecord object using the public key.
> 
> 5) Create RRset object from the response Record used for signing.
> 
> 6) Generate the response RRSIGRecord using the DNSSEC.sign() method which
> takes all the objects created in previous steps.
> 
> 
> ADDING DNSSEC TO THE RESPONSE 
> 1) Create a Record containing all the modified information that is needed by
> the client.
> 
> 2) Add the Record from the previous step into the messages ANSWER section.
> 
> 3) Add the RRSIGRecord into the messages ANSWER section.
> 
> 4) Send it to the client.

I believe this will work, but only in a very limited situation where all queries have a simple, positive answer and performance is not an issue.

Brian

Re: DNSSEC

[mod63 <mod...@gm...>]

Brian Wellington wrote:
> 
> On Nov 23, 2010, at 1:50 AM, mod63 wrote:
> 
>> Brian Wellington wrote:
>>> 
>>> 
>>> On Nov 22, 2010, at 5:04 AM, mod63 wrote:
>>> 
>>>> 
>>>> Hi there,
>>>> 
>>>> I’m currently working on a project that requires DNSSEC, the current
>>>> situation is basically that I get a request from a client and based on
>>>> that
>>>> I generate a response i.e. Message object and send it of to the client,
>>>> very
>>>> basic stuff, the problem is I need to add DNSSEC to that, and that’s
>>>> where
>>>> I’m currently stuck.
>>>> 
>>>> I couldn’t find any good resources about the subject and the
>>>> explanation
>>>> in
>>>> the dnsjava documentation wasn’t adequate
>>>> 
>>>> Any help would be appreciated; I need to resolve this problem as
>>>> quickly
>>>> as
>>>> possible.
>>> 
>>> If you want to write a DNSSEC-compliant name server, there is no
>>> resource
>>> better than the DNSSEC RFCs.  There are a whole lot of them, but the
>>> important ones are probably 4034 and 4035.
>>> 
>>> You're not going to find much in the dnsjava documentation, as dnsjava
>>> doesn't include a DNSSEC-compliant name server.  I think the library is
>>> complete enough that one could be written, but it definitely would not
>>> be
>>> trivial, and would likely take a considerable amount of time.
>> 
>> Thank you for the fast reply.
>> 
>> The javadns documentation for version 2.1.0 contains additional methods
>> not
>> mentions in the online documentation such as the DNSSEC.sign() method
>> which
>> returns a RRSIGRecord, could you please clarify this, whats the state of
>> the
>> implementation?can it be used or modified?
> 
> The online documentation was outdated; I just updated it to point at the
> current release.
> 
> The implementation is complete (to the best of my knowledge), but as David
> said, the implementation only contains the low-level routines needed to
> build an authoritative server with DNSSEC support.
> 
> Brian
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> dnsjava-users mailing list
> dns...@li...
> https://lists.sourceforge.net/lists/listinfo/dnsjava-users
> 
> 

I got a little bit confused by your responses so hers what we’ve done so far

We have a Message object which is the response we are sending back to the
client; we need to add DNSSEC to it.

DNSSEC
1) Initialize all the values needed to create a RRSIGRecord(name, algorithm,
ttl  ,etc).

3) Read a private key from a file and generate PrivateKey object

4) Read a public  key from a file and generate  PublicKey object

4) Create a DNSKEYRecord object using the public key.

5) Create RRset object from the response Record used for signing.

6) Generate the response RRSIGRecord using the DNSSEC.sign() method which
takes all the objects created in previous steps.


ADDING DNSSEC TO THE RESPONSE 
1) Create a Record containing all the modified information that is needed by
the client.

2) Add the Record from the previous step into the messages ANSWER section.

3) Add the RRSIGRecord into the messages ANSWER section.

4) Send it to the client.






-- 
View this message in context: http://old.nabble.com/DNSSEC-tp30278312p30296449.html
Sent from the dnsjava-users mailing list archive at Nabble.com.

Re: DNSSEC

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

On Nov 23, 2010, at 1:50 AM, mod63 wrote:

> Brian Wellington wrote:
>> 
>> 
>> On Nov 22, 2010, at 5:04 AM, mod63 wrote:
>> 
>>> 
>>> Hi there,
>>> 
>>> I’m currently working on a project that requires DNSSEC, the current
>>> situation is basically that I get a request from a client and based on
>>> that
>>> I generate a response i.e. Message object and send it of to the client,
>>> very
>>> basic stuff, the problem is I need to add DNSSEC to that, and that’s
>>> where
>>> I’m currently stuck.
>>> 
>>> I couldn’t find any good resources about the subject and the explanation
>>> in
>>> the dnsjava documentation wasn’t adequate
>>> 
>>> Any help would be appreciated; I need to resolve this problem as quickly
>>> as
>>> possible.
>> 
>> If you want to write a DNSSEC-compliant name server, there is no resource
>> better than the DNSSEC RFCs.  There are a whole lot of them, but the
>> important ones are probably 4034 and 4035.
>> 
>> You're not going to find much in the dnsjava documentation, as dnsjava
>> doesn't include a DNSSEC-compliant name server.  I think the library is
>> complete enough that one could be written, but it definitely would not be
>> trivial, and would likely take a considerable amount of time.
> 
> Thank you for the fast reply.
> 
> The javadns documentation for version 2.1.0 contains additional methods not
> mentions in the online documentation such as the DNSSEC.sign() method which
> returns a RRSIGRecord, could you please clarify this, whats the state of the
> implementation?can it be used or modified?

The online documentation was outdated; I just updated it to point at the current release.

The implementation is complete (to the best of my knowledge), but as David said, the implementation only contains the low-level routines needed to build an authoritative server with DNSSEC support.

Brian

Re: DNSSEC

[David B. <da...@ve...>]

On Nov 23, 2010, at 4:50 AM, mod63 wrote:
> 
> Thank you for the fast reply.
> 
> The javadns documentation for version 2.1.0 contains additional methods not
> mentions in the online documentation such as the DNSSEC.sign() method which
> returns a RRSIGRecord, could you please clarify this, whats the state of the
> implementation?can it be used or modified?

I think what Brian is trying to say is that "adding DNSSEC" to existing DNS software is a non-trivial exercise.  It isn't (nearly) enough just to call DNSSEC.sign().

DNSJava does contain the building blocks for creating (say) a DNSSEC-enabled authoritative DNS server.  But it only contains a set of record types and useful, but low-level, signing  and verification routines.

--
David Blacka                          <da...@ve...> 
Principal Engineer    VeriSign Platform Product Development

Re: DNSSEC

[mod63 <mod...@gm...>]

Brian Wellington wrote:
> 
> 
> On Nov 22, 2010, at 5:04 AM, mod63 wrote:
> 
>> 
>> Hi there,
>> 
>> I’m currently working on a project that requires DNSSEC, the current
>> situation is basically that I get a request from a client and based on
>> that
>> I generate a response i.e. Message object and send it of to the client,
>> very
>> basic stuff, the problem is I need to add DNSSEC to that, and that’s
>> where
>> I’m currently stuck.
>> 
>> I couldn’t find any good resources about the subject and the explanation
>> in
>> the dnsjava documentation wasn’t adequate
>> 
>> Any help would be appreciated; I need to resolve this problem as quickly
>> as
>> possible.
> 
> If you want to write a DNSSEC-compliant name server, there is no resource
> better than the DNSSEC RFCs.  There are a whole lot of them, but the
> important ones are probably 4034 and 4035.
> 
> You're not going to find much in the dnsjava documentation, as dnsjava
> doesn't include a DNSSEC-compliant name server.  I think the library is
> complete enough that one could be written, but it definitely would not be
> trivial, and would likely take a considerable amount of time.
> 
> Brian
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> dnsjava-users mailing list
> dns...@li...
> https://lists.sourceforge.net/lists/listinfo/dnsjava-users
> 
> 


Thank you for the fast reply.

The javadns documentation for version 2.1.0 contains additional methods not
mentions in the online documentation such as the DNSSEC.sign() method which
returns a RRSIGRecord, could you please clarify this, whats the state of the
implementation?can it be used or modified?

-- 
View this message in context: http://old.nabble.com/DNSSEC-tp30278312p30283787.html
Sent from the dnsjava-users mailing list archive at Nabble.com.

Re: DNSSEC

[mod63 <mod...@gm...>]

Brian Wellington wrote:
> 
> 
> On Nov 22, 2010, at 5:04 AM, mod63 wrote:
> 
>> 
>> Hi there,
>> 
>> I’m currently working on a project that requires DNSSEC, the current
>> situation is basically that I get a request from a client and based on
>> that
>> I generate a response i.e. Message object and send it of to the client,
>> very
>> basic stuff, the problem is I need to add DNSSEC to that, and that’s
>> where
>> I’m currently stuck.
>> 
>> I couldn’t find any good resources about the subject and the explanation
>> in
>> the dnsjava documentation wasn’t adequate
>> 
>> Any help would be appreciated; I need to resolve this problem as quickly
>> as
>> possible.
> 
> If you want to write a DNSSEC-compliant name server, there is no resource
> better than the DNSSEC RFCs.  There are a whole lot of them, but the
> important ones are probably 4034 and 4035.
> 
> You're not going to find much in the dnsjava documentation, as dnsjava
> doesn't include a DNSSEC-compliant name server.  I think the library is
> complete enough that one could be written, but it definitely would not be
> trivial, and would likely take a considerable amount of time.
> 
> Brian
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> dnsjava-users mailing list
> dns...@li...
> https://lists.sourceforge.net/lists/listinfo/dnsjava-users
> 
> 


Thank you for the fast reply.

The javadns documentation for version 2.1.0 contains additional methods not
mentions in the online documentation such as the DNSSEC.sign() method which
returns a RRSIGRecord, could you please clarify this, whats the state of the
implementation?can it be used or modified?
-- 
View this message in context: http://old.nabble.com/DNSSEC-tp30278312p30283784.html
Sent from the dnsjava-users mailing list archive at Nabble.com.