New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
The output is the same like yours. I am pretty sure port 53 is opened. According to online port checker. Anyway I have put your command, and still nothing. And yeah, I am pretty sure the problem is in my server.
Named.conf
// // named.conf // // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS // server as a caching only nameserver (as a any DNS resolver only). // // See /usr/share/doc/bind*/sample/ for example named configuration files. // // See the BIND Administrator's Reference Manual (ARM) for details about the // configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html options { listen-on port 53 { any; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { any; }; /* - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion. - If you are building a RECURSIVE (caching) DNS server, you need to enable recursion. - If your recursive DNS server has a public IP address, you MUST enable access control to limit queries to your legitimate users. Failing to do so will cause your server to become part of large scale DNS amplification attacks. Implementing BCP38 within your network would greatly reduce such attack surface */ recursion no; dnssec-enable yes; dnssec-validation yes; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; // zone ppdb-online.web.id zone "ppdb-online.web.id" { type master; file "/var/named/ppdb-online.web.id.db";}; // zone_end ppdb-online.web.idZone File
; Panel %version% ; Zone file for ppdb-online.web.id $TTL 14400 ppdb-online.web.id. 86400 IN SOA ns1.ppdb-online.web.id. yokowasis.gmail.com. ( 2017072414 ;serial, todays date+todays 86400 ;refresh, seconds 7200 ;retry, seconds 3600000 ;expire, seconds 86400 ;minimum, seconds ) ppdb-online.web.id. 86400 IN NS ns1.ppdb-online.web.id. ppdb-online.web.id. 86400 IN NS ns2.ppdb-online.web.id. ppdb-online.web.id. 86400 IN A 139.99.x.x localhost.ppdb-online.web.id. 86400 IN A 127.0.0.1 ppdb-online.web.id. 86400 IN MX 5 ppdb-online.web.id. mail 86400 IN CNAME ppdb-online.web.id. www 86400 IN CNAME ppdb-online.web.id. ftp 86400 IN CNAME ppdb-online.web.id. ; Add additional line ns1 14400 IN A 139.99.x.x ; #subdomainns1 ns2 14400 IN A 139.99.x.x ; #subdomainns2I wonder, where do I get wrong.
I don't know what's wrong. So I just reinstall the server using vestacp, and it works out of the box. Now the domain is resolved but leafdns and intodns keep throwing error. I don't know why.
https://www.iana.org/help/nameserver-requirements
Yet
Your problem may be due to the above.
Also, your nameserver doesn't respond. Double check your firewall. You need to allow access to any on UDP 53.
U sure it's resolving? Not working for me when I try:
Scratch that. Now that I tried it from another of my vps it won't resolved. It get resolved from my pc. I don't know why.
So you are saying, I shouldn't host ppdb-online.web.id in IP 193.99.x.x ? I need to get 2 vps ? is that it ?
Yeah you should a it's best practice to do so however technically it should be working on 1 IP. If one of your servers is down the other one will serve the zone so your domain will still resolve.
Now that I think of it. I am on ovh network. Do you think their DDOS Protection block my UDP nameserver or something ?
What ovh DC? I'm running one of my DNS servers @ ovh network (Strasbourg) without issues but it could be the case. I encountered this issue with a DC before.
Singapore, I don't know which one exactly. I am with dedicenter/racksx/cloudflexy, whatever his name is.
It seems your whole config is fucked up.
According to whois (which provides the glue records) the nameservers for ppdb-online.web.id are [ns1,ns2,ns3].ppdb-online.web.id.
The ns ip you have in your above dns setup (139.99.2.142) is for racksx.bimasoft.web.id which is also what the name server (or whatever runs on port 53) tells.
--- change
You seem to have changed some things and [ns1,ns2,ns3].ppdb-online.web.id now all resolve - however to the same IP which is not proper and nonsensical, too.
In case you only have 1 vps or dedi you can make that the master and have secondaries provided by some thrid party. Whatever you do DO NOT MUCK AROUND WITH NS! Be sure to have 2+ working ns on different IPs (preferably at least in different /24 or even in different AS).
Actually it is still not resolved for me.
I can confirm that, for some reason, OVH Network fucked up my nameserver.
I tried with different vps provider, but the same domain provider.
I am using CWP (Centos Web Panel). And all I need is just put the name server + ip in the provided box, the name server instantly online and can be used by other domain. I don't even need to tinker with settings manually, and I don't even need to wait for the glue record. I should have find this sooner. I am wasting days for this.
http://leafdns.com/index.cgi?testid=47164C61
Ok. If the same setup you're using works at other providers it wouldn't harm to open a ticket. It's weird cos as mentioned before I'm using ovh Strasbourg and Sydney without problems although they're rented directly from ovh.
That's an entirely different domain.
The glue records for bimasoft.web.id say that the dale and ines nameservers of cloudflare are your name servers. Those cloudflare servers seem to be set up correctly (pointing at themselves as ns in charge of bimasoft.web.id).
That leaf dns test seems to be worthless.
The relevant glue records are usually given in a domains whois record. If things are really fucked up you have to go to the next domain level (in your case web.id) and ask one of its nameservers for yours. ->
host -t ns bimasoft.web.id d.dns.id(meaning: "hey, ns for the web.id zone, tell me the name servers of bimasoft.web.id").Those are the official glue records and typically provided by the domain registrar (according to what you tell them in their domain panel).
As of now your config seems to be ok, i.e. both whois and dns say that the 2 cloudflare name servers are in charge of bimasoft.web.id
Yes, I am using cloudflare to manage bimasoft.web.id, but that hardly have any difference in my case. I am using different domain, different name server. So I can compare both cases (ppdb-online.web.id and bimakota.net) easily.
In this case I am using domain bimakota.net and use the nameserver ns1.bimasoft.web.id.
I point to the name server I just setup (us1.bimasoft.web.id, us2.bimasoft.web.id) to my new nameserver. dnsleaf says the Nameservers works and bimakota.net is resolveable.
Now, if I change the us1.bimasoft.web.id and us2.bimasoft.web.id and point it to my ovh networked server the nameserver will become unreachable and bimakota.net will cease to resolveable. I think it is because my ovh nameservers port 53 udp is blocked / filtered.
You think? Should be easy enough to check.
Btw., as you set your soa times to values that are nonsensical for a not-yet-stable situation that quite probably is an additional obstacle when changing/playing with name servers. I'd set them to a reasonable minimum to able to do necessary changes quicker.
I just point the ppdb-online.web.id to my new nameserver.
http://leafdns.com/index.cgi?testid=6B0F34AD
Looks good. The domain is now resolvable. So there must be wrong with my previous vps network.
How can I check if the udp port blocked or something ? Because when I check it using online tools it says port open.
Turn out my settings is right all along. Never occurred my mind it is because of my provider network problem.
dns works both with tcp and udp (udp is the usual one. tcp is used mainly for large responses like zone xfers).
For tcp it's just
telnet _your-server-ip_ 53.For udp, due to its nature you'll have to run something on your server, too; for example netcat or even just tcpdump.
On the client you can use netcat, too. (
nc -u _host_ 53).I would be surprised, though, if ovh blocked port 53.
Whatever the case I should open ticket to my provider. Perhaps it is not the ovh in the wrong here. It is possible my provider accidentally blocked port 53 or something like that.