disabling lame server logging
Continuing to 'clean up' my new server by reviewing logged messages.
Researching a common one:
Feb 26 07:30:29 onlo named[19336]: error (unexpected RCODE SERVFAIL)
resolving 'foo.com/MX/IN': 1.2.3.4#53
I get the drift that my server has been directed to a 'lame server' and
logs that fact. Supposedly I am to lookup the SOA record and contact
the admin to fix this. What I really want to do is stop all these
messages as I suspect I will not be able to do anything to fix the
problem. So far what I have found is to add to my global logging section:
category lame-servers { null; };
Is there a finer scalpel? I believe there are other lame server
failures? Like 'RCODE REFUSED' and 'RCODE 15' (these are the 3 I see in
my messages)? Can I block logging by RCODE, so as new ones appear I can
learn what they mean before /dev/null ing them?
___
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: disabling lame server logging
On 02/26/2013 08:38 AM, Robert Moskowitz wrote:
Continuing to 'clean up' my new server by reviewing logged messages.
Researching a common one:
Feb 26 07:30:29 onlo named[19336]: error (unexpected RCODE SERVFAIL)
resolving 'foo.com/MX/IN': 1.2.3.4#53
I get the drift that my server has been directed to a 'lame server'
and logs that fact. Supposedly I am to lookup the SOA record and
contact the admin to fix this. What I really want to do is stop all
these messages as I suspect I will not be able to do anything to fix
the problem. So far what I have found is to add to my global logging
section:
category lame-servers { null; };
Is there a finer scalpel? I believe there are other lame server
failures? Like 'RCODE REFUSED' and 'RCODE 15' (these are the 3 I see
in my messages)? Can I block logging by RCODE, so as new ones appear
I can learn what they mean before /dev/null ing them?
I would be interested in which client is requesting these lookups that
end up going to lame servers. I am assuming the IP address in the log
is the address of the lame server, not the requesting client.
___
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: disabling lame server logging
On 26/02/13 13:54, Robert Moskowitz wrote: I would be interested in which client is requesting these lookups that end up going to lame servers. I am assuming the IP address in the log is the address of the lame server, not the requesting client. Look at the query logs? ___ 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: disabling lame server logging
On 02/26/2013 09:13 AM, Phil Mayers wrote: On 26/02/13 13:54, Robert Moskowitz wrote: I would be interested in which client is requesting these lookups that end up going to lame servers. I am assuming the IP address in the log is the address of the lame server, not the requesting client. Look at the query logs? I suspect I do not have any query logs. Where are they, typically. How are they controled (logging commands)? ___ 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: disabling lame server logging
On 02/26/2013 09:25 AM, Robert Moskowitz wrote: On 02/26/2013 09:13 AM, Phil Mayers wrote: On 26/02/13 13:54, Robert Moskowitz wrote: I would be interested in which client is requesting these lookups that end up going to lame servers. I am assuming the IP address in the log is the address of the lame server, not the requesting client. Look at the query logs? I suspect I do not have any query logs. Where are they, typically. How are they controled (logging commands)? OK. I found the 'rndc querylog' command. Boy is my mailserver hitting me up with repeated queries! I should probably be running a namecaching server on it to stop this resource hit? ___ 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: disabling lame server logging
On 26/02/13 14:31, Robert Moskowitz wrote: On 02/26/2013 09:25 AM, Robert Moskowitz wrote: On 02/26/2013 09:13 AM, Phil Mayers wrote: On 26/02/13 13:54, Robert Moskowitz wrote: I would be interested in which client is requesting these lookups that end up going to lame servers. I am assuming the IP address in the log is the address of the lame server, not the requesting client. Look at the query logs? I suspect I do not have any query logs. Where are they, typically. How are they controled (logging commands)? OK. I found the 'rndc querylog' command. Yes. Note that you can enable this by default in the options statement. This is all pretty well documented and easy to find in the ARM... Boy is my mailserver hitting me up with repeated queries! I should probably be running a namecaching server on it to stop this resource hit? Shrug. It depends on your config, load and so forth. There's no right answer to that sort of question. We do run caching resolvers on our MX/outbound relays. You can still forward such to your main resolvers. ___ 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: disabling lame server logging
On 02/26/2013 09:37 AM, Phil Mayers wrote: On 26/02/13 14:31, Robert Moskowitz wrote: On 02/26/2013 09:25 AM, Robert Moskowitz wrote: On 02/26/2013 09:13 AM, Phil Mayers wrote: On 26/02/13 13:54, Robert Moskowitz wrote: I would be interested in which client is requesting these lookups that end up going to lame servers. I am assuming the IP address in the log is the address of the lame server, not the requesting client. Look at the query logs? I suspect I do not have any query logs. Where are they, typically. How are they controled (logging commands)? OK. I found the 'rndc querylog' command. Yes. Note that you can enable this by default in the options statement. This is all pretty well documented and easy to find in the ARM... This is traffic I only want occationally! I am trying to reduce the logging size to find new problems. Boy is my mailserver hitting me up with repeated queries! I should probably be running a namecaching server on it to stop this resource hit? Shrug. It depends on your config, load and so forth. There's no right answer to that sort of question. We do run caching resolvers on our MX/outbound relays. You can still forward such to your main resolvers. I would expect that a namecaching server on the mailserver would reduce traffic and resources all the way around. I don't need my mailserver to constantly be asking my name server about, say, zen.spamhaus.org. ___ 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: disabling lame server logging
On 26/02/13 14:50, Robert Moskowitz wrote: Yes. Note that you can enable this by default in the options statement. This is all pretty well documented and easy to find in the ARM... This is traffic I only want occationally! I am trying to reduce the logging size to find new problems. Fair enough. Personally we leave query logging enabled constantly (to local files) as it can be useful to retroactively troubleshoot. But it's your choice - that's why it's configurable. I don't need my mailserver to constantly be asking my name server about, say, zen.spamhaus.org. Maybe, maybe not. I gave my opinion (it depends) earlier, no point in repeating it. ___ 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
name caching and forwarding
So now I am working on adding a name caching service to my mailserver.
And I am reading up on namecaching. For RHEL/Centos, there is not much
to doing this as the default install of bind SEEMS to be a name caching
server. But I want it to NOT go out on the net for queries, but to
direct all of its queries to my internal bind server.
The latter I see I need:
forwarders { 10.2.3.4; 192.168.2.5; };
But it seems that with this you need to include:
forward ( only | first );
And I am having challenges with the forward option. It reads that
'forward only' will always ask the forwarder about the query and seems
to defeat caching? And 'forward first' only looks in cache after a
forward fails? This does not sound right and I am missing something in
the documentation; like forwarding ONLY applies IF the query is NOT in
cache?
___
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: name caching and forwarding
On 26/02/13 16:07, Robert Moskowitz wrote: And I am having challenges with the forward option. It reads that 'forward only' will always ask the forwarder about the query and seems to defeat caching? And 'forward first' only looks in cache after a forward fails? This does not sound right and I am missing something in the documentation; like forwarding ONLY applies IF the query is NOT in cache? No, you've misunderstood. forward first means try the forwarders, and if you don't get a reply, try the query yourself starting from the root forward only means only ever try the forwarders forward replies are always cached for the relevant TTL. ___ 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: name caching and forwarding
On 02/26/2013 11:14 AM, Phil Mayers wrote: On 26/02/13 16:07, Robert Moskowitz wrote: And I am having challenges with the forward option. It reads that 'forward only' will always ask the forwarder about the query and seems to defeat caching? And 'forward first' only looks in cache after a forward fails? This does not sound right and I am missing something in the documentation; like forwarding ONLY applies IF the query is NOT in cache? No, you've misunderstood. forward first means try the forwarders, and if you don't get a reply, try the query yourself starting from the root forward only means only ever try the forwarders forward replies are always cached for the relevant TTL. OK. This is what I was hoping it meant, but I was not good at expressing it. ___ 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: disabling lame server logging
On 26/02/13 15:50, Robert Moskowitz wrote: I would expect that a namecaching server on the mailserver would reduce traffic and resources all the way around. I don't need my mailserver to constantly be asking my name server about, say, zen.spamhaus.org. This is one reason my mailserver has a DNS server. No forward, that only slows down things. The question here is whether there is a good reason that this instance must not go directly to the roots? ___ 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 -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ 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: disabling lame server logging
On 2/26/13 10:43 AM, Sten Carlsen st...@s-carlsen.dk wrote: On 26/02/13 15:50, Robert Moskowitz wrote: I would expect that a namecaching server on the mailserver would reduce traffic and resources all the way around. I don't need my mailserver to constantly be asking my name server about, say, zen.spamhaus.org. This is one reason my mailserver has a DNS server. No forward, that only slows down things. The question here is whether there is a good reason that this instance must not go directly to the roots? In my opinion mail servers that receive outside mail should point to root servers and nothing internally. Particularly if you have spam filtering that relies on any sort of dns lookup. A message will cause a spam filter to produce a predictable set of queries, so someone who can come up with a bind vulnerability can force your mail server to make potentially vulnerable requests. If the vulnerability involves cache poisoning, then the malware authors would be able to pollute your internal DNS by convincing your spam filter to query crafted entries. That's not to say that there is currently any cache-poisoning vulnerability that someone might exploit, or that any current malware makes use of this two-phase approach to exploit desktops. But why take the risk when setting up bind as a recursive server pointing at roots is so trivial? -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ 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: disabling lame server logging
On 02/26/2013 11:43 AM, Sten Carlsen wrote: On 26/02/13 15:50, Robert Moskowitz wrote: I would expect that a namecaching server on the mailserver would reduce traffic and resources all the way around. I don't need my mailserver to constantly be asking my name server about, say, zen.spamhaus.org. This is one reason my mailserver has a DNS server. No forward, that only slows down things. The question here is whether there is a good reason that this instance must not go directly to the roots? To support systems only visable to your internal view? ___ 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: disabling lame server logging
From: Daniel McDonald dan.mcdon...@austinenergy.com That's not to say that there is currently any cache-poisoning vulnerability that someone might exploit, or that any current malware makes use of this two-phase approach to exploit desktops. But why take the risk when setting up bind as a recursive server pointing at roots is so trivial? It's not clear to me the risk of evil mail causing poisonous lookups is enough larger than other vectors for poisonous lookups to balance the costs and risks of additional DNS servers at a small site: - Partitioning your DNS cache among separate servers reduces its overall hit rate and so costs more RAM, CPU cycles, and bandwidth. (given the mention of zen.spamhaus.org, consider the records for .org) - Maintain another server costs additional system administration labor and system administration errors. - Having DNS broken only for mail by an hypothetical evil lookups is likely to be unnoticed for longer than when all DNS is broken, especially at small sites. - Every additional anything increases your attack surface, especially when it talks to the whole Internet. There are many situations where those costs are worthwhile, but they are less common at small sites. When two DNS servers are justified at a small site, I bet the best common tactic is to put all servers in all /etc/resolv.conf files or Windows equivalent, but with differing orders. For example, the mail system might prefer its own DNS server but fall back to another server. Vernon Schryverv...@rhyolite.com ___ 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: disabling lame server logging
On 26/02/13 18:06, Robert Moskowitz wrote: On 02/26/2013 11:43 AM, Sten Carlsen wrote: On 26/02/13 15:50, Robert Moskowitz wrote: I would expect that a namecaching server on the mailserver would reduce traffic and resources all the way around. I don't need my mailserver to constantly be asking my name server about, say, zen.spamhaus.org. This is one reason my mailserver has a DNS server. No forward, that only slows down things. The question here is whether there is a good reason that this instance must not go directly to the roots? To support systems only visable to your internal view? I have in my internal view mostly systems that are not visible from the outside but my internal view has direct access to the world with regards to DNS. I don't see any risk in that , except the predictability of RBL-lookups as mentioned elsewhere. Speed is much improved, even with a standard ADSL line I have better performance than by forwarding to the ISP DNS server. -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ 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: disabling lame server logging
On 02/26/2013 12:58 PM, Sten Carlsen wrote: On 26/02/13 18:06, Robert Moskowitz wrote: On 02/26/2013 11:43 AM, Sten Carlsen wrote: On 26/02/13 15:50, Robert Moskowitz wrote: I would expect that a namecaching server on the mailserver would reduce traffic and resources all the way around. I don't need my mailserver to constantly be asking my name server about, say, zen.spamhaus.org. This is one reason my mailserver has a DNS server. No forward, that only slows down things. The question here is whether there is a good reason that this instance must not go directly to the roots? To support systems only visable to your internal view? I have in my internal view mostly systems that are not visible from the outside but my internal view has direct access to the world with regards to DNS. I don't see any risk in that , except the predictability of RBL-lookups as mentioned elsewhere. Speed is much improved, even with a standard ADSL line I have better performance than by forwarding to the ISP DNS server. What I meant here, rather poorly stated, is that my mail server would have to look up clients that only resolve within my internal view. For example foo.bar which resolves to 192.168.178.5. That query would fail if all the caching server had was public DNS data. I DO run a hidden TLD here for some testing and those devices currently do send mail from one to another through my current mail server. -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ 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: disabling lame server logging
You want to set up your resolver on your mail server to forward to your main resolver, using the forward only option. This will allow your mail server resolver to benefit from the cache already populated on your main resolver, while still maintaining the value of caching the answers itself locally. Your goal of reducing the number of error messages in your main resolver's logs so that you can better chase down real problems is a good one. However you eventually reach a point of diminishing return where further reducing the errors ends up in you missing actual new problems. Or, put another way, slogging through noisy logs is part of the job, given the horrific state of most DNS out there. Welcome to the club. Doug ___ 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: Stop of logging of No Valid Signature Found
On Feb 25, 2013, at 8:25 PM, Robert Moskowitz wrote: So should I change this to an include and put dnssec-validation back to yes? No. dnssec-validation auto; is correct for 90% of cases. An Internet validating resolver should almost certainly use this. Mark is simply being precise and complete in his explanation. Chris Buxton BlueCat Networks ___ 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: disabling lame server logging
On 02/26/2013 01:19 PM, Doug Barton wrote: You want to set up your resolver on your mail server to forward to your main resolver, using the forward only option. This will allow your mail server resolver to benefit from the cache already populated on your main resolver, while still maintaining the value of caching the answers itself locally. What I have done. Your goal of reducing the number of error messages in your main resolver's logs so that you can better chase down real problems is a good one. However you eventually reach a point of diminishing return where further reducing the errors ends up in you missing actual new problems. Pretty quite. For now. I would like a scalpel for lame logging, but probably would not discover any actionable data. Or, put another way, slogging through noisy logs is part of the job, given the horrific state of most DNS out there. Welcome to the club. Well I am working at getting off the 'horrific state' list. ___ 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: name caching and forwarding
On 2/26/2013 11:39 AM, Robert Moskowitz wrote: On 02/26/2013 11:14 AM, Phil Mayers wrote: On 26/02/13 16:07, Robert Moskowitz wrote: And I am having challenges with the forward option. It reads that 'forward only' will always ask the forwarder about the query and seems to defeat caching? And 'forward first' only looks in cache after a forward fails? This does not sound right and I am missing something in the documentation; like forwarding ONLY applies IF the query is NOT in cache? No, you've misunderstood. forward first means try the forwarders, and if you don't get a reply, try the query yourself starting from the root forward only means only ever try the forwarders forward replies are always cached for the relevant TTL. OK. This is what I was hoping it meant, but I was not good at expressing it. To clarify even further, caching is *always* in effect, no matter what kind of non-authoritative zone you define (forward, stub, etc.) or even if you have no explicit zone definition at all and simply follow the delegation chain to the data, as Phil described. Think of forward first as opportunistic, in the sense that you'll try to get the data via forwarding, but if that doesn't work, you'll fall back to whatever mechanism you'd use to resolve the name, if the zone definition didn't exist at all. Generally speaking, forward first is an attempt (usually unsuccessful, in most environments) to improve query performance by utilizing a centralized cache. Forward only, on the other hand, is dependent, in the sense that your forwarders are the *only* thing that will allow you to resolve the name. If that doesn't work, the query fails completely. Forward only should be used, not solely as an attempt to enhance performance, but as a way to get around connectivity restrictions, e.g. firewalls or a restrictive routing regime. So, in a nutshell: forward first as an opportunistic attempt to improve performance, but you can still fall back to your regular resolution methods; forward only to get around blockages or connectivity restrictions. If all you want to do is run a private namespace, I wouldn't be fiddling around with forwarding at all. Set up your own root zone, propagate a private set of hints data, and be happy. I know that you once thrived in such a DNS environment :-) - Kevin P.S. Insightful readers may have picked up from the above that I am not particularly fond of forwarding at all. In my experience, iterative resolution usually shows better performance, especially in geographically-diverse infrastructures with many subdomain levels (would I really want to forward through Italian nameservers to resolve names that I could resolve from nameservers in the same metro area, for the North American subdivision of one of our partners?). For that matter, I'm an even bigger fan of replicating zone data far and wide on stealth slaves -- give your users the maximum in performance and resiliency, and they'll be happier for it. In practical terms, one of the biggest issues I have about forwarding is that admins who go hog wild with it tend to get really lazy and sloppy about keeping their delegations and glue straight. Which means they create massive interoperability problems for anyone who doesn't want to play in their forwarding sandbox. Even though I eschew forwarding myself, I leave the option open for people to forward to my infrastructure *if*they*must*, but with all of the broken delegations/glue, I am not afforded the same opportunity to utilize my preferred resolution methodology. That seems a little selfish/one-sided. ___ 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: disabling lame server logging
On 02/26/2013 10:38 AM, Robert Moskowitz wrote: I would like a scalpel for lame logging, but probably would not discover any actionable data. There is a logging category for lame-servers. It's in the ARM. Doug ___ 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: name caching and forwarding
hey, Kevin, hope you are hanging well back at the old stomping ground! On 02/26/2013 01:42 PM, Kevin Darcy wrote: On 2/26/2013 11:39 AM, Robert Moskowitz wrote: On 02/26/2013 11:14 AM, Phil Mayers wrote: On 26/02/13 16:07, Robert Moskowitz wrote: And I am having challenges with the forward option. It reads that 'forward only' will always ask the forwarder about the query and seems to defeat caching? And 'forward first' only looks in cache after a forward fails? This does not sound right and I am missing something in the documentation; like forwarding ONLY applies IF the query is NOT in cache? No, you've misunderstood. forward first means try the forwarders, and if you don't get a reply, try the query yourself starting from the root forward only means only ever try the forwarders forward replies are always cached for the relevant TTL. OK. This is what I was hoping it meant, but I was not good at expressing it. To clarify even further, caching is *always* in effect, no matter what kind of non-authoritative zone you define (forward, stub, etc.) or even if you have no explicit zone definition at all and simply follow the delegation chain to the data, as Phil described. Think of forward first as opportunistic, in the sense that you'll try to get the data via forwarding, but if that doesn't work, you'll fall back to whatever mechanism you'd use to resolve the name, if the zone definition didn't exist at all. Generally speaking, forward first is an attempt (usually unsuccessful, in most environments) to improve query performance by utilizing a centralized cache. Forward only, on the other hand, is dependent, in the sense that your forwarders are the *only* thing that will allow you to resolve the name. If that doesn't work, the query fails completely. Forward only should be used, not solely as an attempt to enhance performance, but as a way to get around connectivity restrictions, e.g. firewalls or a restrictive routing regime. So, in a nutshell: forward first as an opportunistic attempt to improve performance, but you can still fall back to your regular resolution methods; forward only to get around blockages or connectivity restrictions. Very well summarized. Thank you. What I was expecting it to work, but verify; don't just trust. If all you want to do is run a private namespace, I wouldn't be fiddling around with forwarding at all. Set up your own root zone, propagate a private set of hints data, and be happy. I know that you once thrived in such a DNS environment :-) Them were the days. - Kevin P.S. Insightful readers may have picked up from the above that I am not particularly fond of forwarding at all. In my experience, iterative resolution usually shows better performance, especially in geographically-diverse infrastructures with many subdomain levels (would I really want to forward through Italian nameservers to resolve names that I could resolve from nameservers in the same metro area, for the North American subdivision of one of our partners?). For that matter, I'm an even bigger fan of replicating zone data far and wide on stealth slaves -- give your users the maximum in performance and resiliency, and they'll be happier for it. In practical terms, one of the biggest issues I have about forwarding is that admins who go hog wild with it tend to get really lazy and sloppy about keeping their delegations and glue straight. Which means they create massive interoperability problems for anyone who doesn't want to play in their forwarding sandbox. Even though I eschew forwarding myself, I leave the option open for people to forward to my infrastructure *if*they*must*, but with all of the broken delegations/glue, I am not afforded the same opportunity to utilize my preferred resolution methodology. That seems a little selfish/one-sided. My little network will do well as I am setting it up. Plus I can run my HIP testing. I leave the world-wide mess to old hands like you. ___ 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: disabling lame server logging
On 02/26/2013 01:57 PM, Doug Barton wrote: On 02/26/2013 10:38 AM, Robert Moskowitz wrote: I would like a scalpel for lame logging, but probably would not discover any actionable data. There is a logging category for lame-servers. It's in the ARM. So far 2 reads and I am not getting out of it what to do for selective logging based on return codes. I am going to let it stay for now as I move on to other parts of this project. ___ 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: disabling lame server logging
Robert wrote on 02/26/2013 02:23:44 PM:
There is a logging category for lame-servers. It's in the ARM.
So far 2 reads and I am not getting out of it what to do for selective
logging based on return codes. I am going to let it stay for now as I
move on to other parts of this project.
From my named.conf.logging:
// Send all lame server errors to the null channel
category lame-servers { null; };
Confidentiality Notice:
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if this
message has been addressed to you in error, you are hereby notified that
you may not copy, forward, disclose or use any part of this message or any
attachments. Please notify the sender immediately by return e-mail or
telephone and delete this message from your system.
___
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: disabling lame server logging
On 26/02/13 19:09, Robert Moskowitz wrote: On 02/26/2013 12:58 PM, Sten Carlsen wrote: On 26/02/13 18:06, Robert Moskowitz wrote: On 02/26/2013 11:43 AM, Sten Carlsen wrote: On 26/02/13 15:50, Robert Moskowitz wrote: I would expect that a namecaching server on the mailserver would reduce traffic and resources all the way around. I don't need my mailserver to constantly be asking my name server about, say, zen.spamhaus.org. This is one reason my mailserver has a DNS server. No forward, that only slows down things. The question here is whether there is a good reason that this instance must not go directly to the roots? To support systems only visable to your internal view? I have in my internal view mostly systems that are not visible from the outside but my internal view has direct access to the world with regards to DNS. I don't see any risk in that , except the predictability of RBL-lookups as mentioned elsewhere. Speed is much improved, even with a standard ADSL line I have better performance than by forwarding to the ISP DNS server. What I meant here, rather poorly stated, is that my mail server would have to look up clients that only resolve within my internal view. For example foo.bar which resolves to 192.168.178.5. That query would fail if all the caching server had was public DNS data. I DO run a hidden TLD here for some testing and those devices currently do send mail from one to another through my current mail server. Almost my setup. I don't have a hidden TLD, that was too painful and did not provide what I wanted. I use the same domain and the same names inside and outside, except inside there are many more names. E.g. my mail server is called mail2. both outside and inside, outside it has a public IP and inside it has an IP in the 192.168.x.x range. I also have servers that have the same IP both inside and outside. -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ 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: disabling lame server logging
Hi Robert, On Feb 26, 2013, at 2:23 PM, Robert Moskowitz r...@htt-consult.com wrote: On 02/26/2013 01:57 PM, Doug Barton wrote: On 02/26/2013 10:38 AM, Robert Moskowitz wrote: I would like a scalpel for lame logging, but probably would not discover any actionable data. There is a logging category for lame-servers. It's in the ARM. So far 2 reads and I am not getting out of it what to do for selective logging based on return codes. I am going to let it stay for now as I move on to other parts of this project. Perhaps you want something outside of bind; e.g. The rsyslog software can exclude/filter based on regex. Just a thought. Bryan ___ 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: name caching and forwarding
In message 512d0222.5020...@chrysler.com, Kevin Darcy writes: If all you want to do is run a private namespace, I wouldn't be fiddling around with forwarding at all. Set up your own root zone, propagate a private set of hints data, and be happy. I know that you once thrived in such a DNS environment :-) - Kevin For private namespaces stub, slave and master zones are your friends. Use one of these at the apex of each internal namespace. I don't recommend setting up your own root zone as most of the time you are grafting on only a few namespaces. Kevin has had to deal with hundreds of internal namespaces and the trade off are different in those cases. It's do you graft the world onto your namespaces or do you graft your namespaces onto the world. For most situations the later is less complicated and has less on going overhead. The root is adding more tlds more rapidly lately. YMMV Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
{plain} BIND 10, and DNS and BIND by Liu Albitz
Has there been any word on when (if?) a new edition of DNS and BIND will be available covering BIND 10? James. ___ 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
