Trying to verify that I can make changes with nsupdatem and running into something I don’t understand.

mail # nsupdate -k admin.key

zone name covisp.net
update delete ns1.covisp.net. IN A 65.121.55.42
update add ns1.covisp.net. 3601 IN A 65.121.55.42
send

; Communication with 192.42.173.30#53 failed: timed out

Uh… what? Why is it trying to update 192.42.173.30 (ac1.nstld.com)?

That IP does not appear in any file in /usr/local/etc/ nor in /etc/ on my system.

What am I missing here?

In fact, the only file on the entire /usr/ that has this IP address in it is the draft copy of this email.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06 Jul 2020, at 16:47, Kevin Darcy <kevin.darcy@fcagroup.com> wrote:

You didn't dot-terminate covisp.net in the "zone" statement

<Beats head on desk>

Ow!

<Beats head on desk>

Sigh.



--
The whole thing that makes a mathematician's life worthwhile is that
he gets the grudging admiration of three or four colleagues

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: bind-users@lists.isc.org (bind-users)

Actually you had "zone name covisp.net” which told nsupdate to update the “name.” zone as it was treated as “zone name”. Nsupdate then when and looked up the SOA for name and found ac1.nstld.com is the primary server.

name. 86400 IN SOA ac1.nstld.com. info.verisign-grs.com. 1594079077 1800 900 604800 86400

Nsupdate can normally determine the name of the zone that has to be updated so most of the time you don’t need to specify the zone. There are a few cases, like when adding delegating NS records or glue to the parent zone you have to override the
normal zone discovery procedure.

Mark

On 7 Jul 2020, at 08:59, @lbutlr <kremels@kreme.com> wrote:

On 06 Jul 2020, at 16:47, Kevin Darcy <kevin.darcy@fcagroup.com> wrote:

You didn't dot-terminate covisp.net in the "zone" statement

<Beats head on desk>

Ow!

<Beats head on desk>

Sigh.

--
The whole thing that makes a mathematician's life worthwhile is that
he gets the grudging admiration of three or four colleagues

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

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

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06 Jul 2020, at 17:59, Mark Andrews <marka@isc.org> wrote:

Nsupdate can normally determine the name of the zone that has to be updated so most of the time you don’t need to specify the zone. There are a few cases, like when adding delegating NS records or glue to the parent zone you have to override the

normal zone discovery procedure.

So if I were to try adding web2.example.com via nsupdate I could simply

update add web2.example.com 96400 IN CNAME www.covisp.net
send

That's good to know, but I fear I will remember that and use it in cases where I do need to specify it and muck things up.

I change DNS settings so infrequently that each time it is almost like starting over, especially since the underlying software has changed as well. Also, I need better notes, which I am taking this time. (Most of the serials on the DNS files are more
than two years old)

The latest surprise was that dnssec-enable yes; is obsolete in Bind 9.16. I've noticed no fallout from simply uncommenting it, so I assume it is either required now or implied with dnssec-validation set or auto-dnssec in the zone config.

I do have motivation to get all this nsupdate stuff square, however, as I want to move Letsencrypt to wildcard certs and that requires updating the DNS during the LE exchange.



--
Vi Veri Veniversum Vivus Vici

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: bind-users@lists.isc.org (bind-users)

@lbutlr <kremels@kreme.com> wrote:

The latest surprise was that dnssec-enable yes; is obsolete in Bind 9.16.

`dnssec-enable yes` has been the default since 2007, so that directive has
been useless for quite a long time :-) What changed in 9.16 is that you
now can't turn DNSSEC off. (Specifically, support for correctly serving
signed zones on authoritative servers, and support for DNSSEC-aware
clients of resolvers, whether or not any validation is happening. `dnssec-validation` is a separate setting.)

Tony.
--
f.anthony.n.finch <dot@dotat.at> http://dotat.at/
individual and social justice

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)