Re: per-zone-recursion?
On Mon, Oct 04, 2010 at 11:30:03AM +0200, Kalman Feher wrote: probably it was not thought because it's wrong. This point is getting religious now, IMHO. Bear in mind that your rationale is based on getting an inaccessible DNS server to return information that a client has correctly asked for. I can't imagine a situation where there'll be a strong desire to codify that kind of set up. If your DNS server is not accessible to clients that need to query it for data, your set up is wrong. That isn't religious, that is practical reality. I was more with with lack of arguments or explanations. So thank you for writing a few words about it. I am completely with you for all practical aspects. However, I am still surprised that reverse-proxy-functionality causes that much irritation. For other protocols, esp. in the days of NAT, it is common practice, although most likely still not a clean design. less palatable option: 1. Make the other DNS software available on another IP. So normal DNS behaviour works. Hm, this is not too easy in practice, but of course optimal solution. IPv6 will help here, I hope. I don't think this will solve the problem, it will just be a workaround for it. With IPv6, I see much better chances of having more than one address available, which would make the best architectural solution a practical one as well. I think you need to consider your architectural design in a different light. Address availability is not your problem. Your solution seems to be a work around built on a work around. Ask yourself: am I using DNS to fix a problem or shortcoming in another system?. If yes, fix the other system instead. Yes, this a fix for undesired behaviour of another system, if you want to put it like this. Unfortunately, the other system is out of influence. I was wondering if there is an easy support in bind for this kind of situation. Obviously, there is none. No problem with that. It is a cornercase, and, as you (and others) pointed out, not a clean design anyway. At least, I appreciate the clear view how things should be. If you think it is abuse the transport real-time data with DNS, I am ok with that. Maybe studying the sources helps me for practical matters. To be more accurate, the reasons people think they need a TTL of 0 indicate they are using DNS incorrectly. Often it is an attempt at working around the restrictions of other systems. Hence the guess at load balancing. What data are you providing that changes second to second and must be provided using DNS? I am thinking of situations where no real connectivity is available but just DNS, and am currently trying to find out how well bind combines with anything-over-dns implementations. Hence the separate server software. Bye, Joerg ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone-recursion?
On 1/10/10 9:15 AM, Joerg Dorchain jo...@dorchain.net wrote:
On Thu, Sep 30, 2010 at 07:13:11PM -0400, Kevin Darcy wrote:
Per-zone recursion control doesn't exist in BIND, because frankly it
doesn't make sense.
I used to think that, too, until I came to my specific problem.
Either a zone type is meaningless *without* recursion (type forward,
type stub), or recursion is *unnecessary* because the nameserver
answers from authoritative data (type master, type slave).
Exactly. Up to here I completely agree.
Put another way, have you thought through exactly what you want to
happen if a client queries something not specifically carved out for
recursion, e.g. isc.org?
Yes. To explain my setup further, there is a view based on
src-IPs for some clients, where recursion is turned on.
The rest of the world gets non-recursive answers, e.g. with
authoritative data, or refused.
In case of that specfic forward zone, bind answers in the
non-recursive case with a referal to itself (there is only one
public IP), which is causing a loop, as there is no way to
specify a different port in the DNS protocol (AFAIK)
This is the problem and the reason I agree with Kevin. The referral is
correct behaviour. Your DNS set up is wrong. You have 2 choices and a third
less palatable option:
1. Make the other DNS software available on another IP. So normal DNS
behaviour works.
2. Add the zone as a slave within your authoritative view. (this option may
be the easiest for your situation).
3. recursive view with forwards to both your authoritative view and the
dynamic subdomain. I think this solution is silly and will be problematic to
maintain, but its likely to suite your needs exactly.
The response from a BIND instance, when recursion is denied or not
requested, is always either (as per Section 4.3.1 of RFC 1034):
a) an answer from authoritative data,
b) an answer from cache
c) a negative-caching response,
d) a (0 answers) referral, or
e) some sort of non-response, like an error (SERVFAIL) or an
administrative rejection of the query (REFUSED)
If (a) doesn't apply (because not authoritative) and neither does
(b) (because how can answers be cached in the first place if
recursion is being denied?), that leaves (c) through (e), none of
which are particularly useful to the client. So you might as well
REFUSE queries outside of zones for which recursion is not
explicitly enabled. Configure allow-query { none; }; as the
default followed by specific exceptions for the zones you want to
open up, e.g., dynsup.example.net.
You have summarized my thoughts very well. At this point I found
out that the current grammar for bind does not allow to combine
type forward; with an allow-query (or allow-recursion).
A quick look at the sources also showed that forward zones are
implemented differently than real zones like master or slave.
This way I came to the point where I am wondering if it is
possible to configure bind either
- do recursion on a per-zone base for forward zones, as the
currently implemented criteria (src-ip, dst-ip, recursion flag)
do not cover my case in an obvious way
- forward queries to a specific destination and the answers back,
acting as a reverse-proxy without too much intelligence.
Bye,
Joerg
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Kal Feher
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone-recursion?
On Fri, Oct 01, 2010 at 11:25:31AM +0200, Kalman Feher wrote: Yes. To explain my setup further, there is a view based on src-IPs for some clients, where recursion is turned on. The rest of the world gets non-recursive answers, e.g. with authoritative data, or refused. In case of that specfic forward zone, bind answers in the non-recursive case with a referal to itself (there is only one public IP), which is causing a loop, as there is no way to specify a different port in the DNS protocol (AFAIK) This is the problem and the reason I agree with Kevin. The referral is correct behaviour. Your DNS set up is wrong. You have 2 choices and a third Well, I could agree agree that wrong means not thought of by RfC-Designers and bind implementators (yet). less palatable option: 1. Make the other DNS software available on another IP. So normal DNS behaviour works. Hm, this is not too easy in practice, but of course optimal solution. IPv6 will help here, I hope. 2. Add the zone as a slave within your authoritative view. (this option may be the easiest for your situation). Not feasible as it contains dynamically generated content, typically with a TTL of 0. 3. recursive view with forwards to both your authoritative view and the dynamic subdomain. I think this solution is silly and will be problematic to maintain, but its likely to suite your needs exactly. Hm, I have to think about that. As said, I do not want to give recursive answers to the whole world. It sounds like a hack, though. The more I am into the problem, the more I come to the point where I like to have some sort of query switch, i.e. something that redirects queries for a certain domain to one address, and other queries to other servers. It would be great if it would be part of bind. Bye, Joerg signature.asc Description: Digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone-recursion?
Yes. To explain my setup further, there is a view based on src-IPs for some clients, where recursion is turned on. The rest of the world gets non-recursive answers, e.g. with authoritative data, or refused. In case of that specfic forward zone, bind answers in the non-recursive case with a referal to itself (there is only one public IP), which is causing a loop, as there is no way to specify a different port in the DNS protocol (AFAIK) On Fri, Oct 01, 2010 at 11:25:31AM +0200, Kalman Feher wrote: This is the problem and the reason I agree with Kevin. The referral is correct behaviour. Your DNS set up is wrong. You have 2 choices and a third On 01.10.10 12:39, Joerg Dorchain wrote: Well, I could agree agree that wrong means not thought of by RfC-Designers and bind implementators (yet). probably it was not thought because it's wrong. less palatable option: 1. Make the other DNS software available on another IP. So normal DNS behaviour works. Hm, this is not too easy in practice, but of course optimal solution. IPv6 will help here, I hope. I don't think this will solve the problem, it will just be a workaround for it. 2. Add the zone as a slave within your authoritative view. (this option may be the easiest for your situation). Not feasible as it contains dynamically generated content, typically with a TTL of 0. this strongly indicates that there's something broken in your DNS. The DNS is not designed to provide anything that short-lived, the whole DNS architecture is based on cachind. Are you doing any kind of DNS-based load balancing? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Enter any 12-digit prime number to continue. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone-recursion?
On Fri, Oct 01, 2010 at 05:39:16PM +0200, Matus UHLAR - fantomas wrote: On 01.10.10 12:39, Joerg Dorchain wrote: Well, I could agree agree that wrong means not thought of by RfC-Designers and bind implementators (yet). probably it was not thought because it's wrong. This point is getting religious now, IMHO. less palatable option: 1. Make the other DNS software available on another IP. So normal DNS behaviour works. Hm, this is not too easy in practice, but of course optimal solution. IPv6 will help here, I hope. I don't think this will solve the problem, it will just be a workaround for it. With IPv6, I see much better chances of having more than one address available, which would make the best architectural solution a practical one as well. 2. Add the zone as a slave within your authoritative view. (this option may be the easiest for your situation). Not feasible as it contains dynamically generated content, typically with a TTL of 0. this strongly indicates that there's something broken in your DNS. The DNS is not designed to provide anything that short-lived, the whole DNS architecture is based on cachind. Yes, DNS works best with caching. I know that this setup is a corner case and very individual (If would had two public IPs then I would be fine) To be a bit polemic, if you think it is wrong, TTL of 0 should be forbidden, I suppose. Are you doing any kind of DNS-based load balancing? No, then multiple A records or so would be just fine. Bye, Joerg signature.asc Description: Digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
per-zone-recursion?
Hello,
I am puzzled with a bind config for a kind of dns-reverse-proxy situation.
I have a server with only one public IP addresse, bind running on
port 53 of it.
This bind serves examples.net. A subdomain dynsub.example.net
should be served on some other software answering DNS request
with dynamically generated answers.
I can create a forward zone like this
zone dynsup.example.net {
type forward;
forward only;
forwarders { 127.0.0.1 port 5353; };
};
which works fine in the way that it forwards all queries to and
all answers from the other DNS software running on port 5353, but
- this is problem - only if the view with the statement allows
recursion.
For several reasons I do not want to answer all queries for all
domains recursivly, just those for that one zone.
When I turn recursion off, bind answers with a referal to itself
(glue records work ;-), which in this case is not helpful.
Does anybody have an idea on how I can persuade bind to answer
only this zone recusivly?
TIA,
Joerg
signature.asc
Description: Digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone-recursion?
Per-zone recursion control doesn't exist in BIND, because frankly it
doesn't make sense.
Either a zone type is meaningless *without* recursion (type forward,
type stub), or recursion is *unnecessary* because the nameserver answers
from authoritative data (type master, type slave).
Put another way, have you thought through exactly what you want to
happen if a client queries something not specifically carved out for
recursion, e.g. isc.org?
The response from a BIND instance, when recursion is denied or not
requested, is always either (as per Section 4.3.1 of RFC 1034):
a) an answer from authoritative data,
b) an answer from cache
c) a negative-caching response,
d) a (0 answers) referral, or
e) some sort of non-response, like an error (SERVFAIL) or an
administrative rejection of the query (REFUSED)
If (a) doesn't apply (because not authoritative) and neither does (b)
(because how can answers be cached in the first place if recursion is
being denied?), that leaves (c) through (e), none of which are
particularly useful to the client. So you might as well REFUSE queries
outside of zones for which recursion is not explicitly enabled.
Configure allow-query { none; }; as the default followed by specific
exceptions for the zones you want to open up, e.g., dynsup.example.net.
- Kevin
On 9/30/2010 5:09 AM, Joerg Dorchain wrote:
Hello,
I am puzzled with a bind config for a kind of dns-reverse-proxy situation.
I have a server with only one public IP addresse, bind running on
port 53 of it.
This bind serves examples.net. A subdomain dynsub.example.net
should be served on some other software answering DNS request
with dynamically generated answers.
I can create a forward zone like this
zone dynsup.example.net {
type forward;
forward only;
forwarders { 127.0.0.1 port 5353; };
};
which works fine in the way that it forwards all queries to and
all answers from the other DNS software running on port 5353, but
- this is problem - only if the view with the statement allows
recursion.
For several reasons I do not want to answer all queries for all
domains recursivly, just those for that one zone.
When I turn recursion off, bind answers with a referal to itself
(glue records work ;-), which in this case is not helpful.
Does anybody have an idea on how I can persuade bind to answer
only this zone recusivly?
TIA,
Joerg
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
