NANOG list reverse DNS handling
A couple of days ago I moved my mail server, and inadvertently mistyped its name in the reverse DNS. After this, I noticed a message wasn't making it to the list. Investigation showed: rcpt to: nanog@nanog.org 450 Client host rejected: cannot find your hostname [83.149.65.1] info at: http://www.merit.edu/cgi-bin/mn/reversednsinfo Ok, so far so good. But when I visited the URL mentioned in the rejection message, I just got a web form saying "Please enter your e-mail address and select your organization from the list below". Obviously this is meant to do _something_, but it's entirely unclear what and why. After this the page I think should have been referred in the first place comes up: http://www.merit.edu/mn/support/reversedns.html There is also a link to a DNS checking tool. However, this tool is pretty much useless in situations such as the one in which I found myself, as it doesn't answer the real question: what is the TTL for the offending DNS information.
Iljitsch van Beijnum wrote:
There is also a link to a DNS checking tool. However, this tool is pretty much useless in situations such as the one in which I found myself, as it doesn't answer the real question: what is the TTL for the offending DNS information.
You should have the answer to that (more or less- at least the upper bound) as it is set by you in your zone. Now, if you want to know how much of the TTL remains wrt to merit.edu accepting mail, you need to know what resolvers the mail server is using, and can then query thusly: $ dig ptr 1.65.149.83.in-addr.arpa @dns.merit.net | grep ^1 1.65.149.83.in-addr.arpa. 86400 IN PTR sequoia.muada.com. (I see that dns.merit.net is the next IP above mail.merit.net which is the only MX RR for merit.edu, although that's really still just a guess as to the resolver it uses) A second query reveals that the TTL on this record has decreased by a few seconds. Since your .arpa zone ttl seems to be at one day, it isn't likely that dns.merit.edu is the resolver for mail.merit.edu (or else it has since expired from cache): $ dig ptr 1.65.149.83.in-addr.arpa @dns.merit.net | grep ^1 1.65.149.83.in-addr.arpa. 86398 IN PTR sequoia.muada.com. Note that this doesn't work if the resolver has an ACL applied that restricts who can do resolution on it and you don't fall within that ACL. But the bigger hurdle here is really figuring out what the resolver mail.merit.edu uses, since it's most likely open. A check of all the auth DNS servers for merit.edu reveals no evidence of caching for this particular record.
On Sat, Apr 03, 2004 at 02:02:54PM -0700, Mike Lewinski wrote:
Note that this doesn't work if the resolver has an ACL applied that restricts who can do resolution on it and you don't fall within that ACL.
This is the case, sadly. I wanted to propose your method too. :-)
But the bigger hurdle here is really figuring out what the resolver mail.merit.edu uses, since it's most likely open.
Not a big hurdle. Run tcpdumps on the auth servers of a domain from which you do a test connect to mail.merit.edu. Of course, this machine shouldn't be in their cache already. You'll find out that mail.merit.edu runs a local DNS cache and that it refuses any queries from outside. Best regards, Daniel
participants (3)
-
Daniel Roesen -
Iljitsch van Beijnum -
Mike Lewinski