Maintained by: NLnet Labs

[Unbound-users] TCP and/or UDP used by resolver?

Patrik Fältström
Thu Aug 25 20:45:04 CEST 2011


On 25 aug 2011, at 20.41, Paul Wouters wrote:

> On Thu, 25 Aug 2011, Patrik Fältström wrote:
> 
>> On 25 aug 2011, at 17:52, Paul Wouters wrote:
>> 
>>> I think the easiest is to configure multiple unbound instances. One with defaults, one with do-tcp:no
>>> 
>>> In svn there is also the tcp-upstream:yes|no option that controls if tcp can be used by the resolver to obtain data (as opposed to the client method of accessing unbound itself)
>> 
>> Hmm...I am using pyldns as a stub resolver, so what you suggest is not really helping.
> 
> have a look at http://git.xelerance.com/cgi-bin/gitweb.cgi?p=ldnsx.git;a=summary

Will check.

> If there is functionality you need exposed, Chris will be able to implement them for you.
> 
> I know he has usage cases where he sets TCP specifically. Though then you're not using unbound
> (or its cache), as the client cannot tell the server how it should fetch results. And even if
> we'd add such a flag, how would you deal with cached data?

I am caching data myself.

> If you are trying to figure out TCP or EDNS connectivity, you cannot really go through an
> intermediate resolver (unless you're just testing this specific last mile resolver)

I do not go via an intermediate resolver. I issue queries directly towards the server I want to check.

> If you can tell us a bit more, perhaps we can help you, as we're doing similar things with
> ldnsx on top of ldns-python.

See http://dnscheck.se/

That is written in perl, and not really up to date, and there are some bugs, but the perl code is so hairy that it is not fun anymore.

So I am working on a more modular library to use in Python, and to do that, I want a very stable and effective subclass of resolver that can do what I need. Like issuing queries over UDP or TCP etc...

Specifically, I want to force queries over TCP. And then for example force queries over UDP with specific size of payload and other fun stuff (no fallback to TCP).

The alternative is of course that I send the packets myself, but...that is not fun, and I was hoping I did not have to do everything myself, but instead subclass the pyldns classes.

   Patrik