Re: dnsmasq and SOA
Hi.
On Fri, Mar 09, 2018 at 03:34:27AM +0100, Jacques Rodary wrote:
> > Today "dig in soa rodary.net" gives me:
> > rodary.net. 600 IN SOA . root.ns.rodary.net.
> > 2018022801 10800 3600 10800 600
> > Which is neither the answer I had yesterday, neither yours (by the way
> > I don't find how to use the "dig +trace" command), and "dig in ns
> > rodary.net" which gave me ns.rodary.net and ns6.gandi.net , gives me
> > only ns.rodary.net now, and "dig in ns/soa rodary.net @ns6.gandi.net"
> > has no answer, but "recursion requested but not available"
> > > Did your previous BIND configuration implement DNSSEC?
> No
> ns6.gandi.net was NS in my main zone file; so I think I will try
> auth-sec-servers=ns6.gandi.net as it was in my BIND setup. I did and it
> worked: "dig in soa rodary.net" gives me:
> ;; ANSWER SECTION:
> rodary.net. 600 IN SOA . root.ns.rodary.net.
> 2018022801 10800 3600 10800 600
>
> ;; AUTHORITY SECTION:
> rodary.net. 600 IN NS .
> rodary.net. 600 IN NS ns6.gandi.net.
Hate to break it to you, but it seems to fail for everyone else.
Today "dig in soa rodary.net" gives me SERVFAIL.
> and even if I don't quite understand why "." (the root) is my secondary
> server, I suppose it means I succeeded to have my host as a stealth server!
I believe that it means that somehow you're announcing authority on root
domain. I would advise against it.
"dig +trace" gives me "BAD REFERRAL", which is not a good sign, to say the
least.
> But when I added "auth-peer=217.70.177.40" I had to restart everything,
> which means reboot for me because I don't understand quite well how
> NetworkManager works.
I don't understand it either, but frankly I don't need to. IP adresses,
routing table and packet flow are the state of the kernel. Using
always-running userland tool for their configuration *may* be
appropriate in certain cases (DHCP, anyone?), but for your typical
server environment such cases do not apply.
That said, for your typical server environment nothing beats ifupdown.
So my advice is - if you need a predictable behaviour - you exterminate
NetworkManager, connman and other fancy toys, and stick to the ifupdown,
or maybe systemd-networkd.
Reco
Reply to: