AT&T refuses to provide PTR records?
Anyone familiar with AT&T's policies on PTR records for their customer-assigned address space? We have a customer whose website we host that has their own in-house mail server that they run off of their AT&T internet connection at their office. We handle the DNS for their domain name. AT&T is refusing to set up PTR records for them because they're not handling DNS for the domain name. Is this normal? I haven't dug through the ARIN agreements but I thought it was required to provide reverse DNS on your allocations. Thanks, David
We have a customer that has AT&T and they reassigned the IP space to our name servers to allow us to do reverse DNS for them. Mike Walter, MCP Systems Administrator 3z.net a PCD Company http://www.3z.net -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of David Hubbard Sent: Tuesday, October 17, 2006 4:21 PM To: NANOG list Subject: AT&T refuses to provide PTR records? Anyone familiar with AT&T's policies on PTR records for their customer-assigned address space? We have a customer whose website we host that has their own in-house mail server that they run off of their AT&T internet connection at their office. We handle the DNS for their domain name. AT&T is refusing to set up PTR records for them because they're not handling DNS for the domain name. Is this normal? I haven't dug through the ARIN agreements but I thought it was required to provide reverse DNS on your allocations. Thanks, David
Mike Walter wrote:
We have a customer that has AT&T and they reassigned the IP space to our name servers to allow us to do reverse DNS for them.
We had a similar situation. AT&T states that they will only handle rDNS using domains that they control. They will happily CNAME the IPs appropriately or reassign the IP space, depending on block size and request. The issue we ran into was that we couldn't get them to *unassign* a CNAME for an IP block so that it would fail immediately, and so servers (web,ftp, etc) which requested rDNS for the connection information would time out connections waiting for the non-existent nameservers. We weren't really interested in handling rDNS for the IP given that it wasn't handling mail, web, or have any A records pointing to it. It is the easiest way to get it done, though. Jack Bates
On Tue, 17 Oct 2006, Jack Bates wrote:
Mike Walter wrote:
We have a customer that has AT&T and they reassigned the IP space to our name servers to allow us to do reverse DNS for them.
We had a similar situation. AT&T states that they will only handle rDNS using domains that they control. They will happily CNAME the IPs appropriately or reassign the IP space, depending on block size and request.
The issue we ran into was that we couldn't get them to *unassign* a CNAME for an IP block so that it would fail immediately, and so servers (web,ftp, etc) which requested rDNS for the connection information would time out connections waiting for the non-existent nameservers. We weren't really interested in handling rDNS for the IP given that it wasn't handling mail, web, or have any A records pointing to it. It is the easiest way to get it done, though.
Surely if you have _a_ matching forward and reverse DNS pair, that'd get you started? My experience in this game was that you could create mail.xyz.com and point it to their IP as an A record, and point MX at this - no problems. So long as the host had a valid and matching forward/reverse DNS entry there was no grief. The issue was where there was no matching A/PTR set, this would increase the likelyhood of a spam host or something... right? Or is it now a case of A/PTR must match the MX? Mark.
Mark Foster wrote:
Surely if you have _a_ matching forward and reverse DNS pair, that'd get you started?
The problem in our case is that this wasn't an email issue. Any service (http/ftp/nntp/etc) which performed rDNS lookups prior to handling the connection would end up timing out the connection due to the fact that AT&T had setup a CNAME which pointed to a nameserver that no longer existed (from when the IP was owned by someone else). The actual complaint was failure to ftp files from the location due to the ftp server doing rDNS. AT&T refused to remove the old CNAME which was defunct. We didn't need matching anything. NXDOMAIN would have even been acceptable. However, forwarding the request to non-existent nameservers is not.
The issue was where there was no matching A/PTR set, this would increase the likelyhood of a spam host or something... right?
The issue was that when revoking an IP from a customer, AT&T did not remove the rDNS configuration for that IP. Had they done so, their own servers would have reported back that there wasn't any rDNS (NXDOMAIN) which would have been perfectly acceptable. Jack Bates
participants (4)
-
David Hubbard -
Jack Bates -
Mark Foster -
Mike Walter