[afnog] SMTP server rejecting domain

[Brian Candler]

On Mon, Jun 05, 2006 at 07:45:45AM +0200, David Chima wrote:
> You are right. But what I meant is that mangaliso should just make sure that what is declared in the .org database for 
> NSes for cedrisa.org should not be only secondaries for this domain but include a primary. Currently, the NSes for the 
> domain as declared at .org does not include the primary nameserver. As Randy has put it with doc, it straight asks 
> chambo.sdnp.org.mw for SOA. I guess that's what is declared as primary for this domain at .org while at present it is 
> nyala.sdnp.org.mw which is the primary for the domain yet not declared at .org.

As I said before, the distinction between master and slave is arbitary.

It is a common (and perfectly legitimate) arrangement to have a "hidden"
master server which is not listed in the NS records at all.

The hidden master is where the zone files are built and maintained. There
are then a number of slaves which copy from this master. The NS records list
only the slaves, and not the master.

This arrangement is sometimes chosen if the number of zones is very large,
and the master server doesn't want to have the load of processing inbound
queries from the Internet in addition to its work of building and rebuilding
zone files. Sometimes it's chosen for security reasons, since the master can
be completely firewalled off from the Internet, and only needs to allow zone
transfers from the slaves.

The real problem with cedrisa.org is that it is delegated to two
nameservers, both of which are non-authoritative or unreachable. Whether one
is master and the other slave, or both slaves, for this zone is not
relevant.

Actually, I've just tried again and right now one of them is answering
properly:

$ dig +norec @tld1.ultradns.net. cedrisa.org. mx
...
;; AUTHORITY SECTION:
cedrisa.org.            86400   IN      NS      domwe.leland-mw.org.
cedrisa.org.            86400   IN      NS      chambo.sdnp.org.mw.

$ dig +norec @domwe.leland-mw.org. cedrisa.org. mx
...
;; ANSWER SECTION:
cedrisa.org.            14400   IN      MX      10 domwe.leland-mw.org.
cedrisa.org.            14400   IN      MX      15 kalata1.sdnp.org.mw.
cedrisa.org.            14400   IN      MX      5 zalewa.sdnp.org.mw.

;; AUTHORITY SECTION:
cedrisa.org.            14400   IN      NS      domwe.leland-mw.org.
cedrisa.org.            14400   IN      NS      nyala.sdnp.org.mw.

This shows a different problem, an inconsistency: the delegation from the
zone above is to domwe and chambo, but the NS records *within* the zone list
domwe and nyala.

They need to match, and to point to whatever is the correct list of
nameservers which are (a) authoritative for this zone, and (b) intended to
answer queries from the Internet.

Regards,

Brian.

P.S. chambo is lame for this domain. Although it has no info itself, if you
make a recursive query it finds domwe and puts info in its cache, which it
then returns in subsequent queries. You can see this by watching the TTL of
the answer resource records count down:

$ dig +norec @chambo.sdnp.org.mw. cedrisa.org. mx
...
;; ANSWER SECTION:
cedrisa.org.            14240   IN      MX      15 kalata1.sdnp.org.mw.
cedrisa.org.            14240   IN      MX      5 zalewa.sdnp.org.mw.
cedrisa.org.            14240   IN      MX      10 domwe.leland-mw.org.

$ dig +norec @chambo.sdnp.org.mw. cedrisa.org. mx
...
;; ANSWER SECTION:
cedrisa.org.            14227   IN      MX      10 domwe.leland-mw.org.
cedrisa.org.            14227   IN      MX      15 kalata1.sdnp.org.mw.
cedrisa.org.            14227   IN      MX      5 zalewa.sdnp.org.mw.

This is not an authoritative nameserver and does not add any resilience to
the zone, since it has no knowledge except that which it has learned
second-hand from domwe.