TCP and/or UDP used by resolver?

Unbound
1

Hi, I use the pylons package and see that one can set the transport mechanism via the set_usevc call. The argument is boolean and one set whether a virtual circuit can be used or not. What makes me confused is that I feel such a value should have three states: UDP/TCP with fallback, UDP only and TCP only.

I read the manual as if this (when true) uses TCP only, but if false uses UDP with fallback to TCP.

Or is the value to use UDP with fallback to TCP, but UDP only if false?

Can someone help with interpretation please?

   Patrik

P.S. In my code that test DNS I want to be able to set whether UDP or TCP is in use, with no fallback, but then I also have "normal" queries that can use whatever works (and I do not care what was used).

P.P.S. This is my part of the testing of pylons with Python3 and so far it works!

2

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)

Paul

3

Hmm...I am using pyldns as a stub resolver, so what you suggest is not really helping.

   Patrik

4

have a look at http://git.xelerance.com/cgi-bin/gitweb.cgi?p=ldnsx.git;a=summary

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?

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)

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.

Paul

5

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

6

Why exactly?

Probably of no help but OpenBSD has a resolv.conf option to only use
TCP. Maybe you could hack OpenBSD to conditionally do what you want or
hack a DNS perl module.

7

Yes, I like ldnsx...

Thanks for the pointers. Makes my life easier :wink:

   Patrik