Re: 'inline-signing' might go away and be replaced by dnssec-policy ?
Retried my named.conf with BIND 9.19.7-dev (Development Release)
which reports:
26-Oct-2022 21:31:42.021 /private/tmp/b/named.conf:11: 'inline-signing
yes;' must also be configured explicitly for zones using dnssec-policy without
a configured 'allow-update' or 'update-policy'. See
https://kb.isc.org/docs/dnssec-policy-requires-dynamic-dns-or-inline-signing
If I add an allow-update{} or inline-signing{} stanza, the server starts and
neither combination overwrites the primary zone file.
-JP
--
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
Re: dig +norecurse behaviour changed with 9.16.33
The change is that with 9.16, if the requested name is a CNAME, only the CNAME value is returned by dig, while with 9.11 dig would return both the CNAME value and the IP of the CNAME. as others have said, this needs more details, but I wonder whether you might now be querying a server which has `minimal-responses yes' configured which it didn't previously. -JP -- 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
Re: 'inline-signing' might go away and be replaced by dnssec-policy ?
the 'inline-signing yes;' is needed IN ADDITION to 'dnssec-policy' in order to
_not_ overwrite original zone files/data on signing.
I cannot confirm that (9.17.22):
% ls -1
example.aa
named.conf
% cat named.conf
options {
directory ".";
listen-on port 5301 { 127.0.0.2; };
recursion no;
dnssec-validation no;
};
zone "example.aa" in {
type primary;
file "example.aa";
dnssec-policy "default";
};
% named -g -c named.conf &
% ls -1
Kexample.aa.+013+11677.key
Kexample.aa.+013+11677.private
Kexample.aa.+013+11677.state
example.aa
example.aa.jbk
example.aa.signed
example.aa.signed.jnl
named.conf
The .signed has the signed zone from which BIND serves data, and the original
source file is unchanged.
-JP
--
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
Re: A beginner's guide to DNSSEC with BIND 9
The inline-signing feature will not go away. Thanks, Matthijs, I stand corrected. I believe I had seen that in ISC documentation and/or issues, but I will now stop saying that. :) -JP -- 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
Re: A beginner's guide to DNSSEC with BIND 9
A Beginner's Guide to DNSSEC with BIND 9.
Well done! A few comments, if I may:
1. in your zone stanzas you use the term "master" (type: master, ... masters
{}). BIND has been updated already a while ago to support the term primary, e.g. `type
primary;' and `primaries {};' (likewise for 'secondary'). It might be a good time to
switch to the new nomenclature, particularly as you rightly call the primary primary and
secondary a secondary :)
2. I tend to use `rndc reconfig' for re-configuration (after adding a new zone,
say) rather than `reload', which I used when I wish named to load a modified
primary zone.
3. on your primary you have an allow-transfer{} ACL for your secondary using its IP address. You might wish to look into using TSIG for that.
4. note that `inline-signing' might go away and be replaced by dnssec-policy
which you may wish to look into at some point.
5. I'm not familiar with the paths used by your Ubuntu distro, but the command
at #6 appears to be incorrect:
sudo ./etc/bind/named-checkconf named.conf.local
named-checkconf(8) is likely in /usr/sbin and it will use a compiled-in
default configuration file.
6. just as a FYI: instead of "and if you quickly type tail var/log/syslog" I
typically `tail -f' (follow) the log file in a second window/pane/console or even in the
same session in order to have logs show up immediately. :)
7. Instead of querying for the SOA (dig ... SOA +dnssec), I like querying for
the DNSKEY RRset so that I see the key tags (key IDs): `dig @::1 example.com
DNSKEY +dnssec +multi' (the +multi flag shows me the key types and tags, or use
+nocrypto to omit the base64-encdoded stuff)
8. in the section on externally validating, I'd love to recommend dnsviz.net: I
cannot think of another testing site which I would *pay* to use. These chaps
are grand!
Feel free to talk to me off-list if I've not made sense.
Best regards,
-JP
--
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
Re: DS keys with 2 digest algorithms
Maybe in the future dnssec-signzone won't generate the deprecated entry to begin with. BIND 9.16.0 stopped generating SHA1 digests [1] : "DS and CDS records are now generated with SHA-256 digests only, instead of both SHA-1 and SHA-256. This affects the default output of dnssec-dsfromkey, the dsset files generated by dnssec-signzone, the DS records added to a zone by dnssec-signzone based on keyset files, the CDS records added to a zone by named and dnssec-signzone based on “sync” timing parameters in key files, and the checks performed by dnssec-checkds." -JP [1] https://bind9.readthedocs.io/en/v9_16_6/notes.html -- 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
Re: Delete/update MX record
Using nsupdate when I try to delete an MX record for a domain, I get REFSUED. REFUSED is also reported when attempting to update a non-dynamic zone. Are you sure the zone you're trying to update is actually dynamic? How do I remove and replace the MX record for a domain with nsupdate? del ownernamne. MX [rdata] should do it. Without [rdata] all MX for the owner will be removed, but specify rdata to indicate you wish to delete just the one. As Mark said: best demonstrate what you are doing. -JP -- 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
Re: Splitting long strings in RRs using parentheses
20220317-a4qe._domainkeyTXT ( v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAA ^ begin comment OCAQ8AMIIBCgKCAQEAmEsWuQCj+OenaSQ3dM6WItExor The bit from the first semicolon to the end of the line was missing. Is that expected behavior? A semicolon begins a comment in a zone file [1], so yes. -JP [1] https://jpmens.net/2015/10/28/the-semicolon-in-zone-master-files-some-history/ -- 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
Re: Primary zone not fully maintained by BIND
26-May-2022 10:06:14.458 debug 3: zone penguinpee.nl/IN/external: zone_rekey failure: unexpected error (retry in 600 seconds) One of the first things BIND does, if I'm reading lib/dns/zone.c correctly, is to attempt to lock the keys, and if it fails it emits that diagnostic. Assuming the signing is being attempted simultaneously in both views, I wonder if that goes hand-in-hand with what Matthijs writes: Since 9.16.18 you should not be able to set the same key-directory for the same zone in different views. So maybe using the same key directory (from the same dnssec-policy) is actually causing the issue? -JP -- 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
Re: bugs for cname can not be working properly with bind 9.11.4
(putting this back on list) thank you for the feedback,now I have already start the slave server [root@bind-master-centos7 ~]# dig kaixinduole.com +nssearch SOA ns1.kaixinduole.com. shawn.kaixinduole.com. 2022041566 3600 900 604800 86400 from server 52.130.145.30 in 0 ms. SOA ns1.kaixinduole.com. shawn.kaixinduole.com. 2022041584 3600 900 604800 86400 from server 139.217.99.188 in 1 ms. You'll note that the two servers have a differing SOA serial: 2022041566 vs 2022041584. Something has changed, because the zone now SERVFAILs: $ dig @9.9.9.9 kaixinduole.com ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56297 When queried directly, I get a response: $ dig @52.130.145.30 ns1.kaixinduole.com +norec ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 I can't get rid of the feeling that we're not seeing the same server you are... -JP -- 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
Re: bugs for cname can not be working properly with bind 9.11.4
2. [image: image.png] In this screenshot you've shown the result of `cat named.conf', but where's the zone definition for kaixinduole.com? What we are seeing here is a recursive server. -JP -- 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
Re: bugs for cname can not be working properly with bind 9.11.4
I just modified the serial number this is not currently a problem, but please note that you've changed the first four digits which are likely to 2023. Also if the zone is reloaded there's no need to restart named. Actually nothing changed , Indeed. Are you doing these changes on the server we know as NS1.kaixinduole.com with the IP address shown below? As Bob mentions, the second NS2 is not responding: $ dig kaixinduole.com +nssearch SOA ns1.kaixinduole.com. shawn.kaixinduole.com. 2022041566 3600 900 604800 86400 from server 52.130.145.30 in 343 ms. From here we're still seeing the unchanged SOA serial number. -JP -- 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
Re: There are some prombles in the query log
All queries are from the same client whose ip is 192.168.100.126, but why the port which each query from is so different? The source port is random and it should be different. I disabled the recursion of bind 9 ,but all the Recursion Desired flag was set '+', this confused me. > If you add the +norec (no recursion) flag to dig, it will not request recursion The client object identifiers are not the same although all queries are from the same client. That is correct, and you can safely ignore them. BIND developers can use those for intense debugging. One more thing, I use dlz to allows zone data to be retrieved from postgresql. I think (actually I'm pretty sure) that DLZ at you have been using it is meanwhile deprecated, so I would consider migrating to something else, i.e. plain zone master files. (Please do not confuse DLZ as you've been using it with the new DLZ loadable modules.) -JP -- 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
Re: bugs for cname can not be working properly with bind 9.11.4
the domain name is kaixinduole.com Querying the SOA record for kaixinduole.com shows the SOA serial number is less than what you showed in the screenshot: ;; ANSWER SECTION: kaixinduole.com.21600 IN SOA ns1.kaixinduole.com. shawn.kaixinduole.com. ( 2022041566 ; serial 3600 ; refresh (1 hour) 900; retry (15 minutes) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) I just create a cname record for testing, which is www cname to www.baidu.com. please see the below : When you update the zone file and add the CNAME, you must increase the SOA serial number to anything higher than what it currently is. The zone seems to use MMDDnn format, but you can also just increment the current number. After storing the zone file, I recommend you use named-checkconf -z to make sure you see no error messages, and then you should be able to load the zone with an rndc reload kaixinduole.com Good luck, -JP -- 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
Re: bugs for cname can not be working properly with bind 9.11.4
(I've tried to reformat some of this; it was illegible to me and I'm probably misreading some of it) www IN CNAME www.baidu.com. [root@centos7 ~]# dig www.kaixinduole.com# it should be cname to You've not specified an address for dig to use so it's using your system's resolver, likely querying a caching server which is responding with a cached entry. -JP -- 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
Re: Primary zone not fully maintained by BIND
dnssec-policy default;
Slightly off-topic, but I believe ISC reccomend using a custom policy instead
of `default' in case the default changes in future.
view "internal" {
zone "penguinpee.nl" {
typeprimary;
file"dynamic/penguinpee.nl.internal.zone";
};
};
view "external" {
zone "penguinpee.nl" {
typeprimary;
file"master/penguinpee.nl.zone";
};
};
Using delv, the internal view of the zone fully validated, for SOA, A,
etc.
That surprises me a bit; I've always maintained BIND will not validate a
DNSSEC-signed zone it is authoritative for. Unless you mean RRSIGs were
still valid.
I thought that with 'dnssec-policy default' BIND would take care of
it. Upon updating the zone, increase the serial number and tell named
with 'rndc reload zone'. What am I missing?
BIND should be signing the zone(s) with dnssec-policy, yes, and the
dynamically-updateable zone will be signed on update and SOA serial
increased automatically.
I wonder whether it's getting confused (can software get confused? I suppose
so) with the two identically-named zones. If this were my installation and
I had to use views, I'd try specifying distinct policies for the zones
to see if that makes a difference.
-JP
--
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
Re: Dynamic A records similar to nip.io or xip
Does the $GENERATE directive in BIND zone files do what you need? The $GENERATE statement is executed when loading the zone file results in an expanded in-memory version of the zone being used. That can get quite large. -JP -- 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
Re: Dynamic A records similar to nip.io or xip
DLZ are loadable modules I should have pointed to the documentation [1] and some example modules [2]. -JP [1] https://github.com/isc-projects/bind9/tree/main/contrib/dlz/example [2] https://github.com/isc-projects/bind9/tree/main/contrib/dlz/modules -- 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
Re: Dynamic A records similar to nip.io or xip
Does anyone know whether it's possible to generate with Bind these kind of A records automatically on the authoritative side BIND has DLZ, Dynamically Loadable Zones, which is an extension which allows zone data to be retrieved from basically anywhere. DLZ are loadable modules written in the C language [1]. So the answer is yes, but it entails a non-trivial bit of programming. -JP -- 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
Re: Only one DS key comes back in query
I am ridiculed by an ISC member for using a reserved domain according to For the record, assuming you mean me, I am not affiliated with the gold folk at ISC. -JP -- 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
Re: Only one DS key comes back in query
Suppose I was working on a problem for Barclays Bank In that case I would think Barclays Bank's Platinum Enterprise BIND Support contract would cover answering such questions. -JP -- 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
Re: Only one DS key comes back in query
The values in the file dsset-example.com generated by signing the zone are not good. If they are 'not good' then it's possible you are using an outdated dsset file. (And you are hiding domain names; I doubt example.com has been delegated to you.) dnssec-signzone creates dsset- files when signing a zone manually/semi-automatically. If you are signing with, say, autodnssec-maintain, then no dsset- file is created and you use dnssec-dsfromkey to determine the DS which you then submit to your parent zone. -JP -- 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
Re: Transitioning to new algorithm for DNSSEC
Is there a guide on transitioning the DNSSEC signing algorithm, One of the best concise instructions on doing this was written by Tony Finch while at Cambridge, and I have used this [1] successfully a few times. My recommendation: print it out, and use a red pen to tick off the individual points as you complete them. The most difficult phases are where the document says 'wait'. Not only should you wait but also wait 'a bit more'. Timing is of the essence. Good luck! -JP [1] https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html -- 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
Re: Supporting LOC RR's
Fun is a sufficient reason. Definitely. IATA airport codes to LOC: % dig +short CDG.air.jpmens.net LOC 49 0 46.073 N 2 33 0.000 E 119.00m 1m 1m 10m and more fun with an associated TXT: % dig +short CDG.air.jpmens.net TXT "cc:FR; m:Paris; t:large, n:Charles de Gaulle International Airport" with more at https://jpmens.net/2020/10/04/airports-of-the-world/ -JP -- 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
Re: Using Ansible to manage bind installation/basic setup.
Ansible's template module is what you'd probably use for #1, the service module (with handlers) for #2, and #3 comes out of the box when you use Ansible. While you might find existing roles and playbooks on the internets, I would strongly recommend to vet them carefully in a test environment before using them in production; just because something works for me doesn't mean it will satisfy you. :) Good luck, -JP ___ 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
