-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have had a long running issue with the delegation checker. I appreciate that I may be unique, but having to get the database manager to help out with (infrequent, admittedly) exception handling is irritating to say the least. The problem is with the PROBLEM_WRONG_REVERSE_MAPPING check. Background. I work for a company that has a very large "non-network". We have lots of islands of infrastructure mainly not on "our" IP space, but provider PA space where we don't control the rDNS (I'm not saying we couldn't, but we only run into issues with RIPE - so the pay off doesn't seem to be worth the effort). The PROBLEM_WRONG_REVERSE_MAPPING is assigning 4 points for each nameserver missing "correct" rDNS. With 8 nameservers, that's 12 points more than failure. Now, I could work around this by only submitting 4 nameservers, but that seems contrary to the goal of having a stable in-addr.arpa delegation. The description for PROBLEM_WRONG_REVERSE_MAPPING refers to RFC1912, section 2.1 which says "should", not "must", so such a high penalty for no technical problem does not seem valid. I can't think of a truely operational problem caused by missing rDNS on an auth nameserver. I would like to propose either changing this to a 0 point Information, or a 1 point Warning. Thanks for listening John (BTW, PROBLEM_MAILCHECK_CONNECTION_FAILED also doesn't seem to be doing an MX lookup before attempting a connection. The A record for $company.com does not point to a mailserver which is why RIPE gets connection refused... but the MX records are correctly set up). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFC6lRr3TsPuH6oTJ8RAiXnAKDbgkGdV6+OIQ2FP/wvKsZWcSNF8gCghScv Ry07wV96ZJT7Ty/DGa10pjk= =IRKq -----END PGP SIGNATURE-----
John,
The PROBLEM_WRONG_REVERSE_MAPPING is assigning 4 points for each nameserver missing "correct" rDNS. With 8 nameservers, that's 12
just to be clear: "wrong" means inconsistent reverse mapping, not a missing one. While reverse mapping may be absent, inconsistencies are almost always a sign of a problem. The reverse mapping is not required for the resolution processs but is helpful (and in the case of inconsistencies: less helpful) for debugging.
points more than failure. Now, I could work around this by only submitting 4 nameservers, but that seems contrary to the goal of having a stable in-addr.arpa delegation.
I wonder why you're having so many name servers all suffering from the same problem. Maybe they're administratively *and* topologically close? Could you give details, please?
The description for PROBLEM_WRONG_REVERSE_MAPPING refers to RFC1912, section 2.1 which says "should", not "must", so such a high penalty for no technical problem does not seem valid. I can't think of a truely operational problem caused by missing rDNS on an auth nameserver.
RFC 1912 predates RFC 2119, so this 'should' vs 'must' deliberations must(sic!) be taken with a grain of salt.
I would like to propose either changing this to a 0 point Information, or a 1 point Warning.
One could also argue that the same warning produced by several servers should be limited in its impact, but OTOH this accumulation of warnings, even of the same type, suggests a deeper inspection is due. -Peter
On Jul 29, 2005, at 1:29 PM, Peter Koch wrote:
John,
The PROBLEM_WRONG_REVERSE_MAPPING is assigning 4 points for each nameserver missing "correct" rDNS. With 8 nameservers, that's 12
just to be clear: "wrong" means inconsistent reverse mapping, not a missing one. While reverse mapping may be absent, inconsistencies are almost always a sign of a problem. The reverse mapping is not required for the resolution processs but is helpful (and in the case of inconsistencies: less helpful) for debugging.
OK... well, the inconsistancy is there because we do get the providers to put generic rDNS in place in most places. Of course, we don't always have matching fwds for the reverse, because, well, nobody every uses the rDNS we have :)
points more than failure. Now, I could work around this by only submitting 4 nameservers, but that seems contrary to the goal of having a stable in-addr.arpa delegation.
I wonder why you're having so many name servers all suffering from the same problem. Maybe they're administratively *and* topologically close? Could you give details, please?
When we setup locations, we don't always know in advance what machines are going in. We move stuff around a lot... and have procedures in place to handle A records, because, well we control those. We don't control the rDNS, nor do we really want/need to.
The description for PROBLEM_WRONG_REVERSE_MAPPING refers to RFC1912, section 2.1 which says "should", not "must", so such a high penalty for no technical problem does not seem valid. I can't think of a truely operational problem caused by missing rDNS on an auth nameserver.
RFC 1912 predates RFC 2119, so this 'should' vs 'must' deliberations must(sic!) be taken with a grain of salt.
Heh... well, I would be surprised if it was updated that it would be set to a must rather than should :)
I would like to propose either changing this to a 0 point Information, or a 1 point Warning.
One could also argue that the same warning produced by several servers should be limited in its impact, but OTOH this accumulation of warnings, even of the same type, suggests a deeper inspection is due.
Potentially, but I still disagree that 4 points is valid for a non-technical issue.
participants (2)
-
John Payne -
Peter Koch