Re: lists subdomain not fully working
Il 25/05/2015 15:39, Niall O'Reilly ha scritto:
On Mon, 25 May 2015 11:26:58 +0100,
Lucio Crusca wrote:
I moved my bind installation to a new server two weeks ago and I
copied the zones verbatim: on the old server everything was working
ok.
More precisely, you weren't aware of a problem, which is not
necessarily the same thing.
I am aware there wasn't this problem, because the two users told me
about this problem only after I moved the mailing list to the new
server. Before the move, they could use the mailing list just fine.
The zone lists.granellodisenape.org
This isn't a zone, as it's not delegated; it's just a host, as can
be seen by requesting relevant DNS resource records from one of the
servers (ns{1,2}.virtualbit.it) responsible for the zone
granellodisenape.org.
You are absolutely right, my mistake. It's the host where mailman is
installed, the new server.
Where your new server fits in all of this isn't clear, as you don't
mention what either its name or its address is.
See above, it's lists.granellodisenape.org.
It may be useful for you to use a public validation service (such as
http://zonemaster.net/) to check the name service for your zone.
I've tried, here are the results: http://zonemaster.net/test/13162
Seems to me the two warnings can't be the cause of a "non-existant
domain" error.
550 RCPT address has non-existant domain
From where I sit, this problem does not appear.
If you can confirm that this problem is still present, you'll need
to look for help with analysing it to someone who has access to the
name server(s) used by this SMTP server. Either of the users you
mention may be able to help.
I confirm the problem is still present, and your suggestion confirms
what I was fearing: I won't be able to solve this problem, because I
need assistance from alice.it, the italian telco with a nice call center
full of monkeys, and I'm not even between their customers. I'm going to
tell the two users the only viable solution is changing email provider.
___
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
key-restricted nsupdate of internal view's zone's host REFUSED with 'signer "" denied' ?
I run
named -v
BIND 9.10.2
in split-horizon mode with two views
view "internal" {
view "external" {
For a single zone
MYDOMAIN.com
I'm targeting two hostnames in the zone
test.MYDOMAIN.com
external.test.MYDOMAIN.com
for dynamic updates. At any given time, the A records should return
view=internal:
dig A test.MYDOMAIN.com +short
A.B.C.D
dig A external.test.MYDOMAIN.com +short
10.1.1.14
view=external:
dig A test.MYDOMAIN.com +short
A.B.C.D
dig A external.test.MYDOMAIN.com +short
A.B.C.D
I want to dynamically update A.B.C.D, using 'nsupdate'. I.e., I'll update
internal: external.test.MYDOMAIN.com
external: test.MYDOMAIN.com
external: external.test.MYDOMAIN.com
In my dns conf
cat named.conf
...
acl presgrp_internal { localhost; 10.1.1.0/24;
2001:xxx::xxx::/64; };
...
view "internal" {
match-clients { key test-key; presgrp_internal; };
...
zone "MYDOMAIN.com" {
type master; file
"/namedb/master/internal.MYDOMAIN.com.zone";
update-policy {
grant brahms-rndc-key zonesub ANY;
grant test-key name external.test.MYDOMAIN.com ANY;
};
};
...
view "external" {
match-clients { key test-key; any; };
...
zone "MYDOMAIN.com" IN {
type master; file "/namedb/master/MYDOMAIN.com.zone";
update-policy {
grant test-key name test.MYDOMAIN.com ANY;
grant test-key name external.test.MYDOMAIN.com ANY;
};
};
...
I have an update script
cat dyn-update.sh
#!/bin/sh
IP=$1
NSUPDATE="/usr/local/bind9/bin/nsupdate"
RNDC="/usr/local/bind9/sbin/rndc"
KEYFILE="/usr/local/etc/named/keys/test.rndc.key"
SERVER="2001:xxx::xxx::100"
ZONE="MYDOMAIN.com"
HOST="test"
cat
RRL settings that work for you
Hi folks,
I've read about RRL with interest since its inception, but just now
getting around to rolling it out. That is partially because we run a very
small authoritative infrastructure serving mostly as Akamai EDNS origins.
However, since it is exposed externally, used by a few tenants and RRL has
been running in the wild for awhile now...we decided to finally hop on the
bandwagon as part of our latest round of DNS infrastructure upgrades.
We are experimenting in log-only mode, and wanted to get feedback on
settings which work well for others in production. So far we have the
following which appears to work well (not limiting typical clients during
normal operation):
rate-limit {
log-only yes;
ipv4-prefix-length 32;
window 10;
responses-per-second 20;
nxdomains-per-second 10;
exempt-clients {
[...]
};
};
However, as we've mostly just been turning knobs in an attempt to minimize
log entries... insight from operators is appreciated.
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: random latency in named
FWIW as another data point we've seen the same in the wild across RHEL/CentOS 5.x and 6.x on "large" (32 core) Xeon based servers (E5-2650's), including 6.6 with the 2.6.32-504.16.2.el6.x86_64 kernel. Observed while debugging other things, and haven't had time to follow up. -Original Message- From: Mathew Ian Eis Date: Friday, May 22, 2015 at 11:33 AM To: "bind-users@lists.isc.org" Cc: Tony Finch Subject: Re: random latency in named > >-Original Message- >From: Tony Finch >Date: Friday, May 22, 2015 at 2:32 AM >To: Mathew Eis >Cc: "bind-users@lists.isc.org" >Subject: Re: random latency in named > >>Mathew Ian Eis wrote: >>> >>> * The OS is RHEL 6.6; we just updated the kernel to >>> 2.6.32-504.16.2.el6.x86_64, also with no effect. >> >>Is your server using a Haswell CPU? If so it might be the lost futex >>wakeup bug discussed at the links below, in which case the problem might >>go away if you upgrade to RHEL 6.6.z. >> >>https://groups.google.com/forum/#!topic/mechanical-sympathy/QbmpZxp6C64 >>https://news.ycombinator.com/item?id=9542548 > >Nope, AMD here, but that probably wouldn¹t rule it out. I think I have a >comment somewhere on that HN thread... It looks like the futex bug >probably affects all architectures; just some more than others, as the >actual kernel patch references ARM. > >Anyhow, I wish it had been that, but the 2.6.32-504.16.2.el6.x86_64 kernel >didn¹t fix the issue. > >(6.6 2.6.32-504.16.2.el6.x86_64 kernel is the 6.6.z one): >https://rhn.redhat.com/errata/rhel-server-6.6-errata.html > >https://rhn.redhat.com/errata/RHSA-2015-0864.html > > >Thanks, > >Mathew Eis >Northern Arizona University >Information Technology Services > >___ >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: key-restricted nsupdate of internal view's zone's host REFUSED with 'signer "" denied' ?
You can't update multiple views with a single update message. Use
two update commands. The update is being processed by the first
view and the policy in the internal zone doesn't allow you to update
*every* record you are attempting to update so the whole update is
refused.
Also use two different keys for internal and external. You currently
can only update the internal view as the key is common to both views
and you are using it in match-clients to select which view is
matched.
match-clients { !key external ; key internal ; ... };
match-clients { !key internal ; key external ; ... };
Mark
In message <1432655713.2057519.278447305.2152c...@webmail.messagingengine.com>
, PGNd writes:
> I run
>
> named -v
> BIND 9.10.2
>
> in split-horizon mode with two views
>
> view "internal" {
> view "external" {
>
> For a single zone
>
> MYDOMAIN.com
>
> I'm targeting two hostnames in the zone
>
> test.MYDOMAIN.com
> external.test.MYDOMAIN.com
>
> for dynamic updates. At any given time, the A records should return
>
> view=internal:
> dig A test.MYDOMAIN.com +short
> A.B.C.D
> dig A external.test.MYDOMAIN.com +short
> 10.1.1.14
>
> view=external:
> dig A test.MYDOMAIN.com +short
> A.B.C.D
> dig A external.test.MYDOMAIN.com +short
> A.B.C.D
>
> I want to dynamically update A.B.C.D, using 'nsupdate'. I.e., I'll update
>
> internal: external.test.MYDOMAIN.com
> external: test.MYDOMAIN.com
> external: external.test.MYDOMAIN.com
>
> In my dns conf
>
> cat named.conf
> ...
> acl presgrp_internal { localhost; 10.1.1.0/24; 2001:xxx::x
> xx::/64; };
> ...
> view "internal" {
> match-clients { key test-key; presgrp_internal; };
> ...
> zone "MYDOMAIN.com" {
> type master; file "/namedb/master/internal.MYDOMAIN.com.zo
> ne";
> update-policy {
> grant brahms-rndc-key zonesub ANY;
> grant test-key name external.test.MYDOMAIN.com ANY;
> };
> };
> ...
> view "external" {
> match-clients { key test-key; any; };
> ...
> zone "MYDOMAIN.com" IN {
> type master; file "/namedb/master/MYDOMAIN.com.zone";
> update-policy {
> grant test-key name test.MYDOMAIN.com ANY;
> grant test-key name external.test.MYDOMAIN.com ANY;
> };
> };
> ...
>
> I have an update script
>
> cat dyn-update.sh
> #!/bin/sh
> IP=$1
>
> NSUPDATE="/usr/local/bind9/bin/nsupdate"
> RNDC="/usr/local/bind9/sbin/rndc"
> KEYFILE="/usr/local/etc/named/keys/test.rndc.key"
>
> SERVER="2001:xxx::xxx::100"
> ZONE="MYDOMAIN.com"
> HOST="test"
>
> cat < server ${SERVER}
> zone ${ZONE}
> local ::1
> update delete ${HOST}.${ZONE}. ANY
> update delete external.${HOST}.${ZONE}. ANY
> update add ${HOST}.${ZONE}. 5 A ${IP}
> update addexternal.${HOST}.${ZONE}. 5 A ${IP}
> update add ${HOST}.${ZONE}. 5 TXT "Updated on $(da
> te)"
> update addexternal.${HOST}.${ZONE}. 5 TXT "Updated on $(da
> te)"
> show
> send
> EOF
>
> ${RNDC} reload
>
> where
>
> cat /usr/local/etc/named/keys/test.rndc.key
> key "test-key" {
> algorithm hmac-md5;
> secret "gcNd3eCe87cc3FefDD8e5Z==";
> };
>
> On exec of the update script
>
> sh dyn-update.sh 11.22.33.44
> Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
> ;; ZONE SECTION:
> ;MYDOMAIN.com. IN SOA
>
> ;; UPDATE SECTION:
> test.MYDOMAIN.com. 0 ANY ANY
> external.test.MYDOMAIN.com. 0 ANY ANY
> test.MYDOMAIN.com. 5 IN A 11.22.33.44
> external.test.MYDOMAIN.com. 5 IN A 11.22.33.44
> test.MYDOMAIN.com. 5 IN TXT "Updated on Tue May
> 26 08:25:40 PDT 2015"
> external.test.MYDOMAIN.com. 5 IN TXT "Updated on Tue May
> 26 08:25:40 PDT 2015"
>
> update failed: REFUSED
>
bind9 Numerous recent - error (FORMERR) resolving 'dns3.registrar-servers.com/AAAA/IN'
All, I have run bind8 and bind9 for the past 15 years beginning on Mandrake before it went corporate and tanked. Over the past few weeks to a month or so, my logs have been filling with (FORMERR) messages like: May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#53 resolving dns3.registrar-servers.com/: invalid response May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 'dns3.registrar-servers.com//IN': 208.67.222.222#53 May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#53 resolving dns4.registrar-servers.com/: invalid response May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 'dns4.registrar-servers.com//IN': 208.67.222.222#53 May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#53 resolving dns2.registrar-servers.com/: invalid response May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 'dns2.registrar-servers.com//IN': 208.67.222.222#53 May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#53 resolving dns3.registrar-servers.com/: invalid response May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 'dns3.registrar-servers.com//IN': 208.67.220.220#53 May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#53 resolving dns4.registrar-servers.com/: invalid response May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 'dns4.registrar-servers.com//IN': 208.67.220.220#53 May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#53 resolving dns2.registrar-servers.com/: invalid response May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 'dns2.registrar-servers.com//IN': 208.67.220.220#53 I'm not sure what to make of it. Is there something that has changed requiring an update on my end, or is this just an issue with the remote? I have an older bind 9.9.1 running. -- David C. Rankin, J.D.,P.E. ___ 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: bind9 Numerous recent - error (FORMERR) resolving 'dns3.registrar-servers.com/AAAA/IN'
Well 208.67.220.220 returns the wrong SOA record which is why you are getting the message. For that matter why are you talking to 208.67.220.220 in the first place? It is not normally involved in resolving dns2.registrar-servers.com. registrar-servers.com. 2898IN NS dns1.name-services.com. registrar-servers.com. 2898IN NS dns3.name-services.com. registrar-servers.com. 2898IN NS dns4.name-services.com. registrar-servers.com. 2898IN NS dns5.name-services.com. registrar-servers.com. 2898IN NS dns2.name-services.com. ;; ADDITIONAL SECTION: dns4.name-services.com. 7 IN A 98.124.194.1 dns3.name-services.com. 7 IN A 98.124.193.1 dns5.name-services.com. 7 IN A 98.124.196.1 dns2.name-services.com. 7 IN A 98.124.197.1 dns1.name-services.com. 6 IN A 98.124.192.1 ; <<>> DiG 9.11.0pre-alpha <<>> dns2.registrar-servers.com @208.67.220.220 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41549 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;dns2.registrar-servers.com.IN ;; AUTHORITY SECTION: . 1434IN SOA a.root-servers.net. nstld.verisign-grs.com. 2015052601 1800 900 604800 86400 ;; Query time: 19 msec ;; SERVER: 208.67.220.220#53(208.67.220.220) ;; WHEN: Wed May 27 08:24:35 EST 2015 ;; MSG SIZE rcvd: 130 In message <5564f08c.4070...@suddenlinkmail.com>, "David C. Rankin" writes: > All, > >I have run bind8 and bind9 for the past 15 years beginning on Mandrake be > fore > it went corporate and tanked. Over the past few weeks to a month or so, my l > ogs > have been filling with (FORMERR) messages like: > > May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#5 > 3 > resolving dns3.registrar-servers.com/: invalid response > May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving > 'dns3.registrar-servers.com//IN': 208.67.222.222#53 > May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#5 > 3 > resolving dns4.registrar-servers.com/: invalid response > May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving > 'dns4.registrar-servers.com//IN': 208.67.222.222#53 > May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#5 > 3 > resolving dns2.registrar-servers.com/: invalid response > May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving > 'dns2.registrar-servers.com//IN': 208.67.222.222#53 > May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#5 > 3 > resolving dns3.registrar-servers.com/: invalid response > May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving > 'dns3.registrar-servers.com//IN': 208.67.220.220#53 > May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#5 > 3 > resolving dns4.registrar-servers.com/: invalid response > May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving > 'dns4.registrar-servers.com//IN': 208.67.220.220#53 > May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#5 > 3 > resolving dns2.registrar-servers.com/: invalid response > May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving > 'dns2.registrar-servers.com//IN': 208.67.220.220#53 > >I'm not sure what to make of it. Is there something that has changed > requiring an update on my end, or is this just an issue with the remote? I h > ave > an older bind 9.9.1 running. > > -- > David C. Rankin, J.D.,P.E. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscrib > e 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: key-restricted nsupdate of internal view's zone's host REFUSED with 'signer "" denied' ?
On Tue, May 26, 2015, at 02:32 PM, Mark Andrews wrote:
> You can't update multiple views with a single update message. Use
> two update commands. The update is being processed by the first
> view and the policy in the internal zone doesn't allow you to update
> *every* record you are attempting to update so the whole update is
> refused.
>
> Also use two different keys for internal and external. You currently
> can only update the internal view as the key is common to both views
> and you are using it in match-clients to select which view is
> matched.
>
> match-clients { !key external ; key internal ; ... };
>
> match-clients { !key internal ; key external ; ... };
Clear.
Works perfectly.
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: RRL settings that work for you
On 27/05/2015 07:00, Mike Hoskins (michoski) wrote:
> Hi folks,
>
> I've read about RRL with interest since its inception, but just now
> getting around to rolling it out. That is partially because we run a very
> small authoritative infrastructure serving mostly as Akamai EDNS origins.
> However, since it is exposed externally, used by a few tenants and RRL has
> been running in the wild for awhile now...we decided to finally hop on the
> bandwagon as part of our latest round of DNS infrastructure upgrades.
>
> We are experimenting in log-only mode, and wanted to get feedback on
> settings which work well for others in production. So far we have the
> following which appears to work well (not limiting typical clients during
> normal operation):
>
> rate-limit {
> log-only yes;
> ipv4-prefix-length 32;
> window 10;
> responses-per-second 20;
> nxdomains-per-second 10;
> exempt-clients {
> [...]
> };
>
> };
>
> However, as we've mostly just been turning knobs in an attempt to minimize
> log entries... insight from operators is appreciated.
Looks good, its pretty close to what I use, however one thing to
consider (maybe you have) is the ipv6 prefix, its default from memory is
56, in Australia, the typical assignments for those few ISP's issuing
IPv6, is /64, so I set "ipv6-prefix-length 64", but depends on
geographic's I suppose, maybe if your traffic is mostly U.S. and if the
average U.S. ISP dishes out /56's, it doesn't matter much to change it.
Cheers
___
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: lists subdomain not fully working [SOLVED]
On May 26, 2015 at 19:27, Niall O'Reilly wrote: TTL and same subnet can't matter. I had in mind rather the warning about the SOA MNAME. You the man! I totally overlooked those messages by zonemaster just because of their green background color, which was meaning to me "these are the OK things". I've now fixed the MNAME and I have to wait propagation before testing again, but I'm really confident it will solve the problem, because the old server had bind, mailman, courier, apache and everything on it, so any MNAME could work, in the end it was always the same server. Now they are 3 different servers and the primary DNS is just one of them. Thanks a lot! ___ 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
