need to disable dnssec for pseudo TLD zone
When I recently installed the root dnssec initial key on our DNS it broke
it's ability to accept responses for forwarded requests for a DNS block
list zone served by another system. Other queries aren't affected. The
config for the forwarded zone looks like:
zone dnsbl {
type forward;
forward only;
forwarders {
10.0.0.124;
};
};
The server at 10.0.0.124 is running rbldnsd. Queries to our main resolver
DNS for anything in the 'dnsbl' zone generate a SERVFAIL and BIND logs
messages similar to the following:
error (chase DS servers) resolving 'sbl.dnsbl/DS/IN': 10.0.0.124#53
If I disable the root initial key, the forwarded queries work again. I
think the problem is that our pseudo TLD 'dnsbl' isn't a signed zone or
something like that. The RRs for the zone are retrieved from various spam
BL repositories.
Is there a way to disable dnssec validation on a per-zone basis for
internal pseudo TLDs?
Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: t...@lava.net
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: non-improving referral
Hi Mark, Op 28/10/2010 om 13:38:13 +1100, schreef Mark Andrews: In message 20101026161348.gj2...@omroep.nl, Leo Baltus writes: We are in the process of migrating from bind-9.4-ESV-R2 to bind-9.7.2-P2. We have our authoritative servers migrated to bind-9.7.2-P2 and it all seems to work fine. While testing our caching resolvers with bind-9.7.2-P2 however, we noticed some errors in our logfiles we have never seen before. Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.3.4#53 resolvi ng 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: non-improving re ferral Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.2.2#53 resolvi ng 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: non-improving re ferral Obviously I have obscured some data here :) As you may guess this is a query for a TXT record from a blocklist-daemon. The nameservers on 1.5.3.4 and 1.5.2.2 are bind-9.7.2-P2. The queried domains are hosted by us and the hopefully relevant part of the zone looks like this: x.y.z.example.com. IN NS bl1a.example.com. x.y.z.example.com. IN NS bl1b.example.com. A dump of the cache shows NS and A records are in the cache for bl1[ab] however, on each non-cached query from the client both errorlines are printed in the log suggesting the resolver is not using the cached NS records. The client receives a valid answer, so my only real problem seems to be the amount of spam I get in our logfiles. The blocklist is served by rbldnsd, manually query-ing gives my a valid response. Could anybody tell me what problem bind is complaining about? Please CC me as I am not on this list. Run dig +trace +all 1.2.4.2.x.y.z.example.com txt and look at the results. Somewhere in that chain there will be a broken delegation. This may manifest itself as a authority section in the reply that doesn't match the delegation. The only thing that doesn't match is the TTL, 7200 on the delegation, 300 on the authoritative side. -- Leo Baltus, internetbeheerder /\ NPO ICT Internet Services/NPO/\ Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \ /\/ beh...@omroep.nl, 035-6773555 \/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
basic MX question
Hello I have a question. I am going to start in production environment a bunch of 3 mail servers for my domain, let'say mydomain.com I need to install a X509 certificate on each server in a way that upon x509 authentication thunderbird or whatever MUA won't complain about hostname different from certificate subject name of the mail server, and I also need round robin feature to have SMTP traffic load balanced between different SMTP servers. what is the best option ? option 1: IN MX 10 mx.mydomain.com IN MX 10 mx2.mydomain.com IN MX 10 mx3.mydomain.com ; ; mx.mydomain.com.IN A 10.10.10.25 m1.mydomain.com.IN A 10.10.10.26 m2.mydomain.com.IN A 10.10.10.27 option 2: IN MX 10 mx.mydomain.com mx.mydomain.com.IN A 10.10.10.25 IN A 10.10.10.26 IN A 10.10.10.27 mx1.mydomain.com. IN A 10.10.10.26 mx2.mydomain.com. IN A 10.10.10.27 are both option correct and have the same effect ? thank you Rick ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
On 28/10/10 11:56, Tony Finch wrote: On Thu, 28 Oct 2010, Gregory Machin wrote: My question is why would INMX10mcvpemr01 and INMX 10mcvpemr02 be repeated trough the zone file surely this is redundant ? Some hostmasters like to ensure that mail is not directed to hosts that do not listen on SMTP. They prefer misdirected mail to be rejected immediately rather than waiting days for the sending system to time out. Some of my colleagues have this setup on the zones they manage (eng.cam.ac.uk and cl.cam.ac.uk). We historically did this, for the same reason. We abandoned it recently, because it bloated our (already large) zone, and because the majority of the inbound email for u...@host.domain.com was spam. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: basic MX question
On Thu, 28 Oct 2010, fddi wrote: I am going to start in production environment a bunch of 3 mail servers for my domain, let'say mydomain.com I need to install a X509 certificate on each server in a way that upon x509 authentication thunderbird or whatever MUA won't complain about hostname different from certificate subject name of the mail server, and I also need round robin feature to have SMTP traffic load balanced between different SMTP servers. MX records are not used by MUAs. What you want to do is set up a name used by MUAs for message submission, e.g. smtp.mydomain.com. This will have multiple A (and perhaps ) records, one for each of your message submission servers. These servers should listen on port 587 and perhaps ports 25 (and maybe smtps on 465 for compatibility with old Microsoft MUAs that cannot talk on port 587 correctly). They should only accept mail that uses TLS and AUTH. For incoming mail from MTAs at other domains, I recommend setting up separate IP addresses that listen on port 25, since sharing port 25 for message submission and inter-domain mail limits the anti-spam techniques you can use. You can still use the same mail servers for both purposes if you configure two IP addresses on each server and configure your MTA to treat them differently. Set up a name such as mx.mydomain.com to collect the A records, and point the MX record for mydomain.com at mx.mydomain.com. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
In article mailman.585.1288263412.555.bind-us...@lists.isc.org, Tony Finch d...@dotat.at wrote: On Thu, 28 Oct 2010, Gregory Machin wrote: My question is why would INMX10mcvpemr01 and INMX 10mcvpemr02 be repeated trough the zone file surely this is redundant ? Some hostmasters like to ensure that mail is not directed to hosts that do not listen on SMTP. They prefer misdirected mail to be rejected immediately rather than waiting days for the sending system to time out. Some of my colleagues have this setup on the zones they manage (eng.cam.ac.uk and cl.cam.ac.uk). But configuring MX records won't necessarily accomplish this. It will cause mail for all these hosts to be delivered to mcvpemr01 or mcvpemr02. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
In message barmar-ed15c5.21262028102...@news.eternal-september.org, Barry Mar golin writes: In article mailman.585.1288263412.555.bind-us...@lists.isc.org, Tony Finch d...@dotat.at wrote: On Thu, 28 Oct 2010, Gregory Machin wrote: My question is why would INMX10mcvpemr01 and INMX 10mcvpemr02 be repeated trough the zone file surely this is redundant ? Some hostmasters like to ensure that mail is not directed to hosts that do not listen on SMTP. They prefer misdirected mail to be rejected immediately rather than waiting days for the sending system to time out. Some of my colleagues have this setup on the zones they manage (eng.cam.ac.uk and cl.cam.ac.uk). But configuring MX records won't necessarily accomplish this. It will cause mail for all these hosts to be delivered to mcvpemr01 or mcvpemr02. And they can do a SMTP level rejection rather than waiting for the sending server to abandon sending the email due to multiple timeouts. Just return 550 for all mail directed to users at those hosts. It would be nice if we could standardise a MX target of . as saying that this domain doesn't accept email e.g. MX 0 . the same way as SRV 0 0 0 . means that there is no service for the named protocol. That way the sending MTA or the MSA can reject the email. Every time it get suggested people shoot it down worrying about private nets that have addresses at . or get worried about thousands of machines making A/ queries for . where the MTA doesn't check that the MX target is a valid host name. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
- Original Message From: Mark Andrews ma...@isc.org To: Barry Margolin bar...@alum.mit.edu Cc: comp-protocols-dns-b...@isc.org Sent: Thu, October 28, 2010 9:49:46 PM Subject: Re: out of place mx records. In message barmar-ed15c5.21262028102...@news.eternal-september.org, Barry Mar golin writes: In article mailman.585.1288263412.555.bind-us...@lists.isc.org, Tony Finch d...@dotat.at wrote: On Thu, 28 Oct 2010, Gregory Machin wrote: My question is why would INMX10 mcvpemr01 and INMX 10 mcvpemr02 be repeated trough the zone file surely this is redundant ? Some hostmasters like to ensure that mail is not directed to hosts that do not listen on SMTP. They prefer misdirected mail to be rejected immediately rather than waiting days for the sending system to time out. Some of my colleagues have this setup on the zones they manage (eng.cam.ac.uk and cl.cam.ac.uk). But configuring MX records won't necessarily accomplish this. It will cause mail for all these hosts to be delivered to mcvpemr01 or mcvpemr02. And they can do a SMTP level rejection rather than waiting for the sending server to abandon sending the email due to multiple timeouts. Just return 550 for all mail directed to users at those hosts. It would be nice if we could standardise a MX target of . as saying that this domain doesn't accept email e.g. MX 0 . the same way as SRV 0 0 0 . means that there is no service for the named protocol. That way the sending MTA or the MSA can reject the email. Hello, Is there an advantage to process email just to have the destination MX reject it? Why not use IN MX 100 localhost so the email doesn't even leave the source? Or, am I confused? Every time it get suggested people shoot it down worrying about private nets that have addresses at . or get worried about thousands of machines making A/ queries for . where the MTA doesn't check that the MX target is a valid host name. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
