Specific configuration can still crash dnschain 0.1.1 about dnschain HOT 6 CLOSED

Yep, that's a good catch. Will have a look into this! Thanks!

from dnschain.

What do you think the behavior should be here (because it's not clear to me)?

I understand that it shouldn't have the exception, but if the info in the blockchain wants you to connect to regular DNS, shouldn't it be allowed to? Or do you want oldDNSMethod=2 to mean that even in this instance the answer will be refused?

from dnschain.

There are 2 things here I think. One is that regardless of functionality decisions, dnschain will crash on timeout to oldDNS servers.

The other is what it should be doing. My original intent was to refuse non blockchain queries. This is because I have unbound doing that on another server and I want to manage that on one box only. So this was just a request to be able to make sure dnschain only does that.

However it wouldn't make much sense to refuse connecting to regular DNS when blockchain says you should. For example: dns.dot-bit.org (178.32.31.41) would connect and that makes sense, because this would render dnschain only capable of resolving some domain names. Unless it is possible to craft a DNS response to say: domain.bit is hosted by these 2 name servers, go ask them, I can't. That way my unbound server would respect it and go fetch those names for the client and you wouldn't have to implement other records MX, AAAA, TXT, etc:

                         .------[ask NS for AAAA,MX,TXT]
                         |
client ---> .... ---> Unbound ---> [.bit] ---> dnschain --> blockchain
                         ^                       |
                         |---------go ask NS-----.

So oldDNSMethod=2 could be an option to say:

• Although I will perform query resolution if blockchain delegates to, I will not, if the original query is for regular DNS.
• or (if it is possible): I do not talk to regular DNS at all so direct .bit mappings I can do, and if there are delegations, you have to ask the following NS:...

Both solutions are fine for me.
I also realize I probably might be one of the few users thinking of this, so if this is too much, ignore me :-)

from dnschain.

@pysiak, you grace our Issue's page with your beautiful ASCII-art, and for that I thank you. ^_^

That's the beautify of options though: it's not difficult to support both of the possibilities you list. Someone might want to prohibit canonical DNS completely, or allow it only if the blockchain says "go fetch!".

In the latter case, the IP listed in dns.oldDNS.address will be used to do the lookup.

Also, for the options, I think string values might be better than numerical values, what do you think? We can support both for a while (deprecating the numerical ones).

from dnschain.

Cool, you're welcome!

That's true, you can cater for various scenarios and often the power of the software is in versatility.

I'd give +1 to string values.

Anyway, something causes dnschain not to handle a timeout well. I think that should generate a SERVFAIL back.

from dnschain.

In 0.2, you can now do this:

[dns]
oldDNSMethod = NO_OLD_DNS_EVER

Note that NO_OLD_DNS is also supported (allow resolution if blockchain says to). Using the numerical values is deprecated now.

Also fixed the timeout crash. :)

from dnschain.