RE: does zone trump forward?
I wasn't trying to start a fight. Perhaps I didn't provide enough detail. We have 2843 authoritative zones. We run a split brain DNS. The new hospitals and other entities need to see our internal zone view once they have joined. So I have them forward queries during the early stages of the merger, until I can get control of their DNS and make appropriate changes. There are fatherhood issues and all manner of ego problems involved in absorbing someone else's DNS. This step provides a workable solution in the very first stages. Then I make them slaves, with a reasonable expire time, to give them a copy of the data locally. As for the distinction between forwarding and recursion, I used the term forwarding to describe him sending queries for my internal zones to me, thereby ensuring he sees the internal presentation of the data. I used the term recursion to describe his DNS doing recursion for all names and IPs that were not owned by either of us. This allows his users to look up all of his data, and all other data on earth except mine, no matter what happens with the cup-and-string circuit. Then, once the fiber is turned up, we do a proper merge. Sorry to have ruffled Kevin's feathers. Just trying to describe a behavior in response to a question from the field. I was certainly not recommending a configuration. Not everyone has to deal with these issues in a clinical environment. I do. Alan From: bind-users-bounces+ashackel=jhmi@lists.isc.org [mailto:bind-users-bounces+ashackel=jhmi@lists.isc.org] On Behalf Of Kevin Darcy Sent: Monday, June 03, 2013 3:40 PM To: bind-users@lists.isc.org Subject: Re: does zone trump forward? Why would you use forwarding over links that are neither fat nor reliable? Are you a masochist? Replication of the data is much recommended over such links... As for your pecking order, what distinction are you drawing between forwarding and recursion? Forwarding is recursive. The high-level distinction is between having the data authoritative locally and not having it authoritative locally. If you want to make a finer distinction within the not-locally-authoritative case, then make the distinction between recursive (e.g. forwarding) and iterative (e.g. stub, or delegation from an internal root zone). - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: does zone trump forward?
I agree with Len. Whenever we merge a new location into our network, and the
circuit is neither fat nor reliable, I make their DNS forward queries for our
internal zones to us, keep authority for their own zones, and do recursion for
everything else. This allows us to serve the users as we slowly homogenize the
whole mess. The pecking order seems to be authoritative first, forward
second, and recursion last.
Alan
Alan V. Shackelford Senior Systems Software Engineer
The Johns Hopkins University and Johns Hopkins Medical Institutions
Baltimore, Maryland USA ashac...@jhmi.edumailto:ashac...@jhmi.edu
410-735-4773
From: bind-users-bounces+ashackel=jhmi@lists.isc.org
[mailto:bind-users-bounces+ashackel=jhmi@lists.isc.org] On Behalf Of
Leonard Mills
Sent: Sunday, June 02, 2013 3:29 PM
To: Jonathan Reed; bind-users
Subject: Re: does zone trump forward?
As I understand AUTHORITATIVE trumps anything. For example, from an inside
intranet name server forward the root (.) to somewhere on your edge, sprinkle
in a few internal-only authoritative zones, and enjoy. This is certainly not
the only choice, but it functions pretty well.
Len
From: Jonathan Reed cronst...@gmail.commailto:cronst...@gmail.com
To: bind-users bind-users@lists.isc.orgmailto:bind-users@lists.isc.org
Sent: Sunday, June 2, 2013 12:10 PM
Subject: does zone trump forward?
I've only ever come across bind configs where forwarding is in place to locate
certain zones, then all other queries are handled by either recursion or
authoritatively. But what about the other way around, where I'm master for a
few zones but forward the rest? Consider this:
view the-internet {
recursion no;
type forward;
forwarders { 8.8.8.8; };
zone example.comhttp://example.com/ {
type master
file example.comhttp://example.com/
..
}
Whats confusing me is the implied configuration setting of forward first when
the forward statement is used. If it truly forwards first, then I see an odd
logical scenario happening. All queries are sent to the forwarder before being
handled by localhost. Then, once the forwarder recognizes that I'm the master
of example.comhttp://example.com/, why would a loop not occur if the
forwarder matches this view?
To ask the question another way, does the zone statement take precedence on
matching queries over any forwarding?
Thanks
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.orgmailto:bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: records via GENERATE
Todd is correct. The GENERATE only exists on the master DNS in the zone data file. The DNS data, as made available to the querying machines, will contain all the individual records upon startup, on the master and all slaves. Alan V. Shackelford Senior Systems Software Engineer The Johns Hopkins University and John Hopkins Medicial Institutions Baltimore, Maryland USA ashac...@jhmi.edumailto:ashac...@jhmi.edu 410-735-4773 From: bind-users-bounces+ashackel=jhmi@lists.isc.org [mailto:bind-users-bounces+ashackel=jhmi@lists.isc.org] On Behalf Of Todd Snyder Sent: Monday, May 14, 2012 1:28 PM To: hugo hugoo; bind-users@lists.isc.org Subject: RE: records via GENERATE If I remember correctly, $GENERATE is a zone file syntax only. When you start up BIND, it parses those out and loads the generated records as if you'd written them out manually. $GENERATE just helps condense the zone file, but has no impact on overall operation. I'm sure someone from ISC could provide a much more technically in depth answer, but hopefully my memory serves correctly. t. From: bind-users-bounces+tsnyder=rim@lists.isc.orgmailto:bind-users-bounces+tsnyder=rim@lists.isc.org [mailto:bind-users-bounces+tsnyder=rim@lists.isc.org]mailto:[mailto:bind-users-bounces+tsnyder=rim@lists.isc.org] On Behalf Of hugo hugoo Sent: Monday, May 14, 2012 12:14 PM To: bind-users@lists.isc.orgmailto:bind-users@lists.isc.org Subject: records via GENERATE Dear all, Is there a difference between the configuration of a set of A records using: 1) GENERATE command like: $GENERATE 0-255 $-1.2.3 A3.2.1.$ 2) Defining all the records one by one. - difference in the amount of memory used? - difference in the speed to retrive the answer. If GENERATE command is used == is the answer calculated at the query incoming or are all the records already present in memory? Thanks in advance for your feedback, - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Question About max-clients-per-query
I had a situation a couple of days ago where a compromised machine in the DMZ portion of my network began sending an incredible number of queries to a couple of the primary internal DNS servers. The traffic was so intense that legitimate queries were unable to get through, or the customer timed out before the response came back. It took me a while to diagnose, because tailing the logs with querylog on was not possible. The data were coming too fast for my terminal to display them. Only after several Cntl-C commands was I able to escape from the tail, and a portion of the logs was displayed. Only queries from the compromised machine were visible. Nothing else got through during that time period. My customers and bosses are naturally furious. So is it possible to limit the number of queries for one name from one client, or even better, limit the number in a certain time, or the number of queries in a row from one client. If not we are going to have to be creative with some iptables or firewall rules. Thanks for any help you can lend. Alan V. Shackelford Sr. Systems Software Engineer The Johns Hopkins University and Johns Hopkins Medical Institutions Baltimore, Maryland USA 410-735-4773ashac...@jhmi.edu PGP.sig Description: PGP signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Problems With allow-update-forwarding
This weekend my stealth master DNS went off the network for a few hours due to a problem with some fiber. Two of my six slaves seemed to be adversely affected by the master's outage. The expire time on my zones is a week, and we have always believed (and in fact observed) that the zones can stay healthy for days without contact from the stealth master. However, this weekend two of the slaves had problems. Close examination of the configs showed only one difference between these slaves and the other four. These two are configured with allow-update-forwarding for six reverse zones, to allow Windows AD client machines to create their own PTR records. Naturally, it was impossible for these updates to be forwarded when the master was off line. Could this have caused the average lookup times to go from 40ms to over 1000ms for these two servers? It doesn't seem that it could, since it is a totally different sort of operation, but I can only find this difference between these two and the other four. Thanks for your help, Alan Alan V. Shackelford Sr. Systems Software Engineer The Johns Hopkins University and Johns Hopkins Medical Institutions Baltimore, Maryland USA 410-735-4773ashac...@jhmi.edu PGP.sig Description: PGP signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Multiple PTRs for an in-addr
Well said, Paul. I make my users choose between the various names for a server, and generally publish the name that the machine actually knows itself as, rather than any of the application names that reside there. In my opinion, the RFC is fairly clear. And my users don't know you have added this capability to BIND. So I agree this should never become the expected behavior, even if it begins to appear in great DNS software around the world. 73 Paul de NG3B Alan Alan V. Shackelford Sr. Systems Software Engineer The Johns Hopkins University and Johns Hopkins Medical Institutions Baltimore, Maryland USA 410-735-4773ashac...@jhmi.edu -Original Message- From: bind-users-bounces+ashackel=jhmi@lists.isc.org [mailto:bind-users-bounces+ashackel=jhmi@lists.isc.org] On Behalf Of Paul Vixie Sent: Wednesday, June 02, 2010 11:41 AM To: bind-us...@isc.org Subject: Chris Thompson c...@cam.ac.uk writes: Nothing that I can see. Maybe dnsviz can't cope with multiple PTR records in an RRset, as your first case has? (On the other hand it handles multiple A records in forward zones OK.) to be fair, multiple PTR RRs is something we added in BIND gethostbyaddr() in more or less direct contravention to RFC 1034. if dnsviz doesn't handle it (and i don't know if it doesn't) then it's not dnsviz's fault at all since the DNS RFC's say that there will only be one PTR RR at an in-addr. -- Paul Vixie KI6YSY ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users PGP.sig Description: PGP signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
