Using nsupdate when I try to delete an MX record for a domain, I get REFSUED.
When I try to add an MX record with the same priority (or not), it leaves the
old record as well.
How do I remove and replace the MX record for a domain with nsupdate?
--
A woman stays up all night with two men
On 2022 Apr 12, at 18:25, @lbutlr wrote:
>
> My secondary DNS server (bind916-9-16-27) is reporting:
>
> managed-keys-zone: Failed to create fetch for DNSKEY update
Named.conf relevant settings (I think) are:
recursion yes;
allow-query { any; };
all
My secondary DNS server (bind916-9-16-27) is reporting:
managed-keys-zone: Failed to create fetch for DNSKEY update
At this point it only respond SERVFAIL to all queries.
The secondary DNS is a spare machine that is not used for anything else but
DNS, so no one has touched it other than to
In the process of setting u a new domain I noticed that some existing domains
are logging and error into /var/log/messages
domain.tld.signed:120: signature has expired
Each domain that is expired shows the same :120
The lines in question do refer to old ALG-7 signatures but shouldn’t those go
On 2022 Apr 10, at 05:37, Bjørn Mork wrote:
> "@lbutlr" writes:
>
>> # dnssec-keygen -a 13 example,com
>> # dnssec-keygen -f KSK -a 13 example,com
>>
>> Add $INLCUDE to the zone file for each of these 4 keys.
>
> 4? You've generated 2 key pairs.
I have an several domains setup in bind, all with DNSSEC implemented, and am
trying to add a new domain, and seem to have missed a step.
# dnssec-keygen -a 13 example,com
# dnssec-keygen -f KSK -a 13 example,com
Add $INLCUDE to the zone file for each of these 4 keys.
# dnssec-signzone -3
On 2022 Feb 27, at 05:46, Bob McDonald wrote:
> I'm guessing that the zone files hosted on the new DNS servers still contain
> NS records pointing to the old DNS servers.
After propagation everything seems to have settled out properly, no errors on
dnsviz now.
Thanks though.
--
Advance and
On 2022 Feb 22, at 04:31, Julien Salort wrote:
> For information, bind 9.18.0 compiles fine under Macports on a variety of
> systems, including Catalina.
And with homebrew as well, though I don't know what versions of macOS it does
back to (Everything here is now on M1s with Monterey).
--
Is this a result of the propagation of DNS still occurring and dnsviz still
seeing the old DNS servers? The DNS pointers have been changed with the
registrar, but dnsviz is throwing quite a few errors, including this one.
"DNSKEY: The Authoritative Answer (AA) flag was not set in the response."
On 2022 Feb 24, at 14:19, @lbutlr wrote:
> I am invoking nsupdate with
Oh, never mind. Major Brain Fart.
--
"Everyone has a photographic Memory, some just don't have film."
~Steven Wright
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
t
I am invoking nsupdate with
nsupdate -k /etc/namedb/admin.key
When I make the changes to a domain and `send` I get,
; TSIG error with server: expected a TSIG or SIG(0)
update failed: REFUSED
/etc/namedb is an alias to /usr/local/etc/namedb/ and admin.jet contains:
# cat admin.key
key
I have a domain that I hot DNS and email for, but not web. I set the A record
for www.example.com to the IP of the web server with nsupdate, removing the old
CNAME the pointed to the local webserver, but the web monkey for the new
website is saying that www has to be a CNAME and the @ record
On 2021 Jul 05, at 18:20, Mark Andrews wrote:
> On 6 Jul 2021, at 06:40, @lbutlr wrote:
>> DNS format error from 64.70.78.82#53 resolving ok.contact/NS for
>> 127.0.0.1#16749: non-improving referra
>
> This is an error with the delegation of ok.contact. The NS records
I've been getting a few errors along these lines (bind 9.16.18), the IPs
changes, but I don't know what "non0improving referral" means or if I should be
concerned.
DNS format error from 64.70.78.82#53 resolving ok.contact/NS for
127.0.0.1#16749: non-improving referra
This IP is owned bv
On 30 May 2021, at 12:23, Grant Taylor via bind-users
wrote:
> On 5/30/21 9:24 AM, Richard T.A. Neal wrote:
>> I spent a little time this weekend setting-up BIND 9.17.13 on Ubuntu 21.04
>> and configuring the system as a recursive resolver offering DNS over HTTPS
>> using a LetsEncrypt
On 30 Apr 2021, at 12:15, Tony Finch wrote:
>
> dig +ttlunits example.com ds @$(dig +short com ns | head -1)
I update the last of my zones over a month ago and they are still showing
alg-7. The longest TTL int e zone files is 2w, but we're 29 days in.
Te signed file has
On 30 Apr 2021, at 08:21, Jordan Tinsley wrote:
> Is BIND 9.11.6 (Extended Support Version) vulnerable?
>
> Is BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 (Extended Support Version)
> vulnerable?
The CVE descriptions indicates both of those versions are vulnerable.
"In BIND 9.5.0 -> 9.11.29 …
On 29 Apr 2021, at 05:35, Ondřej Surý wrote:
> * Windows now has WSL2
> (https://docs.microsoft.com/en-us/windows/wsl/install-win10) that can be used
> to run BIND 9 natively
I'd suggest this be the first listed reason as it pretty much makes all the
other reasons irrelevant. OTOH, I don't
On 13 Apr 2021, at 04:02, Anand Buddhdev wrote:
> A legitimate client, following a normal chain of referrals, has *no*
> reason to query a server for zones it is not authoritative for.
Well, that's not really true. A mobile user might have their device configured
to always check their corporate
On 12 Apr 2021, at 07:04, Matthijs Mekking wrote:
> Perhaps inspect the zone file?
Ah, since it is named localhost-reverse.db I assumed it was not plain txtm but
some db format.
>>>FILE
$ORIGIN .
$TTL 3600 ; 1 hour
0.ip6.arpa IN SOA localhost. nobody.localhost. (
I restored a backup of my named.conf after a little bit of an oops. The file is
the same exact file as it was yesterday, bt on starting bind I get:
named[24161]
named[24161] BIND 9 is maintained by Internet Systems Consortium,
named[24161]
> On 12 Apr 2021, at 01:12, Matthijs Mekking wrote:
>
>
>
> On 11-04-2021 01:22, @lbutlr wrote:
>> On 06 Apr 2021, at 01:13, Matthijs Mekking wrote:
>>> In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By
&
Doe anyone know the syntax for using purge-keys in 9.16.13? I've search and all
I can find is notes that it was added. I've tried a couple of things, but I am
shooting in the dark. I cannot redefine the "default" policy as that gives and
error and simply putting "purge-keys P90D;" or
On 06 Apr 2021, at 01:13, Matthijs Mekking wrote:
> In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By
> default the keys are retained for 90 days after their latest usage. So in
> that case keys will be cleaned up automatically.
Excellent. Does that go in the zone record
If I do:
cd /etc/named/working/main/
for i in *; do dig $i +dnssec | grep "A 13 2" | awk '{print $1}';done
I see a list of all the domains on the system, so that's good, everything has a
ALG-13 signature.
If I do
for i in *; do dig $i +dnssec | grep "A 7 2" | awk '{print $1}';done
I see a
On 26 Mar 2021, at 14:32, alcol alcol wrote:
> seriously? is like linux/unix FAQ
Oh, I would say learning how to post to mailing lists in linux/unix 101.
Perhaps you could review that yourself and not send bloated messages full of
HTML garbage?
--
"Are you pondering what I'm pondering?"
I am getting the following warning:
The following NS name(s) were found in the authoritative NS RRset, but not in
the delegation NS RRset (i.e., in the com zone): (a DNS server)
The DNS server exists and is used by other domains, so This is something
specific to this one domain and not to the
On 24 Feb 2021, at 03:38, Ondřej Surý wrote:
>> On 24. 2. 2021, at 11:36, @lbutlr wrote:
>> I also see this note from last year:
>>
>> <https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9.17-Plan>
>> "September 2020 DoH backported to Extended Sup
On 23 Feb 2021, at 23:02, Evan Hunt wrote:
> DoH is supported in named in 9.17.10 (server side only). Client-side
> support will be added to dig in 9.17.11.
There's 9.17.10? I have 9.16.12 and see no sign of 9.17.x in FreeBSD ports. Is
it "bind9-devel"?
I seem to recall something about the
On 11 Feb 2021, at 16:38, John W. Blue via bind-users
wrote:
> I have found to tshark to be useful as well but the failing it has is that it
> is generally not included in a unix OS distribution.
Is bind? I mean, I have to install a bunch of stuff right off on a new bistro
just to get a
On 09 Feb 2021, at 16:19, Mal via bind-users wrote:
> On 09/02/2021 10:47 pm, @ wrote:
>> Well, I have finally ogttenteh test zone to the point where dnssec-verify is
>> happy and everything that I can check also seems happy except dnsviz which
>> is very very VERY angry and basically says the
> On 08 Feb 2021, at 07:24, Matthijs Mekking wrote:
>
> Hi,
>
> On 08-02-2021 12:20, @lbutlr wrote:
>> I feel I am getting close. I got the digest generated for hover.com and
>> updated the DNS on the test zone, but I am getting errors on verify that I
I feel I am getting close. I got the digest generated for hover.com and updated
the DNS on the test zone, but I am getting errors on verify that I don't
understand.
#v+
# dnssec-verify -I text -o example.com /etc/namedb/working/example.com.signed
Loading zone 'example.com' from file
On 06 Feb 2021, at 17:45, Paul Kosinski via bind-users
wrote:
> It sounds to me like dnssec-verify is sending the output in question to
> STDERR instead of STDOUT.
Dnssec-verify sends errors (like missing /Bad/Expected lines) to stderr, it
sends status warnings like "The zone is not fully
So, with my test domain that is using dsnssec-policy default dnsviz reports
"DNSKEY: No response was received from the server over UDP"
But:
dig +norec +dnssec +bufsize=512 +ignore dnskey
Shows a DNSKEY record.
(There is no DNSKEY record shown on the domains still using auto-dnssec
Is the mechanism of using $INCLUDE in the zone file still used?
If so, do I need to update the when moving to a new alg method or
are they only used when initially creating a signed zone file or are they no
longer needed at all?
--
'I'll tell you this!' shouted Rincewind. 'I'd rather trust
On 02 Feb 2021, at 07:36, Matthijs Mekking wrote:
> If the PDF is not working for you, perhaps https://bind9.readthedocs.io/
> suits you better?
The PDF works fine, and I can search for "dnssec" and "policy" but it is using
some emdash or similar character for the - in between which makes
On 02 Feb 2021, at 02:23, Matthijs Mekking wrote:
> 1. Create a dnssec-policy that matches your current keys (so in your case
> algorithm 7, also make sure you use the same length).
>
> So I guess something like:
>
>dnssec-policy alg13-ksk-unlimited-zsk-60day {
>keys {
>
On 01 Feb 2021, at 07:14, Matthijs Mekking wrote:
> Depends on what your DNSSEC configuration is. Are you using
> dnssec-signzone/named? auto-dnssec maintain? inline-signing? dnssec-policy?
> dnssec-keymgr?
These are all good questions, and when I set this up I could have answered with
some
I've been using alg-7 for DNS, but that is no longer recommended. How difficult
is it to change the signing algorithm and what is the process (Bind 9.16.11)?
--
"He raised his hammer defiantly and opened his mouth to say, "Oh,
yeah?" but stopped, because just by his ear he heard a
On 23 Dec 2020, at 21:23, Grant Taylor via bind-users
wrote:
> On 12/23/20 6:53 PM, @lbutlr wrote:
>> Give that I have a authoritative bind9 server for example.com and given that
>> I have a home connection that is (technically) dynamic home.example.com what
>> is t
Give that I have a authoritative bind9 server for example.com and given that I
have a home connection that is (technically) dynamic home.example.com what is
the easiest way for me to automatically update the DNS on the rare occasions
that it changes?
The example.com domain is setup with DNSSEC
On 18 Dec 2020, at 10:56, Nicolas Bock wrote:
> ;; ANSWER SECTION:
> com. 63779 IN DS 30909 8 2
> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
> In other words, the forwarder returns a Delegation Signer
> record but not an RRset Signature record. Presumably that
> means
On 27 Nov 2020, at 00:00, Onur GURSOY wrote:
> Hello Everyone,
Oh, come on!
--
"Are you pondering what I'm pondering?"
"Wuh, I think so, Brain, but if we didn't have ears, we'd look like
weasels."
___
Please visit
On 19 Oct 2020, at 08:57, Bob McDonald wrote:
> When you talk about "putting the .jnl file aside" what are you doing?
> Stopping named THEN deleting the .jnl file?
I did not delete the file. I stopped named and moved the file, then restarted
named. After everything seemed to be working, then I
On 19 Oct 2020, at 00:54, Matus UHLAR - fantomas wrote:
> On 18.10.20 11:00, @lbutlr wrote:
>> I am getting the following error on one specific domain and I am unsure how
>> to fi it. Searching for the error lead to suggestions about not running
>> multiple copies of bin
On 16 Oct 2020, at 08:36, Bob Harold wrote:
> That is certainly not obvious. How do I request improving the manual?
>
> "in turn" would seem to imply "in order", and the order would logically be
> the order I listed them.]
I disagree. In turn means one is tried, then if that fails the next is
I am getting the following error on one specific domain and I am unsure how to
fi it. Searching for the error lead to suggestions about not running multiple
copies of bind on the same machine, but that is not the case here (and it is
only affecting one domain).
named[652] malformed
On 23 Sep 2020, at 19:19, @lbutlr wrote:
> named[652] malformed transaction: managed-keys.bind.jnl last serial 1204 !=
> transaction first serial 1159
> named[652] managed-keys-zone: keyfetch_done:dns_journal_write_transaction ->
> unexpected error
> named[652] managed-keys-
Getting these in the logs:
named[652] malformed transaction: managed-keys.bind.jnl last serial 1204 !=
transaction first serial 1159
named[652] managed-keys-zone: keyfetch_done:dns_journal_write_transaction ->
unexpected error
named[652] managed-keys-zone: error during managed-keys processing
On 21 Jul 2020, at 06:37, Mark Andrews wrote:
> On 21 Jul 2020, at 18:23, @lbutlr wrote:
>>
>> Bind is a poor choice for desktop use. Packages like unbound are much better
>> for that sort of use, and it is fr less critical if those packages have
>> security issue
On 20 Jul 2020, at 10:09, tale wrote:
> And for what it's worth, not all systems moved away from "named" to
> "bind9". I've been running FreeBSD for decades, and I can't remember
> ever calling the service "bind9".
The service is always named, the package is bind. I stopped adding the 9 many
On 17 Jul 2020, at 11:56, Ted Mittelstaedt wrote:
> In fact, the ONLY reason that the name "bind9" was ever even coined
> at all was because the changes from bind8 both in the syntax of the
> config file and how the program operated they wanted to boot admins
> in the behind to get them to change
On 14 Jul 2020, at 00:31, MEjaz wrote:
>
Please do not post images. Copy and paste the text.
(Over 100 lines of quoted lines with no content deleted)
--
I WILL NOT BARF UNLESS I'M SICK Bart chalkboard Ep. 8F15
___
Please visit
On 28 Jun 2020, at 09:13, Matus UHLAR - fantomas wrote:
>> zone "abc.com" {
>> type forward;
>> forwarders {1.1.1.1;};
>
> of 1.1.1.1 is IP of nameserver for abc.com, you should better configure it
> as "type stub" or "type static-stub".
1.1.1.1 is a DNS resolver for Cloudflare and
On 12 Jul 2020, at 06:28, Matus UHLAR - fantomas wrote:
>> On 7/12/20 6:23 AM, ShubhamGoyal wrote:
>>> I am thinking to stop or drop ANY type queries from our DNS Recursive
>>> resolver , so please tell me how can we drop or stop ANY type queries from
>>> bind.
Don't do this.
> On 12.07.20
Given a domain that is hosted and used for email and web, is an A record for
that domain actually required?
That is, if bob.tld is hosted by example.com can you simply have
NS ns1.example.com
NS ns2.example.com
MX mx.example.com
www CNAME www.example.com
Without
On 08 Jul 2020, at 05:03, Adrian van Bloois wrote:
> When I try to start bind 9.16.x from systemd it fails not being able to
> find something.
…
> What could be the problem???
Not really possible to guess without the error message.
--
"Are you pondering what I'm pondering?"
"I think so,
On 07 Jul 2020, at 12:06, Michael De Roover wrote:
> On 7/7/20 4:06 PM, Tony Finch wrote:
>
>> max-udp-size 1420;
>> https://dnsflagday.net/2020/
> Interesting, I wasn't aware of this campaign. I don't know if I'm
> knowledgeable enough on UDP to be able to make educated decisions on
On 07 Jul 2020, at 08:06, Tony Finch wrote:
Excellent post, and a nice summary of some best practices.
I have a couple of questions.
> Response rate limiting is very effective. Start off by putting the
> following in your options{} section, and look in the BIND ARM for other
> directives you
On 06 Jul 2020, at 17:59, Mark Andrews 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
On 06 Jul 2020, at 22:00, ShubhamGoyal wrote:
> I am installing bind latest version with additional feature , it gave me
> "configure: error librpz.so and dlopen needed for dnsrps" error.
> I am searching for that error but i did not find the solution.
You have configured bind for dnsrps
On 06 Jul 2020, at 16:47, Kevin Darcy wrote:
> You didn't dot-terminate covisp.net in the "zone" statement
Ow!
Sigh.
--
The whole thing that makes a mathematician's life worthwhile is that
he gets the grudging admiration of three or four colleagues
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. INA 65.121.55.42
> update add ns1.covisp.net. 3601 INA 65.121.55.42
> send
;
When seeing up a secondary zone what do I replace # with in following (the
old syntax was masters instead od master, so I am guessing it needs a new
keyword)?
zone "example.com" {
type secondary;
# { 192.168.10.1; };
file "/var/lib/bind/db.example.com";
};
in
On 05 Jul 2020, at 07:51, @lbutlr via bind-users
wrote:
> mail # rndc reload
> rndc: 'reload' failed: failure
> mail # tail /var/log/messages
> Jul 5 07:41:24 mail.covisp.net named[53940]
> /usr/local/etc/namedb/bind.keys:29: unknown option 'trust-anchors'
> Jul 5 07:41:
On 05 Jul 2020, at 10:12, Tony Finch wrote:
> @lbutlr wrote:
>
>> When a domain configuration file contains an include line for the key,
>> where is that include looking for the key file?
>
> ... good question, I have avoided having to find that out ...
Heh.
> So
In named.conf I have
dnssec-enable yes;
dnssec-validation auto;
# rndc managed-keys status
view: _default
next scheduled event: Sun, 05 Jul 2020 20:43:00 GMT
name: .
keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Sun, 05 Jul 2020
When a domain configuration file contains an include line for the key, where is
that include looking for the key file?
I'm in a situation where the keys seems to work fine for updating DNSSEC, but
nsdiff complains the key file is not found.
Obviously something in named.conf or the domain file
On 05 Jun 2020, at 04:10, Jukka Pakkanen wrote:
> Thx for the info, had missed this one and actually we have that minor
> misconfiguration too. Have had since 1995 when started our nameservers and
> never noticed…
If it makes you feel better, it wasn't an error in 1995.
I remember removing
On 29 Apr 2020, at 14:19, Tony Finch wrote:
> DoT is easier since you only need a raw TLS reverse proxy, and there are
> lots of those, for example, nginx:
DOH is better because it cannot be blocked without blocking all https traffic.
(FSVO of better, of course. I am sure there is a vi/emacs
What is the proper syntax gor changing the TTL on a zone with nsupdate?
Does the existence of $TTL 86400 in the domain.conf file override nssupdate’s
attempts to change the TTL?
# nsupdate -k /path/to/key
> zone example.com
> ttl 3600
> send
> ^d
No errors, but no change in the TTL.
--
"I
On 18 Apr 2020, at 09:34, Reindl Harald wrote:
> Am 18.04.20 um 17:23 schrieb @lbutlr:
>> Is it possible to batch update all the domains? Looking at nsupdate it looks
>> like I have to step through and do every domain individually.
> well, where is the issue iterate all your
We are making some changes to our NSP account and the NSP is threatening to
change our IP block. This means I will have to update all the domains on the
system (all using DNSSEC). We are still arguing with them since there is no
technical reason for forcing this change on us, but chances are
With my install of bind 9.14 bindtools 9.16.0 was also installed.
This version is missing some (legacy) algorithms that I am still using on my
system, specifically hmac-sha256
dnssec-keygen [options] name
Version: 9.16.0
name: owner of the key
Options:
-a :
RSASHA1 |
On 23 Feb 2020, at 07:57, @lbutlr wrote:
> (9.11.6 should be coming really soon)
9.11.16, and I appear to be behind a touch, it is already released.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this l
On 22 Feb 2020, at 18:25, Scott A. Wozny wrote:
> I’m setting up hot-hot webserver clusters hosted on the west and east coasts
> of the US and would like to use Bind 9.11.4
I’d consider changing that version. While Bind 9.11 *is* still supported, it is
EOL at the end of this year. If you
On 11 Jul 2019, at 10:52, Lefteris Tsintjelis via bind-users
wrote:
> On 11/7/2019 15:35, Tony Finch wrote:
>> Lefteris Tsintjelis via bind-users wrote:
>>>
>>> Why would you want something like that?
>> https://datatracker.ietf.org/wg/dprive/about/
>
> If you are willing to sacrifice speed.
Is it possible to setup bind to use DOH (FNS over HTTPS) rather than
unencrypted DNS lookups? Our in addition to?
--
'An appointment is an engagement to see someone, while a morningstar is
a large lump of metal used for viciously crushing skulls. It is
important not to confuse the two.’
On 13 Jun2019, at 17:48, Browne, Stuart via bind-users
wrote:
> For options that have passed their warning phase and have been removed, I'm
> all for BIND failing to start and named-checkconf erroring out , rather than
> quietly ignoring them.
Yes, I think this is the best way, otherwise
On 22 May 2019, at 23:31, Evan Hunt wrote:
> One possible reason is distribution of trust anchors for a private corporate
> domain.
Aren't there better days to do this?
Or at least other ways to do this?
Anything to make bind leaner and meaner and with fewer LOCs seems like a plus
to me.
On 20 May 2019, at 20:45, @lbutlr wrote:
>
> On 20 May 2019, at 16:21, Noel Butler wrote:
>> allow-update { key "keyname"; };
>
> Ah, no I did not. The instructions I found, as I mentioned in a later post,
> were to add grant dons-key. iOS this a change
On 20 May 2019, at 16:21, Noel Butler wrote:
>allow-update { key "keyname"; };
Ah, no I did not. The instructions I found, as I mentioned in a later post,
were to add grant dons-key. iOS this a change in 9.14, because I did not have
to do this in 9.12?
> and nsLOOKUP ?
Just a thinko.
On 19 May 2019, at 18:27, @lbutlr wrote:
> This is the same key block that is in named.conf. I am launching NSLOOKUP
> with -k admin.key, but when I try to make a change and then "send", I get
> "update failed: REFUSED."
I found a page that recommended adding a dd
Trying to update some DNS under a relatively newly installed bin 9.14 with
nsupdate.
I have a file admin.key that looks basically like this:
key "rndc-key" {
algorithm hmac-sha256;
secret "SECRETSTUFF=";
};
This is the same key block that is in named.conf. I am launching NSLOOKUP
Currently running latest release of Bind 9.12, which is now EOLed and want to
move to 9.14. I was looking on google for
update "bind9.12" "bind 9.14"
But did not find anything of use. I did find the 9.14 announcement, but there
isn't a link there to release notes. I know there has been at
On 27 Apr 2019, at 16:21, Tim Daneliuk wrote:
> Why is 9.12+ now suddenly so grumpy about who owns the files? Is this a
> recent fix to reduce the attack surface on files owned by root?
Pretty sure. I thought it was mentioned in the 9.12 release notes, but now I
can't find it.
--
One of
On 25 Apr 2019, at 06:10, Martin Meadows via bind-users
wrote:
>
> ns ms,sans-serif">Wondering if anyone is aware of a max file size or max nu=
> mber of lines that a given BIND zone file can contain?=C2=A0 s=3D"gmail_default" style=3D"font-family:comic sans ms,sans-serif"> v> f">Thanks, s
On 17 Mar 2019, at 15:52, Grant Taylor via bind-users
wrote:
> If the consensus is that the new behavior is desired, I would hope ~> expect
> for a survey of the BIND user community like I've seen in the past about
> removing / significantly altering functionality.
I disagree. I'd prefer the
On 23 Feb 2019, at 14:45, Mark Andrews wrote:
> On IPv6 why wouldn’t you support it?
Our ISP does not support it. We get 5 static IPv4 addresses and no IPv6 at all.
--
Critics look at actresses one of two ways: you're either bankable or
boinkable.
On 22 Feb 2019, at 12:28, @lbutlr wrote:
> ; Communication with ::1#53 failed: timed out
I am still getting this error whenever I try to make a change in the zone with
nsupdate -l, should I not worry about it?
I mean, the records appear to be updating… 路♀️
--
First we must ass
On 22 Feb 2019, at 12:12, Tony Finch wrote:
> Get it from the link above, if you want :-)
Doh!
OK, got it, installed it, changed the path to perl, and that’s pretty slick.
--
"I don't think the kind of friends I'd have would care.”
___
Please visit
I did try manually updating vi nsupdate -l
> zone example.com
> update add example.com. 86400 IN SOA ns1.example.net. admin.example.com.
> 2019022200 3600 300 1209600 3600
> update add konamicode.example.com. 86400 IN CNAME www.example.com.
> send
; Communication with ::1#53 failed:
On 22 Feb 2019, at 09:54, Tony Finch wrote:
> You might want a config like
>
> zone "example.com" {
> type master;
> file "master/example.com”;
Not example.com.signed?
> update-policy local;
> auto-dnssec maintain;
>
On 21 Feb 2019, at 20:43, Grant Taylor via bind-users
wrote:
>
> On 2/21/19 6:28 PM, @lbutlr wrote:
>> rndc reload did not recreate (or at least update the time stamp) on the
>> .signed file.
>
> Hum. Maybe it's something different about how you're doing DNSSEC tha
On 21 Feb 2019, at 18:28, @lbutlr wrote:
> Is the original random key that was generated at the time of signing kept
> somewhere? NSEC3 seems to contain a 16 character hex sting that recurs
> throughout the file.
OK, I moved aside the signed file, resigned the domain using the 16
>> OK, but rndc flush example.com results in:
>> rndc: 'flush' failed: not found
>
> *FACEpalm*
>
> I'm sorry. I gave you the wrong command. You want "sync", not "flush". My
> brain always thinks "flush the journal to disk" when it's really supposed to
> be "sync the journal to disk". You
> On 21 Feb 2019, at 13:41, Grant Taylor via bind-users
> wrote:
>
> On 02/21/2019 01:34 PM, @lbutlr via bind-users wrote:
>> I edited a zone file after issuing a rndc freeze command, added two new sub
>> zones, changed the serial number, saved the file, and then
I edited a zone file after issuing a rndc freeze command, added two new sub
zones, changed the serial number, saved the file, and then did an rndc thaw.
In var/log.messages I get
zone serial (2019020105) unchanged. zone may fail to transfer to slaves.
which is the previous serial number.
So,
> On 5 Feb 2019, at 04:57, Tony Finch wrote:
>
> @lbutlr wrote:
>>
>> OK, then how do I get Bind9.122 to update the .signed files?
>
> Did you see my previous message?
I did not, sorry.
> https://lists.isc.org/pipermail/bind-users/2019-February/101335.html
1 - 100 of 136 matches
Mail list logo
