Obtaining Reverse DNS Records from Your Uplink? 19
aralin asks: "Recently I was trying to set up my own server at home. I've got a domain and set everything, but I've come to one problem. When I want to give my server some reasonable name, I hit into DNS record mismatch. In other words, my DNS records do not match the reverse IP records set by my provider and thus some nodes reject to communicate with different services of my machine. Now I hit a wall when I tried to ask AT&T Cable to set reverse DNS records for my IP to something reasonable. And thus I would like to ask: What are you experiences with different broadband providers and obtaining reverse IP records for your own domain names?"
Forward and Reverse // should be free (Score:2)
-davidu
Re:CNAME records (Score:1)
Victor
Re:Just another example of SpeakEasy on top (Score:1)
Re:CNAME records (Score:1)
And if mydomain.com is a CNAME you can't add any other kind of records for it (eg MX, NS, RP, etc.)
In short, this isn't what CNAME records are for, it's a very bad idea, and don't do it.
Also, I fail to see why anything is breaking, so long as your ISP has matching A and PTR records that associate that IP with some hostname, then it shouldn't matter what other A records you create referring to that IP as tcpwrappers (and probably most other services) works like this:
* Find the IP address that's just connected.
* Look up the PTR record for that address in DNS
* For every name that's returned, look up the A records for that name.
* If at least one of the IP addresses returned matches the on that's connecting now, allow the connection.
(which isn't to say that convincing your ISP to delegate the PTR for your IP to you, or at the very least enter a custom record in their DNS, isn't nice... and it does look really cool on IRC... just that it shouldn't horribly break things if they don't)
Re:Just another example of SpeakEasy on top (Score:2)
Re:You don't have to make them match (Score:1)
--
Adam Sherman
You don't have to make them match (Score:4)
For example, take a random cable modem user (if you have the itch to portscan someone, PLEASE pick your own completely random ips), 24.5.2.24. This address reverses to cx54499-b.dt1.sdca.home.com, which in turn resolves to 24.5.2.24.
That machine may host example.com and example.net... You'll still be able to ssh to example.com and example.net, send mail to them, or do whatever, even though 24.5.2.24 does not reverse to example.com or example.net.
DNS delegation trick (Score:3)
But for those with more flexible providers and a larger block of IP addresses, there's a nice trick that covers this:
RFC 2317 [faqs.org] (aka BCP 20)
This allows the delegation of DNS PTR management even when the block doesn't start or end on octet boundaries.
Here's what it looks like from the upstream end (Score:3)
A second problem is that DNS servers can be a major hassle and a misconfigured DNS server can cause things to stop working. An admin tends to not be real comfortable delegating domains to the typical customer because the typical customer hasn't proven he knows what he's doing. We often run both the forward and reverse DNS for our fixed-IP customers for this very reason.
On the other hand, as someone else pointed out, it should be enough for tcpd if there's a forward DNS entry that matches each reverse-DNS entry no matter what other DNS entries also map to that address. If each address has a default name and each address maps to that default name, then everything should work even if other names map to any given address. I consider that sort of thing to be basic to good network design.
Just another example of SpeakEasy on top (Score:5)
ChoiceOne will do this. (Score:1)
Reverse DNS (Score:1)
Re:CNAME records (Score:2)
i doubt it.. (Score:1)
Re:Forward and Reverse // should be free (Score:1)
CNAME records (Score:3)
ISP DNS has:
ISPassignedHostname.isp.net. IN A 64.28.150.67
and
67.150.28.64. IN PTR ISPassignedHostname.isp.net.
You then add to your DNS:
mydomain.com IN CNAME ISPassignedHostname.isp.net.
When people try to hit your domain, the lookup will show the canonical name as the one assigned by the ISP. That's the one that reverse lookup checks will do. The CNAME is just letting you assign a handy alias to it.
Are you sure? (Score:2)
The only thing that matters (and only occasionally) is that it has a reverse DNS entry that matches some forward DNS entry. It doesn't have to match whatever additional name(s) you gave it. And to the best of my knowledge, AT&T cable customers are assigned IP numbers with matching forward and reverse DNS.
I'm thinking that you're just sad to learn that your machine doesn't show up in logs and wtmp with the name you want. As for that - which is unimportant at best - you're out of luck unless you go with a less mass-market provider. Others have suggested Speakeasy, and I'd agree.
reverse ARP is the same mess as ICANN (Score:1)
I'm not surprised to see your telco misbehaving. I have no experience dealing with them, other than as a unsatisfied end-user, but then again their behavior reminds me of ICANN: customers are expected to take whatever bullshit the telco shoves at them, the same way ICANN board members are expected to be nothing more than rubber stamps for what influential industry members want. Doesn't the Internet start to suck, as far as end-user experience is concerned? How about a nice commune, somewhere miles away from the nearest telco and cop?
@home and IPs (Score:1)
@home uses DHCP, and the IP can and will change about once a week. However! Your hostmask will NOT change, it will remain static, and it will always point to your current IP. For example, rcw-work mentioned his hostmask was cx54499-b.dt1.sdca.home.com. No matter what his IP address changes to, the hostmask will not change, but will resolve to the right IP address
Hope this helps!
-Henry