reload but the old value linger

[Boylan, Ross]

My fix for the DNS lookup problems I reported a few days ago, based on help 
here, seems to mostly work.  But there is one oddity.  When the tunnel goes 
down I comment out the special handling for the zone I reach through the tunnel 
and reload the server.  But my DNS queries return the same internal IP number I 
got before, at least for awhile.

Since I can't reach the remote machine anyway, this is probably a pretty minor 
problem, but I'd like to understand what's going on and how I might fix it.

My theory is that reloading (via rndc reload) does not clear the cache, and 
that my queries just get the cached value until they expire.  Is that plausible?

If that is the problem, would
rndc flushtree ucsf.edu inside
remove the no longer valid values from the cache?  ucsf.edu is the domain for 
which I forward, and it is accessible from the "inside" view.

Details:
My main bind configuration includes
view "inside" {
match-clients { internals; };

recursion yes;

// next is only active when vpn tunnel is up
//when tunnel goes down it is commented out
include "/etc/bind/ucsf.conf.tunnel";

// allow dhcp to update me
include "/etc/bind/rndc.key";

include "/etc/bind/named.conf.default-zones";

zone "1.168.192.in-addr.arpa" {
# stuff
}
# and a forward zone
};

lwres {
   view "inside";
   search { "betterworld.us";};
};


And the sometimes included file is
- ucsf.conf.tunnel
zone "ucsf.edu" {
 type forward;
 forwarders {10.10.10.10;};
 };

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: [External] Re: How can I launch a private Internet DNS server?

[Tom J. Marcoen]

Thank you for your valuable feedback. It is much appreciated.

On Fri, 20 Nov 2020 at 19:37, Reindl Harald  wrote:

>
> Am 08.11.20 um 14:44 schrieb Timothe Litt:
>
>
> I'm amazed that this thread has persisted for so long on this list of
> knowledgeable people
>
>
> me too, i would understand that on the spamassassin list but not here and
> what i *really* don't understand is jumping into the thread with "I just
> wanted to comment that there is no requirement to run a secondary DNS
> server"
>
> even if it would not be a requirement (but it is) it's common sense not to
> contradict best practices everyone running critical services is following
>
> there are enough beginners which don't follow best practices anyways, no
> need to encourage them
>
> RFC1034 , one of the two
> foundational RFCs for the DNS:
>
> P.18 in section 4.1 (NAME SERVERS => Introduction):
>
> A given zone will be available from several name servers to insure its
> availability in spite of host or communication link failure.  By
> administrative fiat, we require every zone to be available on at least
> two servers, and many zones have more redundancy than that.
>
> In case the font is too small, the key phrase is:
>
> "we require every zone to be available on at least two servers"
>
> That's "REQUIRE" at least TWO SERVERS
>
> i heard of registries whcih require even 3 and when they say they require
> it means you have them or you can't register a domain, no RFC needed to
> begin with
>
> https://tools.ietf.org/html/rfc1537 documents common misconfigurations -
> that is, cases of non-conformance to the RFCs that the author encountered
> circa 1993.  It was superseded in 1993 by RFC 1912
> , where section 2.8 starts with "You
> are required to have at least two nameservers for every domain".  Neither
> document supersedes RFC1034; rather they attempt to help with interpreting
> it.
>
> https://www.iana.org/help/nameserver-requirements  consolidates
> information from several RFCs, since the DNS has evolved over time.  It is
> not an RFC, but a convenient summary.  It primarily documents the tests
> performed by IANA when it processes a delegation change to the root, .INT,
> and .ARPA zones.  These tests validate conformance to the RFCs.  As the
> introduction says, "These tests do not measure against best practices or
> comprehensively measure protocol conformance. They are a practical set of
> baseline requirements that catch common misconfiguration errors that impact
> stable operations of the DNS."
>
> Bottom line: two servers per zone are required by the DNS architecture.
> It's not folklore.  It's not optional.
>
> yes
>
> It is true that the DNS is robust enough to function with a number of
> misconfigurations (including just one server for a zone, since in practice
> this is almost indistinguishable from transient conditions.)
>
> Nonetheless, the goal of the DNS architecture (and most of its operators)
> is to have a stable and robust name service.  Misconfigurations, such as
> those documented in rfc1527, make the DNS unstable and fragile.  The
> architecture tends to contain the effects of many misconfigurations, but
> that doesn't make them wise.
>
> As I noted earlier: "DNS appears deceptively simple at first blush.
> Setting up a serviceable infrastructure requires an investment of thought
> and on-going maintenance.  You will not be happy if you skimp on that
> investment, since broken DNS is externally visible - and frequently
> catastrophic."
>
> I'll finish with a 1987 quote from Leslie Lamport on distributed systems,
> which the DNS most certainly is:
>
> "A distributed system is one in which the failure of a computer you didn't
> even know existed can render your own computer  unusable."
>
> Can the quibbling stop now?
>
>
> thank you
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> 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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: [External] Re: How can I launch a private Internet DNS server?

[Reindl Harald]

Am 08.11.20 um 14:44 schrieb Timothe Litt:


I'm amazed that this thread has persisted for so long on this list of 
knowledgeable people




me too, i would understand that on the spamassassin list but not here 
and what i *really* don't understand is jumping into the thread with "I 
just wanted to comment that there is no requirement to run a secondary 
DNS server"


even if it would not be a requirement (but it is) it's common sense not 
to contradict best practices everyone running critical services is following


there are enough beginners which don't follow best practices anyways, no 
need to encourage them


RFC1034 , one of the two 
foundational RFCs for the DNS:


P.18 in section 4.1 (NAME SERVERS => Introduction):

A given zone will be available from several name servers to insure its
availability in spite of host or communication link failure.  By
administrative fiat, we require every zone to be available on at least
two servers, and many zones have more redundancy than that.

In case the font is too small, the key phrase is:

"we require every zone to be available on at least two servers"

That's "REQUIRE" at least TWO SERVERS

i heard of registries whcih require even 3 and when they say they 
require it means you have them or you can't register a domain, no RFC 
needed to begin with


https://tools.ietf.org/html/rfc1537 
 documents common 
misconfigurations - that is, cases of non-conformance to the RFCs that 
the author encountered circa 1993.  It was superseded in 1993 by RFC 
1912 , where section 2.8 starts 
with "You are required to have at least two nameservers for every 
domain".  Neither document supersedes RFC1034; rather they attempt to 
help with interpreting it.


https://www.iana.org/help/nameserver-requirements 
 consolidates 
information from several RFCs, since the DNS has evolved over time.  
It is not an RFC, but a convenient summary. It primarily documents the 
tests performed by IANA when it processes a delegation change to the 
root, .INT, and .ARPA zones.  These tests validate conformance to the 
RFCs.  As the introduction says, "These tests do not measure against 
best practices or comprehensively measure protocol conformance. They 
are a practical set of baseline requirements that catch common 
misconfiguration errors that impact stable operations of the DNS."


Bottom line: two servers per zone are required by the DNS 
architecture.  It's not folklore.  It's not optional.



yes

It is true that the DNS is robust enough to function with a number of 
misconfigurations (including just one server for a zone, since in 
practice this is almost indistinguishable from transient conditions.)


Nonetheless, the goal of the DNS architecture (and most of its 
operators) is to have a stable and robust name service. 
Misconfigurations, such as those documented in rfc1527, make the DNS 
unstable and fragile.  The architecture tends to contain the effects 
of many misconfigurations, but that doesn't make them wise.


As I noted earlier: "DNS appears deceptively simple at first blush.  
Setting up a serviceable infrastructure requires an investment of 
thought and on-going maintenance.  You will not be happy if you skimp 
on that investment, since broken DNS is externally visible - and 
frequently catastrophic."


I'll finish with a 1987 quote from Leslie Lamport on distributed 
systems, which the DNS most certainly is:


"A distributed system is one in which the failure of a computer you 
didn't even know existed can render your own computer unusable."


Can the quibbling stop now?



thank you
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

BIND OS tuning

[Ben Croswell]

Does BIND take advantage of net.core.rmem_max on Linux boxes?
If I set the rmem_max to 12.5mb but leave the rmem_default as the OS
default will I see a benefit on a high QPS DNS server?

Or does BIND look to the rmem_default and ignore the rmem_max?

-- 
-Ben Croswell
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users