Hi Thomas, obfuscating IP addresses doesn't help in the least.
ns1.sleepyvalley.net cannot be resolved, nor can we query it directly due
to that.

Did you register the nameserver ns1.sleepyvalley.net with your domain
registrar?

On Sat, May 26, 2018 at 12:44 PM, Thomas Strike <thomas.str...@gmail.com>
wrote:

> I have been fighting a problem of setting up a new Bind9.9 primary
> authoritative server on the Internet for over 2 weeks now. My hosted
> secondary server cannot be set up until my primary server comes alive on
> the Internet. I have fought my domain name provider for over 2 weeks trying
> to get my new server propagated throwout the Internet and they say that the
> problem is with my server. This is very perplexing because there are at
> least 4 DNS servers out there that see my server and respond to all queries
> successfully that land on my server but no other server can see mine. It's
> hard to believe that the problem is on my end.
>
> I am here asking for fresh sets of eyes to look at my setup file and the
> domain zone record that is at issue. My domain is sleepyvalley.net and my
> primary dns server is ns1.sleepyvalley.net. Standard A records that
> should resolve are www., ftp., and mail.sleepyvalley.net.
>
> ------------------------------------------------------------
> ------------------------------------------------------
>
> *named.conf:*
>
> acl trusted-servers  {
>     144.x.x.x.;     // ns1.sleepyvalley.net
>     8..x.x.x;       // sdns1.ovh.ca
> };
>
> options {
>     listen-on port 53 { any; };
>     listen-on-v6 port 53 { any; };
>
> // I have IPv6 implemented on my server but could it be an IPv6 issue?
>
>     allow-query { any; };
>
>     recursion yes;
>     allow-recursion {
>         any;
>         };
>     allow-transfer {
>         trusted-servers;
>         };
>
>     directory     "/var/named";
>     dump-file     "/var/log/named/data/cache_dump.db";
>     statistics-file "/var/log/named/data/named_stats.txt";
>     memstatistics-file "/var/log/named/data/named_mem_stats.txt";
>
>     notify yes;
>
>
> // I am not familiar with what dnssec does. Is it necessary for a primary
> DNS server to run properly?
>
>     dnssec-enable yes;
>     dnssec-validation yes;
>     dnssec-lookaside auto;
>
> // Could this be a security key management issue?
>
>     bindkeys-file "/etc/named.iscdlv.key";
>     managed-keys-directory "/var/named/dynamic";
>
>     pid-file "/run/named/named.pid";
>     session-keyfile "/run/named/session.key";
> };include "/etc/named.logging";
>
> zone "." IN {
>     type hint;
>     file "named.ca";
> };
>
> include "/etc/named.rfc1912.zones";
> include "/etc/named.root.key";
>
> zone "sleepyvalley.net" {
>     type master;
>     file "/var/named/sleepyvalley.net.hosts";
>     allow-transfer { trusted-servers; };
>     };
> key rndc-key {
>     algorithm hmac-md5;
>     secret "xxxxxxxxxxxxxxxxxxxxxxxx";
>     };
> controls {
>     inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
>     };
> ------------------------------------------------------------
> --------------------------------------------------------------------------
>
> *sleepyvalley.net.hosts:*
>
> */*
> */ I am a little confused about the Time-To-Live in this record. *
>
> *// Which of these 2 ttls do resolvers use to cache their answers for?*
>
> $ttl 38400
> sleepyvalley.net.    IN    SOA    ns1.sleepyvalley.net.
> administrator.sleepyvalley.net. (
>             1526060969
>             1H
>             3600
>             5M
>             300 )    // short 5 min. ttl for testing.
> sleepyvalley.net.    IN    A    144.x.x.x.x
> mail.sleepyvalley.net.    IN    MX    10 mail.sleepyvalley.net.
> mail.sleepyvalley.net.    IN    A    144.x.x.x.x
> www.sleepyvalley.net.    IN    A    144.x.x.x.x
> ftp.sleepyvalley.net.    IN    A    144.x.x.x.x
> ns1.sleepyvalley.net.    IN    A    144.x.x.x.x
> sleepyvalley.net.        IN    NS    ns1.sleepyvalley.net. // Primary DNS
> service
> sleepyvalley.net.        IN    NS    sdns1.ovh.ca.            //
> Secondary externally hosted DNS service.
> ------------------------------------------------------------
> ------------------------------------------------------------
> ----------------
>
> Any insights would be gratefully appreciated. Thanks in advance.
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to