Re: Request to use "Canonical/Mirror"
On May 13, 2022, at 19.10, Felicia P wrote: > > Hello, I see that ISC updated terminology for BIND9 to use primary/secondary > in addition to the original master/slave which many projects have been > deprecating. > > In the context of BIND9, it seems that 'primary/secondary' is less clear than > master/slave. > > My understanding is that it is possible to have a standalone BIND server that > is running as a 'master' yet acting as a 'secondary' for a particular domain. > In this context, secondary doesn't necessarily refer to the 'slave' status > of the server, but that it is sort of like a backup server in the event that > the primary is unavailable. > > Given this, it seems like instead of 'primary/secondary', a better choice of > terms would be 'canonical/mirror' which unambiguously conveys the roles of > respective servers and does not overlap with other contexts or meanings of > primary/secondary. servers are neither master, nor slave, nor primary, nor secondary. zones are. -- 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: "lame-servers: info: no valid RRSIG resolving ..."
thanks- we're running 9.14.8, courtesy of the isc ubuntu ppa [https://launchpad.net/~isc]: >named -v BIND 9.14.8-Ubuntu (Stable Release) >dpkg -s bind9 Package: bind9 Status: install ok installed Priority: optional Section: net Installed-Size: 872 Maintainer: Debian DNS Team Architecture: amd64 Version: 1:9.14.8-1+ubuntu19.10.1+isc+1 Replaces: bind (<< 1:9.13.6~) [...] Homepage: https://www.isc.org/downloads/bind/ does that mean in theory the version we're running would be new enough we shouldn't be seeing that particular symptom? thanks > On Apr 17, 2020, at 19.01, Mark Andrews wrote: > > They are almost certainly the result of running an older version of named and > packet loss > causing named to fallback to plain DNS which doesn’t return DNSSEC records. > Newer versions > of named don’t fallback to plain DNS on packet loss. > > 5029. [func] Workarounds for servers that misbehave when queried >with EDNS have been removed, because these broken >servers and the workarounds for their noncompliance >cause unnecessary delays, increase code complexity, >and prevent deployment of new DNS features. See >https://dnsflagday.net for further details. [GL #150] > > BIND 9.14.0 is the first non development version with this behaviour. > > Mark > >> On 18 Apr 2020, at 01:24, btb via bind-users >> wrote: >> >> hi- >> >> i'm seeing what i'm wondering if is a lot of "lame-servers: info: no valid >> RRSIG resolving ..." messages in the logs [on average ~500 messages per >> day]. a small snippet: >> >> 15-Apr-2020 18:11:46.057 lame-servers: info: no valid RRSIG resolving >> 'jwplayer.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:11:46.150 lame-servers: info: no valid RRSIG resolving >> 'tranet.net/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:11:47.559 lame-servers: info: no valid RRSIG resolving >> 'inboxsdk.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:11:49.146 lame-servers: info: no valid RRSIG resolving >> 'basis.net/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:11:58.474 lame-servers: info: no valid RRSIG resolving >> 'starfinancial.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:11:59.665 lame-servers: info: no valid RRSIG resolving >> 'vice.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:09.501 lame-servers: info: no valid RRSIG resolving >> 'lithium.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:09.756 lame-servers: info: no valid RRSIG resolving >> 'sc-static.net/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:10.004 lame-servers: info: no valid RRSIG resolving >> 'snapchat.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:12.638 lame-servers: info: no valid RRSIG resolving >> 'yimg.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:16.823 lame-servers: info: no valid RRSIG resolving >> 'transamerica.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:16.932 lame-servers: info: no valid RRSIG resolving >> 'quantummetric.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:17.129 lame-servers: info: no valid RRSIG resolving >> 'tealiumiq.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:17.171 lame-servers: info: no valid RRSIG resolving >> 'bounceexchange.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:22.971 lame-servers: info: no valid RRSIG resolving >> 'mwefinancial.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:23.248 lame-servers: info: no valid RRSIG resolving >> 'redditmedia.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:23.869 lame-servers: info: no valid RRSIG resolving >> 'imtwjwoasak.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:25.189 lame-servers: info: no valid RRSIG resolving >> 'b.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:25.313 lame-servers: info: no valid RRSIG resolving >> 'jquery.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:26.555 lame-servers: info: no valid RRSIG resolving >> 'forter.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:29.008 lame-servers: info: no valid RRSIG resolving >> 'quovadisoffshore.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:29.029 lame-servers: info: no valid RRSIG resolving >> 'quovadisglobal.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:29.974 lame-servers: info: no valid RRSIG resolving >> 'mixpanel.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:35.786 lame-servers: info: no valid RRSIG resolving >> 'spotify.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:36.982 lame-servers: info: no valid RRSIG resolving >> 'freeform.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:38.295 lame-servers: info
"lame-servers: info: no valid RRSIG resolving ..."
hi- i'm seeing what i'm wondering if is a lot of "lame-servers: info: no valid RRSIG resolving ..." messages in the logs [on average ~500 messages per day]. a small snippet: 15-Apr-2020 18:11:46.057 lame-servers: info: no valid RRSIG resolving 'jwplayer.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:11:46.150 lame-servers: info: no valid RRSIG resolving 'tranet.net/DS/IN': 192.5.6.30#53 15-Apr-2020 18:11:47.559 lame-servers: info: no valid RRSIG resolving 'inboxsdk.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:11:49.146 lame-servers: info: no valid RRSIG resolving 'basis.net/DS/IN': 192.5.6.30#53 15-Apr-2020 18:11:58.474 lame-servers: info: no valid RRSIG resolving 'starfinancial.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:11:59.665 lame-servers: info: no valid RRSIG resolving 'vice.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:09.501 lame-servers: info: no valid RRSIG resolving 'lithium.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:09.756 lame-servers: info: no valid RRSIG resolving 'sc-static.net/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:10.004 lame-servers: info: no valid RRSIG resolving 'snapchat.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:12.638 lame-servers: info: no valid RRSIG resolving 'yimg.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:16.823 lame-servers: info: no valid RRSIG resolving 'transamerica.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:16.932 lame-servers: info: no valid RRSIG resolving 'quantummetric.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:17.129 lame-servers: info: no valid RRSIG resolving 'tealiumiq.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:17.171 lame-servers: info: no valid RRSIG resolving 'bounceexchange.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:22.971 lame-servers: info: no valid RRSIG resolving 'mwefinancial.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:23.248 lame-servers: info: no valid RRSIG resolving 'redditmedia.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:23.869 lame-servers: info: no valid RRSIG resolving 'imtwjwoasak.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:25.189 lame-servers: info: no valid RRSIG resolving 'b.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:25.313 lame-servers: info: no valid RRSIG resolving 'jquery.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:26.555 lame-servers: info: no valid RRSIG resolving 'forter.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:29.008 lame-servers: info: no valid RRSIG resolving 'quovadisoffshore.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:29.029 lame-servers: info: no valid RRSIG resolving 'quovadisglobal.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:29.974 lame-servers: info: no valid RRSIG resolving 'mixpanel.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:35.786 lame-servers: info: no valid RRSIG resolving 'spotify.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:36.982 lame-servers: info: no valid RRSIG resolving 'freeform.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:38.295 lame-servers: info: no valid RRSIG resolving 'edgedatg.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:58.190 lame-servers: info: no valid RRSIG resolving 'footprintdns.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:13:01.282 lame-servers: info: no valid RRSIG resolving 'qualifiedaddress.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:13:01.744 lame-servers: info: no valid RRSIG resolving 'dc-msedge.net/DS/IN': 192.5.6.30#53 15-Apr-2020 18:14:54.009 lame-servers: info: no valid RRSIG resolving 'facebook.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:16:20.039 lame-servers: info: no valid RRSIG resolving 'pphosted.com/DS/IN': 192.5.6.30#53 a number of these [most?] are zones that are signed, and some don't even exist, so i'm curious about seeing these messages. what am i not understanding, and/or what can i do to troubleshoot further? thanks! ___ 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
static stub zone not working as expected
hi-
i have an environment which over time has managed to accumulate various
"internal" zones [in this specific case, "foo.local"]. eventually, these zones
will be phased out, but unfortunately in the interim, i'm stuck with this. i'm
attempting to configure them as static-stub zones:
zone "foo.local" {
type static-stub;
server-addresses {
192.168.220.20;
192.168.220.21;
};
};
however, queries are not working. following a cache flush, the initial query
is servfail and subsequent queries are nxdomain:
>dig @localhost foo.local ns
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @localhost foo.local ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2550
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.local. IN NS
;; Query time: 181 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 11 16:11:02 EDT 2019
;; MSG SIZE rcvd: 38
>dig @localhost foo.local ns
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @localhost foo.local ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43056
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.local. IN NS
;; AUTHORITY SECTION:
. 10796 IN SOA a.root-servers.net.
nstld.verisign-grs.com. 2019071101 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 11 16:11:06 EDT 2019
;; MSG SIZE rcvd: 113
querying the auth nameservers directory is successful:
>dig @192.168.220.20 foo.local ns +norec
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @192.168.220.20 foo.local ns +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23
;; flags: qr aa ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;foo.local. IN NS
;; ANSWER SECTION:
foo.local. 3600IN NS 01.foo.local.
foo.local. 3600IN NS 02.foo.local.
foo.local. 3600IN NS a2.foo.local.
foo.local. 3600IN NS a1.foo.local.
;; ADDITIONAL SECTION:
01.foo.local. 3600 IN A 192.168.0.20
02.foo.local. 3600 IN A 192.168.0.21
a2.foo.local. 3600 IN A 10.201.11.8
a1.foo.local. 1200 IN A 10.201.10.119
;; Query time: 82 msec
;; SERVER: 192.168.220.20#53(192.168.220.20)
;; WHEN: Thu Jul 11 16:35:39 EDT 2019
;; MSG SIZE rcvd: 214
additionally unfortunate, there is nat involved here, due to address space
collision, and while this obviously means the practical functionality of this
is questionable, i was expecting that with a static-stub zone, the query itself
would at least function.
i see these messages in the logs:
11-Jul-2019 16:08:51.406 lame-servers: info: error (insecurity proof failed)
resolving 'foo.local/NS/IN': 192.168.220.20#53
11-Jul-2019 16:08:51.489 lame-servers: info: error (insecurity proof failed)
resolving 'foo.local/NS/IN': 192.168.220.21#53
11-Jul-2019 17:08:44.111 lame-servers: info: error (no valid DS) resolving
'foo.local/NS/IN': 192.168.220.21#53
11-Jul-2019 17:08:44.194 lame-servers: info: error (broken trust chain)
resolving 'foo.local/NS/IN': 192.168.220.20#53
i've not had much experience with dnssec yet, but it would seem that perhaps it
relates here in some capacity, as there is no public .local domain, obviously?
disabling dnssec [dnssec-enable no;] seems to support this, as when doing so,
queries work.
that said, i'm wondering why this is happening - e.g. why bind seems to be
consulting public dns for this zone, if i've explicitly told bind where to go
to find this zone data, and how i might be able to troubleshoot further, or
what my options might be.
lastly, this is currently an older version of bind [9.9.5, courtesy of ubuntu
packages]. it will be updated, but can't be just yet.
thanks!
___
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: Problem w/ Forwarding Zone in Caching-Only Config
On 6/27/17 12:13 PM, Michael W. Fleming wrote:
We're setting up a wireless printing service that uses
Zeroconf/bonjour/rendevouz dns entries. The product, Presto, has it's
own dns server for a private, on-campus only zone (presto.). We're
running bind 9.9 with a master server, three slaves and two caching-only
servers (anycasted to 136.168.255.2). We have the following in
named.conf (as per the vendor) on the caching-only servers.
zone "presto." {
type forward;
forward only;
forwarders { 136.168.2.66; };
};
on a slightly side note, i'd use a stub or static-stub zone for this,
not a forward 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: Complete DNS fake root setup example
On 2016.01.20 12.12, MURTARI, JOHN wrote: Folks, Had to do some testing where we wanted our own insulated fake root environment. We wanted to start from simulated root name servers. I was surprised I couldn’t find a complete example even after some extensive searches. The concepts are easy, but the devil is in the details. We had done this before, but no one ever kept notes so I figured by posting it on the list it will eventually find its way into Google. Here are the setup instructions below, name & ip address have been changed to protect the innocent! Your comments/suggestions are welcome! my suggestion would be to not use other people's domain names and ip addresses when protecting the innocent. after all, they're innocent too, and i'd imagine you wouldn't want them using your domain name in their examples ;) . various rfcs [6761, 3330, others] provide for these needs. -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
notify not getting without also-notify
hi-
i'm having a problem where notifies are not sent unless also-notify is used to
explicitly specify hosts.
here is the config from the computer serving the master zone:
named-checkconf -p
options {
bindkeys-file /etc/bind/keys/dnssec/bind.keys;
blackhole {
bogon;
};
session-keyalg hmac-sha512;
directory /var/cache/bind;
hostname dca-ans-1.example.com;
interface-interval 0;
managed-keys-directory /etc/bind/keys/managed;
server-id dca-ans-1.example.com;
version none;
additional-from-auth no;
additional-from-cache no;
allow-query-cache {
none;
};
allow-query-cache-on {
none;
};
allow-recursion {
none;
};
allow-recursion-on {
none;
};
dnssec-enable yes;
empty-zones-enable no;
minimal-responses yes;
recursion no;
allow-query {
any;
};
allow-query-on {
any;
};
allow-transfer {
loopback;
physical_interfaces;
slaves;
};
check-dup-records fail;
check-mx fail;
check-mx-cname fail;
check-srv-cname fail;
check-wildcard yes;
masterfile-format raw;
zone-statistics full;
};
controls {
inet 127.0.0.1 port 953 allow {
127.0.0.1/32;
} keys {
rndc-key-1;
};
};
acl loopback {
127.0.0.1/32;
::1/128;
};
acl physical_interfaces {
10.128.13.62/32;
};
acl local_network {
10.0.0.0/8;
};
acl slaves {
10.128.13.63/32;
};
acl bogon {
0.0.0.0/8;
169.254.0.0/16;
172.16.0.0/12;
192.0.0.0/24;
192.0.2.0/24;
192.168.0.0/16;
198.18.0.0/15;
198.51.100.0/24;
203.0.113.0/24;
224.0.0.0/3;
};
logging {
[...]
};
key rndc-key-1 {
algorithm hmac-md5;
secret x;
};
key ddns-key-1 {
algorithm hmac-sha512;
secret x;
};
zone 10.in-addr.arpa {
type master;
file /srv/dns/internal/master/reverse/10.in-addr.arpa;
update-policy {
grant ddns-key-1 zonesub any;
};
};
and here is the zone being served:
dig @localhost -x 10 axfr +norec
; DiG 9.9.5-3ubuntu0.2-Ubuntu @localhost -x 10 axfr +norec
; (1 server found)
;; global options: +cmd
10.in-addr.arpa.86400 IN SOA dca-ans-1.example.com.
hostmaster.example.com. 2015032904 7200 1800 1209600 3600
10.in-addr.arpa.86400 IN NS dca-ans-1.example.com.
10.in-addr.arpa.86400 IN NS dca-ans-2.example.com.
10.in-addr.arpa.86400 IN SOA dca-ans-1.example.com.
hostmaster.example.com. 2015032904 7200 1800 1209600 3600
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 29 17:19:51 EDT 2015
;; XFR size: 16 records (messages 1, bytes 449)
dca-ans-2 resolves to 10.128.13.63:
host dca-ans-2.example.com
dca-ans-2.example.com has address 10.128.13.63
when i trigger a notify, bind never sends a notify to dca-ans-2:
rndc trace 3
rndc notify 10.in-addr.arpa.
zone notify queued
debug.log:
29-Mar-2015 17:25:33.860 general: debug 1: received control channel command
'null'
29-Mar-2015 17:25:33.860 general: info: received control channel command
'notify 10.in-addr.arpa.'
29-Mar-2015 17:25:33.860 general: debug 1: zone_settimer: zone
10.in-addr.arpa/IN: enter
29-Mar-2015 17:25:33.860 general: debug 1: zone_timer: zone 10.in-addr.arpa/IN:
enter
29-Mar-2015 17:25:33.860 general: debug 1: zone_maintenance: zone
10.in-addr.arpa/IN: enter
29-Mar-2015 17:25:33.860 notify: info: zone 10.in-addr.arpa/IN: sending
notifies (serial 2015032904)
29-Mar-2015 17:25:33.860 general: debug 1: zone_settimer: zone
10.in-addr.arpa/IN: enter
but when specifying dca-ans-2 explicitly in also-notify:
also-notify {
10.128.13.63;
};
it does:
29-Mar-2015 17:27:15.945 general: debug 1: received control channel command
'null'
29-Mar-2015 17:27:15.945 general: info: received control channel command
'notify 10.in-addr.arpa.'
29-Mar-2015 17:27:15.945 general: debug 1: zone_settimer: zone
10.in-addr.arpa/IN: enter
29-Mar-2015 17:27:15.945 general: debug 1: zone_timer: zone 10.in-addr.arpa/IN:
enter
29-Mar-2015 17:27:15.945 general: debug 1: zone_maintenance: zone
10.in-addr.arpa/IN: enter
29-Mar-2015 17:27:15.945 notify: info: zone 10.in-addr.arpa/IN: sending
notifies (serial 2015032904)
29-Mar-2015 17:27:15.945 general: debug 1: zone_settimer: zone
10.in-addr.arpa/IN: enter
29-Mar-2015 17:27:15.945 notify: debug 3: zone 10.in-addr.arpa/IN: sending
notify to 10.128.13.63#53
29-Mar-2015 17:27:15.945 general: debug 3: dns_request_createvia
29-Mar-2015
Re: notify not getting without also-notify
On Mar 29, 2015, at 18.09, Mark Andrews ma...@isc.org wrote: The nameserver needs to be able to resolve the hostname of the secondary itself, it does not use the servers listed in resolv.conf. aha, that was the clue i needed, thanks. -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
behavior of dnssec-enable in relation to dnssec-validation
hi- in the arm, it says dnssec-enable: Enable DNSSEC support in named. Unless set to yes, named behaves as if it does not support DNSSEC.. behaves as if it does not support DNSSEC seemed quite unequivocal to me, so i interpreted this to mean that if dnssec-enable no; is set, no dnssec operations/behavior of any kind would be seen, period, regardless of what other settings might be set. however, it seems that if dnssec-validation auto; is set [i didn't try dnssec-validation yes;], bind does perform dnssec related operations even though dnssec-enable no; is set [from looking briefly at logs with rndc trace 1, i see what appear to be attempts at validation - retrieving ds records, dnskey records, etc]. am i misinterpreting the documentation? misinterpreting the apparent behavior? something else? thanks -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: ISO or virtual appliance
On 2013.08.22 00.39, Manish Rane wrote: Well the main idea behind and have been struggling to configure for almost last one year is to have a open source alternative to DNS Based failover/System monitoring thus have inbound loadbalancer. i guess it's worth noting, since i don't believe it's yet been mentioned, that dns offers really only a very crude form of load balancing, and does not do high availability at all. yes, there is all sorts of trickery that can be done, like changing zone data when certain events happen, and very low ttls, but these things are fundamentally at odds with both the nature of how dns works, and the essence of a courteous dns admin. there are numerous layers of caching, from the client directly contacting the authoritative nameserver all of the way through to often the operating system's resolver libraries and ultimately the program which instantiated the request to begin with. this heavy, fundamental dependence on caching means that there will be consistent failures experienced by users [especially if you are talking about high availability], since they will not necessarily see the updated zone data immediately upon failure of the service. this is also a function of the service/protocol/program in question, as there may not be iteration through the returned addresses upon failure. in terms of courtesy, theoretically, as a general rule, ttls should be encouraged to be higher, rather than lower [as is the essence of having a mechanism to cache the result in the first place], and thus encouraging use of unnecessarily low ttls is in contrast to a large part of the spirit of dns - that one can avoid unnecessary bandwidth consumption just because you might want to change your data. that is not to say that there are not legitimate applications for lower ttls [any dns admin knows that there of course are] - just that the goal should begin life as an attempt to publish higher ttls, not lower ttls. in short, although rr dns can be [and often is] a part of load balancing, there are ultimately almost always better ways to do it, and certainly better ways to do high availability. -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: Slave not creating/updating zones
On Jul 15, 2013, at 04.56, Grace Ingabire grac...@ricta.org.rw wrote: Dear Team, I have an issue where by my slave machine does not create/update new zones while pulling zones from the master. Nod2.ricta.org.rw is configured as my master, see result run from my slave(ns1……) dig @nod2.ricta.org.rw ltd.rw axfr ; DiG 9.8.1-P1 @nod2.ricta.org.rw ltd.rw axfr ; (1 server found) ;; global options: +cmd ltd.rw. 86400 IN SOA ns1.ricta.org.rw. info.ricta.org.rw. 2013071522 21600 3600 604800 86400 ltd.rw. 86400 IN NS ns1.ricta.org.rw. ltd.rw. 86400 IN NS ns2.ricta.org.rw. ltd.rw. 86400 IN TXT Generation Time: 1373884211 ashimwe.ltd.rw. 86400 IN NS ns1.kaneza.com. ashimwe.ltd.rw. 86400 IN NS ns2.kaneza.com. Serial number is updating on both my 2 slaves but zones are empty. Permission on my slave where zones should be created is bind:bind and directory created for zones has this permission: drwxr-sr-x 2 bind bind 4096 Jul 15 10:30 rw Logs shows that the transfer has been started and ended but don’t see those zones. i'm not sure what you mean don't see those zones. is the slave not serving the zone? that would be the dig output i'd want to see. -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
On Jul 12, 2013, at 09.14, sumsum 2000 sum2h...@gmail.com 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
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: Confused about a basic concept
On 2013.06.05 10.02, Bryan Harris wrote: Hi all, I think I may be confused about a very basic DNS concept. Sorry if this has been asked before. 1. I have a master and two slaves. 2. The master server is the SOA for my zone. The SOA record points to the master server. 3. Each of the two slaves are authoritative for my zone. 4. There are 2 NS records for my zone. The first NS = slave1 and the second NS = slave2. 5. The Master server is not listed in the NS records for my zone. 6. The master does not receive any queries from the clients. 7. The slaves receive queries from the clients. 8. The master - slaves relationship is via tcp/53 (notifies zone transfers) 9. The slaves - clients relationship is via udp/53 (queries) Is this correct so far? I'm being told our authoritative DNS servers should not receive any queries, as well as DNS slaves respond to queries. These statements seem like a conflict to me, but maybe I'm simply confused? whoever said our authoritative DNS servers should not receive any queries is the confused one, not you. master/slave has nothing to do with authoritative or not. the master/slave mechanism/relationship is simply one [common] choice for duplicating zone data amongst servers, using an in-band mechanism. what makes a nameserver authoritative for a zone is if it publishes zone data for that zone. where it gets the data it publishes [e.g. from a file, from a database, from some other server] has no bearing on that. in concert with publishing the zone data, to be truly accepted as authoritative, the nameservers must of course be listed in the zone's ns records as well [and in the parent's delegation], but that's a bit of a digression. what you describe above is typically referred as a hidden master configuration, and is occasionally used, but is by no means the norm, and certainly not any sort of technical requirement in the least. while there are arguably appropriate environments/applications for a hidden master, the reality is that most people i've encountered using a hidden master don't need it, and when pressed, it becomes clear they're doing it because they think that the complexity of the implementation directly correlates to their technical prowess. but then, i'm a cynical jerk :) also, on another note, master/slave relationships are not exclusively tcp, and client/server [be it master or slave] are not exclusively udp. dns uses port 53, period. that means both udp and tcp. I don't see how a slave could respond to a query unless it's authoritative. The only thing I can imagine is adding some more caching servers just for queries and have them forward+recurse to the authoritative slave servers (but they're not slaves themselves). But even in that case, the authoritative servers would still need to respond to queries, no? Otherwise how would the caching servers get any answers in the first place? any server can respond to any query. it just won't be an authoritative response unless that server has loaded/is publishing the zone data. if you put caching nameservers in between the internet and your actual nameservers, then your zone would be plain and simple broken, because the nameservers answering queries for everyone on the internet would not be answering authoritatively [and yes, they'd still have to get those answers from the actual nameservers anyway]. -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: architecture question
On May 10, 2013, at 01.18, Dave Warren da...@hireahit.com wrote: On 2013-05-08 11:13, btb wrote: it's also mildly humorous that they used to quite religiously endorse .local, in some documents even categorizing use of the same domain name on an internal and external network as a security risk. Keep in mind that this was before ubiquitous, always-on TCP/IP was the norm. It was coming, but we weren't there yet and Microsoft was still catching up. i disagree. in 1999, when .local was first referenced [and only in id form], short of perhaps the residential environment, always-on tcp/ip was commonplace - and i'm doubtful you'd even find microsoft references that early to it anyway, since microsoft was still catching up [this i heartily agree with, as they always are] :) -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: architecture question
On May 8, 2013, at 10.56, Jeremy P jpcra...@gmail.com wrote: I am building a lab environment where there are several separate domains, all of them ending in .local on a side note, i would strongly discourage you from using .local in dns. .local is a pseudo tld, reserved for use with mdns. -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: architecture question
On 2013.05.08 13.20, Steven Carr wrote: On 8 May 2013 18:09, wbr...@e1b.org wrote: This just came up with a site I support. Thanks to this list and the DNS-OARC list, I know better. Hopefully, I can redirect them to use something below their real domain for Active Directory such as ad.example.org. FWIW: MS now advises not to use .local for internal AD anymore. They suggest you use your owned/registered namespace to prevent domain collisions. http://support.microsoft.com/kb/909264 Generally, we recommend that you register DNS names for internal and external namespaces with an Internet registrar... Registering your DNS name with an Internet registrar may help prevent a name collision. it's also mildly humorous that they used to quite religiously endorse .local, in some documents even categorizing use of the same domain name on an internal and external network as a security risk. -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: architecture question
On 2013.05.08 13.33, Jeremy P wrote: I understand letter of the law, spirit of the law and playing it safe to avoid headaches. However, there are times where registering a real domain just isn't practical. For example, I'm not going to ask all of the students in my courses to go out and register a .com for the semester. It would be a waste of money as their systems never leave the local network, except through a NAT connection. So in those types of instances, I'm assuming .lan or .test are safest? well, the thing is, in reality, there is almost *never* not an actual domain name [or subdomain] which is applicable. surely the organization has a domain name, within which there is plenty of latitude for various subdomains, to accommodate a given need. that's kind of the whole entire point of how dns was designed to begin with. even if formally sanctioned subdomains aren't available [e.g. non-technical issues], there's nothing at all stopping you from unilaterally inventing your own pretend subdomain to use for such things [effectively just the same as you'd do by inventing your own pretend tld - but without the potential for upstream collision]. doing that involves little more than a modicum of effort towards avoiding collisions with other existing [or potentially existing] subdomains, but that's of course relatively trivial. not only that, in an environment in which the goal is presumably instruction and learning, what better approach to take than actual particip ation in namespace? all of that being said, i think you'll find the unspoken [and quite informal] consensus is that either the .site or .internal tld are tolerable for such use - but to reiterate my soliloquy above - why bother, when you probably don't need to? -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: BIND 9.8.2: forward zone not working
On Mar 18, 2013, at 23.04, Gerry Reno gr...@verizon.net wrote: On 03/18/2013 10:25 PM, b...@bitrate.net wrote: On Mar 18, 2013, at 20.27, Gerry Reno gr...@verizon.net wrote: Using BIND 9.8.2 When you setup Samba 4 AD DC using BIND9_DLZ and your domain has external servers (eg: www,mail) at external providers this means that the ISP and the internal network nameservers will both have SOA record for the domain. it's not really anything particularly related to samba or dlz. it's just two different computers serving the same zone. you're just hijacking or overloading that particular label. in addition to declaring the zone in your config, you'll need to delegate that new zone from the parent. it's worth noting that this scales poorly. having to add delegations and zone declarations for every label for which this is desired becomes quickly prohibitive. instead, i'd suggest using a subdomain for samba - e.g. something like ad.example.com. there are a number of other solutions as well which would likely be more sensible than hijacking labels. -ben If it was more than just a few labels I would do it another way. But this will suffice, if I can only get bind to actually get the forward zone working. I don't need any delegation. I'm not looking to slave the zone. as i said, you'll need to delegate that new zone from the parent. i'm not sure what slaves zones would have to do with that. -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: BIND 9.8.2: forward zone not working
On Mar 19, 2013, at 20.30, Gerry Reno gr...@verizon.net wrote: On 03/19/2013 08:10 PM, b...@bitrate.net wrote: On Mar 18, 2013, at 23.04, Gerry Reno gr...@verizon.net wrote: On 03/18/2013 10:25 PM, b...@bitrate.net wrote: On Mar 18, 2013, at 20.27, Gerry Reno gr...@verizon.net wrote: Using BIND 9.8.2 When you setup Samba 4 AD DC using BIND9_DLZ and your domain has external servers (eg: www,mail) at external providers this means that the ISP and the internal network nameservers will both have SOA record for the domain. it's not really anything particularly related to samba or dlz. it's just two different computers serving the same zone. you're just hijacking or overloading that particular label. in addition to declaring the zone in your config, you'll need to delegate that new zone from the parent. it's worth noting that this scales poorly. having to add delegations and zone declarations for every label for which this is desired becomes quickly prohibitive. instead, i'd suggest using a subdomain for samba - e.g. something like ad.example.com. there are a number of other solutions as well which would likely be more sensible than hijacking labels. -ben If it was more than just a few labels I would do it another way. But this will suffice, if I can only get bind to actually get the forward zone working. I don't need any delegation. I'm not looking to slave the zone. as i said, you'll need to delegate that new zone from the parent. i'm not sure what slaves zones would have to do with that. -ben As I said, if I was going to do this for a bunch of labels I would add an external view and just slave it from the ISP which holds the SOA for the external answers. i don't know what the point of that would be. you'd still have to overload your other zone. all i can do at this point is suggest you simply try what has been suggested [by multiple people]. -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: BIND 9.8.2: forward zone not working
On Mar 18, 2013, at 20.27, Gerry Reno gr...@verizon.net wrote: Using BIND 9.8.2 When you setup Samba 4 AD DC using BIND9_DLZ and your domain has external servers (eg: www,mail) at external providers this means that the ISP and the internal network nameservers will both have SOA record for the domain. it's not really anything particularly related to samba or dlz. it's just two different computers serving the same zone. you're just hijacking or overloading that particular label. in addition to declaring the zone in your config, you'll need to delegate that new zone from the parent. it's worth noting that this scales poorly. having to add delegations and zone declarations for every label for which this is desired becomes quickly prohibitive. instead, i'd suggest using a subdomain for samba - e.g. something like ad.example.com. there are a number of other solutions as well which would likely be more sensible than hijacking labels. -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: How to optimize dns requests
forwarders {
208.67.220.220;
208.67.222.222;
8.8.8.8;
};
on a semi-related note, i'd encourage you to not use forwarders. bind is
perfectly happy to lookup and cache any data necessary on its own.
-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: Registrar that supports self-run domains and provides DNSSEC support
On Feb 18, 2013, at 15.32, Robert Moskowitz r...@htt-consult.com wrote: Delving further into my challenges. Right now I use Network Solutions as my registrar. Just never changes as they were the only show in town back then. But they don't seem to support DNSSEC protected domains, and even IPv6 glue records are special requests, it seems. My registration is up for renewal; it expires 4/6/13 so this is a good time to move. But of course my domain is locked and I can't see on NS account page how to change that. I was pointed to dyn.com, but they are not clear about how to apply for them just being a registrar and how to contact them for help. Either you are asking for their managedDNS service of go to their free community forum(s). i've recently switched to gkg.net, and have had a generally positive experience so far. in addition to supporting ipv6 glue and dnssec [without having to jump through hoops], they also offer an api for ds record management, which can be helpful. -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: User wanting to use a .local domain to host DNS
On 2012.11.15 10.14, Novosielski, Ryan wrote: Failing to operate a private TLD correctly is causing internal data leaking to the Internet, which could be a security risk but in all cases is a burden on the root server system. Not that I think that I'm doing this (and as I'd said, the only place I use this is at home on a NAT'd network where there is no public DNS at all), but what are some common ways to let this happen if you happen to know? a nat'd network is a prime example of exactly the sort of place this kind of thing happens. what it usually boils down to is non public namespace being used [be it invented tlds or rfc1918/5735/etc address space] with no nameserver on the local network with those zones configured as authoritative. for example, someone decides it would be fun to have a play domain name on their private network, but doesn't set up a nameserver [aside from the simple caching nameserver built into their access device [dsl/cable modem, router, whatever]]. naturally, hosts on the network are constantly doing dns lookups which reference this domain name, and as such, the access device tries to resolve said hostname, likely passing the query on to some upstream resolver. regardless of it a forwarder is used or traditional iterative queries are used by the access device, now the query ends up getting shopped around in some capacity to various nameservers, all on the public internet, to see if it can be resolved. queries for dns data which will never exist on the public internet should never make it beyond the borders of a private network. running an authoritative nameserver with the proper zones loaded [and bind makes this even easier with empty zones] is what prevents this from happening. unfortunately, it is exceedingly common, as carsten points out, and in some contexts has become bad enough - e.g. rfc1918 arpa space - that separate nameservers have been set up to deal with the problem [rfc 6305]. -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: User wanting to use a .local domain to host DNS
On 2012.11.15 11.39, Novosielski, Ryan wrote: Great, thanks, sounds like I'm covered then (I have BIND running authoritative for my zone on the firewall/NAT machine only accepting queries from my local 1918 addresses) and DHCP providing its address as the nameserver. be sure that bind is also authoritative for your 1918 arpa space as well [and you might as well just make it authoritative for all previously mentioned address space]. accepting queries from only your private network is good, but that alone will not prevent leakage [and leakage is never good, dns or otherwise :) ] -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: User wanting to use a .local domain to host DNS
On 2012.11.14 10.02, King, Harold Clyde (Hal) wrote: I'm a bit confused by a user request. I think he is trying to keep some hosts on the private side of DNS, but he wants to use a DNS name like host.sub.local. I do not know of the use of the .local TLD except in bonjure. Can anyone shed some light on the use of the .local TLD? this is a bad idea, plain and simple. don't do it. .local is reserved [as others have mentioned] for mdns/zeroconf, and while there may still be some undulation in the various documents which standardize it, it is in active, relatively prevalent use today. i repeatedly see demonstrable, reproducible problems which manifest in mysterious symptoms to those who do not understand the difference between dns and name resolution. while dns itself does not care in the slightest what string a person might choose to use in a label [given of course the constraints of character sets in general], the various name resolution mechanisms used by a system's stub resolver/libraries risk being short circuited [dependent on the specifics of the configuration] by the mdns resolution mechanism if there is a .local reference. while there are no formally established private tlds, the closest thing to a consensus is to user either .site or .internal for this sort of thing. that being said - i question the necessity of a special internal domain. not only is it likely to generate confusion for users, rarely is this truly necessary, with the trivial expense of domain names [not to mention the probability of existing ownership anyway] and mechanisms like split horizon/views. -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: ISC Bind in Active Directory
On Oct 19, 2012, at 13.27, Phil Mayers wrote: Nicholas F Miller nicholas.mil...@colorado.edu wrote: DDNS record scavenging is the only feature I'm aware of that MS DNS has that Bind doesn't . On the flip side, ISC Bind can ACL who can add certain record types to a dynamic zone using GSS-TSIG as well as supports views and ACLs for recursion. Everything else should be standard DNS. Yeah, that would be nice to have actually. More generally, metadata on ddns records would be useful. to be honest, this doesn't seem to me to be something that would fall within bind's purview. comparing bind to microsoft dns isn't really apples to apples. microsoft dns is more than just a dns server. it's also a dns management system [whereas bind is not], which is where things like scavenging dns data or publishing metadata would belong. one partial example of this would be dhcpd's use of ddns, which uses txt records to include some metadata in dns.as it is, bind can fully support probably any such mechanism, with the benefit of being agnostic. i like that modularity, and would be disappointed if it changed. -b ___ 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: Version statement...
On Aug 17, 2012, at 22.02, Michael Hoskins (michoski) wrote: -Original Message- From: Jeff Justice listacco...@starionline.com Date: Friday, August 17, 2012 6:10 PM To: bind-users@lists.isc.org bind-users@lists.isc.org Subject: Re: Version statement... Okay, here's what I know: named-checkconf says there are no errors. There is only one named process running. When I apply my edited named.conf, the log shows named stopping and restarting with no errors. How can I check to see the path where my named process thinks named.conf is located? I think configuration and OS tools are your best bet... strings -a /path/to/named | grep -iF 'named.conf' and/or named -V, looking for --sysconfdir= -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: Query about mirroring Root DNS Server
On 07/06/2012 06:30 AM, Tony Finch wrote: Gaurav Kansal gaurav.kan...@nic.in wrote: Somewhere I heard that one of the Root Servers allows you to take a zone copy of that, so that if you want to look and feel about Root DNS servers, you can do so. Is it true? If yes then can anyone please guide me which Root DNS Server is allowing for the same? You can find out for yourself (see below). I usually use the F root since I know the ISC has a long-term policy of allowing zone transfers. Some people like to slave the root zone on their recursive servers instead of using the root zone hints. This is not the same as looking or feeling like a root server. If you want to actually look and feel like a root server, talk to ICANN who are very liberal in allowing sites to host instances of the L root. http://blog.icann.org/2012/03/l-root-in-your-pocket/ http://dns.icann.org/lroot/infocollect/ it can also be retrieved out of band: https://www.iana.org/domains/root/files -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: Using proxy DNS servers for bind as an alternative to slave servers.
On 07/01/2012 02:42 PM, J P wrote: Hello all! I understand RFC compliant DNS servers use AXFR and IXFR for synching bewteen masters and slaves... and that this is the general scenario for that purpose. However, I need somebody to technically explain to me why cant I use a DNS resolver daemon such as the pdnsd dns proxy daemon with a cache of for example 5 minutes... so I can configure it to forward requests to my master (where I feed and store my zones), with the cache being 5 minutes then iam sure the latency between my master and the proxy will be minimal. Is this possible why yes or why not. a couple of things come to mind. there are probably other issues as well. to begin with, if this other server is not actually loading the zone itself, and is just forwarding all requests to your master, you'd need to somehow get this other server to answer those requests authoritatively. i don't know how pdnsd dns proxy daemon works, but air, the software i'm familiar with does not answer authoritatively for that sort of configuration. second, even if you could get the software to sort of lie and answer authoritatively, you're losing largely all of the benefits of a slave nameserver by doing something like this. if you cached data for five minutes [which raises another question as to how you would do this - i hope not by using a ttl of 5 minutes for all records on the master], then any changes you made would not be reflected on this server for up to five minutes - whereas if it were a properly configured slave, the changes would be reflected immediately. additionally, were the master to become unavailable, this other server would only be able to answer queries for five more minutes, at which point it's cache would expire and it would have no server to get answers from. in contrast, an actual slave nameserver is typically configured to continue serving the zone for much longer than five minutes if the master becomes unreachable [generally weeks, at least], regardless of the ttls for the individual records that might be served. in terms of latency, i'm not quite sure what you're getting after, but there is, for all intents and purposes, no latency in a traditional master/slave environment [if nothing else, certainly magnitudes smaller than five minutes]. having additional nameservers which become basically useless if the master has a problem doesn't make much sense to me. my suggestion would really be to take a bit of a different philosophical approach, and instead of pursuing an abnormal environment unless there is some prohibitive aspect, just pursue a normal, tried and tested environment unless there is some genuine reason why you can't. if there is some aspect of a traditional master/slave [or some variation thereof] environment that you're concerned might pose issues, my recommendation would be to just ask about that. regards -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: new here
On 2012.05.02 13.01, David wrote:
Hello All,
I am new here but have been watching the list for a while.
I run a small WISP and we have just moved to a new carrier.
They have provided us with a cdir ipv4 block of /22 and a /23.
I am trying to get my reverse DNS working correctly but they will not point
their servers to my authoritative servers to tell these blocks where to
find
their reverse. They told me to place forwards in my servers which I have
done.
this all seems terribly and unnecessarily convoluted. the 6 arpa zones
for this address space should simply be delegated to your nameservers.
you are saying that your provider will not do this?
FYI: I am running Bind 9 latest stable on my systems not sure what the
carrier is running.
Here is what they show on their logs:
01-May-2012 09:07:30.868 transfer of '104-22.16.98.in-addr.arpa/IN' from
98.16.104.14#53: connected using 207.91.5.70#40513
01-May-2012 09:07:30.971 transfer of '104-22.16.98.in-addr.arpa/IN' from
98.16.104.14#53: failed while receiving responses: NOTAUTH
01-May-2012 09:07:30.971 transfer of '104-22.16.98.in-addr.arpa/IN' from
98.16.104.14#53: end of transfer
they appear to be attempting classless arpa delegation, but with net
blocks larger than /24. this seems odd to me.
Here is what My logs show:
02-May-2012 15:28:29.979 security: client 162.40.117.250#6483: query
(cache) '104-22.16.98.in-addr.arpa/SOA/IN' denied
02-May-2012 15:28:30.133 xfer-out: client 162.40.117.250#43378: bad zone
transfer request: '104-22.16.98.in-addr.arpa/IN': non-authoritative zone
(NOTAUTH)
Here is what the named.conf zone looks like
zone 104.16.98.in-addr.arpa {
type master;
file /var/named/98.16.104.rev;
allow-transfer {
166.102.165.15;
162.39.164.14;
207.91.5.70;
162.40.117.250;
};
they want you to have a zone named 104-22.16.98.in-addr.arpa, yet you
have instead proclaimed a zone named 104.16.98.in-addr.arpa. why they
want this, though, is a mystery to me.
I placed the forwarders to allow transfer on this zone but I think the
zone name is no good.
i'm not sure what they're/you're referring to with forwarders here, but
it's not really relevant given the context so far.
-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: new here
On May 02, 2012, at 14.41, David wrote: so far they are telling me that their systems require the forwards. I think they have it backwards.. please keep replies on the list. yes, it certainly seems so. if you indeed have been assigned a /22 and a /23, then a number of things should happen [all of which are quite routine]- the address space should be swip'd to you, as per iana's policies, and the arpa zones which accompany said address space should be delegated to you. if there is some compelling reason to not follow this long established convention, i'd ask your provider to explain themselves. -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: Host command timing out sporadically
On May 02, 2012, at 18.41, Paul Marais wrote: So it looks like I just need to make postfix use a longer timeout perhaps. or, you could just not use your isp's nameservers, and let bind do what it does. it's unlikely that your isp's nameservers are doing you great favors, if any at all. either way, recursion needs to be allowed for any clients [this includes localhost] which expect to be able to look up arbitrary information in dns. -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
