Handle ANY requests correctly. #7
Conversation
| This looks good, but can you explain to me a bit more about the typical use-case? |
| That's pretty simple... :) Let's say you just try to run the example at As you can see, you won't get any reply from the server. This because it's trying to match the resource class ANY against the rule class. But, instead, you should skip the resource class at all. The only problem I saw is in Transaction#respond!. With a ANY query you don't have a good default for Hope my explanation is useful. |
| Right, so you'd like to include a special treatment of Semantically, I'm assuming that |
| Yes, a ANY record should return any record that matchs (A, CNAME etc) (as stated here). So we shouldn't require the user to write a specific rule for that. |
| Do you think this is a good default behaviour, maybe we should make it an option that can be switched on or off, it sounds like the type of record that could be exploited easily. Already, one can specify multiple RR types for a given block that will match, if the user intends for this behaviour wouldn't it be better to specify it explicitly? If it was on by default, how about if the user didn't want that behaviour by default, how would they switch it off? Finally, the default behaviour for all existing RubyDNS scripts would be changed by the above patch. Do you think this is a problem? |
| Probably you're right... this could lead to exploits and to user confusion. Additionally, when it is a ANY request or a ANY response, I also set |
| Some modification are still pending. Please wait for a next commit. |
| Keep in mind that in the patch you are referring to IN::ANY, yet there are a variety of resource classes other than IN, it seems like a more generic approach would be better? Not that classes other than IN are very practical these days.. Just wondering if there is some way to keep the main pattern matching simple and with some extra option to handle the ANY case. Keep in mind that the more complex the pattern matching code, the harder it is to maintain and use. |
| Ok, all commit are there now. The request is ready. What do you mean by "other classes than IN"? ANY is the only class which acts as wildcard, AFAIK. |
| While it is highly unlikely, there are more than one kind of address class. IN::A is an internet address, but there are other address class e.g. CHAOS for chaos network names. http://www.miek.nl/s/2f9a7850f8/ In this case, the patch includes a hard-coded reference IN::ANY, yet DNS has lots of different resource classes. It isn't impossible to imagine that someone would use RubyDNS for a real mashup - that is kind of the point, it isn't your average DNS server - you can do all sorts of whacky things with it. I will review the patch when I have a moment. |
| Ok, I'll take a look to all address classes |
| I think what you've done so far looks really good. Here is the crux of the issue as I see it. What you want to do is basically have all handlers match against IN::ANY or even ANY, in addition to the original resource record type. Essentially what this looks like is: So for each rule you simply allow it to match The main case for matching multiple resource record types is if you are passing the request upstream. For example, you might want to pass all requests to In order to process When responding to Perhaps we need to write: I think I need to think about this problem a bit more. |
| Ok, but for your last concern I suggest you to leave it to the user. He should make the decision of which class return to the user. |
| There is one other option, to have an explicit clause to match |
| Good idea... I'll take a look to a possible implementation... |
| Ok, I followed your suggestion and simply make the server process a rule for every type in case of ANY requests. |
| Hi ShogunPanda - thanks for all the effort you put into this. In the end I think it is best that the RubyDNS transaction resolver is kept as simple as possible. To clarify, the goal of RubyDNS is to be a programmable DNS domain specific language, without making any assumptions about what you might want to do with that. I've released RubyDNS 0.4.1 which shows how to implement ANY requests with a minimum of changes and a large degree of flexibility, I believe this should meet your requirements efficiently. I hope this is sufficient for your needs - please let me know how you get on. Again, thanks for all your effort and do let me know if you have any more ideas. Kind regards, |
| Please checkout the example1.rb file which shows the code required =) |
| Ok, I implemented it following your suggestion. If you'd like to check the results, they are here: http://github.com/ShogunPanda/devdnsd. |
| Looks good - that project looks interesting, thanks for sharing it with me. |
2 participants
Currently the server respond only to a rule explicitilly configured for ANY RR requests.
Instead, in case of ANY requests, it should completely skip resource class matching.