Re: Forwarders working differently on bind9.8 & bind9.11
Hi Prashasti.
I'm on my phone, so I'll keep it brief.
- ditch both 9.8 and 9.11; install 9.18
- why are you forwarding to yourself? 127.0.0.1
- get binary packet captures and look at them in Wireshark to see what's
actually going on.
- real IPs please.
- why use "port xxx"?
Cheers, Greg
On Tue, 19 Sep 2023, 12:28 Prashasti Arora,
wrote:
> I have configured a new zone to forward certain queries to my application
> on 2 VMs (One local and the other in my network) through a specific port. I
> have 2 similar setups - they are identical, except that one uses bind9.8
> and the other uses bind9.11. Configuration is also identical for both.
>
> On the first setup (using bind9.8): the traffic I send gets distributed
> uniformly.
> On the second setup (using bind9.11): the traffic gets distributed barely.
> 99% of the traffic is sent to one VM.
>
> I have verified that forwarding is working correctly on both, the issue is
> not with the application because both VMs on each setup can handle traffic
> individually, the firewall is not blocking the queries, and the
> configuration is correct.
>
> This is the zone:
>
> zone "example.com" IN {
> type forward;
> forwarders { 127.0.0.1 port xxx; a.b.c.d port xxx; };
> forward only;
> };
>
>
> Please share any other possible solutions.
> --
> 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
>
--
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: Forwarders working differently on bind9.8 & bind9.11
On Tue, Sep 19, 2023 at 7:28 AM Prashasti Arora
wrote:
I have configured a new zone to forward certain queries to my application
on 2 VMs (One local and the other in my network) through a specific port. I
have 2 similar setups - they are identical, except that one uses bind9.8
and the other uses bind9.11. Configuration is also identical for both.
On the first setup (using bind9.8): the traffic I send gets distributed
uniformly.
On the second setup (using bind9.11): the traffic gets distributed barely.
99% of the traffic is sent to one VM.
BIND wants to get responses as soon as possible, thus it queries servers who
respond fastest.
BIND keeps track of how fast servers are responding, and which server
responds faster, will get queries more often.
Time to time, BIND re-checks other servers to see if they perform better,
because that can change over time.
What is the problem?
I have verified that forwarding is working correctly on both, the issue is
not with the application because both VMs on each setup can handle traffic
individually, the firewall is not blocking the queries, and the
configuration is correct.
This is the zone:
zone "example.com" IN {
type forward;
forwarders { 127.0.0.1 port xxx; a.b.c.d port xxx; };
forward only;
};
Please share any other possible solutions.
On 19.09.23 08:25, Bob Harold wrote:
Note that the 'forwarders' line, from the BIND 9.11 manual: "There may be
one or more forwarders, and they are queried in turn until the list is
exhausted
or an answer is found." So the first one will get all the traffic, the
second is just a backup to be used if the first fails.
If you expect that to do load balancing, it will not. Try a real load
balancer, or 'dnsdist'.
I think this behaviour changed to the one I described above a long time ago.
Perhaps after BIND 9.8
--
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.
Support bacteria - they're the only culture some people have.
--
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: Forwarders working differently on bind9.8 & bind9.11
On Tue, Sep 19, 2023 at 7:28 AM Prashasti Arora
wrote:
> I have configured a new zone to forward certain queries to my application
> on 2 VMs (One local and the other in my network) through a specific port. I
> have 2 similar setups - they are identical, except that one uses bind9.8
> and the other uses bind9.11. Configuration is also identical for both.
>
> On the first setup (using bind9.8): the traffic I send gets distributed
> uniformly.
> On the second setup (using bind9.11): the traffic gets distributed barely.
> 99% of the traffic is sent to one VM.
>
> I have verified that forwarding is working correctly on both, the issue is
> not with the application because both VMs on each setup can handle traffic
> individually, the firewall is not blocking the queries, and the
> configuration is correct.
>
> This is the zone:
>
> zone "example.com" IN {
> type forward;
> forwarders { 127.0.0.1 port xxx; a.b.c.d port xxx; };
> forward only;
> };
>
>
> Please share any other possible solutions.
> --
>
Note that the 'forwarders' line, from the BIND 9.11 manual: "There may be
one or more forwarders, and they are queried in turn until the list is
exhausted
or an answer is found." So the first one will get all the traffic, the
second is just a backup to be used if the first fails.
If you expect that to do load balancing, it will not. Try a real load
balancer, or 'dnsdist'.
---
Bob Harold
--
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
Forwarders working differently on bind9.8 & bind9.11
I have configured a new zone to forward certain queries to my application
on 2 VMs (One local and the other in my network) through a specific port. I
have 2 similar setups - they are identical, except that one uses bind9.8
and the other uses bind9.11. Configuration is also identical for both.
On the first setup (using bind9.8): the traffic I send gets distributed
uniformly.
On the second setup (using bind9.11): the traffic gets distributed barely.
99% of the traffic is sent to one VM.
I have verified that forwarding is working correctly on both, the issue is
not with the application because both VMs on each setup can handle traffic
individually, the firewall is not blocking the queries, and the
configuration is correct.
This is the zone:
zone "example.com" IN {
type forward;
forwarders { 127.0.0.1 port xxx; a.b.c.d port xxx; };
forward only;
};
Please share any other possible solutions.
--
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
interpretation of timeout errors from forwarders
Hello,
in the logs I see occasionally entries like this, for various remote zones:
2023-07-24T08:37:30.531Z query-errors: info: client @0x7feaf40cd570
1.2.3.4#45736 (push.services.mozilla.com): query failed (timed out) for
push.services.mozilla.com/IN/A at query.c:7465
The named version 9.16.42 serves its local DNS zone, everything else is
supposed to come from the IT DNS servers. Therefore named.conf contains:
options {
forward only;
forwarders { ip4A; ip4B; }
};
It is my understanding that this local instance serves client queries either
from its cache, or it relies on the two forwarders to provide an answer. It
should not try to find an answer itself, because if the forwarders fail to find
an answer, this instance will most likely fail to do so as well.
Now the questions are: does named contact both forwarders for an answer at the
same time, or one after the other, or just a single one of both? In case one
times out like shown above, will it ask the other one?
Thanks,
Olaf
pgpw8tL8HuaS5.pgp
Description: Digitale Signatur von OpenPGP
--
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: named failed to resolve forwarding queries(with global forwarders specified with "forward only") when "server section statement" has forwarder IP
Thanks a lot for your quick response. Your answer is helpful. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Wed, Nov 24, 2021 at 4:22 PM Tony Finch wrote: > Nagesh Thati wrote: > > > > Can anyone tell me why I am getting tsig errors and SERVFAIL errors for > > non managed zones? Why named using the "server statement" TSIG key in > > forwarding queries instead of using this TSIG only for ixfr/axfr? > > TSIG is a bit confusing to set up because there are a bunch of options > and the use-cases and pros and cons can be unclear. > > The `server` clause has a grab-bag of options that you can specify about > other nameservers that your server might communicate with for whatever > reason. If you configure a TSIG key in a `server` clause, it is used for > all traffic with that server. (There will normally be a corresponding > config on the other server for traffic in the opposite direction.) It's > convenient to use for traffic between authoritative servers, because it > gives you one place to secure refresh queries, notifies, and zone > transfers. But in a more complicated configuration like yours it can have > an unwanted effect on other traffic. > > Another approach is to configure TSIG for each kind of traffic separately. > More explicit, but more verbose. The way I like to do this is to have > `acl` clauses with helpful names, which can then be used in allow-notify > and allow-transfer options to require TSIG for incoming requests; and > corresponding top-level `primaries` clauses for use in per-zone > `primaries` and/or `also-notify` clauses for outgoing requests. I can put > all this access control stuff into a shared config file used on all my > servers, and the authoritative TSIG stuff will not affect recursive > queries. > > (For example, at Cambridge we have a mutual secondarying arrangement with > Imperial College with TSIG and IPv6 and DNSSEC and all that good stuff; > our recursive servers don't know anything special about the Imperial > zones, and we don't need or want recursive queries between us to use TSIG. > Our recursive servers still have the same shared access control config, > but the Imperial parts are not used there, because none of the zone > clauses refer to the Imperial acl/primaries names.) > > This kind of explicit TSIG configuration doesn't work in all cases: for > instance, you can't specify TSIG keys in the `forwarders` clause, so you > have to use a `server` clause to configure TSIG for forwarding. > > I haven't answered your specific questions because I'm not sure I > understand the details of your setup properly, but I hope this more > general answer is helpful. > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > harness technological change to human advantage > > ___ 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: named failed to resolve forwarding queries(with global forwarders specified with "forward only") when "server section statement" has forwarder IP
Nagesh Thati wrote: > > Can anyone tell me why I am getting tsig errors and SERVFAIL errors for > non managed zones? Why named using the "server statement" TSIG key in > forwarding queries instead of using this TSIG only for ixfr/axfr? TSIG is a bit confusing to set up because there are a bunch of options and the use-cases and pros and cons can be unclear. The `server` clause has a grab-bag of options that you can specify about other nameservers that your server might communicate with for whatever reason. If you configure a TSIG key in a `server` clause, it is used for all traffic with that server. (There will normally be a corresponding config on the other server for traffic in the opposite direction.) It's convenient to use for traffic between authoritative servers, because it gives you one place to secure refresh queries, notifies, and zone transfers. But in a more complicated configuration like yours it can have an unwanted effect on other traffic. Another approach is to configure TSIG for each kind of traffic separately. More explicit, but more verbose. The way I like to do this is to have `acl` clauses with helpful names, which can then be used in allow-notify and allow-transfer options to require TSIG for incoming requests; and corresponding top-level `primaries` clauses for use in per-zone `primaries` and/or `also-notify` clauses for outgoing requests. I can put all this access control stuff into a shared config file used on all my servers, and the authoritative TSIG stuff will not affect recursive queries. (For example, at Cambridge we have a mutual secondarying arrangement with Imperial College with TSIG and IPv6 and DNSSEC and all that good stuff; our recursive servers don't know anything special about the Imperial zones, and we don't need or want recursive queries between us to use TSIG. Our recursive servers still have the same shared access control config, but the Imperial parts are not used there, because none of the zone clauses refer to the Imperial acl/primaries names.) This kind of explicit TSIG configuration doesn't work in all cases: for instance, you can't specify TSIG keys in the `forwarders` clause, so you have to use a `server` clause to configure TSIG for forwarding. I haven't answered your specific questions because I'm not sure I understand the details of your setup properly, but I hope this more general answer is helpful. Tony. -- f.anthony.n.finchhttps://dotat.at/ harness technological change to human advantage ___ 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
named failed to resolve forwarding queries(with global forwarders specified with "forward only") when "server section statement" has forwarder IP
Hi,
I have a BIND master server(10.1.10.110) and slave server(Recursive,
10.1.10.120) and also a global forwarding to another server for non managed
domains.
Forwarding server(10.1.10.25) also a slave for example1.com and example2.com,
which will get zone transfers from BIND slave server.
Below is my named.conf configuration, in the config, for secure zone
transfers I am using "server statement" with a TSIG communication key. With
this configuration when named is loaded in the BIND slave server,
I can only resolve exmple1.com and example2.com on BIND slave server
(10.1.10.120), for other non managed domains I see *SERVFAIL errors*.
Can anyone tell me why I am getting* tsig errors and SERVFAIL errors* for
non managed zones? Why named using the "server statement" TSIG key in
forwarding queries instead of using this TSIG only for ixfr/axfr?
*BIND AUTH Master IP: 10.1.10.110BIND AUTH Slave IP: 10.1.10.120Forwarder
IP: 10.1.10.25*
*named.conf:*
#-
# ACLs
#-
*acl "transfer-core-dns" { 10.1.10.25};*
#-
# Key Definition
#-
key "RNDC-KEY" {
algorithm HMAC-SHA512;
secret
"ykLMNmAECOp4fcBMqIddG17Ubo4sTvm1zb5YSh7HvEjP8F2f+XU9uavOx4hoVBKANDY0tJIRlNOI8U8LaJunDg==";
};
#-
# Controls Definition
#-
acl "RNDC-USERS" {
127.0.0.1;
localhost;
};
controls {
inet 127.0.0.1 port 953 allow { RNDC-USERS; } keys { "RNDC-KEY";};
};
#-
# Logging Definition
#-
logging {
channel named {
file "/var/named/log/named.log" versions 10 size 100M;
severity dynamic;
print-category yes;
print-severity yes;
print-time yes;
};
category default {
named;
};
};
#-
# Global Options
#-
options {
directory "/";
allow-query {any;};
allow-transfer {none;};
blackhole {none;};
dnssec-enable yes;
dnssec-validation no;
listen-on-v6 {none;};
check-srv-cname ignore;
check-mx-cname ignore;
check-mx ignore;
check-names master ignore;
check-names response ignore;
dump-file "/var/named/log/named_dump.db";
lame-ttl 600;
max-ncache-ttl 10800;
minimal-responses yes;
pid-file "/var/run/named/named.pid";
recursion yes;
session-keyfile "/var/run/named/session.key";
statistics-file "/var/named/log/named.stats";
tcp-clients 1000;
zone-statistics yes;
empty-zones-enable no;
rrset-order {
order cyclic;
};
transfers-in 50;
transfers-out 30;
transfers-per-ns 30;
no-case-compress {any; };
allow-recursion {any;};
recursive-clients 1;
* forward only; forwarders {10.1.10.25;};*
flush-zones-on-shutdown yes;
};
#-
# Statistics Section
#-
statistics-channels {
inet 127.0.0.1 port 8080 allow { 127.0.0.1; };
};
#-
# Server Definition
#-
key "COMMUNICATION-KEY" {
algorithm HMAC-SHA512;
secret
"1HVF90bx+6ywx5Ovr1SOCcL2inTDc0gYRoG6BK/TU+g8tAr3j0ptJsZ6OjfNxEYcMGDRt5m5z/it1gPe7+jJqA==";
};
*server 10.1.10.25 { keys "COMMUNICATION-KEY"; provide-ixfr yes;
request-ixfr yes;};*
#-
# Zone Section
#-
zone "." IN { type hint; file "/var/named/zones/masters/db.cache"; };
zone "example1.com" IN {
type slave;
file "/var/named/zones/slaves/db.example1.com";
* allow-transfer {transfer-core-dns;};*
allow-notify {10.1.10.110;};
notify yes;
masters {
10.1.10.110;
};
check-names ignore;
zone-statistics yes;
forwarders {};
};
zone "example2.com" IN {
type slave;
file "/var/named/zones/slaves/db.example2.com";
allow-transfer {transfer-core-dns;};
allow-notify {10.1.10.110;};
notify yes;
masters {
10.1.10.110;
};
check-names ignore;
zone-statistics yes;
forwarders {};
};
*named.log:*
client: error: query (google.com/NS): query_find: *unexpected error after
resuming: tsig indicates error*
query-errors: info: (google.com): *query failed (SERVFAIL) *for
google.com/IN/NS at query.c:8678
client: error: query (google.com/MX): query_find: unexpected error after
resuming: tsig indicates error
query-errors: info: (google.com): query failed (SERVFAIL) for
google.com/IN/MX at query.c:8678
query-errors: info: (google.com): query failed (SERVFAIL) for
google.com/IN/A at query.c:7118
query-errors: info: (google.com): query failed (SERVFAIL) for
google.com/IN/A at query.c:7118
query-errors: info: (google.com): query failed (SERVFAIL) for
google.com/IN/NS at query.c:7118
query-errors: info: (google.com): query failed (SERVFAIL) for
google.com/IN/MX at query.c:7118
___
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: How to measure use of forwarders?
Hello Richard, "Parkin, Richard (R.)" writes: Hello! We recently re-addressed some of our external-facing cache servers into a new network and discovered that our IPs appear to be blackholed going to certain third-party auth servers, either intentionally or unintentionally. Our workaround while we sort through these issues is implementing forwarders. I’d like to understand how much traffic is flowing to each forwarder (QPS, etc) and monitor that for any issues. Is there a way to do that effectively in Bind without putting some kind of network device on the outbound path to measure it? If not, does anyone have any suggestions? I've done a webinar this week for ISC on the topic of "Instrumenting BIND 9 on Linux with BCC/eBPF". In this webinar, I've used logging of forwarding decisions as one example to instrument BIND 9 with eBPF. The bpftrace script I've presented might work as a starting point to create custom BIND 9 logging for forwarding operations, which does not slow down the operation of the BIND 9 server itself. A recording of the webinar is available at <https://www.youtube.com/watch?v=VYpZg89NJeA> Greetings Carsten ___ 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: How to measure use of forwarders?
Parkin, Richard (R.) wrote: > > I’d like to understand how much traffic is flowing to each forwarder > (QPS, etc) and monitor that for any issues. Is there a way to do that > effectively in Bind without putting some kind of network device on the > outbound path to measure it? If not, does anyone have any suggestions? One option is dnstap, though you will need to do your own scripting to get the numbers you are interested in. You can configure dnstap to log only forwarded queries so it doesn't have to drink the whole firehose. Tony. -- f.anthony.n.finchhttps://dotat.at/ Irish Sea, Shannon: West or southwest 4 to 6. Moderate or rough in Shannon, slight or moderate in Irish Sea. Occasional drizzle. Good occasionally poor. ___ 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
How to measure use of forwarders?
Hello! We recently re-addressed some of our external-facing cache servers into a new network and discovered that our IPs appear to be blackholed going to certain third-party auth servers, either intentionally or unintentionally. Our workaround while we sort through these issues is implementing forwarders. I’d like to understand how much traffic is flowing to each forwarder (QPS, etc) and monitor that for any issues. Is there a way to do that effectively in Bind without putting some kind of network device on the outbound path to measure it? If not, does anyone have any suggestions? Thanks in advance! -- Rich Parkin ___ 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: forwarders used in order or based on RTT ?
On Mon, Oct 19, 2020 at 11:26 AM Victoria Risk wrote: > > The ARM was updated in 9.16.6. Sorry it took us so long! > > from https://gitlab.isc.org/isc-projects/bind9/-/issues/2030 > Forwarders are typically used when an administrator does not wish for > all the servers at a given site to interact directly with the rest of > the Internet. For example, a common scenario is when multiple internal > DNS servers are behind an Internet firewall. Servers behind the firewall > forward their requests to the server with external access, which queries > Internet DNS servers on the internal servers' behalf. > > Another scenario (largely now superseded by Response Policy Zones) is to > send queries first to a custom server for RBL processing before > forwarding them to the wider Internet. > > There may be one or more forwarders in a given setup. The order in which > the forwarders are listed in ``named.conf`` does not determine the > sequence in which they are queried; rather, ``named`` uses the response > times from previous queries to select the server that is likely to > respond the most quickly. A server that has not yet been queried is > given an initial small random response time to ensure that it is tried > at least once. Dynamic adjustment of the recorded response times ensures > that all forwarders are queried, even those with slower response times. > This permits changes in behavior based on server responsiveness. Awesome, thank you -- that's clean and easy to understand. W > > Vicky > ___ > 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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: forwarders used in order or based on RTT ?
The ARM was updated in 9.16.6. Sorry it took us so long! from https://gitlab.isc.org/isc-projects/bind9/-/issues/2030 Forwarders are typically used when an administrator does not wish for all the servers at a given site to interact directly with the rest of the Internet. For example, a common scenario is when multiple internal DNS servers are behind an Internet firewall. Servers behind the firewall forward their requests to the server with external access, which queries Internet DNS servers on the internal servers' behalf. Another scenario (largely now superseded by Response Policy Zones) is to send queries first to a custom server for RBL processing before forwarding them to the wider Internet. There may be one or more forwarders in a given setup. The order in which the forwarders are listed in ``named.conf`` does not determine the sequence in which they are queried; rather, ``named`` uses the response times from previous queries to select the server that is likely to respond the most quickly. A server that has not yet been queried is given an initial small random response time to ensure that it is tried at least once. Dynamic adjustment of the recorded response times ensures that all forwarders are queried, even those with slower response times. This permits changes in behavior based on server responsiveness. Vicky ___ 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: forwarders used in order or based on RTT ?
On Sun, Oct 18, 2020 at 2:32 PM @lbutlr wrote: > > On 16 Oct 2020, at 08:36, Bob Harold wrote: > > That is certainly not obvious. How do I request improving the manual? > > > > "in turn" would seem to imply "in order", and the order would logically be > > the order I listed them.] > > I disagree. In turn means one is tried, then if that fails the next is tried. > There is no implication at all that the order they are tried in is the order > specified. > > It would not hurt anything to say they were tried in turn accords to RTT, but > as it stands the documentation doesn’t say what you think it says. > > Again, "in turn" doesn’t mean "in the order I expect" it simply means one > after another until all are checked (or one succeeds). "In turn" might not strictly mean in the order listed (the definitions converge around 1: "in succession", or 2: a causal step from a previous outcome), but there is *implication* that it is in the order listed. If I said "The carolers visited the houses in turn", the *implication* is that they visited the first house, then the second, then the third, etc and not the first, then the seventeenth, etc. Yes, there is ambiguity - it appears that this usage is that the succession is "in RTT order", and not "in listed order", but the fact that it is ambiguous, and people are unsure what is meant, demonstrates a bug in the documentation. W > > > -- > "Are you pondering what I'm pondering?" > "Wuh, I think so, Brain, but I prefer Space Jelly." > > ___ > 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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: forwarders used in order or based on RTT ?
On 16 Oct 2020, at 08:36, Bob Harold wrote: > That is certainly not obvious. How do I request improving the manual? > > "in turn" would seem to imply "in order", and the order would logically be > the order I listed them.] I disagree. In turn means one is tried, then if that fails the next is tried. There is no implication at all that the order they are tried in is the order specified. It would not hurt anything to say they were tried in turn accords to RTT, but as it stands the documentation doesn’t say what you think it says. Again, "in turn" doesn’t mean "in the order I expect" it simply means one after another until all are checked (or one succeeds). -- "Are you pondering what I'm pondering?" "Wuh, I think so, Brain, but I prefer Space Jelly." ___ 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: forwarders used in order or based on RTT ?
On Fri, Oct 16, 2020 at 10:22 AM Matus UHLAR - fantomas wrote: >> On 16.10.20 09:56, Bob Harold wrote: > >The BIND ARM (9.16.2) says: > >"There may be one or more forwarders, and they are queried in turn until > >the list is exhausted or an answer is found." > > > >But [an old mailinglist post] says: > >"Forwarders are selected based on an RTT(round-trip-time)-based algorithm" > > > >So which is correct? > > both are. The ARM does not say they are queried in defined order. > The order is defined by RTT To be fair, the ARM strongly implies in its context that it's the order you put them in the list. The ARM discrepancy has already been noted by ISC, but the first bug report in the long long ago on it was never really fixed.They raised the issue again internally a few months ago and so I would anticipate that the ARM will be fixed in a not too distant release. https://gitlab.isc.org/isc-projects/bind9/-/issues/2030 ___ 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: forwarders used in order or based on RTT ?
That is certainly not obvious. How do I request improving the manual? "in turn" would seem to imply "in order", and the order would logically be the order I listed them. -- Bob Harold DNS and DHCP Hostmaster - UMNet Information and Technology Services (ITS) rharo...@umich.edu 734-512-7038 On Fri, Oct 16, 2020 at 10:21 AM Matus UHLAR - fantomas wrote: > On 16.10.20 09:56, Bob Harold wrote: > >The BIND ARM (9.16.2) says: > >"There may be one or more forwarders, and they are queried in turn until > >the list is exhausted > >or an answer is found." > > > >But > >https://lists.isc.org/pipermail/bind-users/2015-August/095544.html > >says: > >"Forwarders are selected based on an RTT(round-trip-time)-based algorithm" > > > >So which is correct? > > both are. The ARM does not say they are queried in defined order. > The order is defined by RTT > > >And did it change at some point? > > -- > 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. > Fucking windows! Bring Bill Gates! (Southpark the movie) > ___ > 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: forwarders used in order or based on RTT ?
On 16.10.20 09:56, Bob Harold wrote: The BIND ARM (9.16.2) says: "There may be one or more forwarders, and they are queried in turn until the list is exhausted or an answer is found." But https://lists.isc.org/pipermail/bind-users/2015-August/095544.html says: "Forwarders are selected based on an RTT(round-trip-time)-based algorithm" So which is correct? both are. The ARM does not say they are queried in defined order. The order is defined by RTT And did it change at some point? -- 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. Fucking windows! Bring Bill Gates! (Southpark the movie) ___ 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
forwarders used in order or based on RTT ?
The BIND ARM (9.16.2) says: "There may be one or more forwarders, and they are queried in turn until the list is exhausted or an answer is found." But https://lists.isc.org/pipermail/bind-users/2015-August/095544.html says: "Forwarders are selected based on an RTT(round-trip-time)-based algorithm" So which is correct? And did it change at some point? -- Bob Harold DNS and DHCP Hostmaster - UMNet Information and Technology Services (ITS) rharo...@umich.edu 734-512-7038 ___ 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: factor addresses out of 'forwarders' statement
On 18.07.19 13:24, John Thurston wrote:
I have a number of 'forward' zones defined. Many of them look exactly
the same except for their name. It would be helpful to abstract the
addresses of my forwarders out and name them only once. But I can't
find any way to do this.
An ACL doesn't make sense. A 'masters' list doesn't work.
Is there some way to do this?
alias { 10.10.1.2; 10.10.3.4; 10.10.5.6; }
zone "foo" {type forward; forwarders ( alias;}; };
do you really need to use "type forward" zone?
that's needed when the zone contains subzones you do not know or their
nameservers are unreachable.
If not, you can try using stub or static-stub zone and named masters list.
yes, this is case where it would be greas to use masters for forward zones.
--
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.
Eagles may soar, but weasels don't get sucked into jet engines.
___
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: factor addresses out of 'forwarders' statement
On 7/18/19 3:24 PM, John Thurston wrote:
I have a number of 'forward' zones defined. Many of them look exactly
the same except for their name. It would be helpful to abstract the
addresses of my forwarders out and name them only once. But I can't find
any way to do this.
An ACL doesn't make sense. A 'masters' list doesn't work.
Is there some way to do this?
alias { 10.10.1.2; 10.10.3.4; 10.10.5.6; }
zone "foo" {type forward; forwarders ( alias;}; };
Maybe.
Take a look at include statements.
You'll probably need to have the contents of the alias in it's own file:
--8<--
10.10.1.2; 10.10.3.4; 10.10.5.6;
-->8--
Then construct your zone statement a little bit differently.
--8<--
zone "foo" {type forward; forwarders (
include "/path/to/alias/file"
); };
-->8--
You are functionally doing what you want.
What you're really doing is manipulating text files that happen to be
the aggregate BIND config file.
You could probably move more of the duplicate part of the config into
the included file and have less to type for each zone.
Note: I've not tested this in a while, things may have changed since I
last tried this.
The other non-BIND option is to use some sort of pre-processor to
generate your BIND config file for you. I personally reach for M4 for
things like this. I can define a macro that accepts the zone name as a
parameter. Then I use the macro for each zone and let M4 stamp out the
necessary config lines for me. }:-)
Then there are the other zone loading methods, DLZ, catalog zones, etc.
--
Grant. . . .
unix || die
smime.p7s
Description: S/MIME Cryptographic 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
factor addresses out of 'forwarders' statement
I have a number of 'forward' zones defined. Many of them look exactly
the same except for their name. It would be helpful to abstract the
addresses of my forwarders out and name them only once. But I can't find
any way to do this.
An ACL doesn't make sense. A 'masters' list doesn't work.
Is there some way to do this?
alias { 10.10.1.2; 10.10.3.4; 10.10.5.6; }
zone "foo" {type forward; forwarders ( alias;}; };
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
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: Forwarders with static-stub
TBH, I haven't worked specifically with "static-stub", but with the classic
"stub", one would put a "null forwarders" statement in the zone definition
to inhibit forwarding.
I.e.
forwarders { };
- Kevin
On Wed, May 22, 2019 at 8:16 AM Ben Lavender wrote:
> Hi,
>
> When I setup static-stub zones with the global forwarders options
> configured, BIND by design forwards the requests before using the stubs.
>
> What is the best way around this so the stubs and cache are consulted
> first?
>
> This is required for split-brain DNS.
>
> Thanks
>
> Regards
>
> Ben Lavender
> ___
> 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
Forwarders with static-stub
Hi, When I setup static-stub zones with the global forwarders options configured, BIND by design forwards the requests before using the stubs. What is the best way around this so the stubs and cache are consulted first? This is required for split-brain DNS. Thanks Regards Ben Lavender ___ 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: Queries regarding forwarders
On 10/25/2018 06:26 PM, Lee wrote: If you're using those addresses internally it makes sense to filter them from 'outside'. That's what I thought. I play those games at times also :) So it sounds like what I was missing is that you like a challenge & are using more address space that I thought. Games are good learning opportunities. I don't know if I'm /using/ the address space per say or not. I do have 12 /24 non-globally routed networks that aren't from RFC 1918 address space. Mainly because I can and the address space makes it easy to do. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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: Queries regarding forwarders
On 10/25/18, Grant Taylor via bind-users wrote: > On 10/25/2018 03:25 PM, Lee wrote: > >> I'm missing what filtering out things like benchmarking & documentation >> network addrs gets you beyond maybe saving some bandwidth? > > I do use all sorts of IP ranges (test networks extensively) in my home / > lab networks. So I'd really rather external things not resolve to an > address that I may be using. But that's me being atypical. If you're using those addresses internally it makes sense to filter them from 'outside'. >> Same deal with using RPZ to block IPv4 BOGONs. What does RPZ blocking >> get you that you don't get by blocking them on your edge routers? > > Defense in depth. > > It's more of an exercise of can it be done. Read: Can I concoct > something that will receive feed from Team Cymru's BGP Bogon Rout Server > and turn it into an RPZ. I play those games at times also :) So it sounds like what I was missing is that you like a challenge & are using more address space that I thought. Regards, Lee ___ 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: Queries regarding forwarders
On 10/25/2018 03:25 PM, Lee wrote: I feel like I'm missing something :( I'll see if I can fill in below. I read this https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325 and used RPZ to block anything coming from outside that might be an internal address. I'll read that and reply later if I feel it's warranted. I'm missing what filtering out things like benchmarking & documentation network addrs gets you beyond maybe saving some bandwidth? Probably not much for most people. I do use all sorts of IP ranges (test networks extensively) in my home / lab networks. So I'd really rather external things not resolve to an address that I may be using. But that's me being atypical. Same deal with using RPZ to block IPv4 BOGONs. What does RPZ blocking get you that you don't get by blocking them on your edge routers? Defense in depth. It's more of an exercise of can it be done. Read: Can I concoct something that will receive feed from Team Cymru's BGP Bogon Rout Server and turn it into an RPZ. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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: Queries regarding forwarders
On 10/24/18, Grant Taylor via bind-users wrote: > On 08/09/2018 01:01 AM, Lee wrote: >> it does, so you have to flag your local zones as rpz-passthru. > > Thank you again Lee. You gave me exactly what I needed and wanted to know. you're welcome :) > I finally got around to configuring my RPZ to filter IPv4 > Special-Purpose Address Registry as per IANA's definition. > (https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml#iana-ipv4-special-registry-1) > > I am also happily using rpz-passthru for my local domain(s) that resolve > to filtered IPs. > > Now I'm pontificating augmenting my RPZ to also filter replies that > resolve to IPv4 BOGONs. (Received via BGP feed with Team Cymru.) I feel like I'm missing something :( I read this https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325 and used RPZ to block anything coming from outside that might be an internal address. I'm missing what filtering out things like benchmarking & documentation network addrs gets you beyond maybe saving some bandwidth? Same deal with using RPZ to block IPv4 BOGONs. What does RPZ blocking get you that you don't get by blocking them on your edge routers? Thanks, Lee ___ 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: Queries regarding forwarders
On 08/09/2018 01:01 AM, Lee wrote: it does, so you have to flag your local zones as rpz-passthru. Thank you again Lee. You gave me exactly what I needed and wanted to know. I finally got around to configuring my RPZ to filter IPv4 Special-Purpose Address Registry as per IANA's definition. (https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml#iana-ipv4-special-registry-1) I am also happily using rpz-passthru for my local domain(s) that resolve to filtered IPs. Now I'm pontificating augmenting my RPZ to also filter replies that resolve to IPv4 BOGONs. (Received via BGP feed with Team Cymru.) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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: Queries regarding forwarders
Well this is valid when users are directly talking to RPZ servers. What if there is one more resolver in between like Active Directory which itself acts as a DNS server? In that case I believe you don't need to do that, right? On Fri, Aug 10, 2018 at 12:33 AM Grant Taylor via bind-users < bind-users@lists.isc.org> wrote: > On 08/09/2018 01:01 AM, Lee wrote: > > yes, it works just fine > > Good. > > > it does, so you have to flag your local zones as rpz-passthru. eg: > > *.home.net CNAME rpz-passthru. > > localhost CNAME rpz-passthru. > > 8.0.0.0.127.rpz-ip CNAME . ; 127.0.0.0/8 > > 8.0.0.0.10.rpz-ip CNAME . ; 10.0.0.0/8 > > 12.0.0.16.172.rpz-ipCNAME . ; 172.16.0.0/12 > > 16.0.0.168.192.rpz-ip CNAME . ; 192.168.0.0/16 > > That makes sense. RPZ would filter the private IPs by default, but > zones with said records can be told to not be blocked by RPZ. > > Thank you for the clarification Lee. > > > > -- > Grant. . . . > unix || die > > ___ > 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: Queries regarding forwarders
On 08/09/2018 01:01 AM, Lee wrote: yes, it works just fine Good. it does, so you have to flag your local zones as rpz-passthru. eg: *.home.net CNAME rpz-passthru. localhost CNAME rpz-passthru. 8.0.0.0.127.rpz-ip CNAME . ; 127.0.0.0/8 8.0.0.0.10.rpz-ip CNAME . ; 10.0.0.0/8 12.0.0.16.172.rpz-ipCNAME . ; 172.16.0.0/12 16.0.0.168.192.rpz-ip CNAME . ; 192.168.0.0/16 That makes sense. RPZ would filter the private IPs by default, but zones with said records can be told to not be blocked by RPZ. Thank you for the clarification Lee. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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: Queries regarding forwarders
On 8/9/18, Grant Taylor via bind-users wrote: > On 08/08/2018 10:02 PM, Blason R wrote: >> Due to the architecture since I have my internal DNS RPZ built I wanted >> my other internal DNS servers should send traffic to RPZ server and >> then RPZ would resolve on behalf of client. > > Speaking of PRZ and forwarding… > > Does anyone know off hand if BIND, with RPZ configured to filter answers > that resolve to private IPs, can actually respond with private answers > from a local authoritative zone? yes, it works just fine > My long standing fear is that RPZ would filter replies from local > authoritative zones. it does, so you have to flag your local zones as rpz-passthru. eg: *.home.net CNAME rpz-passthru. localhost CNAME rpz-passthru. 8.0.0.0.127.rpz-ip CNAME . ; 127.0.0.0/8 8.0.0.0.10.rpz-ip CNAME . ; 10.0.0.0/8 12.0.0.16.172.rpz-ipCNAME . ; 172.16.0.0/12 16.0.0.168.192.rpz-ip CNAME . ; 192.168.0.0/16 Regards, Lee ___ 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: Queries regarding forwarders
On 08/08/2018 10:02 PM, Blason R wrote: Due to the architecture since I have my internal DNS RPZ built I wanted my other internal DNS servers should send traffic to RPZ server and then RPZ would resolve on behalf of client. Speaking of PRZ and forwarding… Does anyone know off hand if BIND, with RPZ configured to filter answers that resolve to private IPs, can actually respond with private answers from a local authoritative zone? My long standing fear is that RPZ would filter replies from local authoritative zones. Thus I would want my recursive resolver, hosting zones with private IPs, to forward to an RPZ server. Thus allowing me to return private IPs from authoritative zones while filtering private IPs from other external queries. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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: Queries regarding forwarders
Hi there, Due to the architecture since I have my internal DNS RPZ built I wanted my other internal DNS servers should send traffic to RPZ server and then RPZ would resolve on behalf of client. Client --->DNS AUTH Server for xyz.com===> Fporwarder ==> 192.168.3.44===> INTERNET On Wed, Aug 8, 2018 at 10:26 PM Matus UHLAR - fantomas wrote: > On 08.08.18 19:32, Blason R wrote: > >I am bit confused about DNS forwarders. I have two BIND Servers one is > >being used as Authoritative DNS server which has forwarder set > > why? > > > to other > >server like this > > > >Auth Server for xvyz.com 192.168.3.15 > >Recursive Server 192.168.3.44 > > > >Now if I am debugging from client side using -debug option I see > >192.168.3.15 is directly resolving with ROOT DNS Servers though I have > >recursive no; option set in my BIND config. > > BIND has internal list of root servers. > > > Ideally the query should have > >gone to 192.168.3.44 but in debug I am seeing the below output. > > ideally you would not use forwarder on BIND, unless you really must. > > > -- > 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. > If Barbie is so popular, why do you have to buy her friends? > ___ > 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: Queries regarding forwarders
On 08.08.18 19:32, Blason R wrote: I am bit confused about DNS forwarders. I have two BIND Servers one is being used as Authoritative DNS server which has forwarder set why? to other server like this Auth Server for xvyz.com 192.168.3.15 Recursive Server 192.168.3.44 Now if I am debugging from client side using -debug option I see 192.168.3.15 is directly resolving with ROOT DNS Servers though I have recursive no; option set in my BIND config. BIND has internal list of root servers. Ideally the query should have gone to 192.168.3.44 but in debug I am seeing the below output. ideally you would not use forwarder on BIND, unless you really must. -- 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. If Barbie is so popular, why do you have to buy her friends? ___ 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: Queries regarding forwarders
In article , Blason R wrote: > Hi there, > > I am bit confused about DNS forwarders. I have two BIND Servers one is > being used as Authoritative DNS server which has forwarder set to other > server like this > > Auth Server for xvyz.com 192.168.3.15 > Recursive Server 192.168.3.44 > > Now if I am debugging from client side using -debug option I see > 192.168.3.15 is directly resolving with ROOT DNS Servers though I have > recursive no; option set in my BIND config. Ideally the query should have > gone to 192.168.3.44 but in debug I am seeing the below output. The response says "recursion available". Are you sure you disabled recursion? Note that if you want to use forwarders, you have to enable recursion. Forwarding is only done when the server is recursing, it tells it to send to the forwarder instead of the servers named in the NS records. What makes you think the server is directly resolving instead of going to the forwarder? There's nothing in the response that tells you where it got the answer from. > > Well how do I trace if forwarding is happening? > > > C:\Users\Administrator>nslookup -type=a -debug www.cisco.com > > Got answer: > HEADER: > opcode = QUERY, id = 1, rcode = NOERROR > header flags: response, auth. answer, want recursion, recursion > questions = 1, answers = 1, authority records = 2, additional > > QUESTIONS: > 15.3.168.192.in-addr.arpa, type = PTR, class = IN > ANSWERS: > -> 15.3.168.192.in-addr.arpa > name = dns.xyz.com > ttl = 10800 (3 hours) > AUTHORITY RECORDS: > -> 3.168.192.in-addr.arpa > nameserver = dns02.xyz.com > ttl = 10800 (3 hours) > -> 3.168.192.in-addr.arpa > nameserver = dns.xyz.com > ttl = 10800 (3 hours) > ADDITIONAL RECORDS: > -> dns.xyz.com > internet address = 192.168.3.15 > ttl = 10800 (3 hours) > -> dns02.xyz.com > internet address = 192.168.3.14 > ttl = 10800 (3 hours) > > > Server: dns.xyz.com > Address: 192.168.3.15 > > > Got answer: > HEADER: > opcode = QUERY, id = 2, rcode = NOERROR > header flags: response, want recursion, recursion avail. > questions = 1, answers = 5, authority records = 13, additiona > > QUESTIONS: > www.cisco.com, type = A, class = IN > ANSWERS: > -> www.cisco.com > canonical name = www.cisco.com.akadns.net > ttl = 838 (13 mins 58 secs) > -> www.cisco.com.akadns.net > canonical name = wwwds.cisco.com.edgekey.net > ttl = 299 (4 mins 59 secs) > -> wwwds.cisco.com.edgekey.net > canonical name = wwwds.cisco.com.edgekey.net.globalredir.akadns. > ttl = 14531 (4 hours 2 mins 11 secs) > -> wwwds.cisco.com.edgekey.net.globalredir.akadns.net > canonical name = e2867.dsca.akamaiedge.net > ttl = 3599 (59 mins 59 secs) > -> e2867.dsca.akamaiedge.net > internet address = 23.57.126.108 > ttl = 19 (19 secs) > AUTHORITY RECORDS: > -> net > nameserver = a.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = l.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = e.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = i.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = d.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = f.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = b.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = h.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = g.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = c.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = k.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = j.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > -> net > nameserver = m.gtld-servers.net > ttl = 4663 (1 hour 17 mins 43 secs) > ADDITIONAL RECORDS: > -> m.gtld-servers.net > internet address = 192
Queries regarding forwarders
Hi there, I am bit confused about DNS forwarders. I have two BIND Servers one is being used as Authoritative DNS server which has forwarder set to other server like this Auth Server for xvyz.com 192.168.3.15 Recursive Server 192.168.3.44 Now if I am debugging from client side using -debug option I see 192.168.3.15 is directly resolving with ROOT DNS Servers though I have recursive no; option set in my BIND config. Ideally the query should have gone to 192.168.3.44 but in debug I am seeing the below output. Well how do I trace if forwarding is happening? C:\Users\Administrator>nslookup -type=a -debug www.cisco.com Got answer: HEADER: opcode = QUERY, id = 1, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion questions = 1, answers = 1, authority records = 2, additional QUESTIONS: 15.3.168.192.in-addr.arpa, type = PTR, class = IN ANSWERS: -> 15.3.168.192.in-addr.arpa name = dns.xyz.com ttl = 10800 (3 hours) AUTHORITY RECORDS: -> 3.168.192.in-addr.arpa nameserver = dns02.xyz.com ttl = 10800 (3 hours) -> 3.168.192.in-addr.arpa nameserver = dns.xyz.com ttl = 10800 (3 hours) ADDITIONAL RECORDS: -> dns.xyz.com internet address = 192.168.3.15 ttl = 10800 (3 hours) -> dns02.xyz.com internet address = 192.168.3.14 ttl = 10800 (3 hours) Server: dns.xyz.com Address: 192.168.3.15 Got answer: HEADER: opcode = QUERY, id = 2, rcode = NOERROR header flags: response, want recursion, recursion avail. questions = 1, answers = 5, authority records = 13, additiona QUESTIONS: www.cisco.com, type = A, class = IN ANSWERS: -> www.cisco.com canonical name = www.cisco.com.akadns.net ttl = 838 (13 mins 58 secs) -> www.cisco.com.akadns.net canonical name = wwwds.cisco.com.edgekey.net ttl = 299 (4 mins 59 secs) -> wwwds.cisco.com.edgekey.net canonical name = wwwds.cisco.com.edgekey.net.globalredir.akadns. ttl = 14531 (4 hours 2 mins 11 secs) -> wwwds.cisco.com.edgekey.net.globalredir.akadns.net canonical name = e2867.dsca.akamaiedge.net ttl = 3599 (59 mins 59 secs) -> e2867.dsca.akamaiedge.net internet address = 23.57.126.108 ttl = 19 (19 secs) AUTHORITY RECORDS: -> net nameserver = a.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = l.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = e.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = i.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = d.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = f.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = b.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = h.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = g.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = c.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = k.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = j.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) -> net nameserver = m.gtld-servers.net ttl = 4663 (1 hour 17 mins 43 secs) ADDITIONAL RECORDS: -> m.gtld-servers.net internet address = 192.55.83.30 ttl = 103500 (1 day 4 hours 45 mins) -> m.gtld-servers.net IPv6 address = 2001:501:b1f9::30 ttl = 163960 (1 day 21 hours 32 mins 40 secs) -> d.gtld-servers.net internet address = 192.31.80.30 ttl = 77579 (21 hours 32 mins 59 secs) Non-authoritative answer: Name:e2867.dsca.akamaiedge.net Address: 23.57.126.108 Aliases: www.cisco.com www.cisco.com.akadns.net wwwds.cisco.com.edgekey.net wwwds.cisco.com.edgekey.net.globalredir.akadns.net C:\Users\Administrator> ** ___ 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: Why would a master zone use forwarders ?
Thank you Ben,"With no forward {} the path for blah.bar.foo.com directed at
server A will be A > C > B"Do you see any reason why I would use this non
optimal path ?
In your example, how would C contact B, there would be a zone forward ?Regards
Le Vendredi 12 mai 2017 18h10, Ben Croswell a
écrit :
If you load foo.com on server A and delegate bar.foo.com to server B with a
global forwarder of server C you resolution will vary depending on forward
first vs forward only and forwarders {}.
With no forward {} the path for blah.bar.foo.com directed at server A will be A
> C > BWith forward {} the global forward will be short circuited for foo.com
and below resulting in a path of A > B
On May 12, 2017 11:56 AM, "Mik J" wrote:
Thank you Ben for your answer
My server uses a global forwarding
I don't understand what you wrote"If it is master for a foo.com and also has
global forwarding it will use the global forward for any delegated child
domains under foo.com unless they are also loaded locally."
If my DNS is autoritative, why would I use a forwarding ?
For my sub domains I use delegationssub.mydomain.com NS
ns.sub.mydomain.comns.sub.mydomain.com A 1.1.1.1
What's the difference between the global forward for delegated child domains
and the delegation I do ?
Thank you
Le Vendredi 12 mai 2017 15h34, Ben Croswell a
écrit :
This would only change behavior if the server has global forwarding.
If it is master for a foo.com and also has global forwarding it will use the
global forward for any delegated child domains under foo.com unless they are
also loaded locally. The forward{} turns off global forwarding for that branch
of the tree.
On May 12, 2017 9:27 AM, "Mik J via bind-users"
wrote:
Hello,
If my DNS is master/slave for a zone, why would I want it to use forwarders.
In other terms why would I wantzone "mydomain.com"
{
type master;
file "zones/master/com/mydomain.com ";
allow-update { acl; };
};
Instead of (forwarders {};)zone "mydomain.com"
{
type master;
file "zones/master/com/mydomain.com ";
allow-update { acl; }; forwarders {};};
Why would I want to forward requests if I'm autoritative for the zone ?
Thank you for those who can hightligh this 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
___
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: Why would a master zone use forwarders ?
If you load foo.com on server A and delegate bar.foo.com to server B with a
global forwarder of server C you resolution will vary depending on forward
first vs forward only and forwarders {}.
With no forward {} the path for blah.bar.foo.com directed at server A will
be A > C > B
With forward {} the global forward will be short circuited for foo.com and
below resulting in a path of A > B
On May 12, 2017 11:56 AM, "Mik J" wrote:
Thank you Ben for your answer
My server uses a global forwarding
I don't understand what you wrote
"If it is master for a foo.com and also has global forwarding it will use
the global forward for any delegated child domains under foo.com unless
they are also loaded locally."
If my DNS is autoritative, why would I use a forwarding ?
For my sub domains I use delegations
sub.mydomain.com NS ns.sub.mydomain.com
ns.sub.mydomain.com A 1.1.1.1
What's the difference between the global forward for delegated child
domains and the delegation I do ?
Thank you
Le Vendredi 12 mai 2017 15h34, Ben Croswell a
écrit :
This would only change behavior if the server has global forwarding.
If it is master for a foo.com and also has global forwarding it will use
the global forward for any delegated child domains under foo.com unless
they are also loaded locally. The forward{} turns off global forwarding
for that branch of the tree.
On May 12, 2017 9:27 AM, "Mik J via bind-users"
wrote:
Hello,
If my DNS is master/slave for a zone, why would I want it to use forwarders.
In other terms why would I want
zone "mydomain.com"
{
type master;
file "zones/master/com/mydomain.com ";
allow-update { acl; };
};
Instead of (forwarders {};)
zone "mydomain.com"
{
type master;
file "zones/master/com/mydomain.com ";
allow-update { acl; };
forwarders {};
};
Why would I want to forward requests if I'm autoritative for the zone ?
Thank you for those who can hightligh this point.
__ _
Please visit https://lists.isc.org/mailman/ listinfo/bind-users
<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
<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: Why would a master zone use forwarders ?
Thank you Ben for your answer
My server uses a global forwarding
I don't understand what you wrote"If it is master for a foo.com and also has
global forwarding it will use the global forward for any delegated child
domains under foo.com unless they are also loaded locally."
If my DNS is autoritative, why would I use a forwarding ?
For my sub domains I use delegationssub.mydomain.com NS
ns.sub.mydomain.comns.sub.mydomain.com A 1.1.1.1
What's the difference between the global forward for delegated child domains
and the delegation I do ?
Thank you
Le Vendredi 12 mai 2017 15h34, Ben Croswell a
écrit :
This would only change behavior if the server has global forwarding.
If it is master for a foo.com and also has global forwarding it will use the
global forward for any delegated child domains under foo.com unless they are
also loaded locally. The forward{} turns off global forwarding for that branch
of the tree.
On May 12, 2017 9:27 AM, "Mik J via bind-users"
wrote:
Hello,
If my DNS is master/slave for a zone, why would I want it to use forwarders.
In other terms why would I wantzone "mydomain.com"
{
type master;
file "zones/master/com/mydomain.com ";
allow-update { acl; };
};
Instead of (forwarders {};)zone "mydomain.com"
{
type master;
file "zones/master/com/mydomain.com ";
allow-update { acl; }; forwarders {};};
Why would I want to forward requests if I'm autoritative for the zone ?
Thank you for those who can hightligh this 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
___
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: Why would a master zone use forwarders ?
This would only change behavior if the server has global forwarding.
If it is master for a foo.com and also has global forwarding it will use
the global forward for any delegated child domains under foo.com unless
they are also loaded locally. The forward{} turns off global forwarding
for that branch of the tree.
On May 12, 2017 9:27 AM, "Mik J via bind-users"
wrote:
> Hello,
>
> If my DNS is master/slave for a zone, why would I want it to use
> forwarders.
>
> In other terms why would I want
> zone "mydomain.com"
> {
> type master;
> file "zones/master/com/mydomain.com";
> allow-update { acl; };
> };
>
> Instead of (forwarders {};)
> zone "mydomain.com"
> {
> type master;
> file "zones/master/com/mydomain.com";
> allow-update { acl; };
> forwarders {};
> };
>
> Why would I want to forward requests if I'm autoritative for the zone ?
>
> Thank you for those who can hightligh this 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
>
___
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
Why would a master zone use forwarders ?
Hello,
If my DNS is master/slave for a zone, why would I want it to use forwarders.
In other terms why would I wantzone "mydomain.com"
{
type master;
file "zones/master/com/mydomain.com";
allow-update { acl; };
};
Instead of (forwarders {};)zone "mydomain.com"
{
type master;
file "zones/master/com/mydomain.com";
allow-update { acl; }; forwarders {};};
Why would I want to forward requests if I'm autoritative for the zone ?
Thank you for those who can hightligh this 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: Question about forwarders option access
Hi, Steve Thanks for comments! I was mistaken, recheck packet capture results, it was query to all server access in configuration. I thought single server access on first capture results But, I think better to more hight cache hit rate by sequential access(e.g. first access is static). However, Access to all servers (calculate the RTT) is more better? Thanks 2016-11-14 16:54 GMT+09:00 S Carr : > On 14 November 2016 at 02:54, Techs-yama wrote: >> Does not this configuration parameter [server address] is sequential access? > > No, it will use both, it will calculate the RTT for both servers and > work out which one is responding faster and use that one for the > majority of the queries, every so often it will then retry all servers > to revalidate RTT. > > Steve ___ 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: Question about forwarders option access
On 14 November 2016 at 02:54, Techs-yama wrote: > Does not this configuration parameter [server address] is sequential access? No, it will use both, it will calculate the RTT for both servers and work out which one is responding faster and use that one for the majority of the queries, every so often it will then retry all servers to revalidate RTT. Steve ___ 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 forwarders option access
Hi, bind-users All.
I have question about "global forwarders option" in named.conf,
For example,
forwarders {
1.1.1.1;
2.2.2.2;
};
I tried packet capture in this server on dig query,
However, I looked like destination server access is randomized.
looked like
1.1.1.1 -> 2.2.2.2 -> 1.1.1.1 -> 1,1,1,1 -> 1.1.1.1
Does not this configuration parameter [server address] is sequential access?
___
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: forwarders (IPv6)
In message
<3c929ce024ce174480d567360a8291b1ee69071...@hq1-mailmb-v1.trade.ftc.gov>,
"Chakrapani, Praveen CTR via bind-users" writes:
>
> Hi,
>
> I added below line to my named.conf to include IPv6 addresses to the
> forwarders list. However I am getting this error "Sep 13 10:33:06
> servername named[24778]: [ID 873579 daemon.error] /etc/named.conf:158:
> expected IP address near '2001:1890:1C04:3000:0CB7:4432'"
>
> "forwarders { 12.227.230.4; 12.227.230.10; 12.183.68.50; 12.183.68.51;
> 12.71.76.50; 12.71.76.51; 2001:1890:1C04:3000:0CB7:4432;
> 2001:1890:1C04:3000:0CB7:4433; 2001:1890:1C04:3400:0C47:4C32;
> 2001:1890:1C04:3400:0C47:4C33; };
> forward first;"
>
> Please let know how to add IPv6 addresses to the forwarders list.
Add a syntactically valid IPv6 address. 2001:1890:1C04:3000:0CB7:4432
is NOT a valid IPv6 address. It's missing 32 bits of the address.
Did you mean 2001:1890:1C04:3000::0CB7:4432 perhaps as you seem to
be encoding the IPv4 addresses in the last 32 bits? Note the
double "::" signifying 32 zero bits in this case.
Mark
> Thanks,
> Praveen Kumar Chakrapani (CTR)
> AECOM Contractor, Lead UNIX Administrator
> Desk (202)326-3282
--
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
Re: forwarders (IPv6)
I added below line to my named.conf to include IPv6 addresses to the forwarders list. However I am getting this error *“Sep 13 10:33:06 servername named[24778]: [ID 873579 daemon.error] /etc/named.conf:158: expected IP address near '2001:1890:1C04:3000:0CB7:4432'”* That's because it's not a valid representation of an IPv6 address (it has only 6 hextets where you would expect to see 8, or a double-colon to mark compressed zeros): 2001:db8:a4:ea5c:0:0:53:a1 = 2001:db8:a4:ea5c::53:a1 Graham ___ 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: forwarders (IPv6)
That's not a valid IPv6 address representation. You probably mistyped a double
colon as a single colon in the middle of the address.
(RFC 4291)
2.2. Text Representation of Addresses
There are three conventional forms for representing IPv6 addresses as
text strings:
1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
four hexadecimal digits of the eight 16-bit pieces of the address.
Examples:
ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
2001:DB8:0:0:8:800:200C:417A
Note that it is not necessary to write the leading zeros in an
individual field, but there must be at least one numeral in every
field (except for the case described in 2.).
2. Due to some methods of allocating certain styles of IPv6
addresses, it will be common for addresses to contain long strings
of zero bits. In order to make writing addresses containing zero
bits easier, a special syntax is available to compress the zeros.
The use of "::" indicates one or more groups of 16 bits of zeros.
The "::" can only appear once in an address. The "::" can also be
used to compress leading or trailing zeros in an address.
- Kevin
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
Chakrapani, Praveen CTR via bind-users
Sent: Tuesday, September 13, 2016 4:48 PM
To: 'bind-users@lists.isc.org'
Subject: forwarders (IPv6)
Hi,
I added below line to my named.conf to include IPv6 addresses to the forwarders
list. However I am getting this error "Sep 13 10:33:06 servername named[24778]:
[ID 873579 daemon.error] /etc/named.conf:158: expected IP address near
'2001:1890:1C04:3000:0CB7:4432'"
"forwarders { 12.227.230.4; 12.227.230.10; 12.183.68.50; 12.183.68.51;
12.71.76.50; 12.71.76.51; 2001:1890:1C04:3000:0CB7:4432;
2001:1890:1C04:3000:0CB7:4433; 2001:1890:1C04:3400:0C47:4C32;
2001:1890:1C04:3400:0C47:4C33; };
forward first;"
Please let know how to add IPv6 addresses to the forwarders list.
Thanks,
Praveen Kumar Chakrapani (CTR)
AECOM Contractor, Lead UNIX Administrator
Desk (202)326-3282
___
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
forwarders (IPv6)
Hi,
I added below line to my named.conf to include IPv6 addresses to the forwarders
list. However I am getting this error "Sep 13 10:33:06 servername named[24778]:
[ID 873579 daemon.error] /etc/named.conf:158: expected IP address near
'2001:1890:1C04:3000:0CB7:4432'"
"forwarders { 12.227.230.4; 12.227.230.10; 12.183.68.50; 12.183.68.51;
12.71.76.50; 12.71.76.51; 2001:1890:1C04:3000:0CB7:4432;
2001:1890:1C04:3000:0CB7:4433; 2001:1890:1C04:3400:0C47:4C32;
2001:1890:1C04:3400:0C47:4C33; };
forward first;"
Please let know how to add IPv6 addresses to the forwarders list.
Thanks,
Praveen Kumar Chakrapani (CTR)
AECOM Contractor, Lead UNIX Administrator
Desk (202)326-3282
___
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?
In message <7db0887c1dbf4ce0b1590ee09d2cb...@mxph4chrw.fgremc.it>, "Darcy Kevin (FCA)" writes: > AXFR over UDP is explicitly undefined. See RFC 5936 Section 4.2. Given > this, I would have expected either a FORMERR response (interpreting the > request itself as "illegal"), or a NOTIMPL response (interpreting > "undefined" as "might have been defined by an RFC subsequent to 5936, but > I don't happen to know about it"). NOERROR response with TC is surprising. Named sends FORMERR. > IXFR over UDP is defined (RFC 1995 Section 2), but not implemented > (apparently) by BIND. So NOTIMPL would seem appropriate. Named sends back the current SOA record over UDP. This is equivalent to "up to date" or "retry over TCP as the answer will not fit in the space available" depending upon the serial in the request. Mark > - Kevin > > -Original Message- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of S Carr > Sent: Thursday, August 25, 2016 4:09 PM > To: bind-users > Subject: Re: Slaves or Forwarders? > > On 25 August 2016 at 21:06, Matus UHLAR - fantomas wrote: > > just IXFRs or AXFRs too? > > Isn't edns over UDP enough in many cases? > > >From what I've seen in past testing any attempt to request an AXFR against > >BIND using UDP gets an immediate TC response. > > Steve > ___ > 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 -- 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
RE: Slaves or Forwarders?
AXFR over UDP is explicitly undefined. See RFC 5936 Section 4.2. Given this, I would have expected either a FORMERR response (interpreting the request itself as "illegal"), or a NOTIMPL response (interpreting "undefined" as "might have been defined by an RFC subsequent to 5936, but I don't happen to know about it"). NOERROR response with TC is surprising. IXFR over UDP is defined (RFC 1995 Section 2), but not implemented (apparently) by BIND. So NOTIMPL would seem appropriate. - Kevin -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of S Carr Sent: Thursday, August 25, 2016 4:09 PM To: bind-users Subject: Re: Slaves or Forwarders? On 25 August 2016 at 21:06, Matus UHLAR - fantomas wrote: > just IXFRs or AXFRs too? > Isn't edns over UDP enough in many cases? >From what I've seen in past testing any attempt to request an AXFR against >BIND using UDP gets an immediate TC response. Steve ___ 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?
On 25 August 2016 at 21:06, Matus UHLAR - fantomas wrote: > just IXFRs or AXFRs too? > Isn't edns over UDP enough in many cases? >From what I've seen in past testing any attempt to request an AXFR against BIND using UDP gets an immediate TC response. Steve ___ 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?
In message <844475874024407090c1c2e9d5718...@mxph4chrw.fgremc.it>, "Darcy Kevin (FCA)" writes: From an InfoSec standpoint, of course one would prefer to use cryptographic methods of securing DNS data, but, in the absence of that, slaving could, arguably, be considered more secure than forwarding, in the sense that forwarding usually generates more network transactions, over time, for any given resolution of any given name, and thus more chances for a bad guy to successfully spoof a response and have that forged answer be cached. One could also eke out a small measure of extra security (again, if cryptographic methods are for some reason unavailable) by turning off IXFR and thus causing all zone transfers to occur with AXFR, which is TCP-based and thus presumably harder to spoof. But, that's a heavy price to pay for a small increment of extra security. Better to go for crypto, at that point, either within the DNS protocol itself (e.g. TSIG, DNSSEC), by implementing (as many have) an out-of-band method of replicating zone data (e.g. rsync-over-ssh, Infoblox-style "grid replication" over OpenVPN tunnels) or by securing *all* communicati on between nameserver instances (e.g. IPSEC tunnels). On 24.08.16 08:00, Mark Andrews wrote: named only accepts IXFR over TCP. While the protocol supports sending deltas with IXFR/UDP named does not use that part of the protocol. just IXFRs or AXFRs too? Isn't edns over UDP enough in many cases? -- 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. Linux IS user friendly, it's just selective who its friends are... ___ 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: Slaves or Forwarders?
In message <844475874024407090c1c2e9d5718...@mxph4chrw.fgremc.it>, "Darcy Kevin (FCA)" writes: > From an InfoSec standpoint, of course one would prefer to use > cryptographic methods of securing DNS data, but, in the absence of that, > slaving could, arguably, be considered more secure than forwarding, in > the sense that forwarding usually generates more network transactions, > over time, for any given resolution of any given name, and thus more > chances for a bad guy to successfully spoof a response and have that > forged answer be cached. > > One could also eke out a small measure of extra security (again, if > cryptographic methods are for some reason unavailable) by turning off > IXFR and thus causing all zone transfers to occur with AXFR, which is > TCP-based and thus presumably harder to spoof. But, that's a heavy price > to pay for a small increment of extra security. Better to go for crypto, > at that point, either within the DNS protocol itself (e.g. TSIG, DNSSEC), > by implementing (as many have) an out-of-band method of replicating zone > data (e.g. rsync-over-ssh, Infoblox-style "grid replication" over OpenVPN > tunnels) or by securing *all* communicati on between nameserver instances > (e.g. IPSEC tunnels). named only accepts IXFR over TCP. While the protocol supports sending deltas with IXFR/UDP named does not use that part of the protocol. -- 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
RE: Slaves or Forwarders?
>From an InfoSec standpoint, of course one would prefer to use cryptographic >methods of securing DNS data, but, in the absence of that, slaving could, >arguably, be considered more secure than forwarding, in the sense that >forwarding usually generates more network transactions, over time, for any >given resolution of any given name, and thus more chances for a bad guy to >successfully spoof a response and have that forged answer be cached. One could also eke out a small measure of extra security (again, if cryptographic methods are for some reason unavailable) by turning off IXFR and thus causing all zone transfers to occur with AXFR, which is TCP-based and thus presumably harder to spoof. But, that's a heavy price to pay for a small increment of extra security. Better to go for crypto, at that point, either within the DNS protocol itself (e.g. TSIG, DNSSEC), by implementing (as many have) an out-of-band method of replicating zone data (e.g. rsync-over-ssh, Infoblox-style "grid replication" over OpenVPN tunnels) or by securing *all* communication between nameserver instances (e.g. IPSEC tunnels). - Kevin -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tony Finch Sent: Tuesday, August 23, 2016 11:00 AM To: Baird, Josh Cc: bind-users@lists.isc.org Subject: Re: Slaves or Forwarders? Baird, Josh wrote: > > In the past, when I have had a requirement to bring a slave zone into > our environment; I created a slave zone on my master(s) (defining the > external nameserver as a master) and then created slave zones on my > slaves using *my* master as a master (not the master outside of my > environment). > Is this method of 'sub-slaves' considered an acceptable practice? Yes. (The new EDNS EXPIRE feature makes it a bit safer too.) > Some folks also like to use forwarders if they don't have the > capability to slave the zone. In this scenario, I would have to create a > 'forward' > zone on each of my caching servers that forwards requests for 'xyz.com' > to the up-stream nameserver authoritative for the zone. Be careful doing that. The target forwarders have to be recursive servers. This matters if there is a delegated subdomain; if you are forwarding to an authoritative-only server which returns a referral, BIND will be upset that it did not get the final answer it expected. > I would think that slaving the zone would be the preferred method, > since my master/slaves could still serve the zone if the > up-stream/forwarder becomes unreachable (until my slave expires). Yes, slaving can be more robust. But forwarding can be simpler. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Trafalgar: Easterly 6 to gale 8 in east, otherwise northerly or northeasterly 4 or 5, increasing 6 at times. Slight or moderate, occasionally rough in east. Showers. 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 ___ 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?
Baird, Josh wrote: > > In the past, when I have had a requirement to bring a slave zone into > our environment; I created a slave zone on my master(s) (defining the > external nameserver as a master) and then created slave zones on my > slaves using *my* master as a master (not the master outside of my > environment). > Is this method of 'sub-slaves' considered an acceptable practice? Yes. (The new EDNS EXPIRE feature makes it a bit safer too.) > Some folks also like to use forwarders if they don't have the capability > to slave the zone. In this scenario, I would have to create a 'forward' > zone on each of my caching servers that forwards requests for 'xyz.com' > to the up-stream nameserver authoritative for the zone. Be careful doing that. The target forwarders have to be recursive servers. This matters if there is a delegated subdomain; if you are forwarding to an authoritative-only server which returns a referral, BIND will be upset that it did not get the final answer it expected. > I would think that slaving the zone would be the preferred method, since > my master/slaves could still serve the zone if the up-stream/forwarder > becomes unreachable (until my slave expires). Yes, slaving can be more robust. But forwarding can be simpler. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Trafalgar: Easterly 6 to gale 8 in east, otherwise northerly or northeasterly 4 or 5, increasing 6 at times. Slight or moderate, occasionally rough in east. Showers. 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
Slaves or Forwarders?
Hi, In the past, when I have had a requirement to bring a slave zone into our environment; I created a slave zone on my master(s) (defining the external nameserver as a master) and then created slave zones on my slaves using *my* master as a master (not the master outside of my environment). This seems to work well and makes management easier on my end. Is this method of 'sub-slaves' considered an acceptable practice? Some folks also like to use forwarders if they don't have the capability to slave the zone. In this scenario, I would have to create a 'forward' zone on each of my caching servers that forwards requests for 'xyz.com' to the up-stream nameserver authoritative for the zone. Given the choice of creating forwarders or slaving the zone into my environment, which is preferred? I would think that slaving the zone would be the preferred method, since my master/slaves could still serve the zone if the up-stream/forwarder becomes unreachable (until my slave expires). In my infrastructure, it just so happens that managing slave zones across our environment is also simpler than managing independent forward zone(s) on each of our servers as well. Any thoughts/suggestions are appreciated! Thanks, Josh ___ 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: Question about how forwarders work
In article ,
Richard Thomas wrote:
> Hi all,
>
> Having heard about recursion, is there a way of getting BIND to make
> recursive DNS requests to the A.B.C.D and E.F.G.H DNS servers?
Requests to forwarders always have the Recursion Requested flag set. So
you could point them to your ISP's resolvers if you wanted.
>
> Thanks,
>
> Richard Thomas.
>
>
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas
> Sent: 11 December 2014 16:39
> To: bind-users@lists.isc.org
> Subject: Re: Question about how forwarders work
>
> On 11.12.14 16:28, Richard Thomas wrote:
> >Please could I have some advice about how the below example configuration
> >would work:
> >
> >forwarders { A.B.C.D; E.F.G.H; };
> >
> >What I wanted to achieve is that one of the IP addresses to be used as
> >a primary DNS server and the other IP address to be used as a
> >secondary DNS server.
>
> BIND measures RTT for servers and uses the one that answes faster.
> It ocasionally re-tries slower server, if the situation did not change.
> That should result to fastest resolution. This should be the best for you.
>
> Many people recommend doing recursion directly instead of using forwarders.
> Especially for mail servers with anti-spam measures, where your forwarders
> may be ignored by some blacklists, because they send too much queries.
>
> --
> 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.
> REALITY.SYS corrupted. Press any key to reboot Universe.
> ___
> 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
--
Barry Margolin
Arlington, MA
___
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: Question about how forwarders work
On 16.12.14 09:33, Richard Thomas wrote:
Having heard about recursion, is there a way of getting BIND to make
recursive DNS requests to the A.B.C.D and E.F.G.H DNS servers?
forwarding causes BIND to send recursive DNS requests, in both domain and
server config. But note that you should only use it when you don't have
direct connectivity to the destination (or the internet at all).
If you want to use non-recursive queries, configure domain as static-stub.
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas
Sent: 11 December 2014 16:39
To: bind-users@lists.isc.org
Subject: Re: Question about how forwarders work
On 11.12.14 16:28, Richard Thomas wrote:
Please could I have some advice about how the below example configuration would
work:
forwarders { A.B.C.D; E.F.G.H; };
What I wanted to achieve is that one of the IP addresses to be used as
a primary DNS server and the other IP address to be used as a
secondary DNS server.
BIND measures RTT for servers and uses the one that answes faster.
It ocasionally re-tries slower server, if the situation did not change.
That should result to fastest resolution. This should be the best for you.
Many people recommend doing recursion directly instead of using forwarders.
Especially for mail servers with anti-spam measures, where your forwarders may
be ignored by some blacklists, because they send too much queries.
--
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.
Christian Science Programming: "Let God Debug 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: Question about how forwarders work
Hi all,
Having heard about recursion, is there a way of getting BIND to make recursive
DNS requests to the A.B.C.D and E.F.G.H DNS servers?
Thanks,
Richard Thomas.
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas
Sent: 11 December 2014 16:39
To: bind-users@lists.isc.org
Subject: Re: Question about how forwarders work
On 11.12.14 16:28, Richard Thomas wrote:
>Please could I have some advice about how the below example configuration
>would work:
>
>forwarders { A.B.C.D; E.F.G.H; };
>
>What I wanted to achieve is that one of the IP addresses to be used as
>a primary DNS server and the other IP address to be used as a
>secondary DNS server.
BIND measures RTT for servers and uses the one that answes faster.
It ocasionally re-tries slower server, if the situation did not change.
That should result to fastest resolution. This should be the best for you.
Many people recommend doing recursion directly instead of using forwarders.
Especially for mail servers with anti-spam measures, where your forwarders may
be ignored by some blacklists, because they send too much queries.
--
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.
REALITY.SYS corrupted. Press any key to reboot Universe.
___
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: Question about how forwarders work
On 11.12.14 16:28, Richard Thomas wrote:
Please could I have some advice about how the below example configuration would
work:
forwarders { A.B.C.D; E.F.G.H; };
What I wanted to achieve is that one of the IP addresses to be used as a
primary DNS server and the other IP address to be used as a secondary DNS
server.
BIND measures RTT for servers and uses the one that answes faster.
It ocasionally re-tries slower server, if the situation did not change.
That should result to fastest resolution. This should be the best for you.
Many people recommend doing recursion directly instead of using forwarders.
Especially for mail servers with anti-spam measures, where your forwarders
may be ignored by some blacklists, because they send too much queries.
--
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.
REALITY.SYS corrupted. Press any key to reboot Universe.
___
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 how forwarders work
Hi,
Please could I have some advice about how the below example configuration would
work:
forwarders { A.B.C.D; E.F.G.H; };
What I wanted to achieve is that one of the IP addresses to be used as a
primary DNS server and the other IP address to be used as a secondary DNS
server.
I have had differing results from testing that I have performed in my company
and that of two other companies.
Company 1) - The result is that some DNS requests are sent to the first IP
address and some are sent to the second IP address, even though both DNS
servers are available.
Company 2) - The result is that DNS requests are sent to the first IP address
and are only sent to the second IP address, if the first is down.
Company 3) - The result is that DNS requests are sent to the second IP address
and are only sent to the first IP address, if the second is down.
Can anybody explain why there are differing results in different BIND
environments please?
Also, if there is a way of configuring BIND to always work the way it's been
observed for company 2), please could someone let me know.
Many thanks in advance.
Richard Thomas.
[http://www.the-logic-group.com/images/TLG_Logo.jpg]
<http://www.the-logic-group.com/>
The Logic Group sees a future where everything comes together. A future where
every customer interaction paves the way for opportunity. Watch our video to
find out more.
<http://www.the-logic-group.com/cp/every-interaction-creates-opportunity>
The Logic Group Enterprises Limited, Logic House, Waterfront Business Park,
Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England.
Registered No. 2609323
General enquiries tel: +44 1252 776 700 email: i...@the-logic-group.com
<mailto:i...@the-logic-group.com> visit: www.the-logic-group.com
<http://www.the-logic-group.com/>
The information in this email and any attachments are confidential and may be
legally privileged and protected by law. It is for the intended recipient only.
If you are not the intended recipient you may not use, disclose, copy,
distribute, print or rely on the content of this email or its attachments. If
this email has been received by you in error please advise the sender and
delete the email 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: Internal clients' queries for "myhostname." get sent to forwarders. Why?
The search algorithms in libresolve/libbind are a compromise. If I had my way, back when libresolv was updated for RFC 1535, support for partially qualified domain names would have died. ndots was the compromise. Searches would have only continued on NXDOMAIN and unqualified names would not have been tried against the root. There were obvious security and information leakage issues with partially qualified names. So to with continuing searches on NODATA and SERVFAIL. I have been setting hostname to the fully qualified value for the last 20 years or so. The worked on almost all platforms but some needed tweaking to remove assumptions that a hostname was a single label. Also whenever a hostname is added to a configuration file / script the fully qualified version is used. I killed searching in the local sendmail configurations and forced everyone to use fully qualified names in mail. This reduced problems once people got used to it. 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
Re: Internal clients' queries for "myhostname." get sent to forwarders. Why?
On 03/12/14 06:50, Tony Finch wrote: > Lawrence K. Chen, P.Eng. wrote: > >> If you have FQDN for machines, the problem might be that the domain >> isn't set in resolv.conf? > > The machines are configured with a bare hostname. If there isn't a search > or domain directive in /etc/resolv.conf and there isn't an entry for the > machine in /etc/hosts then `hostname -f` will fail. > > It is probably a bug that `hostname -f` does not have any "ndots" logic. > See also RFC 1535. > > Tony. > Around here, the users insist on being able to only use hostname to reach everythingso our resolv.conf's have search is max'd...though some systems seem to work when 7 subdomains are listed for "search". Though most of the time, we'll find that we have to ask them which subdomain can they live without to add a new one to "search". One time, they removed the first one...because the department doesn't exist anymore and they don't (think they) have anything in it they need. Except that the backup jobs they run all stopped working. Yeah, the backup server is in that subdomain (and the fqdn is baked into the library catalog's Oracle DB backend, so we can never change it...though every few years they look at switching us to another vendor's product rather than upgrading...and we end up upgrading.) Also we still have a large number of Solaris systems around...where typing 'hostname -f' would change the hostname of the system to '-f'. (or an error if not root.) And, virtually every system here uses just hostnamesince lots of people call `hostname` in their prompts, and don't like the added length of getting an fqdn. (or figuring out what they need to do to make it right.) Though I did discover that search appends to all lookups, not just bare hostnames. Could not understand why new SA saying machines could be reached with .campus (years ago when we started having systems with RFC1918 IPs...they decided to make up a TLD. The DNS administrator said that it wasn't possible to do split DNS, yet he didn't ask what I meant when I had asked him about it. After he quit, DNS got thrown in my lap. and .campus.ksu.edu was born, which was good, because we had a policy at the time requiring user facing sites to use Thawte certificates...which were hard to get for .campus fqdn's...but we can get for .campus.ksu.edu fqdn's, which can't be resolved from off campus (well, not fully...) Several years ago, another admin tried to get force everybody to stop using the .campus TLD. (I've joked that its only a matter of time that some one goes and registers itor perhaps one of the other fake TLDs we used, like .wireless ;) Problem was there was a big move of Oracle DBs into the TLD...and with the name baked into the installationrenaming isn't going to happen until those systems are abandoned (though a big hardware refresh is near on the horizon...along with a network reorg for data classification.) Though everything that was .campus is in .campus.ksu.edu (except that we had functional subdomains in .campus and functional hostnames in .campus.ksu.edu) But, a host in .campus.ksu.edu is often not in .campus (since its deprecated) And, there's a mix on which domain the reverses are pointed towhich is important for the particular system he was setting up at the time. (Some old systems have had their reverses updated, but not all users have switched to using the new forward in service requests to him) Oh, there have been cases where we've added hostnames to /etc/hosts so that they could use bare hostnames to reach things in other subdomainsother times its to ensure the desired hostname is reached when the name exists in more than one subdomain. Some also have names that are not in DNS (not sure if they thought of CNAMEs) so they can find the application. Which was especially important before we forced a consistent functional naming scheme across our datacenter. They were using Sith Lords to name their machines, some where very similar in spelling but significantly different functions or classifications. Probably ran out of Sith lords with names starting with p, t, d, a or b (prod, test, dev, alpha or beta). It was whole bunch of very similar names starting with 's' that made my manager snap. -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally ___ 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: Internal clients' queries for "myhostname." get sent to forwarders. Why?
Lawrence K. Chen, P.Eng. wrote: > If you have FQDN for machines, the problem might be that the domain > isn't set in resolv.conf? The machines are configured with a bare hostname. If there isn't a search or domain directive in /etc/resolv.conf and there isn't an entry for the machine in /etc/hosts then `hostname -f` will fail. It is probably a bug that `hostname -f` does not have any "ndots" logic. See also RFC 1535. Tony. -- f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger: Southeast veering southwest 3 or 4. Slight. Fog patches in south. Moderate or good, occasionally very poor in south. ___ 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: Internal clients' queries for "myhostname." get sent to forwarders. Why?
If you have FQDN for machines, the problem might be that the domain isn't set in resolv.conf? from resolv.conf(5): domain Local domain name. Most queries for names within this domain can use short names relative to the local domain. If no domain entry is present, the domain is determined from the local host name returned by gethostname(3); the domain part is taken to be everything after the first `.'. Finally, if the host name does not contain a domain part, the root domain is assumed. On 03/11/14 06:28, Tony Finch wrote: > Andreas Ntaflos wrote: >> >> Using Bind 9 on Ubuntu 12.04 for internal DNS (master for zones >> "dc01.example.at.", "7.1.10.in-addr.arpa.", ...) with forwarders (ISP's >> nameservers) for everything outside of internal zones. >> >> The Problem: Clients, when running "hostname -f" or "hostname -i", >> create queries for "myhostname." which are sent to the forwarders which >> respond with NXDomain. This generates load on the forwarders and exposes >> our internally used hostnames, both of which seems unnecessary and >> possible dangerous. >> >> This doesn't seem like normal or healthy behaviour. What can we do to >> stop it? > > Option 1: put the FQDN in /etc/hostname on each machine. > Option 2: populate /etc/hosts on each machine. > Option 3: slave the root zone on your name servers. > > Tony. > -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally ___ 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: Internal clients' queries for "myhostname." get sent to forwarders. Why?
Andreas Ntaflos wrote: > > Using Bind 9 on Ubuntu 12.04 for internal DNS (master for zones > "dc01.example.at.", "7.1.10.in-addr.arpa.", ...) with forwarders (ISP's > nameservers) for everything outside of internal zones. > > The Problem: Clients, when running "hostname -f" or "hostname -i", > create queries for "myhostname." which are sent to the forwarders which > respond with NXDomain. This generates load on the forwarders and exposes > our internally used hostnames, both of which seems unnecessary and > possible dangerous. > > This doesn't seem like normal or healthy behaviour. What can we do to > stop it? Option 1: put the FQDN in /etc/hostname on each machine. Option 2: populate /etc/hosts on each machine. Option 3: slave the root zone on your name servers. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon: Southeasterly 4 or 5, occasionally 6 in northwest. Moderate or rough. Fair. Moderate or 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: Internal clients' queries for "myhostname." get sent to forwarders. Why?
On 2014-03-10 15:05, Andreas Ntaflos wrote: On 2014-03-10 22:23, Kevin Darcy wrote: Options: First, thanks a lot for the reply! So it seems what I described is indeed the expected behaviour for the type of DNS we operate? To put it another way, why wouldn't it? How would your local BIND know whether or not a query for "myhostname." or "museum." is valid or not? One of those has records (although just NS records, no A records) 1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your hosts to prefer another source of name resolution (e.g. /etc/hosts) which can resolve the shortname. Thus DNS is never used for these lookups This might be a solution but I find that our DNS setup is just complex enough that relying on /etc/hosts would probably introduce more problems. Then there's managing /etc/hosts on hundreds of machines, which we could of course do with Puppet, but I find that highly unappealing. Currently we use Puppet to ensure /etc/hosts contains just "127.0.0.1 localhost" and nothing else. Can you configure your environment to also write the machine's own hostname into the hosts file? We're generally not talking about storing every single host into every single HOSTS file, just having each machine know it's own hostname matches 127.0.0.1. This should happen automatically and transparently in the Windows world (without appearing in the HOSTS file explicitly), but not in the *nix world. Beyond that, in the Windows world, a machine will append the local domain's search suffix before doing a bare "hostname" lookup, so these queries typically won't leak as long as your local search suffix points to a zone that resolves local hosts and gives a valid answer. I suspect the same is true in *nix environments, but it's been a while since I mucked around, so I don't know what modern *nix does. 2) Simply :-) change your DNS architecture fundamentally, from one which forwards requests to the Internet by default (aka "the Microsoft way"), to one with an internal root zone and conditionally forwarding only those parts of the namespace that your internal clients actually need to see. I confess that I didn't think there was any feasible way other than what you call "the Microsoft way" to operate this kind of internal DNS. I also don't think I've ever consciously heard of the setup you describe. Can you point me to some reading material on what this entails and how to get there? In general there isn't much to it, if you don't set up a forwarded then BIND will use it's .hints file to locate the root servers, and from there, it will resolve whatever it needs to resolve recursively, taking over the roll of your upstream forwarder. I'm sure someone can post a link to proper documentation, if you need it. Incidentally, in the Windows world, you do the same, just leave the forwarders list blank and Microsoft DNS does full recursion. The old DNS setup wizards encouraged forwarders since they made a lot more sense in the high-latency, well maintained DNS server worlds of yester-year, but today, you'll probably do a better job of doing your own recursion if only because most ISPs do a terrible job of their own DNS servers. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ 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: Internal clients' queries for "myhostname." get sent to forwarders. Why?
On 3/10/2014 6:05 PM, Andreas Ntaflos wrote:
On 2014-03-10 22:23, Kevin Darcy wrote:
Options:
First, thanks a lot for the reply! So it seems what I described is
indeed the expected behaviour for the type of DNS we operate?
1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your
hosts to prefer another source of name resolution (e.g. /etc/hosts)
which can resolve the shortname. Thus DNS is never used for these
lookups
This might be a solution but I find that our DNS setup is just complex
enough that relying on /etc/hosts would probably introduce more
problems. Then there's managing /etc/hosts on hundreds of machines,
which we could of course do with Puppet, but I find that highly
unappealing. Currently we use Puppet to ensure /etc/hosts contains
just "127.0.0.1 localhost" and nothing else.
That's pretty hardcore. I think it's more common for /etc/hosts to
resolve the shortname and at least the primary FQDN of the local host.
2) Simply :-) change your DNS architecture fundamentally, from one which
forwards requests to the Internet by default (aka "the Microsoft way"),
to one with an internal root zone and conditionally forwarding only
those parts of the namespace that your internal clients actually need to
see.
I confess that I didn't think there was any feasible way other than
what you call "the Microsoft way" to operate this kind of internal
DNS. I also don't think I've ever consciously heard of the setup you
describe. Can you point me to some reading material on what this
entails and how to get there?
Well, there's 2 pieces to this: the authoritative core for the root
zone, and then the conditional forwarding for the external namespaces
that need to be made visible.
For setting up and running an internal root on a single primary master
server, just look at the Internet Standards and/or BIND documentation,
since an "internal" root zone isn't fundamentally different than "the"
root zone, or for that matter, much different from any regular zone that
you define (the major difference being, there is no parent from which to
delegate it). Once you have the internal root up on its primary master,
then you should define some slaves (as per the documentation), at least
some of which should be *published* slaves (as per standards, you need 2
or more of those). Outside of your authoritative core, you may then
define other internal nameservers with a "hints" file containing all of
your internal published slaves for the root zone. Essentially, you're
re-creating, on a small scale, what is done on the Internet -- an
authoritative core for root, with "edge" nameservers pointing to that
core with their "hints" files.
For conditional forwarding, again, look at the BIND documentation
(pseudo-zones of "type forward"). These need to be defined on *every*
nameserver where you want the external namespaces to be visible (a
configuration-management system helps here, to ensure configuration
consistency; you mentioned you were using Puppet). For a forwarded
*external* zone, you want "forward only" as the mode, since otherwise
your internal boxes will try to use your internal root (which will give
the wrong information) for names in the zone, whenever the forwarders
are unavailable. Another big gotcha with BIND: if you want to
conditionally forward a namespace, and you're authoritative for its
closest-enclosing ancestor zone (potentially that ancestor zone is your
internal root if there's nothing defined in between), you need to
*delegate* the zone that you want to conditionally forward. It doesn't
really matter what you delegate it *to* -- it can be something bogus --
but the delegation needs to *exist* in order for BIND to "see" the zone
cut and forward appropriately.
Last but not least, if you conditionally forward a namespace (e.g.
example.com) outside, and then you want to carve out an _exception_ to
that namespace internally (e.g. internal.example.com), that has, itself,
one or more subzone levels to its hierarchy (e.g.
foo.bar.internal.example.com), then, on any nameserver that isn't
authoritative for *all* of those subzones in the hierarchy, you should
use the BIND-idiomatic "forwarders { };" syntax to "cancel" forwarding
for the exception namespace, e.g.
zone "example.com" {
type forward;
forward only;
forwarders { 192.0.2.1; 203.0.113.1; };
};
zone "internal.example.com" {
type slave; // or master, or stub...
file "internal.example.com";
forwarders { }; // cancel forwarding for all subzones
};
Failure to do so will cause queries in subzones (e.g.
foo.bar.internal.example.com) to forward according to the
closest-enclosing *forwarded* zone (example.com in the above example),
which
Re: Internal clients' queries for "myhostname." get sent to forwarders. Why?
On 2014-03-10 22:23, Kevin Darcy wrote: Options: First, thanks a lot for the reply! So it seems what I described is indeed the expected behaviour for the type of DNS we operate? 1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your hosts to prefer another source of name resolution (e.g. /etc/hosts) which can resolve the shortname. Thus DNS is never used for these lookups This might be a solution but I find that our DNS setup is just complex enough that relying on /etc/hosts would probably introduce more problems. Then there's managing /etc/hosts on hundreds of machines, which we could of course do with Puppet, but I find that highly unappealing. Currently we use Puppet to ensure /etc/hosts contains just "127.0.0.1 localhost" and nothing else. 2) Simply :-) change your DNS architecture fundamentally, from one which forwards requests to the Internet by default (aka "the Microsoft way"), to one with an internal root zone and conditionally forwarding only those parts of the namespace that your internal clients actually need to see. I confess that I didn't think there was any feasible way other than what you call "the Microsoft way" to operate this kind of internal DNS. I also don't think I've ever consciously heard of the setup you describe. Can you point me to some reading material on what this entails and how to get there? Thanks again! Andreas signature.asc Description: OpenPGP digital 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: Internal clients' queries for "myhostname." get sent to forwarders. Why?
Options:
1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your
hosts to prefer another source of name resolution (e.g. /etc/hosts)
which can resolve the shortname. Thus DNS is never used for these lookups
2) Simply :-) change your DNS architecture fundamentally, from one which
forwards requests to the Internet by default (aka "the Microsoft way"),
to one with an internal root zone and conditionally forwarding only
those parts of the namespace that your internal clients actually need to
see.
- Kevin
On 3/10/2014 3:58 PM, Andreas Ntaflos wrote:
Hi list,
I hope I succeeded in articulating the problem we are facing and I
apologize for the length of this post.
Short version:
Using Bind 9 on Ubuntu 12.04 for internal DNS (master for zones
"dc01.example.at.", "7.1.10.in-addr.arpa.", ...) with forwarders (ISP's
nameservers) for everything outside of internal zones.
The Problem: Clients, when running "hostname -f" or "hostname -i",
create queries for "myhostname." which are sent to the forwarders which
respond with NXDomain. This generates load on the forwarders and exposes
our internally used hostnames, both of which seems unnecessary and
possible dangerous.
This doesn't seem like normal or healthy behaviour. What can we do to
stop it?
Long version:
In our internal networks we are running Bind 9 on Ubuntu 12.04
(9.8.1.dfsg.P1-4ubuntu0.8). The nameserver is configured to be master
for the zone "dc01.example.at" (obviously we don't use "example", but
the other domain components are real). It also serves in-addr.arpa zones
for the internal IP addresses (7.1.10.in-addr.arpa., and so on).
Recursion is enabled for internal clients.
The internal nameserver uses our ISP's nameservers as forwarders for
everything outside of the zones for which it is master.
All clients in our internal networks have names like
"auth01.mgmt.dc01.example.at" or "puppet02.dev.dc01.example.at". All
clients' resolvers are configured with one nameserver and multiple
search domains, like this:
# /etc/hosts:
127.0.0.1 localhost
# /etc/resolv.conf:
nameserver 10.1.7.42
search mgmt.dc01.example.at dc01.example.at
Clients are Ubuntu and Debian machines (10.04, 12.04, Lenny, Wheezy).
This all works fine (and has for years now), but recently we became
aware of the fact that whenever a client system runs "hostname -f" or
"hostname -i" it will ask the internal nameserver for hostname plus each
search domain (which is fine), AND for the plain hostname with a
trailing dot (which is not fine). I can see this from the nameserver's
query logs and from tcpdump.
For example, on "auth01.mgmt.dc01.example.at" the nameserver gets asked for:
auth01.mgmt.dc01.example.at.
auth01.dc.example.at.
auth01.
The nameserver replies correctly with the client's FQDN or IP address
for the first query, as well as with NXDomain for the second query (also
correct) but then forwards the third query ("auth01.") to the configured
forwarders (our ISPs nameservers). This naturally returns NXDomain.
I am confused and worried by this behaviour. Since we have quite a few
hosts in our internal networks (all running Puppet agents) the
forwarders get hit with requests for "hostname." like above multiple
times per second. It also exposes to the forwarders the hostnames of our
internal machines, which isn't great.
Is this the expected behaviour? What can we do to stop our internal
nameserver from forwarding queries for "hostname." to our ISPs nameservers?
I have not included any Bind configuration or zone files here, but I can
provide anything needed to facilitate debugging this issue. Please let
me know!
Thanks in advance for any help and pointers, particularly RTFM. I have
had a really hard time googling this :(
Andreas
___
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
Internal clients' queries for "myhostname." get sent to forwarders. Why?
Hi list,
I hope I succeeded in articulating the problem we are facing and I
apologize for the length of this post.
Short version:
Using Bind 9 on Ubuntu 12.04 for internal DNS (master for zones
"dc01.example.at.", "7.1.10.in-addr.arpa.", ...) with forwarders (ISP's
nameservers) for everything outside of internal zones.
The Problem: Clients, when running "hostname -f" or "hostname -i",
create queries for "myhostname." which are sent to the forwarders which
respond with NXDomain. This generates load on the forwarders and exposes
our internally used hostnames, both of which seems unnecessary and
possible dangerous.
This doesn't seem like normal or healthy behaviour. What can we do to
stop it?
Long version:
In our internal networks we are running Bind 9 on Ubuntu 12.04
(9.8.1.dfsg.P1-4ubuntu0.8). The nameserver is configured to be master
for the zone "dc01.example.at" (obviously we don't use "example", but
the other domain components are real). It also serves in-addr.arpa zones
for the internal IP addresses (7.1.10.in-addr.arpa., and so on).
Recursion is enabled for internal clients.
The internal nameserver uses our ISP's nameservers as forwarders for
everything outside of the zones for which it is master.
All clients in our internal networks have names like
"auth01.mgmt.dc01.example.at" or "puppet02.dev.dc01.example.at". All
clients' resolvers are configured with one nameserver and multiple
search domains, like this:
# /etc/hosts:
127.0.0.1 localhost
# /etc/resolv.conf:
nameserver 10.1.7.42
search mgmt.dc01.example.at dc01.example.at
Clients are Ubuntu and Debian machines (10.04, 12.04, Lenny, Wheezy).
This all works fine (and has for years now), but recently we became
aware of the fact that whenever a client system runs "hostname -f" or
"hostname -i" it will ask the internal nameserver for hostname plus each
search domain (which is fine), AND for the plain hostname with a
trailing dot (which is not fine). I can see this from the nameserver's
query logs and from tcpdump.
For example, on "auth01.mgmt.dc01.example.at" the nameserver gets asked for:
auth01.mgmt.dc01.example.at.
auth01.dc.example.at.
auth01.
The nameserver replies correctly with the client's FQDN or IP address
for the first query, as well as with NXDomain for the second query (also
correct) but then forwards the third query ("auth01.") to the configured
forwarders (our ISPs nameservers). This naturally returns NXDomain.
I am confused and worried by this behaviour. Since we have quite a few
hosts in our internal networks (all running Puppet agents) the
forwarders get hit with requests for "hostname." like above multiple
times per second. It also exposes to the forwarders the hostnames of our
internal machines, which isn't great.
Is this the expected behaviour? What can we do to stop our internal
nameserver from forwarding queries for "hostname." to our ISPs nameservers?
I have not included any Bind configuration or zone files here, but I can
provide anything needed to facilitate debugging this issue. Please let
me know!
Thanks in advance for any help and pointers, particularly RTFM. I have
had a really hard time googling this :(
Andreas
signature.asc
Description: OpenPGP digital 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: Forwarders Timeout
That's kinda what I'm gleaning as well. On Tue, Jan 28, 2014 at 12:43 PM, Matus UHLAR - fantomas wrote: > On 28.01.14 10:08, Phil Fagan wrote: >> >> Is it possible to configure the forward (only|first) timeout? > > > AFAIK not (yet). The forwarder selection is done in the same way as the > server selection by RTT meassuring. > > > -- > 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. > Windows found: (R)emove, (E)rase, (D)elete > ___ > 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 -- Phil Fagan Denver, CO 970-480-7618 ___ 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: Forwarders Timeout
On 28.01.14 10:08, Phil Fagan wrote: Is it possible to configure the forward (only|first) timeout? AFAIK not (yet). The forwarder selection is done in the same way as the server selection by RTT meassuring. -- 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. Windows found: (R)emove, (E)rase, (D)elete ___ 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
Forwarders Timeout
Is it possible to configure the forward (only|first) timeout? So, first query a server listed in the forwarders statement and upon receiving no resolution answer [ in ?configurable? seconds ] query another server (e.g., based on cached information or hints file configuration) (forward first). Thanks, -- Phil Fagan Denver, CO 970-480-7618 ___ 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: forwarders and zone transfer to the same set of servers
On 9/28/2013 12:31 PM, sar...@slashroot.in wrote:
Hi Team,
I have an architecture where i have one bind server that is
forward-only and is authoritative for a domain ab.dc.example.com. It
should forward all requests other than it is authoritative for
(ab.dc.example.com) to a set of servers.
Requests will get forwarded to
172.16.202.1
172.16.202.2
172.16.203.3
172.16.204.4
And the second point is that these same set of servers, where requests
are being forwarded are also slave servers for the domain
ab.dc.example.com (so it will be fetching zone transfer updates as well)
I have TSIG with HMAC md5 keys generated for secure zone transfer..
key ab.dc.example.com {
algorithm hmac-md5;
secret
"s0G8oHowQLWoS6FvOV2W6zKNAv+sC7f2hdJclrtHtEfFPyf3nBNY6xR+1Q==";
};
server 172.16.202.1 {
keys {
ab.dc.example.com;
};
};
server 172.16.202.2 {
keys {
ab.dc.example.com;
};
};
server 172.16.202.3 {
keys {
ab.dc.example.com;
};
};
server 172.16.202.4 {
keys {
ab.dc.example.com;
};
};
And i have my forwarders set to the same set of above servers...My
bind options clause is shown below.
forwarders { 172.16.202.1; 172.16.202.2; 172.16.202.3; 172.16.202.4; };
forward only;
allow-query { any; };
allow-transfer { none; };
allow-recursion { localhost; 0.0.0.0/0; };
dnssec-validation no;
dnssec-enable yes;
Note: I dont have direct access to those 4 servers (they are slave for
the domain for which am authoritative). The zone transfer is working
perfect in the above configs but normal dig queries are not working as
required. What i could make out from the logs is shown below.
;; TSIG PSEUDOSECTION:
0 ANY TSIGhmac-md5.sig-alg.reg.int. 1380379945 300 0 55359
BADSIG 0
However if i query those same servers where am forwarding my dns
requests, with the key option in dig command i do get the desired
proper output. I guess i am missing something in bind configs..please
advice me..
When you TSIG-sign your outgoing dig query, are you using *exactly* the
same key file, via "-k", as named itself uses when it authenticates the
incoming zone transfer requests?
If you're using "-y", you're presumably typing out the key name and key
secret on the command line, and it's very easy to screw that up. Just
saying...
Failing that, one interesting experiment would be to try a zone transfer
in the opposite direction, using dig. Does that work?
Lastly, is it possible that your box is multi-homed and the other server
is expecting a different TSIG key for DNS transactions sourced from a
different address than the one it uses for zone transfers? The answer to
this question may get rather complicated if any NAT'ing is involved, of
course...
- 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
forwarders and zone transfer to the same set of servers
Hi Team,
I have an architecture where i have one bind server that is
forward-only and is authoritative for a domain ab.dc.example.com. It
should forward all requests other than it is authoritative for
(ab.dc.example.com) to a set of servers.
Requests will get forwarded to
172.16.202.1
172.16.202.2
172.16.203.3
172.16.204.4
And the second
point is that these same set of servers, where requests are being
forwarded are also slave servers for the domain ab.dc.example.com (so it
will be fetching zone transfer updates as well)
I have TSIG with HMAC
md5 keys generated for secure zone transfer..
key ab.dc.example.com {
algorithm hmac-md5;
secret
"s0G8oHowQLWoS6FvOV2W6zKNAv+sC7f2hdJclrtHtEfFPyf3nBNY6xR+1Q==";
};
server
172.16.202.1 {
keys {
ab.dc.example.com;
};
};
server 172.16.202.2
{
keys {
ab.dc.example.com;
};
};
server 172.16.202.3 {
keys {
ab.dc.example.com;
};
};
server 172.16.202.4 {
keys {
ab.dc.example.com;
};
};
And i have my forwarders set to the same
set of above servers...My bind options clause is shown below.
forwarders { 172.16.202.1; 172.16.202.2; 172.16.202.3; 172.16.202.4; };
forward only;
allow-query { any; };
allow-transfer { none; };
allow-recursion { localhost; 0.0.0.0/0; };
dnssec-validation no;
dnssec-enable yes;
Note: I dont have direct access to those 4 servers
(they are slave for the domain for which am authoritative). The zone
transfer is working perfect in the above configs but normal dig queries
are not working as required. What i could make out from the logs is
shown below.
;; TSIG PSEUDOSECTION:
0 ANY TSIG
hmac-md5.sig-alg.reg.int. 1380379945 300 0 55359 BADSIG 0
However if i
query those same servers where am forwarding my dns requests, with the
key option in dig command i do get the desired proper output. I guess i
am missing something in bind configs..please advice me...
Thanks &
Regards
Sarath
Powered by BigRock.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: Reverse Lookups with Forwarders
Sumsum--
Using the technique you document, you will need a zone for each of
128.100.168.192.in-addr.arpa through 190.100.168.192.in-addr.arpa
Or you might want to serve the entire class C 100.168.192.in-addr.arpa,
especially if you can get a feed for the zone excluding your portion.
Hope this helps,
Len
>
> From: sumsum 2000
>To: bind-users@lists.isc.org
>Sent: Friday, July 12, 2013 6:14 AM
>Subject: Re: Reverse Lookups with Forwarders
>
>
>
>Along the same lines as that of ipv4 address:
>i have the following zone file configuration for reverse lookup:
>
> Goal: 192.168.100.128/26 to be directed to 10.213.246.15
>
>In this, the network part it 192.168.100.128 and
>network range is 191.168.100.129 - 191.168.100.190
>
>in this specific case, this is what i end up with zone file configuration:
> zone "128.100.168.192.in-addr.arpa" IN {
> type forward;
> forwarders {10.213.246.15;};
> forward only;
> };
>
>
>
>In other cases, where my network is 192.168.100, the configuration is as
>follows and this works
> zone "128.100.168.192.in-addr.arpa" IN {
> type forward;
> forwarders {10.213.246.15;};
> forward only;
> };
>
>
>
>
>
>
>When i do a dig -x 191.168.100.129 it does not go to the configured DNS.
>
>Any way, i can get this to be looked up for the correct specified DNS, as
>there is distinction between the network and the host configuration for this
>specific case.
>
>
>Could you please help on this.
>
>
>
>
>On Tue, Jul 9, 2013 at 1:03 PM, Matus UHLAR - fantomas
>wrote:
>
>On 09.07.13 11:51, sumsum 2000 wrote:
>>
>>I have a reverse lookup zone file configuration as follows:
>>>zone "0/24.110.252.173.in-addr.arpa" {
>>>
[...]
>>
>>
>>When I do dig -x 172.252.110.27, I expect it to forward it to
>>>10.10.96.1, but instead, it uses the default resolver.
>>>
[...]
>>
>>
>>So if DNS Server X is configured against this zone
>>>, then any reverse DNS request for 173.252.110.0-173.252.110.255
>>>should be forwarded via DNS Server X
>>>
>>
>>Currently this is not the case. There is no forwarding in the above
>>>scenario ( where CIDR notation x.x.x.x/Mask is used)
>>>
>>
Neither the BIND nor DNS does use the CIDR format.
>>the resursive resolution searches for 27.110.252.173.in-addr.arpa which does
>>NOT belong into 0/24.110.252.173.in-addr.arpa, they are two separate names.
>>
>>You would have to set up either zone 27.110.252.173.in-addr.arpa or
>>110.252.173.in-addr.arpa.
>>
>>Only when the zone file is changed to
>>> zone "110.252.173.in-addr.arpa" IN {
>>>
>>>
>>>All the requests for
>>>
>>>173.252.110.0-173.252.110.255 is forwarded to 10.10.96.1.
>>>
>>Use 110.252.173.in-addr.arpa then. You should be aware that the IP range
>>belongs to facebook, as already noted.
>>
>>--
>>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.
>>99 percent of lawyers give the rest a bad name.
>>___
>>
>>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: Reverse Lookups with Forwarders
On Jul 12, 2013, at 09.14, sumsum 2000 wrote:
> Along the same lines as that of ipv4 address:
> i have the following zone file configuration for reverse lookup:
>
> Goal: 192.168.100.128/26 to be directed to 10.213.246.15
>
> In this, the network part it 192.168.100.128 and
> network range is 191.168.100.129 - 191.168.100.190
>
> in this specific case, this is what i end up with zone file configuration:
> zone "128.100.168.192.in-addr.arpa" IN {
> type forward;
> forwarders {10.213.246.15;};
> forward only;
> };
>
> In other cases, where my network is 192.168.100, the configuration is as
> follows and this works
> zone "128.100.168.192.in-addr.arpa" IN {
> type forward;
> forwarders {10.213.246.15;};
> forward only;
> };
>
>
>
> When i do a dig -x 191.168.100.129 it does not go to the configured DNS.
please don't hijack existing threads for your questions, even if they're
similar.
if you declare a zone for 128.100.168.192.in-addr.arpa, that is only for the
single ip address 192.168.100.128. nothing else [e.g. not 191.168.100.129].
for netblocks smaller than /24, you'll need to use classless arpa delegation.
see rfc 2317 for details on this concept. also please make note of the
paragraph at the end of section 4 suggesting you not actually use "/" as is
used in the examples. too many people seem to miss this.
-ben
___
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: Reverse Lookups with Forwarders
Along the same lines as that of ipv4 address:
i have the following zone file configuration for reverse lookup:
Goal: 192.168.100.128/26 to be directed to 10.213.246.15
In this, the network part it 192.168.100.128 and
network range is 191.168.100.129 - 191.168.100.190
in this specific case, this is what i end up with zone file configuration:
zone "128.100.168.192.in-addr.arpa" IN {
type forward;
forwarders {10.213.246.15;};
forward only;
};
In other cases, where my network is 192.168.100, the configuration is as
follows and this works
zone "128.100.168.192.in-addr.arpa" IN {
type forward;
forwarders {10.213.246.15;};
forward only;
};
When i do a dig -x 191.168.100.129 it does not go to the configured DNS.
Any way, i can get this to be looked up for the correct specified DNS, as
there is distinction between the network and the host configuration for
this specific case.
Could you please help on this.
On Tue, Jul 9, 2013 at 1:03 PM, Matus UHLAR - fantomas wrote:
> On 09.07.13 11:51, sumsum 2000 wrote:
>
>> I have a reverse lookup zone file configuration as follows:
>> zone "0/24.110.252.173.in-addr.**arpa" {
>>
> [...]
>
> When I do dig -x 172.252.110.27, I expect it to forward it to
>> 10.10.96.1, but instead, it uses the default resolver.
>>
> [...]
>
> So if DNS Server X is configured against this zone
>> , then any reverse DNS request for 173.252.110.0-173.252.110.255
>> should be forwarded via DNS Server X
>>
>
> Currently this is not the case. There is no forwarding in the above
>> scenario ( where CIDR notation x.x.x.x/Mask is used)
>>
>
> Neither the BIND nor DNS does use the CIDR format.
> the resursive resolution searches for 27.110.252.173.in-addr.arpa which
> does
> NOT belong into 0/24.110.252.173.in-addr.arpa, they are two separate names.
>
> You would have to set up either zone 27.110.252.173.in-addr.arpa or
> 110.252.173.in-addr.arpa.
>
>> Only when the zone file is changed to
>>zone "110.252.173.in-addr.arpa" IN {
>>
>> All the requests for
>>
>> 173.252.110.0-173.252.110.255 is forwarded to 10.10.96.1.
>>
>
> Use 110.252.173.in-addr.arpa then. You should be aware that the IP range
> belongs to facebook, as already noted.
>
> --
> 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.
> 99 percent of lawyers give the rest a bad name.
> __**_
>
> Please visit
> https://lists.isc.org/mailman/**listinfo/bind-users<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<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: Reverse Lookups with Forwarders
Thanks for the info
On Tue, Jul 9, 2013 at 1:03 PM, Matus UHLAR - fantomas wrote:
> On 09.07.13 11:51, sumsum 2000 wrote:
>
>> I have a reverse lookup zone file configuration as follows:
>> zone "0/24.110.252.173.in-addr.**arpa" {
>>
> [...]
>
> When I do dig -x 172.252.110.27, I expect it to forward it to
>> 10.10.96.1, but instead, it uses the default resolver.
>>
> [...]
>
> So if DNS Server X is configured against this zone
>> , then any reverse DNS request for 173.252.110.0-173.252.110.255
>> should be forwarded via DNS Server X
>>
>
> Currently this is not the case. There is no forwarding in the above
>> scenario ( where CIDR notation x.x.x.x/Mask is used)
>>
>
> Neither the BIND nor DNS does use the CIDR format.
> the resursive resolution searches for 27.110.252.173.in-addr.arpa which
> does
> NOT belong into 0/24.110.252.173.in-addr.arpa, they are two separate names.
>
> You would have to set up either zone 27.110.252.173.in-addr.arpa or
> 110.252.173.in-addr.arpa.
>
>> Only when the zone file is changed to
>>zone "110.252.173.in-addr.arpa" IN {
>>
>> All the requests for
>>
>> 173.252.110.0-173.252.110.255 is forwarded to 10.10.96.1.
>>
>
> Use 110.252.173.in-addr.arpa then. You should be aware that the IP range
> belongs to facebook, as already noted.
>
> --
> 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.
> 99 percent of lawyers give the rest a bad name.
> __**_
>
> Please visit
> https://lists.isc.org/mailman/**listinfo/bind-usersto
> 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: Reverse Lookups with Forwarders
On 2013.07.09 03.18, sumsum 2000 wrote: What I am trying to achieve is this: I am using BIND9 only for forwarding DNS requests to other DNS Servers. I want the entire hosts in the network : 173.252.110.0 with the host range: 173.252.110.1 - 173.252.110.254 with a total 254 addresses to be sent for reverse lookup say to DNS : 8.8.8.8, using a single zone configuration as shown below. yes, but what is the actual problem? that is facebook address space - not yours. why are you mucking with 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: Reverse Lookups with Forwarders
On 09.07.13 11:51, sumsum 2000 wrote:
I have a reverse lookup zone file configuration as follows:
zone "0/24.110.252.173.in-addr.arpa" {
[...]
When I do dig -x 172.252.110.27, I expect it to forward it to
10.10.96.1, but instead, it uses the default resolver.
[...]
So if DNS Server X is configured against this zone
, then any reverse DNS request for 173.252.110.0-173.252.110.255
should be forwarded via DNS Server X
Currently this is not the case. There is no forwarding in the above
scenario ( where CIDR notation x.x.x.x/Mask is used)
Neither the BIND nor DNS does use the CIDR format.
the resursive resolution searches for 27.110.252.173.in-addr.arpa which does
NOT belong into 0/24.110.252.173.in-addr.arpa, they are two separate names.
You would have to set up either zone 27.110.252.173.in-addr.arpa or
110.252.173.in-addr.arpa.
Only when the zone file is changed to
zone "110.252.173.in-addr.arpa" IN {
All the requests for
173.252.110.0-173.252.110.255 is forwarded to 10.10.96.1.
Use 110.252.173.in-addr.arpa then. You should be aware that the IP range
belongs to facebook, as already noted.
--
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.
99 percent of lawyers give the rest a bad name.
___
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: Reverse Lookups with Forwarders
Ok, simple. The zone you want to forward is 110.252.173.in-addr.arpa.
There is no need to make it more complicated than that.
Good luck,
Doug
On 07/09/2013 12:18 AM, sumsum 2000 wrote:
What I am trying to achieve is this:
I am using BIND9 only for forwarding DNS requests to other DNS Servers.
I want the entire hosts in the
network : 173.252.110.0
with the host range: 173.252.110.1 - 173.252.110.254
with a total 254 addresses to be sent for reverse lookup say to DNS :
8.8.8.8, using a single zone configuration as shown below.
Instead of having a zone file for each and every IP in the network, i
want to use one zone file to have all the hosts in the network
173.252.110.0 to be forwarded to 8.8.8.8.
So when i do a dig -x 173.252.110.27 which is in the range of the
specified network, i want it be forwarded to only 8.8.8.8
When i do dig on a specific address, it gets resolved, but not through
the configured DNS 8.8.8.8, but through default DNS 8.8.4.4. I hope
this explains the situation which i am trying to solve with a zone file
delegation.
I am not sure if the zone file configuration is correct.
==
dig -x 173.252.110.27,
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-14.mlos2.mwg <<>> -x 173.252.110.27
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16896
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;27.110.252.173.in-addr.arpa.INPTR
;; ANSWER SECTION:
27.110.252.173.in-addr.arpa. 39INPTR
edge-star-shv-13-frc1.facebook.com
<http://edge-star-shv-13-frc1.facebook.com>.
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 9 07:11:49 2013
;; MSG SIZE rcvd: 93
named.conf
==
# named.conf
options {
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
allow-query {localhost;};
recursion yes;
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file
"/var/named/data/named_mem_stats.txt";
directory "/var/named";
version "none";
max-cache-size 134217728;
forward only;
};
include "/etc/rndc.key";
include "/etc/named.conf.test";
named.conf.test:
==
view "default" IN {
max-cache-ttl 600;
max-ncache-ttl 600;
zone "." IN {
type forward;
forwarders {8.8.4.4;};
forward only;
};
zone "0/24.110.252.173.in-addr.arpa" IN {
type forward;
forwarders {8.8.8.8;};
forward only;
};
};
~
On Tue, Jul 9, 2013 at 12:23 PM, Doug Barton mailto:do...@dougbarton.us>> wrote:
It's not at all clear from your description what you're trying to
accomplish. Particularly it's not clear what you seem to be trying
to accomplish with the 2317 delegation for a /24 zone.
Can you describe what you're trying to do, and why? It may be easier
to help you that way. Please use the actual zone(s) you're working
with, as that will also make it easier.
Doug
https://dougbarton.us/DNS/__bind-users-FAQ.html#RealNames
<https://dougbarton.us/DNS/bind-users-FAQ.html#RealNames>
___
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: Reverse Lookups with Forwarders
What I am trying to achieve is this:
I am using BIND9 only for forwarding DNS requests to other DNS Servers.
I want the entire hosts in the
network : 173.252.110.0
with the host range: 173.252.110.1 - 173.252.110.254
with a total 254 addresses to be sent for reverse lookup say to DNS :
8.8.8.8, using a single zone configuration as shown below.
Instead of having a zone file for each and every IP in the network, i want
to use one zone file to have all the hosts in the network 173.252.110.0
to be forwarded to 8.8.8.8.
So when i do a dig -x 173.252.110.27 which is in the range of the specified
network, i want it be forwarded to only 8.8.8.8
When i do dig on a specific address, it gets resolved, but not through the
configured DNS 8.8.8.8, but through default DNS 8.8.4.4. I hope this
explains the situation which i am trying to solve with a zone file
delegation.
I am not sure if the zone file configuration is correct.
==
dig -x 173.252.110.27,
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-14.mlos2.mwg <<>> -x 173.252.110.27
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16896
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;27.110.252.173.in-addr.arpa.INPTR
;; ANSWER SECTION:
27.110.252.173.in-addr.arpa. 39INPTR
edge-star-shv-13-frc1.facebook.com.
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 9 07:11:49 2013
;; MSG SIZE rcvd: 93
named.conf
==
# named.conf
options {
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
allow-query {localhost;};
recursion yes;
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file
"/var/named/data/named_mem_stats.txt";
directory "/var/named";
version "none";
max-cache-size 134217728;
forward only;
};
include "/etc/rndc.key";
include "/etc/named.conf.test";
named.conf.test:
==
view "default" IN {
max-cache-ttl 600;
max-ncache-ttl 600;
zone "." IN {
type forward;
forwarders {8.8.4.4;};
forward only;
};
zone "0/24.110.252.173.in-addr.arpa" IN {
type forward;
forwarders {8.8.8.8;};
forward only;
};
};
~
On Tue, Jul 9, 2013 at 12:23 PM, Doug Barton wrote:
> It's not at all clear from your description what you're trying to
> accomplish. Particularly it's not clear what you seem to be trying to
> accomplish with the 2317 delegation for a /24 zone.
>
> Can you describe what you're trying to do, and why? It may be easier to
> help you that way. Please use the actual zone(s) you're working with, as
> that will also make it easier.
>
> Doug
>
> https://dougbarton.us/DNS/**bind-users-FAQ.html#RealNames<https://dougbarton.us/DNS/bind-users-FAQ.html#RealNames>
>
___
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: Reverse Lookups with Forwarders
It's not at all clear from your description what you're trying to accomplish. Particularly it's not clear what you seem to be trying to accomplish with the 2317 delegation for a /24 zone. Can you describe what you're trying to do, and why? It may be easier to help you that way. Please use the actual zone(s) you're working with, as that will also make it easier. Doug https://dougbarton.us/DNS/bind-users-FAQ.html#RealNames ___ 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: Reverse Lookups with Forwarders
Oops mistype range: 172.16.0.0 > 172.31.255.255 range b10: 2886729728 > 2887778303 range b16: 0xac10 > 0xac1f hosts: 1048576 prefixlen: 12 mask:255.240.0.0 -- Jason Hellenthal Inbox: jhellent...@dataix.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jul 9, 2013, at 2:38, Jason Hellenthal wrote: > Only thing I see to be missing here is actual Class B address space 172.16/12 > but instead you are trying to forward from Class A public address space > assigned to FACEBOOK. I don't quite think you will get that to work... That > is unless you are the Facebook authoritative server... > > range: 172.0.0.0 > 172.15.255.255 > range b10: 2885681152 > 2886729727 range b16: 0xac00 > 0xac0f > hosts: 1048576 prefixlen: 12 > mask:255.240.0.0 > > > Was this just an intentional obfuscation ? > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > > > # > # The following results may also be obtained via: > # > http://whois.arin.net/rest/nets;q=173.252.110.0?showDetails=true&showARIN=false&ext=netref2 > # > > NetRange: 173.252.64.0 - 173.252.127.255 > CIDR: 173.252.64.0/18 > OriginAS: AS32934 > NetName:FACEBOOK-INC > NetHandle: NET-173-252-64-0-1 > Parent:NET-173-0-0-0-0 > NetType:Direct Assignment > RegDate:2011-02-28 > Updated:2012-02-24 > Ref:http://whois.arin.net/rest/net/NET-173-252-64-0-1 > > OrgName:Facebook, Inc. > OrgId: THEFA-3 > Address:1601 Willow Rd. > City: Menlo Park > StateProv: CA > PostalCode:94025 > Country:US > RegDate:2004-08-11 > Updated:2012-04-17 > Ref:http://whois.arin.net/rest/org/THEFA-3 > > OrgTechHandle: OPERA82-ARIN > OrgTechName: Operations > OrgTechPhone: +1-650-543-4800 > OrgTechEmail: n...@fb.com > OrgTechRef:http://whois.arin.net/rest/poc/OPERA82-ARIN > > OrgAbuseHandle: OPERA82-ARIN > OrgAbuseName: Operations > OrgAbusePhone: +1-650-543-4800 > OrgAbuseEmail: n...@fb.com > OrgAbuseRef:http://whois.arin.net/rest/poc/OPERA82-ARIN > > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > > -- > Jason Hellenthal > Inbox: jhellent...@dataix.net > Voice: +1 (616) 953-0176 > JJH48-ARIN > > > On Jul 9, 2013, at 2:21, sumsum 2000 wrote: > >> 173.252.110.0 smime.p7s Description: S/MIME cryptographic 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: Reverse Lookups with Forwarders
Sorry for top-post.
Your expectation is incorrect.
zone "0/24.110.252.173.in-addr.arpa"
is not the same as
zone "173.252.110.24.in-addr.arpa"
hth,
Len
>
> From: sumsum 2000
>To: bind-users@lists.isc.org
>Sent: Monday, July 8, 2013 11:21 PM
>Subject: Reverse Lookups with Forwarders
>
>
>
>I have a reverse lookup zone file configuration as follows:
>zone "0/24.110.252.173.in-addr.arpa" {
>type forward; forward only;
>forwarders {10.10.96.1;};
>};
>
>
>When I do dig -x 172.252.110.27, I expect it to forward it to 10.10.96.1, but
>instead, it uses the default resolver.
>
>Am I missing something.
>
>
>
>The address space 173.252.110.0/24 matches 255 address ranging from
>173.252.110.0-255. So if DNS Server X is configured against this zone , then
>any reverse DNS request for 173.252.110.0-173.252.110.255 should be forwarded
>via DNS Server X
Currently this is not the case. There is no forwarding in the above scenario (
where CIDR notation x.x.x.x/Mask is used) . All requests are forwarded via
global resolver only
Although a reverse lookup x.x.x.x/Mask does route through DNS Server X but this
does not seem to be valid QNAME format for PTR queries.
>
>
>Only when the zone file is changed to
>zone "110.252.173.in-addr.arpa" IN {
>type forward;
>forwarders {10.10.96.1;};
>forward only;
>};
>
>
>All the requests for
>
>173.252.110.0-173.252.110.255 is forwarded to 10.10.96.1.
>
>
>
>
>
>
>
>
>
>___
>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: Reverse Lookups with Forwarders
Only thing I see to be missing here is actual Class B address space 172.16/12 but instead you are trying to forward from Class A public address space assigned to FACEBOOK. I don't quite think you will get that to work... That is unless you are the Facebook authoritative server... range: 172.0.0.0 > 172.15.255.255 range b10: 2885681152 > 2886729727 range b16: 0xac00 > 0xac0f hosts: 1048576 prefixlen: 12 mask:255.240.0.0 Was this just an intentional obfuscation ? # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=173.252.110.0?showDetails=true&showARIN=false&ext=netref2 # NetRange: 173.252.64.0 - 173.252.127.255 CIDR: 173.252.64.0/18 OriginAS: AS32934 NetName:FACEBOOK-INC NetHandle: NET-173-252-64-0-1 Parent:NET-173-0-0-0-0 NetType:Direct Assignment RegDate:2011-02-28 Updated:2012-02-24 Ref:http://whois.arin.net/rest/net/NET-173-252-64-0-1 OrgName:Facebook, Inc. OrgId: THEFA-3 Address:1601 Willow Rd. City: Menlo Park StateProv: CA PostalCode:94025 Country:US RegDate:2004-08-11 Updated:2012-04-17 Ref:http://whois.arin.net/rest/org/THEFA-3 OrgTechHandle: OPERA82-ARIN OrgTechName: Operations OrgTechPhone: +1-650-543-4800 OrgTechEmail: n...@fb.com OrgTechRef:http://whois.arin.net/rest/poc/OPERA82-ARIN OrgAbuseHandle: OPERA82-ARIN OrgAbuseName: Operations OrgAbusePhone: +1-650-543-4800 OrgAbuseEmail: n...@fb.com OrgAbuseRef:http://whois.arin.net/rest/poc/OPERA82-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # -- Jason Hellenthal Inbox: jhellent...@dataix.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jul 9, 2013, at 2:21, sumsum 2000 wrote: > 173.252.110.0 smime.p7s Description: S/MIME cryptographic 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
Reverse Lookups with Forwarders
I have a reverse lookup zone file configuration as follows:
zone "0/24.110.252.173.in-addr.arpa" {
type forward; forward only;
forwarders {10.10.96.1;};
};
When I do dig -x 172.252.110.27, I expect it to forward it to
10.10.96.1, but instead, it uses the default resolver.
Am I missing something.
The address space 173.252.110.0/24 matches 255 address ranging from
173.252.110.0-255. So if DNS Server X is configured against this zone
, then any reverse DNS request for 173.252.110.0-173.252.110.255
should be forwarded via DNS Server X
Currently this is not the case. There is no forwarding in the above
scenario ( where CIDR notation x.x.x.x/Mask is used) . All requests
are forwarded via global resolver only
Although a reverse lookup x.x.x.x/Mask does route through DNS Server X
but this does not seem to be valid QNAME format for PTR queries.
Only when the zone file is changed to
zone "110.252.173.in-addr.arpa" IN {
type forward;
forwarders {10.10.96.1;};
forward only;
};
All the requests for
173.252.110.0-173.252.110.255 is forwarded to 10.10.96.1.
___
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: Queries using forwarders
On Jun 3, 2013, at 4:31 PM, John Miller wrote:
> Hi Mike,
>
> To keep my answer simple, if BIND is set up to allow recursion, and gets a
> recursive query for a zone it's not authoritative for, it'll:
>
> 1) Answer from cache
> 2) pass the query off to the configured forwarders
> 3) If the forwarders are unavailable, follow delegation itself to answer the
> query.
>
> BIND is only authoritative for a zone if there's a
>
> zone {}
>
> block for it (or its parent zone).
Weeelll, mostly.
built-in empty zones…
W
>
> As Steven mentioned, you can set BIND up to act as authoritative for a domain
> you don't own (e.g. malware.site.tld) so that your users get a false answer
> to their queries. It's a pretty common anti-malware/anti-spam practice, and
> also gets used (for example) in wifi captive portals.
>
> John
>
> On 06/03/2013 03:36 PM, Ward, Mike S wrote:
>> Hello all, I was trying to follow the thread on the NXDOMAIN and got lost.
>> :) I have a question about using forwarders. If the DNS that is using
>> forwarders receives a query for a zone it's not authoritative for even if
>> it's in the same network, does it go to the forwarders for zone information?
>> I'm trying to get my head around what was discussed in the NXDOMAIN thread.
>> What makes a DNS authoritative for a zone?
>>
>> ==
>> This email, and any files transmitted with it, is confidential and intended
>> solely for the use of the individual or entity to which it is addressed. If
>> you have received this email in error, please notify the system manager.
>> This message contains confidential information and is intended only for the
>> individual named. If you are not the named addressee, you should not
>> disseminate, distribute or copy this e-mail. Please notify the sender
>> immediately by e-mail if you have received this message by mistake and
>> delete this e-mail from your system. If you are not the intended recipient,
>> you are notified that disclosing, copying, distributing or taking any action
>> in reliance on the contents of this information is strictly prohibited.
>> ___
>> 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
>
--
It is impossible to sharpen a pencil with a blunt axe. It is equally vain
to try to do it with ten blunt axes instead.
-- E.W Dijkstra, 1930-2002
___
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: Queries using forwarders
The point of being authoritative is to have a full copy of the zone, so that one is basically autonomous, not dependent on anyone else to resolve names in the zone. In BIND terms, that means "type master" or "type slave". That's why authoritative zones "override" forwarding, since forwarding is a relationship of dependency. One can't be autonomous and dependent, for the same zone, at the same time. A slave nameserver is, of course, "dependent", in a sense, on getting the latest version of the zone from its master(s). But that's not a real-time dependency, since it can always (providing that it hasn't been so long that the zone has expired) answer queries from the latest version of the zone it happens to possess. - Kevin On 6/3/2013 3:36 PM, Ward, Mike S wrote: Hello all, I was trying to follow the thread on the NXDOMAIN and got lost. :) I have a question about using forwarders. If the DNS that is using forwarders receives a query for a zone it's not authoritative for even if it's in the same network, does it go to the forwarders for zone information? I'm trying to get my head around what was discussed in the NXDOMAIN thread. What makes a DNS authoritative for a zone? ___ 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: Queries using forwarders
Hi Mike,
To keep my answer simple, if BIND is set up to allow recursion, and gets
a recursive query for a zone it's not authoritative for, it'll:
1) Answer from cache
2) pass the query off to the configured forwarders
3) If the forwarders are unavailable, follow delegation itself to answer
the query.
BIND is only authoritative for a zone if there's a
zone {}
block for it (or its parent zone).
As Steven mentioned, you can set BIND up to act as authoritative for a
domain you don't own (e.g. malware.site.tld) so that your users get a
false answer to their queries. It's a pretty common
anti-malware/anti-spam practice, and also gets used (for example) in
wifi captive portals.
John
On 06/03/2013 03:36 PM, Ward, Mike S wrote:
Hello all, I was trying to follow the thread on the NXDOMAIN and got lost. :) I
have a question about using forwarders. If the DNS that is using forwarders
receives a query for a zone it's not authoritative for even if it's in the same
network, does it go to the forwarders for zone information? I'm trying to get
my head around what was discussed in the NXDOMAIN thread. What makes a DNS
authoritative for a zone?
==
This email, and any files transmitted with it, is confidential and intended
solely for the use of the individual or entity to which it is addressed. If you
have received this email in error, please notify the system manager. This
message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this message by mistake and delete
this e-mail from your system. If you are not the intended recipient, you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.
___
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: Queries using forwarders
If the records which are being requested are in the DNS server's cache then it may return the records directly from cache (depends on your configuration). If the record isn't in the cache it will attempt to fetch it and return it to the client, it will then be placed in the cache so subsequent queries for that data will be returned direct from cache. A response will be returned as authoritative when the server is an authority for that zone, as in it has been configured to serve the zone*. Steve * Whether you actually have the right to serve that zone as authoritative is another matter, for example I could easily create a zone called microsoft.com and serve it out to my local clients and they would be none the wiser (well other than it's not the real microsoft.com), if you tried to serve it externally to the Internet though it would be ignored as the DNS hierarchy for microsoft.com goes no where near your server and points at Microsoft's DNS servers. On 3 June 2013 20:36, Ward, Mike S wrote: > Hello all, I was trying to follow the thread on the NXDOMAIN and got lost. :) > I have a question about using forwarders. If the DNS that is using forwarders > receives a query for a zone it's not authoritative for even if it's in the > same network, does it go to the forwarders for zone information? I'm trying > to get my head around what was discussed in the NXDOMAIN thread. What makes a > DNS authoritative for a zone? > > == > This email, and any files transmitted with it, is confidential and intended > solely for the use of the individual or entity to which it is addressed. If > you have received this email in error, please notify the system manager. This > message contains confidential information and is intended only for the > individual named. If you are not the named addressee, you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this message by mistake and delete > this e-mail from your system. If you are not the intended recipient, you are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. > ___ > 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
Queries using forwarders
Hello all, I was trying to follow the thread on the NXDOMAIN and got lost. :) I have a question about using forwarders. If the DNS that is using forwarders receives a query for a zone it's not authoritative for even if it's in the same network, does it go to the forwarders for zone information? I'm trying to get my head around what was discussed in the NXDOMAIN thread. What makes a DNS authoritative for a zone? == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ 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: Setting a timeout for forwarders
On 24.03.13 19:05, Stephen Wood wrote: I have bind set up to forward only. Is it possible to declare a timeout for recursive queries? I can't seem to find a setting BIND tunes this timeout dynamically, you can't tuneit for now. I'm trying to protect against slow or unresponsive DNS that are declared as a forwarder in the named.conf.options settings. Why do you define such forwarders in named.conf at all? -- 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. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod ___ 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
Setting a timeout for forwarders
I have bind set up to forward only. Is it possible to declare a timeout for recursive queries? I can't seem to find a setting I'm trying to protect against slow or unresponsive DNS that are declared as a forwarder in the named.conf.options settings. ___ 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
Disable SRTT and enable round-robin for forwarders
I have a question about how smooth round-trip-time (srtt) works. If I declare 5 separate DNS servers to forward queries to and one of them is much faster than the other one, naturally the bulk of all queries will go towards that host because of its low curve, correct? However, what happens when that "fast" host timeouts during queries? Will bind adjust the srtt appropriately and begin sending it less requests by balancing them across the the slower dns servers? I am asking because I am seeing elevations of failures during times of high DNS load. One of the servers we forward to is Google, which is much faster than all of the other ones, but Google enforces a query limit of about 500 qps from what I can tell from testing. I have a feeling -- though I could certainly be wrong -- that we're breaching that limit and getting timeouts but it's taking a moment for Bind to adjust the srtt slow down the traffic to that DNS. And a followup question, is there a simple configuration change I can do to tell bind to ignore srtt values and simply round-robin across a list of DNS that I provide? Thank you in advance for your help. Cheers, Stephen Wood ___ 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: global forwarders - current BIND9 behaviour documentation
All forwarders in the list will tried at least some. Every time the fastest forwarder responds the srtt of the remaining forwarders are decayed. Eventually they will be lower and get tried. If they are slower than the original fastest their srtt go back up and the original will be used again. It's the method for retrying a forwarder after it was set high due to a timeout etc. -Ben Croswell On Jul 25, 2012 2:36 PM, "ip admin" wrote: > Hi, > > anybody there who can provide a definitive answer on the current BIND 9.7 > (or higher) global forwarder behaviour? > > I did find the following info before on using multiple forwarders: > > https://lists.isc.org/pipermail/bind-users/2007-September/067830.html > > My expectation based on that is that the fastest responding forwarder will > basically always be used until a timeout may occur, i.e. when specifying > three forwarders one will be the prefered one based on SRTT and the others > are only used if the prefered one goes down. > > First of all when doing 'rndc dumpdb -all' I cannot find my forwarders' IP > addresses in the named_dump.db at all as explained in the posting above > (BIND 9.7.3-P3 on Linux), so I cannot verify the SRTTs. 'rndc stats' / > named.stats does not show any info on the forwarders as well. > > Also by doing a tcpdump I can see that all three forwarders I have > specified are constantly used. However it is not a real round-robin but > roughly a 3:2:1 ratio instead (i.e. one receives approx 3 times the number > of queries compared to the third one, the other one receives 2 times the > number of queries compared to the 3rd one). In fact the 3:2:1 distribution > reflects the response time I can manually determine by running dig against > all forwarders - the one which responds quickest gets the most queries and > the one which is slowest gets the fewest queries. > > My server receives quite a few queries (approx 10.000 within a minute). > Any idea if the DNS-Server will send every 10th query or so the slower > forwarders? > > I also tried to set the logging level to debug 10 for category resolver > but no luck at all in finding out which forwarder is used (and why). > > So . . . if somebody could explain what the current behaviour is supposed > to be that would be helpful. > > Regards > Tom > > > ___ > 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
