127.0.0.1 fails to resolve
Hi, i had a report in my mailbox that my 127.0.0.1 failed to resolve. This is for hostname account for ie hostname.example.com - it was in my cpanel (not whm) example.com mail and i have a whm just for that account as it is a reseller.
I have all my accounts under this reseller. And everything is set up on cloudflare. Also the site is working fine.
So read a few posts i found some from here and some from other places and i checked my SOA and the record came back fine.
But when i checked the dns record for example.com it showed the really old nameserver that i have not used in a long time. So i edited the dns record and i put the new nameserver info in the blocks. I made a copy of the old settings and i used another domain on the account as a template.
The site still works... so i guess i did this correct is that right?
I also noticed that the serial number of all the other domains in this reseller account all have the same serial number, so i changed this sites serial number to be the same..
Did i do that correctly?
If so once i save the dns record is there anything else i need to restart to make it live?
Thanks :)
UPDATE: when checking cloudflare it shows A record for hostname to the main server IP xxxxxxxxx30 and whm is also xxxxxxx30
but localhost is set to the ip which is xxxxxxxxxx31 which is the ip of the domain. Is that correct or should localhost be 127.0.0.1 or assuming that 127.0.0.1 is the machine, shouldnt that be the same as the hostname xxxxxxxxxx30
-
thanks :) 0 -
I checked mine via putty and if i am logged in as the whm of the hostname site (not root) xxxxxxxxx31 (shared ip) it says this [QUOTE] $ host 127.0.0.1 Host 1.0.0.127.in-addr.arpa. not found: 3(NXDOMAIN)
If i log into putty as root at xxxxxxxx30 the server ip, then it says same [QUOTE] host 127.0.0.1 Host 1.0.0.127.in-addr.arpa. not found: 3(NXDOMAIN)
im checking the guide now :) UPDATE: unfortunately the guide did not cover that much but i am pretty sure my host file and my resolve.conf are correct. I also didnamed-checkconf -z
in which resulted in a long list assigning serials and here are the ones pertaining to local host [QUOTE] zone localhost/IN: loaded serial 42 zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700 zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 1997022700 zone 255.in-addr.arpa/IN: loaded serial 42 zone 0.in-addr.arpa/IN: loaded serial 42
and after that i reranhost 127.0.0.1
[QUOTE] Host 1.0.0.127.in-addr.arpa. not found: 3(NXDOMAIN)
and hear is my named.conf [QUOTE] view "localhost_resolver" { /* This view sets up named to be a localhost resolver ( caching only nameserver ). * If all you want is a caching-only nameserver, then you need only define this view: */ match-clients { 127.0.0.0/24; }; match-destinations { localhost; }; recursion yes; zone "." IN { type hint; file "/var/named/named.ca"; };
and check this out when i did the same with the actual hostname.example.com [QUOTE] [root@titan etc]# hostname titan.example.com [root@titan etc]# host titan.example.com titan.example.com has address xxx.xxx.xxx.130 [root@titan etc]# host xxx.xxx.xxx.130 Host 130.xxx.xxx.xxx.in-addr.arpa. not found: 3(NXDOMAIN)
so it appears the name is resolving but the ip is not. WTH ??0 -
Here is the reply from cloudflare.. [QUOTE] You looking to have PTR records/Reverse Lookups, you need to contact the hosting provider or whoever owns the IP space of your IP address in order to add this record type, it is not something that is done by Cloudflare.
I dont get it, i dont use a host (i use cloudflare) and i am my own registrar (reseller), so is that the server company that i lease the dedicated server from which gave me 5 ip's to use with the server? Is that who i contact?0 -
Yes. You'll contact your Hosting Provider and provide them with your host.name.com and it's IP address. If there are other domains on dedicated IPs that you'd like to setup rDNS for, provide each domain.com and it's IP address it will use to them as well. 0 -
Thanks, so that pretty much says that its not manditory that i do this, and the fact that they are not being resolved, especially 127.0.0.1 is really not a big deal. Actually not having the PTR records could actually provide an additional layer of privacy and security. Is that correct? 0 -
Incorrect. Setting rDNS is quite important. First result from google for your review: blog.leadfeeder.com/what-is-reverse-dns-and-why-you-should-care/ 0 -
OK thanks for the link and the replies 0 -
Hello, Glad Infopro was able to assist! Were you able to get this working correctly? Should you have any further questions or concerns please don't hesitate to reach out to us! 0 -
yes thanks, you can mark this resolved. I give PTR list to my server company who i leased the server from and they did the PTR and it is resolving now... Thanks so much :) 0 -
Hi, i have a problem... i checked again this morning and all are correct except my localhost I told them to assign localhost.example.com to 127.0.0.1 and they assigned it to my shared ip of example.com root [/]# host localhost.example.com localhost.example.com has address xxx.xxx.xxx.131
131 is the shared ip. it should come back as this if correct right? localhost.example.com has address 1.0.0.127 either i messed up and they corrected my error or they did it wrong.0 -
OK fixed, it was my mistake. Something didnt make sense and when i checked i had it set to 131 in cloudflare for some reason. its working now root [/]# host localhost.example.com localhost.example.com has address 127.0.0.1 root [/]#0 -
Hi,
It sounds like you’ve taken the right steps to update your DNS records and ensure they align with your current setup. Here’s a quick overview:
- Updating the DNS records to reflect the new nameservers was the correct move, especially if the old ones were outdated.
- Changing the serial number to match other domains can help with consistency, but ensure it increments correctly with each change.
- The
localhostIP should indeed be127.0.0.1on your local machine, while the hostname’s A record should point to the server’s IP. The discrepancy you noticed might be due to different configurations, but ensure the A record aligns with your actual server IP.
Once saved, DNS changes can take some time to propagate. You generally don’t need to restart anything manually, but verifying the updated settings after propagation is a good practice. If issues persist, double-check the DNS records and Cloudflare settings. Best solution of this error I have learnt from this website: https://techyhivee.com/technology/127-0-0-149342/
0
Please sign in to leave a comment.
Comments
13 comments