Re: out of place mx records.
On 29.10.10 12:49, Mark Andrews wrote: 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. the same would apply for any other hostname not recognized by mailservers. Even localhost, if some servers do not contain zone for it. Technically the best solution would be dropping fallback for A address, however it's apparently unapplicable (or would take years). BTW. I was told that . is not a valid hostname and that it causes DNSSEC problems, at least with debian's named (9.6 ESV now, 9.5.1 before) ... can you confirm this? -- 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. ___ 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 20101112135657.gb22...@fantomas.sk, Matus UHLAR - fantomas writes: On 29.10.10 12:49, Mark Andrews wrote: 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. the same would apply for any other hostname not recognized by mailservers. Even localhost, if some servers do not contain zone for it. Technically the best solution would be dropping fallback for A address, however it's apparently unapplicable (or would take years). BTW. I was told that . is not a valid hostname and that it causes DNSSEC problems, at least with debian's named (9.6 ESV now, 9.5.1 before) ... can you confirm this? . isn't a valid hostname but named will accept it as a place holder. % named-checkzone example test test:1: no TTL specified; using SOA MINTTL instead zone example/IN: example/MX '.' (out of zone) has no addresses records (A or ) zone example/IN: loaded serial 0 OK % cat test @ IN SOA . . 0 0 0 0 0 @ IN NS . @ IN MX 10 . % It's easy enough to remove the address checks for .. DNSSEC doesn't care about valid hostnames. -- 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. ___ 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 ___ 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 20101112135657.gb22...@fantomas.sk, Matus UHLAR - fantomas writes: On 29.10.10 12:49, Mark Andrews wrote: 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. the same would apply for any other hostname not recognized by mailservers. Even localhost, if some servers do not contain zone for it. Technically the best solution would be dropping fallback for A address, however it's apparently unapplicable (or would take years). BTW. I was told that . is not a valid hostname and that it causes DNSSEC problems, at least with debian's named (9.6 ESV now, 9.5.1 before) ... can you confirm this? On 13.11.10 01:24, Mark Andrews wrote: . isn't a valid hostname but named will accept it as a place holder. % named-checkzone example test test:1: no TTL specified; using SOA MINTTL instead zone example/IN: example/MX '.' (out of zone) has no addresses records (A or ) zone example/IN: loaded serial 0 OK % cat test @ IN SOA . . 0 0 0 0 0 @ IN NS . @ IN MX 10 . % It's easy enough to remove the address checks for .. what about check-mx setting, can it be also affected by this setting? DNSSEC doesn't care about valid hostnames. ok -- 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 ___ 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 20101112143542.ga23...@fantomas.sk, Matus UHLAR - fantomas writes:
In message 20101112135657.gb22...@fantomas.sk, Matus UHLAR - fantomas wri
tes:
On 29.10.10 12:49, Mark Andrews wrote:
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.
the same would apply for any other hostname not recognized by mailservers
.
Even localhost, if some servers do not contain zone for it.
Technically the best solution would be dropping fallback for A address,
however it's apparently unapplicable (or would take years).
BTW.
I was told that . is not a valid hostname and that it causes DNSSEC
problems, at least with debian's named (9.6 ESV now, 9.5.1 before)
... can you confirm this?
On 13.11.10 01:24, Mark Andrews wrote:
. isn't a valid hostname but named will accept it as a place holder.
% named-checkzone example test
test:1: no TTL specified; using SOA MINTTL instead
zone example/IN: example/MX '.' (out of zone) has no addresses records (A o
r )
zone example/IN: loaded serial 0
OK
% cat test
@ IN SOA . . 0 0 0 0 0
@ IN NS .
@ IN MX 10 .
%
It's easy enough to remove the address checks for ..
what about check-mx setting, can it be also affected by this setting?
As I said it is a easy fix. This just copies what the srv check does.
Index: lib/dns/zone.c
===
RCS file: /proj/cvs/prod/bind9/lib/dns/zone.c,v
retrieving revision 1.574
diff -u -r1.574 zone.c
--- lib/dns/zone.c 6 Sep 2010 04:41:13 - 1.574
+++ lib/dns/zone.c 12 Nov 2010 22:08:51 -
@@ -1751,6 +1752,12 @@
int level;
/*
+* . means the services does not exist.
+*/
+ if (dns_name_equal(name, dns_rootname))
+ return (ISC_TRUE);
+
+ /*
* Outside of zone.
*/
if (!dns_name_issubdomain(name, zone-origin)) {
--
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.
In message 458977.96237...@web53606.mail.re2.yahoo.com, Fr34k writes: In message barmar-ed15c5.21262028102...@news.eternal-september.org, Barr y 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 INM X 10 mcvpemr02 be repeated trough the zone file surely this is redundant ? Some hostmasters like to ensure that mail is not directed to hosts tha t do not listen on SMTP. They prefer misdirected mail to be rejected immediately rather than waiting days for the sending system to time ou t. 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? Think about the error messages that will be sent. You want these to be meaningful. 550 User unknown. Please use u...@example.com instead. 550 User unknown. host.example.net is not a valid email destination. Messages about mailing looping, which is what you get when you say localhost, are not very informative. 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.
I'd like to suggest an alternative reason for the presence of those records: The Perl script H2N will install them by default for every single host in the zone file, unless you use the -M option to suppress their creation. Obviously this has nothing to do with the value, or lack thereof, of those records. But in answer to your original question, it may be that the only reason they exist in your environment is that your predecessor used H2N with minimal customization to generate the zone file. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
On Fri, 29 Oct 2010, Mark Andrews wrote: 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. Yup. Many MTAs already implement this. 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. Sigh. 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.
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: 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
out of place mx records.
Hi. I have taken over some dns servers, and the process of doing upgrade, half way through the process.. I have a question about the zone files , as there is some configuration here that I have not seen before and seems out of place. here is an excerpt of the zone file $TTL 14400 @ IN SOA example.com. postmaster.example.com. ( 2010042142 ; Serial 3600; Refresh (1 hours) 1200; Retry (20 minutes) 1728000 ; Expire (20 days) 14400 ; Minimum (4 hours) ) IN NS ns1.example.com. IN NS ns2.example.com. ; IN NS ns1.catalyst.net.nz. IN MX 10 mail01.example.com. IN MX 10 mail02.example.com. ; IN MX 20 mail03.example.com. IN A 202.xx.xx.2 ns1 IN A 192.168.xx.xx ns2 IN A 192.168.xx.xx listservIN A 202.xx.xx.2 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 cache IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 captaincometIN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 louie IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 mail01 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 mail02 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 nelson IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 My question is why would INMX10mcvpemr01 and INMX 10mcvpemr02 be repeated trough the zone file surely this is redundant ? Thanks Greg ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
Hello Gregory, Thu, 28 Oct 2010 13:04:58 +1300 Gregory Machin wrote: Hi. I have taken over some dns servers, and the process of doing upgrade, half way through the process.. I have a question about the zone files , as there is some configuration here that I have not seen before and seems out of place. here is an excerpt of the zone file $TTL 14400 @ IN SOA example.com. postmaster.example.com. ( 2010042142 ; Serial 3600; Refresh (1 hours) 1200; Retry (20 minutes) 1728000 ; Expire (20 days) 14400 ; Minimum (4 hours) ) IN NS ns1.example.com. IN NS ns2.example.com. ; IN NS ns1.catalyst.net.nz. IN MX 10 mail01.example.com. IN MX 10 mail02.example.com. ; IN MX 20 mail03.example.com. IN A 202.xx.xx.2 ns1 IN A 192.168.xx.xx ns2 IN A 192.168.xx.xx listservINA 202.xx.xx.2 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 cache INA 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 captaincomet IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 louie IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 mail01 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 mail02 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 nelson INA 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 My question is why would INMX10mcvpemr01 and INMX 10mcvpemr02 be repeated trough the zone file surely this is redundant ? These MX record sets aren't redundant as they belong to the different labels named listserv, cache etc. -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.name/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
Hi Gregory, mail02 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 nelson IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 My question is why would INMX10mcvpemr01 and INMX 10mcvpemr02 be repeated trough the zone file surely this is redundant ? It looks like an old way of specifying the MX for each subdomain. Cheers Ian Manners http://www.os2site.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
To me it looks redundant, named-compilezone -o - zone file should show you how bind interprets these. My guess is that they will be listed only once in the output. I don't see how they could belong to each subdomain, to do that there should be a@... to set a new origin? On 28/10/10 2:14, Ian Manners wrote: Hi Gregory, mail02 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 nelson IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 My question is why would INMX10mcvpemr01 and INMX 10mcvpemr02 be repeated trough the zone file surely this is redundant ? It looks like an old way of specifying the MX for each subdomain. Cheers Ian Manners http://www.os2site.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
Hello Sten, Thu, 28 Oct 2010 02:48:36 +0200 Sten Carlsen wrote: To me it looks redundant, named-compilezone -o - zone file should show you how bind interprets these. My guess is that they will be listed only once in the output. I don't see how they could belong to each subdomain, to do that there should be a@... to set a new origin? ; Set current origin to mail02 mail02 IN A 192.168.xx.xx ; Two lines below are still under the same origin mail02 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 ; Time to set a new origin nelson IN A 202.xx.xx.1 [...] On 28/10/10 2:14, Ian Manners wrote: Hi Gregory, mail02 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 nelson IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 My question is why would INMX10mcvpemr01 and IN MX 10mcvpemr02 be repeated trough the zone file surely this is redundant ? It looks like an old way of specifying the MX for each subdomain. -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.name/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
They prevent people who start a potentially rogue mailserver to receive mails. I.e. You centralize mails and make sure only your authorized mailserver receives them when you dont have full control over these boxes. -mat On Oct 28, 2010, at 8:48 AM, Sten Carlsen st...@s-carlsen.dk wrote: To me it looks redundant, named-compilezone -o - zone file should show you how bind interprets these. My guess is that they will be listed only once in the output. I don't see how they could belong to each subdomain, to do that there should be a@... to set a new origin? On 28/10/10 2:14, Ian Manners wrote: Hi Gregory, mail02 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 nelson IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 My question is why would INMX10mcvpemr01 and INMX 10mcvpemr02 be repeated trough the zone file surely this is redundant ? It looks like an old way of specifying the MX for each subdomain. Cheers Ian Manners http://www.os2site.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ 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
Re: out of place mx records.
In article mailman.575.1288226936.555.bind-us...@lists.isc.org, Sten Carlsen st...@s-carlsen.dk wrote: To me it looks redundant, named-compilezone -o - zone file should show you how bind interprets these. My guess is that they will be listed only once in the output. I suggest you try it, and you'll see that you guessed wrong. I don't see how they could belong to each subdomain, to do that there should be a@... to set a new origin? @ doesn't set a new origin, $ORIGIN does. @ is simply a special token that gets replaced with the current origin. When you begin a record with blank space, it means that it uses the owner name from the previous line. So: mail02 IN A 192.168.x.x IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 is equivalent to: mail02 IN A 192.168.x.x mail02 IN MX 10 mcvpemr01 mail02 IN MX 10 mcvpemr02 On 28/10/10 2:14, Ian Manners wrote: Hi Gregory, mail02 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 nelson IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 My question is why would INMX10mcvpemr01 and INMX 10mcvpemr02 be repeated trough the zone file surely this is redundant ? It looks like an old way of specifying the MX for each subdomain. Cheers Ian Manners http://www.os2site.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- 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.
Hello Gregory, Thu, 28 Oct 2010 15:54:32 +1300 Gregory Machin wrote: Hi Andrey. Thanks for you input. OK .. but most of those hosts should not be accepting email connections, buy my understanding. Or is it implied that email destined for that host would be handled by the email servers mcvpemr01 and mcvpemr02 on its behalf ? Yes. This is a nature of MX RR. If you don't want to handle mail traffic for some of your hosts (labels in terms of DNS) at all, then just route your mail as shown below: ; --- Method 1 --- ; This IP should be unreachable or the mail daemon at this host ; should refuse any connections attempts not-for-mail IN A 192.168.209.16 listserv IN A 202.xx.xx.2 IN MX 10 not-for-mail ; --- Method 2 --- listserv IN A 202.xx.xx.2 IN MX 10 not-for-mail.invalid-domain.tld. Another but more complex way is to handle such traffic at your mail relay which is silently delivers messages destined for some domains to /dev/null. Regards Gregory Machin On Thu, Oct 28, 2010 at 1:09 PM, Andrey G. Sergeev (AKA Andris) and...@aernet.ru wrote: Hello Gregory, Thu, 28 Oct 2010 13:04:58 +1300 Gregory Machin wrote: Hi. I have taken over some dns servers, and the process of doing upgrade, half way through the process.. I have a question about the zone files , as there is some configuration here that I have not seen before and seems out of place. here is an excerpt of the zone file $TTL 14400 @ IN SOA example.com. postmaster.example.com. ( 2010042142 ; Serial 3600 ; Refresh (1 hours) 1200 ; Retry (20 minutes) 1728000 ; Expire (20 days) 14400 ; Minimum (4 hours) ) IN NS ns1.example.com. IN NS ns2.example.com. ; IN NS ns1.catalyst.net.nz. IN MX 10 mail01.example.com. IN MX 10 mail02.example.com. ; IN MX 20 mail03.example.com. IN A 202.xx.xx.2 ns1 IN A 192.168.xx.xx ns2 IN A 192.168.xx.xx listserv IN A 202.xx.xx.2 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 cache IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 captaincomet IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 louie IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 mail01 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 mail02 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 nelson IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 My question is why would IN MX 10 mcvpemr01 and IN MX 10 mcvpemr02 be repeated trough the zone file surely this is redundant ? These MX record sets aren't redundant as they belong to the different labels named listserv, cache etc. -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.name/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
