Re: forward first and fallback not working
No errors on logs and if i remove
forward first;
forwarders {
8.8.8.8;
};
all is workin properly .
i don't know if i am missing something but i think it is a bug .
On Tue, 23 Aug 2016 21:05:13 +
"Darcy Kevin (FCA)" wrote:
> Look in your logs at the time of named startup to see if your
> root-server priming failed at that time.
>
>
> -
> kevin
>
>
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf
> Of ma...@nucleus.it Sent: Tuesday, August 23, 2016 6:42 AM
> To: bind-users@lists.isc.org
> Subject: forward first and fallback not working
>
> Hi,
> bind 9.10.3_p4 with this global option:
>
> forward first;
>
> forwarders {
>8.8.8.8;
> };
>
> If i dig from localhost or any client and 8.8.8.8 answers all is ok
> but if 8.8.8.8 is unreachable or it doesn't respond, bind doesn't
> fallback on himslef asking to root server etc .
>
> This is not expected.
> Anyone with this behavior ?
>
> best regards
> Marco
> ___
> 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
> ___
> 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
___
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: Slaves or Forwarders?
Darcy Kevin (FCA) wrote: > From an InfoSec standpoint, of course one would prefer to use > cryptographic methods of securing DNS data, Yes, use TSIG for zone transfers. You can also use it for forwarding. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Fair Isle, North Faeroes: Variable becoming southerly 3 or 4. Slight or moderate. Rain with fog patches, becoming fair. Moderate or very poor, becoming mainly good. ___ 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: forward first and fallback not working
The dns resolution with 8.8.8.8 works fine with "forward first" if
8.8.8.8 is working but for testing i blocked with an
intermediate firewall the dns requests to the forwarder and two things
happened (the second one is bad).
1) If the firewall reset the connection to 8.8.8.8 bind fallbacks on its
root servers and this is good
2) If the firewall drop the connection to 8.8.8.8 bind does NOT
fallback on its root servers and this is a bad thing cause in this
way i was testing a network outage for my forwarder.
below my config
Hi attach also che config
/etc/resolv.conf
search domain.dom
nameserver 127.0.0.1
named.conf
acl "trusted" {
127.0.0.0/8;
192.168.1.0/24;
};
options {
directory "/var/bind";
pid-file "/run/named/named.pid";
/* https://www.isc.org/solutions/dlv >=bind-9.7.x only */
//bindkeys-file "/etc/bind/bind.keys";
session-keyfile "/var/bind/session.key";
//listen-on-v6 { ::1; };
//listen-on { 127.0.0.1; };
masterfile-format text;
allow-query {
/*
* Accept queries from our "trusted" ACL. We will
* allow anyone to query our master zones below.
* This prevents us from becoming a free DNS server
* to the masses.
*/
trusted;
};
allow-query-cache {
/* Use the cache for the "trusted" ACL. */
trusted;
};
allow-recursion {
/* Only trusted addresses are allowed to use recursion.
*/ trusted;
};
allow-transfer {
/* Zone tranfers are denied by default. */
none;
};
allow-update {
/* Don't allow updates, e.g. via nsupdate. */
none;
};
forward first;
forwarders {
8.8.8.8;
};
};
zone "." in {
type hint;
file "/var/bind/named.cache";
};
zone "localhost" IN {
type master;
file "pri/localhost.zone";
notify no;
};
zone "127.in-addr.arpa" IN {
type master;
file "pri/127.zone";
notify no;
};
End of named.conf
On Wed, 24 Aug 2016 09:21:09 +0200
ma...@nucleus.it wrote:
> No errors on logs and if i remove
> forward first;
>
> forwarders {
>8.8.8.8;
> };
>
> all is workin properly .
>
> i don't know if i am missing something but i think it is a bug .
>
>
>
>
> On Tue, 23 Aug 2016 21:05:13 +
> "Darcy Kevin (FCA)" wrote:
>
> > Look in your logs at the time of named startup to see if your
> > root-server priming failed at that time.
> >
> >
> > -
> > kevin
> >
> >
> > -Original Message-
> > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf
> > Of ma...@nucleus.it Sent: Tuesday, August 23, 2016 6:42 AM
> > To: bind-users@lists.isc.org
> > Subject: forward first and fallback not working
> >
> > Hi,
> > bind 9.10.3_p4 with this global option:
> >
> > forward first;
> >
> > forwarders {
> >8.8.8.8;
> > };
> >
> > If i dig from localhost or any client and 8.8.8.8 answers all is ok
> > but if 8.8.8.8 is unreachable or it doesn't respond, bind doesn't
> > fallback on himslef asking to root server etc .
> >
> > This is not expected.
> > Anyone with this behavior ?
> >
> > best regards
> > Marco
> > ___
> > 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
> > ___
> > 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
>
> ___
> 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
___
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: forward first and fallback not working
On Wed, Aug 24, 2016 at 05:28:55PM +0200, Marco Felettigh wrote: > The dns resolution with 8.8.8.8 works fine with "forward first" if > 8.8.8.8 is working but for testing i blocked with an intermediate > firewall the dns requests to the forwarder and two things happened > (the second one is bad). > > 1) If the firewall reset the connection to 8.8.8.8 bind fallbacks >on its root servers and this is good > > 2) If the firewall drop the connection to 8.8.8.8 bind does NOT > this fallback on its root servers and this is a bad thing cause > in this way i was testing a network outage for my forwarder. > > below my config I am not sure this is a BIND issue. Try this with a longer timeout set in your resolver ... > Hi attach also che config > > /etc/resolv.conf > search domain.dom > nameserver 127.0.0.1 options timeout=20 Try similar settings on other clients. My glibc (GNU/Linux) resolver says the default timeout is 5 seconds. I'm not sure about named, but I think its timeout is greater than that. So named is waiting for its own timeout before attempting recursion. By the time recursion is complete, the client has long since given up. > named.conf snip If anything needs to change on the BIND side of this, perhaps it would be the documentation of "forward first", to note that this feature won't work with most standard resolver clients. I would further suggest that this fallback isn't a very good idea anyway; you'll probably be better off just doing the recursion without forwarders in the picture. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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
Need of caching on bind server
Hello, I am trying to understand why caching is required on the bind server, when the client receiving the responses would be caching based on TTL values. So, Is caching required on the server, if the client is not able to cache such responses? Isn't it a overhead on both the client and server systems to cache the same responses at respective ends What are the possible Use cases of caching the responses at the Server? What if there is a dynamic updates of Records on Server and Server still sends the cached Responses? Thanks Harshith ___ 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: Need of caching on bind server
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > Harshith Mulky > Sent: Thursday, August 25, 2016 12:47 AM > To: bind-users@lists.isc.org > Subject: Need of caching on bind server > > Hello, > > I am trying to understand why caching is required on the bind server, > when the client receiving the responses would be caching based on TTL > values. > Harshith, I had the same question a number of years back and after gathering a fair amount of statistics found we were seeing roughly 95% to 98% hit rates for the cache. This is a huge win when the answers are local to the caching nameserver vs. recursively hitting the network again and again. In the end if the site is unpopular (lower than 5% of nameserver traffic) it does not really matter much but for everything else it will matter a great deal. My findings are likely an extreme case and the traffic of your nameservers will depend greatly on the size of your client base so you may want to run some tests of your own to see just how valuable the cache is. Regards, John > So, > Is caching required on the server, if the client is not able to cache > such responses? Isn't it a overhead on both the client and server > systems to cache the same responses at respective ends > What are the possible Use cases of caching the responses at the Server? > What if there is a dynamic updates of Records on Server and Server > still sends the cached Responses? BTW: Dynamic or not, caching is an expected part of DNS and implementors should take this into careful consideration when implementing protocols relying on DNS as a service component. > > Thanks > Harshith > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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: Need of caching on bind server
Hi Harshith On Thu, Aug 25, 2016 at 04:47:03AM +, Harshith Mulky wrote: > Hello, > > > I am trying to understand why caching is required on the bind server, > when the client receiving the responses would be caching based on TTL > values. > > > So, > > Is caching required on the server, if the client is not able to cache > such responses? Isn't it a overhead on both the client and server > systems to cache the same responses at respective ends Applications usually do not cache DNS records. They usually *use* DNS data such as addresses immediately and discard the data afterwards. Of course, there are exceptions where applications do cache DNS data but this is not the norm. A DNS resolver is also a DNS client that resolves answers to questions and caches them. It is a server to a different kind of DNS client called a stub resolver that an application uses. > What are the possible Use cases of caching the responses at the > Server? > > What if there is a dynamic updates of Records on Server and Server > still sends the cached Responses? DNS resolution is a time-consuming operation. Local resolver caches help improve performance and also reduce load on remote nameservers. Caches also build resiliency into DNS against short disruptive conditions. The TTL field (and some other fields) influence how long a DNS record is valid in the cache before it expires. DNS data is weakly coherent and data in a cache may be out of sync with changes to the corresponding zone on an authoritative server until this data's TTL expires. This is a normal condition. (Similarly, DNS data on secondary nameservers may be out of sync with changes to a zone on a primary nameserver for a period of time.) For answers to these questions, I suggest reading RFC 1034 which explains concepts of DNS. Mukund signature.asc 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
Re: Need of caching on bind server
> I am trying to understand why caching is required on the bind server, > when the client receiving the responses would be caching based on TTL > values. > > So, > Is caching required on the server, if the client is not able to > cache such responses? Isn't it a overhead on both the client and server > systems to cache the same responses at respective ends > What are the possible Use cases of caching the responses at the Server? > What if there is a dynamic updates of Records on Server and > Server still sends the cached Responses? Ubiquitous client-side DNS caching on workstations is relatively new in the grand scheme of things, and shouldn't be assumed to exist. Also, client side caches may be limited in size, may expire data far sooner than the TTL, and with mobile devices, may dump their entire cache frequently (perhaps every time the device jumps between networks). Beyond that, think about the number of queries a resolver must perform to visit a website, we first need the roots (hints or cached), then the authoritative NS for the gTLD, then the NS for the domain, and oops it's in another gTLD so we look that up, from the root again, etc, all just to get a CNAME for a CDN in yet another TLD, and now a single call to a single website has taken 10-15 separate queries just to get the final A record. I haven't done actual statistics, but I've yet to see any time when my resolvers don't have the authoritative servers for COM, NET, INFO, ORG, CA, and various other TLDs in the cache. Plus, even if you do assume that clients cache effectively, AND you ignore the resolver's internal needs, most DNS resolvers serve more than one user and as such, in a company of a few hundred employees (or an ISP with a tens or hundreds of thousands), at any one time at least half are watching cat videos from YouTube, so the cache will help the next 'x' number of users who all need to know www.youtube.com and it's CDN services. Most of the internet uses Google Analytics, AdWords, DoubleClick, has Facebook or Twitter links, Disqus, etc, all of those are in cache approximately 100% of the time if you have more than a handful of users. Or maybe I am completely missing your point? ___ 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: DNSKEY and RRSIG DNSKEY TTL values aren't changed after changing of zone's TTL
To make zone dinamically updated - I added into `zone` section of
named.conf 'allow-update { any; };' directive and made `rndc reload` after
that.
Then I made `rndc freeze `. But after this command - the
signed zone file (`.signed`) still remain
in raw format (not text readable) - so I can read it via
`named-compilezone` utility, but unfortunately I can't change it.
Kind regards,
Aleks Ostapenko
___
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
