Unbound wrapper in Go

Unbound
1

Hello,

I've created a little wrapper so that you can use libunbound from within
Go code (www.golang.org). See: https://github.com/miekg/unbound

I noticed two (small) things though, if I use/convert an ub_result->answer_packet
the message-id in the message 0. Is this on purpose or do I screw up somewhere?

Another thing is that there is no TTL in ub_result, also on purpose I presume?

Regards,

2

Hi Miek,

Hello,

I've created a little wrapper so that you can use libunbound from
within Go code (www.golang.org). See:
https://github.com/miekg/unbound

:slight_smile:

I noticed two (small) things though, if I use/convert an
ub_result->answer_packet the message-id in the message 0. Is this
on purpose or do I screw up somewhere?

Yes, on purpose, since this reply is from a unix-pipe, the ID field
does not have to be used.

Another thing is that there is no TTL in ub_result, also on purpose
I presume?

There is in the answer packet, TTL per resource record even. A TTL
field could be added to the ub_result, but would break ABI, even
though it is not that interesting for most users (and power users can
parse the answer_packet).

Best regards,
   Wouter

3

[ Quoting <wouter@nlnetlabs.nl> in "Re: [Unbound-users] unbound wrapper..." ]

> ub_result->answer_packet the message-id in the message 0. Is this
> on purpose or do I screw up somewhere?

Yes, on purpose, since this reply is from a unix-pipe, the ID field
does not have to be used.

Ok.

> Another thing is that there is no TTL in ub_result, also on purpose
> I presume?

There is in the answer packet, TTL per resource record even. A TTL
field could be added to the ub_result, but would break ABI, even
though it is not that interesting for most users (and power users can
parse the answer_packet).

Ok, that makes sense. Thanks for your reply.

Regards,

4

I thought that DNS responses do not have to come in the same order as
requests, even over stream connections.

Tony.

5

Hi Tony,

Yes, on purpose, since this reply is from a unix-pipe, the ID
field does not have to be used.

I thought that DNS responses do not have to come in the same order
as requests, even over stream connections.

Actually, stream responses could be like that, but I would not know
how backwards compatible with the deployed software that would be.
Unbound serves stream responses in the order they have been queried
for that reason.

This reply we talk about here is an internal pipe in the
implementation of libunbound, and another field is used to
disambiguate it (libunbound could support more than 64k concurrent
queries, therefore it does not use the 16bit ID value).

Best regards,
   Wouter

6

That’s certainly true over the wire.

<http://tools.ietf.org/html/rfc5966#section-6>

Ray

7

Thanks for that link - I forgot that RFC existed!

Tony.