Switching from rhel base 9.16 to 9.18 copr
Hello, I use bind (stock from alma 9.3) as a nameserver for a webhosting server with webmin/virtualmin. If I install BIND via copr (RHEL9 and derivatives only offer 9.16 instead of 9.18 - I want to experiment with DoT for opportunistic TLS between nameservers, upcoming standard <https://datatracker.ietf.org/doc/rfc9539/> RFC 9539 - Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS (ietf.org) ) what are the necessary steps to make isc-bind read the existing config files? named.conf in /etc and zones in /var/named? will the daemon only listen to /etc/opt/isc/scls/isc-bind/named.conf? should I edit the systemctl .service file to adjust the config path? Thanks, Luca -- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
On 01.05.2024 01:33, Mark Andrews wrote: On 1 May 2024, at 03:32, Lee wrote: On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: On 29.04.2024 22:19, Lee wrote: On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users wrote: something that I replied to and got this in response: Error Icon Message blocked Your message to Walter.H@[..snip..] has been blocked. See technical details below for more information. The response from the remote server was: 554 5.7.1 : Client host rejected: Use IPv4 For explanation: this is MY mail server, which blocks IPv6 connections from Outlook.com Gmail.com ... as these are the biggest SPAM senders Which is fine .. your server, your rules. But maybe what isn't so fine is me replying only to the list and still getting a 'rejected: Use IPv4' msg. I don't know how the mailing list works; I'm a bit surprised that I can reply only to the list, get the Client host rejected msg and somehow you can still get the msg?? there are 2 pair of shoes, mails from the list are not from Outlook.com or Gmail.com but if you put my mail address to "To: ", then its from Gmail.com ;-) This is what happens when you put something into the rejection rules which has zero relationship whether something is spam or ham. depends ... I just find it interesting that someone using mx01.ipv6help.de as a MX would be so interested in punishing IPv6 use. you are mixing up 2 independent things ... IPv6 clients aren't blocked at all, just Outlook.com, Gmail.com, ... that is the difference; just for Outlook.com the following fact is true but bullshit # host -t MX outlook.com outlook.com mail is handled by 5 outlook-com.olc.protection.outlook.com. # host outlook-com.olc.protection.outlook.com outlook-com.olc.protection.outlook.com has address 52.101.8.47 outlook-com.olc.protection.outlook.com has address 52.101.9.15 outlook-com.olc.protection.outlook.com has address 52.101.40.30 outlook-com.olc.protection.outlook.com has address 52.101.194.14 # as you see no IPv6 at all; why then the need of accepting their SPAM on IPv6 transport? smime.p7s Description: S/MIME Cryptographic Signature -- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
On 29.04.2024 22:19, Lee wrote: On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users wrote: something that I replied to and got this in response: Error Icon Message blocked Your message to Walter.H@[..snip..] has been blocked. See technical details below for more information. The response from the remote server was: 554 5.7.1 : Client host rejected: Use IPv4 For explanation: this is MY mail server, which blocks IPv6 connections from Outlook.com Gmail.com ... as these are the biggest SPAM senders smime.p7s Description: S/MIME Cryptographic Signature -- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
|Try these four | | | |fail01.dnssec.works| |fail02.dnssec.works| |fail03.dnssec.works| |fail04.dnssec.works| and then with +cd and note the difference; On 28.04.2024 08:17, Walter H. via bind-users wrote: On 27.04.2024 16:54, Lee wrote: On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users wrote: # host dnssec-analyzer.verisignlabs.com dnssec-analyzer.verisignlabs.com is an alias for dnssec-analyzer-gslb.verisignlabs.com. dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 Right, the IPv4 address lookup works. Now try looking up the IPv6 address. if there was one it would be presented there see here for full answer # host one.one.one.one one.one.one.one has address 1.1.1.1 one.one.one.one has address 1.0.0.1 one.one.one.one has IPv6 address 2606:4700:4700::1001 one.one.one.one has IPv6 address 2606:4700:4700:: I get a status: SERVFAIL instead of a status: NOERROR $ dig dnssec-analyzer.verisignlabs.com ; <<>> DiG 9.16.48-Debian <<>> dnssec-analyzer.verisignlabs.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60491 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 Lee this can't be a matter of DNSSEC, as there are only signed whole zones and not just single DNS-records ... would it be a problem with just this DNS zone, why are only problems getting the IPv6? smime.p7s Description: S/MIME Cryptographic Signature -- 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
[help]how to configure ecs subnet for bind-9.18-21
dear admin: now, i use bind-9.18-21, i want to use ecs client subnet function; but i don't know how to configure it, and i don't get method from google please give me some example,or document , or google links to learn about it ; thanks! Yang 395096...@qq.com-- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
On 27.04.2024 16:54, Lee wrote: On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users wrote: # host dnssec-analyzer.verisignlabs.com dnssec-analyzer.verisignlabs.com is an alias for dnssec-analyzer-gslb.verisignlabs.com. dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 Right, the IPv4 address lookup works. Now try looking up the IPv6 address. if there was one it would be presented there see here for full answer # host one.one.one.one one.one.one.one has address 1.1.1.1 one.one.one.one has address 1.0.0.1 one.one.one.one has IPv6 address 2606:4700:4700::1001 one.one.one.one has IPv6 address 2606:4700:4700:: I get a status: SERVFAIL instead of a status: NOERROR $ dig dnssec-analyzer.verisignlabs.com ; <<>> DiG 9.16.48-Debian <<>> dnssec-analyzer.verisignlabs.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60491 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 Lee this can't be a matter of DNSSEC, as there are only signed whole zones and not just single DNS-records ... would it be a problem with just this DNS zone, why are only problems getting the IPv6? smime.p7s Description: S/MIME Cryptographic Signature -- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
# host dnssec-analyzer.verisignlabs.com dnssec-analyzer.verisignlabs.com is an alias for dnssec-analyzer-gslb.verisignlabs.com. dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 On 27.04.2024 01:35, Lee wrote: dig dnssec-analyzer.verisignlabs.com gives me a SERVFAIL & this in the bind errors_log file: $ grep dnssec-analyzer.verisignlabs.com named-errors.log | tail -1 26-Apr-2024 19:28:37.600 query-errors: info: client @0x7f384488e3c0 127.0.0.1#47121 (dnssec-analyzer.verisignlabs.com): query failed (failure) for dnssec-analyzer.verisignlabs.com/IN/ at query.c:7471 Is that because of the insecure delegation shown at https://dnsviz.net/d/dnssec-analyzer.verisignlabs.com/dnssec/ and me having "dnssec-validation auto;" in named.conf? Thanks Lee (still struggling to understand this stuff) smime.p7s Description: S/MIME Cryptographic Signature -- 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: Observation: BIND 9.18 qname-minimization strict vs dig +trace
> The facts are: > > * 191.131.in-addr.arpa is served from awsdns Correct. And it's delegated to from the 131.in-addr.arpa zone, maintained by ARIN. > * It delegates 85.191.131.in-addr.arpa with fs838.click-network.com > and ns102.click-network.com above the zone cut. Correct. > * Below the zone cut the nameserver claims to be authoritative for its > parent's zone (191.131.in-addr.arpa) instead of > 85.191.131.in-addr.arpa. (In other words it's lame.) Well, yes. When queried for the NS set for 85.191.131.in-addr.arpa it returns "NOERROR" with the 191.131.in-addr.arpa SOA record in the authority section. This is what is called an "upward referral", and indicates that the delegation structure and/or child name server setup is inconsistent with the delegation structure. Were I less charitable I would say "messed up". Basically what you say above -- it doesn't serve the delegated zone so is "lame". > * (Below the zone cut it also erroneously advertises one of its > nameservers as simply ns102. instead of ns102.click-network.com) Yep. > * There is no server which actually advertises itself as authoritative > for 85.191.131.in-addr.arpa Yep. Both of the resolveable NSes ns102.click-network.com and fs838.click-network.com claim authority over 191.131.in-addr.arpa, which they don't have according to the parent zone DNS delegations. Regards, - Håvard -- 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: Observation: BIND 9.18 qname-minimization strict vs dig +trace
Hmm, I wonder if qname-minimisation is at issue here. My trace dies with: 85.191.131.in-addr.arpa. 1800 IN NS fs838.click-network.com. 85.191.131.in-addr.arpa. 1800 IN NS ns102.click-network.com. couldn't get address for 'fs838.click-network.com': not found couldn't get address for 'ns102.click-network.com': not found -- 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: RFC8482: Implementation
Hi. In BIND, since 9.11, there is an option/view statement called "minimal-any", which defaults to "no". That might be what you're after. Cheers, Greg On Sat, 20 Apr 2024 at 17:29, Amaury Van Pevenaeyge < avanpevenae...@outlook.fr> wrote: > Hello everyone, > > I've been looking for days and days for a way to implement the principle > documented in RFC8482 (Providing Minimal-Sized Responses to DNS Queries > That Have QTYPE=ANY) as Cloudflare is currently doing. I can't find the > solution to do this. Can anyone help me with this? > > Thanks in advance > -- > 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 > -- 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
RHEL, Centos, Rocky, Fedora rpm 9.18.26
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.five-ten-sg.com/mapper/bind contains links to the source rpm, and build instructions. This .src.rpm contains a .tar.gz file with the ARM documentation, so the rpm rebuild process does not need sphinx- build and associated dependencies. -BEGIN PGP SIGNATURE- iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCZiAhLBUcY2FybEBmaXZl LXRlbi1zZy5jb20ACgkQL6j7milTFsH/TwCfRECCzSbMwWY4o32rzDT1X3b8kxMA nj9AgWAaoXYHW7AtfK7Ii57mrHkp =iSyg -END PGP SIGNATURE- -- 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: Answers for www.dnssec-failed.org with dnssec-validation auto;
On 17/04/2024 11:41, John Thurston wrote:
I'm seeing strange behavior with a BIND 9.18.24 resolver and
dnssec-failed.org.
With no dnssec-validation line (or with "dnssec-validation auto") in
the .conf, querying for www.dnssec-failed.org returns SERVFAIL, as
expected . . until it doesn't. After several seconds of answering
SERVFAIL, I start getting NOERROR responses, and IP addresses in the
ANSWER. It isn't a predictable number of seconds; sometimes 9,
sometimes 20.
Is this supposed to be happening?
When I examine the process with delv and my eyeballs, I can't see why
it is succeeding with dig and my validating resolver.
Maybe I'm not looking for the right things with my eyeballs? I'm
stumped, and looking for advice for nest-steps in understanding what's
going on.
The following one-liner:
# rndc flush && while true; do dig -4 www.dnssec-failed.org. A
@localhost; sleep 1; done
Hi John.
FYI I tried running your command myself and didn't see the same problem.
The first thing you'd want to rule out is the possibility that you have
more than one resolver running? E.g.
sudo netstat -anp | awk '{ if ($4 ~ /:53$/) print; }' | sort -u
The last column in the output from the command above should show a
number followed by a slash then a process name, which should be the same
on every line (e.g. "1804/named"). If it isn't, then see if you can stop
the other service(s) and then rerun your test?
If you have just a single process listening on port 53, then I'd suggest
using "tail -f" to watch your BIND logs (or syslog?) while you are
running your test, to see what is going on from the recursive resolver's
point of view? Hopefully you'll see something interesting when the
problem happens?
Nick.
--
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: Some Authoritative-Only BCPs
Hi Crist. Firstly, DNS servers do not make recursive queries, unless they have been configured to forward. Secondly, please start a packet capture on your server (save to disc, so you can analyse it later in Wireshark) then start BIND and make some test queries to your server. Look at what your server is doing as it starts and as you make queries to it. It *will* need Internet access and you should permit this in your firewall - port 53, both UDP and TCP. As for the question of DNSSEC validation - yes or no? There is more DNSSEC around these days than there used to be and choosing to NOT do validation will hurt you in future, or maybe even right now. My advice would be to enable it, look at packet captures, ask questions and understand it, rather than disable it because you don't think you need it. Cheers, Greg. On Sun, 31 Mar 2024 at 08:07, Crist Clark wrote: > Thanks so much for the response. > > This machine does not have any reasons to do recursive queries to > the Internet, and it is not allowed in the firewall. > > Looks like the article quoted is the guidance I was looking for. This > server has "notify no", AND all of the name servers are in the > authoritative > zones anyway. And it has no need to ever do DNSSEC validation. I wonder > if > the traffic I was seeing was solely due to trust anchor maintenance. If > I > turn off dnssec-validation, will that traffic go away without having to > become master for root? I'll give that a try. > > None of the other cases in the article apply. All zones are "secondary" > (except the fake root if I need to keep that). The DNSSEC arguments seem > kind of circular. You need to allow recursive behavior to support > DNSSEC, > and DNSSEC is needed to support recursive behavior. > > Interesting that you bring up the case of non-Internet root. We do have > networks like that too. The authoritative-only DNS servers there should > have analogous configuration. We shouldn't need to put that network's > root in the authoritative-only servers or enable DNSSEC... > > Although this did remind me of one reason to enable dnssec-validation > for totally non-technical reasons. Compliance. For when the auditors > come > around. It's easier to just have dnssec-validation enabled rather than > deal > with getting security exceptions or adverse findings. It's > (unfortunately) > a _really_ good reason to enable it even if it is technically > unnecessary. > > > On 2024-03-28 01:04, Greg Choules wrote: > > Hi cjc. > > My answers would be: > > > > - Leave `dnssec-validation` alone (auto) and ensure your server has a > > path > > to the Internet to make queries. > > > > - Don't mess with root hints. The only time anyone should need to do > > this > > is when running a completely captive server living in a custom > > namespace > > that is NOT the Internet. > > > > - I don't know if "none" and "!all" work out to be the same thing in > > code > > terms, but my preference would be "none" anyway because 1) that's > > what's in > > the documentation and would be the obvious choice, and 2) why > > deliberately > > create a negated expression that is harder to parse, mentally? Glancing > > through a config and seeing "...!all..." you may not notice the "!" and > > just see the "all". Even if you do see the pling, a statement > > containing it > > reads something like "I would like to permit not all", which requires > > some > > thinking about the intent. Whereas "I would like to permit none" (for > > me > > anyway) is clearer and less ambiguous. > > > > As for why authoritative servers need to make queries at all, please > > take a > > look at this article. > > > https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries > > > > Hope that helps. > > Greg > > > > On Thu, 28 Mar 2024 at 06:15, Crist Clark > > wrote: > > > >> I am upgrading and redeploying some authoritative-only BIND servers. > >> Two > >> questions about some fine points: > >> > >> What to set 'dnssec-validation'? Just let it default to 'auto?' There > >> is > >> no need or opportunity for an authoritative-only server to validate > >> (right?). Should we actively switch it off, set it to 'no?' For > >> example, > >> does setting it to 'no' reduce any resource use or reduce the security > >> vulnerability space? > >> > >> This is bordering on aesthetic (maybe the first one is too), but what > >> to > >> do abou
Re: Some Authoritative-Only BCPs
Hi cjc.
My answers would be:
- Leave `dnssec-validation` alone (auto) and ensure your server has a path
to the Internet to make queries.
- Don't mess with root hints. The only time anyone should need to do this
is when running a completely captive server living in a custom namespace
that is NOT the Internet.
- I don't know if "none" and "!all" work out to be the same thing in code
terms, but my preference would be "none" anyway because 1) that's what's in
the documentation and would be the obvious choice, and 2) why deliberately
create a negated expression that is harder to parse, mentally? Glancing
through a config and seeing "...!all..." you may not notice the "!" and
just see the "all". Even if you do see the pling, a statement containing it
reads something like "I would like to permit not all", which requires some
thinking about the intent. Whereas "I would like to permit none" (for me
anyway) is clearer and less ambiguous.
As for why authoritative servers need to make queries at all, please take a
look at this article.
https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries
Hope that helps.
Greg
On Thu, 28 Mar 2024 at 06:15, Crist Clark wrote:
> I am upgrading and redeploying some authoritative-only BIND servers. Two
> questions about some fine points:
>
> What to set 'dnssec-validation'? Just let it default to 'auto?' There is
> no need or opportunity for an authoritative-only server to validate
> (right?). Should we actively switch it off, set it to 'no?' For example,
> does setting it to 'no' reduce any resource use or reduce the security
> vulnerability space?
>
> This is bordering on aesthetic (maybe the first one is too), but what to
> do about the compiled-in root hints? Even on my authoritative-only server
> with "recursion no," every forty-five minutes or so, it's trying to go to
> the root servers and retrieve the NS and DNSKEY RRs for the root. It's
> blocked since there is no reason for this server to do outbound DNS, except
> to its hidden masters, so it just keeps trying and cluttering the firewall
> logs. What's the best way to stop this behavior? Is there a configuration
> option? I did this,
>
> zone "." {
> type primary;
> file "primary/empty-zone.db";
> allow-query { none; };
> };
>
> Which seems to do the trick, but is that the cleanest way? Any problems
> with that approach that I haven't considered?
>
> Oh, one final bonus question, is there any difference between specifying
> 'none' and '!all' in a server list, ACL, etc.? I prefer 'none', but the old
> configurations used '!all'. Can I change those without worrying?
> --
> 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
>
--
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
AW: [OFF-TOPIC] Question about ClouDNS (and others') ALIAS records
> -Ursprüngliche Nachricht- > Von: bind-users Im Auftrag von Jan > Schaumann via bind-users > Gesendet: Dienstag, 26. März 2024 14:44 > An: bind-users@lists.isc.org > Betreff: Re: [OFF-TOPIC] Question about ClouDNS (and others') ALIAS records > > Karl Auer wrote: > > I'm puzzled by the ClouDNS "ALIAS" record. I was wondering if anyone > > knows how it is handled "under the hood"? > > Many DNS service providers have some sort of variation > of this, since "aliases at the apex" is a feature many > customers need: > > Akamai uses "Zone apex mapping": > https://techdocs.akamai.com/edge-dns/docs/features#zone-apex-mapping > > Cloudflare uses "CNAME flattening": > https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames- > at-a-domains-root/ > > AWS uses "alias records": > https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record- > sets-choosing-alias-non-alias.html > ... Some more info can be found in the deprecated draft: https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ This is for example very similar how ALIAS is implemented in PowerDNS Auth. But as there is no standard for the "CNAME-like at apex" there is no definition on how TTLs should be implemented. Regards Klaus -- 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: [OFF-TOPIC] Question about ClouDNS (and others') ALIAS records
Karl Auer wrote: > I'm puzzled by the ClouDNS "ALIAS" record. I was wondering if anyone > knows how it is handled "under the hood"? Many DNS service providers have some sort of variation of this, since "aliases at the apex" is a feature many customers need: Akamai uses "Zone apex mapping": https://techdocs.akamai.com/edge-dns/docs/features#zone-apex-mapping Cloudflare uses "CNAME flattening": https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/ AWS uses "alias records": https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html Simplified, the authoritative performs the "CNAME" chain resolution (because it controls the zones in question) and returns the final result so the client doesn't have to chase CNAMEs. Fortunately, nowadays we have a proper solution for this problem (which -- bringing it back on-topic :-) -- bind supports): SVCB / HTTPS records (RFC9460). However, adoption of those records is still lacking, with clients behaving inconsistently and services not offering them widely yet. -Jan -- 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: transfert master slave
Hi Sami.
"allow-..." statements are to restrict from which sources *this* server
will accept messages, of whichever type.
On the secondary (slave), "allow-notify {192.168.56.154;};" will permit it
to process NOTIFY messages sent to it from the primary (master), but ignore
any others. Actually, this is not necessary because it would do that
anyway. See the ARM description for this statement -
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-allow-notify
NOTIFY messages from the primary will reach the secondary server and be
processed because the primary is listed in an NS record in the zone. As
Mark says, you cannot stop this. You could test sending NOTIFY from a third
server that is *not* listed as an NS for the zone.
On the primary you do not need allow-transfer {192.168.56.157;}; as the
primary is not transferring *from* the secondary.
You probably also don't need also-notify {192.168.56.157;}; if the
secondary has an NS record in the zones it will be transferring, which it
should.
Hope that helps.
Greg
On Mon, 25 Mar 2024 at 11:34, wrote:
> Hello community,
>
> I'm trying to configure a DNS slave server (192.168.56.157) . I want to
> allow notifications only from the master (192.168.56.154). I added the
> directive "allow-notify {192.168.56.154;};" and it works. However, when I
> try to test the prohibition of notification by adding "allow-notify
> {none;};" at the slave, it still receives updates from the master. The
> transfer on the master is as follows:
>
> allow-transfer {192.168.56.157;};
>
> also-notify {192.168.56.157;};
>
> notify explicit;"
>
>
>
> PS. BIND version : 9.16.48
>
>
>
> Regards Sami
>
> Orange Restricted
>
>
> --
> 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
>
--
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
RHEL, Centos, Rocky, Fedora rpm 9.18.25
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.five-ten-sg.com/mapper/bind contains links to the source rpm, and build instructions. This .src.rpm contains a .tar.gz file with the ARM documentation, so the rpm rebuild process does not need sphinx- build and associated dependencies. -BEGIN PGP SIGNATURE- iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCZf3WuxUcY2FybEBmaXZl LXRlbi1zZy5jb20ACgkQL6j7milTFsHr2gCfYw4U1U1itN4N0USVhyfg1325YjMA nRpCW3TjF6RFMPWZgReI3QC9W2pt =LxDT -END PGP SIGNATURE- -- 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
AW: Crafting a NOTIFY message from the command line?
> -Ursprüngliche Nachricht- > Von: bind-users Im Auftrag von Arsen > STASIC > Gesendet: Donnerstag, 21. März 2024 08:47 > An: Petr Špaček > Cc: bind-users@lists.isc.org > Betreff: Re: Crafting a NOTIFY message from the command line? > > * Petr Špaček [2024-03-20 09:32 (+0100)]: > > On 19. 03. 24 23:10, Anand Buddhdev wrote: > > > You can try something like: > > > > > > dig +norec +opcode=notify soa @server > > > > As an alternative, script > > > https://github.com/rthalley/dnspython/blob/main/examples/send_notify.py > > allows you to specify SOA serial in the NOTIFY message as well. > > As an further alternative written in perl: > https://github.com/gbxyz/pnotify One more: $ pdns_notify Syntax: pdns_notify IP_ADDRESS/HOSTNAME[:PORT] DOMAIN (from package pdns-tools) Regards Klaus -- 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: DNSSEC deployement in an isolated virtual environment
Hi Amaury. You should be able to do this by defining your own trust anchors. This should explain what you need: https://bind9.readthedocs.io/en/latest/dnssec-guide.html#trusted-keys-and-managed-keys Have fun. Greg On Sat, 16 Mar 2024 at 13:38, Amaury Van Pevenaeyge < avanpevenae...@outlook.fr> wrote: > Hello I'm a student in my last year of the Master in Cybersecurity at ULB. > As part of my thesis, I'm doing research to develop a DNS Amplification > scenario that will eventually be deployed within a Cyber Range. I have to > carry out various measurements and develop different attacks in a virtual > environment. I've already been able to set up my entire environment in > VirtualBox for DNS (i.e. without DNSSEC). Now I need to deploy DNSSEC on my > server. I've managed to generate my key pairs and sign my DNS zones. > However, when I try to do a dig from my client VM, I get a SERVFAIL. I > think this is because the chain of trust can't be established, which in my > case is perfectly normal as I'm in an isolated test environment. So how can > I deploy DNSSEC correctly so that the chain of trust is not taken into > account and it works in my virtual environment? I think I know how DNSSEC > works, but if you also have any clarification to offer, I'd be delighted to > hear from you. My BIND server runs on an Ubuntu22.04 Jammy Jellyfish VM. > > Thanks in advance for your help. > -- > 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 > -- 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: opendnssec -> inline-signing
On 08/03/2024 12:54, Randy Bush wrote: but WHY NOT? same key sets with opendnssec and inline-signing, we think. The most obvious possibility is that this is referring to a different directory to where you put the keys that you wanted to use: |key-directory "/usr/home/dns/dkeys"| I couldn't help noticing that when you ran dnssec-dsfromkey you referenced this directory: /usr/home/dns/Fixed Nick. -- 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: Bind9 "split zones"
Hi
Thanks for the quick response!
Answering the last question. There are two different systems where DNS names are generated from. One is actually phpipam where we generate entries from
and the second one is a virtualization platform, where we also dig in the DB to generate entries for VM-s
As I don't think we have had issues with PTR records so not having a "fix" is
not an issue.
In the end the solution is not use one IP range for both use cases.
Taavi Ansper
taavi.ans...@cyber.ee
On 04.03.24 19:06, Greg Choules wrote:
Hi.
If I understand you correctly, you are trying to get your resolver to go to two different places (main_hidden_dns_server and other_dns_server) for
answers to the same question, and then want it combine those answers into a single response to the client, which contains PTR records for both names?
If I got that correct, then it won't. If you want multiple PTR records to be associated with different names then they have to be in the same zone/zone
file.
A few comments:
- The statement "forward first' means, try forwarding first and only if that
fails, then try recursion.
- Adding forwarders to a secondary zone tells the server what to do for names delegated from that zone. e.g. if the zone is "example.com
<http://example.com>" and it contains "sub NS another.server.somewhere.else." then a query to it for "name.sub.example.com
<http://name.sub.example.com>" will follow the "forwarders" statement because "sub.example.com <http://sub.example.com>" has been delegated away.
- Do you really want to be forwarding to your hidden primary anyway?
- Why are two different servers both authoritative for
"100.168.192.in-addr.arpa"? That's asking for trouble.
Hope that helps.
Greg
On Mon, 4 Mar 2024 at 15:35, Taavi Ansper via bind-users mailto:bind-users@lists.isc.org>> wrote:
Hi
I am trying to understand bind9 more thorughly.
Backstory: We have been using bind9 for a long time and overhauling it
for more "usage".
We have been using a "hidden master dns" logic with views for different
usages.
E.g. Client -> Slave DNS Server <- (Transfer zones from hidden master)->
Hidden Master.
We had two views "external" and "internal" and now we added a new view
"dmz" aswell.
In one of those zones we had an interesting DNS "thingy" where for
example a CIDR 192.168.100.0/24 <http://192.168.100.0/24> was generating
entries to the main
"hidden dns" server via includes. It uses a domain called example.com
<http://example.com>.
Now another DNS server created DNS entries for the same CIDR
192.168.100.0/24 <http://192.168.100.0/24> but it had a different domain
"subdomain.example.com <http://subdomain.example.com>".
Including that info was easy.
In the Slave DNS
zone "example.com <http://example.com>" {
file blaah
type slave
masters { main_hidden_dns_server }
}
zone "subdomain.example.com <http://subdomain.example.com>" {
file blaah
type slave;
masters { other_dns_server }
}
But now comes the problem. When generating a PTR record
100.168.192.in-addr.arpa, I wish to combine both of these "results" into
one lookup. How can I do that? I tried to add:
zone "100.168.192.in-addr.arpa" {
file blaah
type slave;
masters { other_dns_server }
forward first;
forwarders { main_hidden_dns_server }
}
But this forwarding logic doesnt work. I have a feeling the forwarding
only works specific zones. and you can't combine two of the same
"names" into one. Am I correct and in order for PTR records to work I
need to get them into a single file?
--
Taavi Ansper
taavi.ans...@cyber.ee <mailto:taavi.ans...@cyber.ee>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users <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/
<https://www.isc.org/contact/> for more information.
bind-users mailing list
bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
<https://lists.isc.org/mailman/listinfo/bind-users>
--
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: Bind9 "split zones"
Hi.
If I understand you correctly, you are trying to get your resolver to go to
two different places (main_hidden_dns_server and other_dns_server) for
answers to the same question, and then want it combine those answers into a
single response to the client, which contains PTR records for both names?
If I got that correct, then it won't. If you want multiple PTR records to
be associated with different names then they have to be in the same
zone/zone file.
A few comments:
- The statement "forward first' means, try forwarding first and only if
that fails, then try recursion.
- Adding forwarders to a secondary zone tells the server what to do for
names delegated from that zone. e.g. if the zone is "example.com" and it
contains "sub NS another.server.somewhere.else." then a query to it for "
name.sub.example.com" will follow the "forwarders" statement because "
sub.example.com" has been delegated away.
- Do you really want to be forwarding to your hidden primary anyway?
- Why are two different servers both authoritative for
"100.168.192.in-addr.arpa"? That's asking for trouble.
Hope that helps.
Greg
On Mon, 4 Mar 2024 at 15:35, Taavi Ansper via bind-users <
bind-users@lists.isc.org> wrote:
> Hi
>
> I am trying to understand bind9 more thorughly.
>
> Backstory: We have been using bind9 for a long time and overhauling it
> for more "usage".
>
> We have been using a "hidden master dns" logic with views for different
> usages.
>
> E.g. Client -> Slave DNS Server <- (Transfer zones from hidden master)->
> Hidden Master.
>
> We had two views "external" and "internal" and now we added a new view
> "dmz" aswell.
>
> In one of those zones we had an interesting DNS "thingy" where for
> example a CIDR 192.168.100.0/24 was generating entries to the main
> "hidden dns" server via includes. It uses a domain called example.com.
> Now another DNS server created DNS entries for the same CIDR
> 192.168.100.0/24 but it had a different domain "subdomain.example.com".
> Including that info was easy.
>
> In the Slave DNS
>
> zone "example.com" {
> file blaah
> type slave
> masters { main_hidden_dns_server }
> }
>
> zone "subdomain.example.com" {
> file blaah
> type slave;
> masters { other_dns_server }
> }
>
> But now comes the problem. When generating a PTR record
> 100.168.192.in-addr.arpa, I wish to combine both of these "results" into
> one lookup. How can I do that? I tried to add:
>
> zone "100.168.192.in-addr.arpa" {
> file blaah
> type slave;
> masters { other_dns_server }
> forward first;
> forwarders { main_hidden_dns_server }
> }
>
> But this forwarding logic doesnt work. I have a feeling the forwarding
> only works specific zones. and you can't combine two of the same
> "names" into one. Am I correct and in order for PTR records to work I
> need to get them into a single file?
>
> --
>
> Taavi Ansper
> taavi.ans...@cyber.ee
>
> --
> 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
>
--
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
Bind9 "split zones"
Hi
I am trying to understand bind9 more thorughly.
Backstory: We have been using bind9 for a long time and overhauling it
for more "usage".
We have been using a "hidden master dns" logic with views for different
usages.
E.g. Client -> Slave DNS Server <- (Transfer zones from hidden master)->
Hidden Master.
We had two views "external" and "internal" and now we added a new view
"dmz" aswell.
In one of those zones we had an interesting DNS "thingy" where for
example a CIDR 192.168.100.0/24 was generating entries to the main
"hidden dns" server via includes. It uses a domain called example.com.
Now another DNS server created DNS entries for the same CIDR
192.168.100.0/24 but it had a different domain "subdomain.example.com".
Including that info was easy.
In the Slave DNS
zone "example.com" {
file blaah
type slave
masters { main_hidden_dns_server }
}
zone "subdomain.example.com" {
file blaah
type slave;
masters { other_dns_server }
}
But now comes the problem. When generating a PTR record
100.168.192.in-addr.arpa, I wish to combine both of these "results" into
one lookup. How can I do that? I tried to add:
zone "100.168.192.in-addr.arpa" {
file blaah
type slave;
masters { other_dns_server }
forward first;
forwarders { main_hidden_dns_server }
}
But this forwarding logic doesnt work. I have a feeling the forwarding
only works specific zones. and you can't combine two of the same
"names" into one. Am I correct and in order for PTR records to work I
need to get them into a single file?
--
Taavi Ansper
taavi.ans...@cyber.ee
--
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: fixed rrset ordering - is this still a thing?
On 02/03/2024 11:36, Greg Choules wrote: Please don't encourage using "search" in resolv.conf or the Windows equivalent. Search domains make queries take longer, impose unnecessary load on resolvers and make diagnosis of issues harder because, when users say "it doesn't work" you have no idea what it was that didn't work. This is not necessarily the case. If you are running your own recursive resolvers that hold mirrors of the root zone, and if you only have a few search domains, the impact will be negligible. Then it is a question of ergonomics. I tried using separate subdomains for different interfaces on devices once and ran into exactly that problem. There's also the overhead of maintaining more zones than you really need. Using sub-domains doesn't mean you have to create separate zones. All the example names I gave could be included in the "example.com" zone. -- 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: fixed rrset ordering - is this still a thing?
Please don't encourage using "search" in resolv.conf or the Windows equivalent. Search domains make queries take longer, impose unnecessary load on resolvers and make diagnosis of issues harder because, when users say "it doesn't work" you have no idea what it was that didn't work. I tried using separate subdomains for different interfaces on devices once and ran into exactly that problem. There's also the overhead of maintaining more zones than you really need. My suggestion would be to replace the dot with a hyphen. That is, instead of: firewall1.example.com = Internet IP address firewall1.dmz.example.com = IP address on DMZ network firewall1.management.example.com = IP address on out-of-band management network do: firewall1-internet.example.com = Internet IP address firewall1-dmz.example.com = IP address on DMZ network firewall1-management.example.com = IP address on out-of-band management network You could even CNAME firewall1 to firewall1-management as this is (presumably) the interface that users and monitoring/management tools will want to reach by default. The hostname of the box is "firewall1" but each interface on it has a unique name, derived from the hostname plus a "-" suffix. Select a set of well known and used suffixes for your environment. If someone really wants to try and SSH to the Internet interface (though I don't understand why you would), they know the hostname and they know the suffix, so it's a simple matter of combining them. On Fri, 1 Mar 2024 at 21:11, Nick Tait via bind-users < bind-users@lists.isc.org> wrote: > On 02/03/2024 03:42, Mike Mitchell via bind-users wrote: > > Our networking team is in the habit of entering the IP address of every > network interface on a router under one name. The very first address > entry is their out-of-band management interface. "rrset-order fixed" is > used on their domain for address records, so they can ssh to the router > by name reliably and not have to worry about interfaces that are down > or that filter SSH. > > I wonder if an alternative (cleaner?) solution to your use case could be > to use different sub-domains for the different networks (network > interfaces)? For example: > > firewall1.example.com = Internet IP address > firewall1.*dmz*.example.com = IP address on DMZ network > firewall1.*management*.example.com = IP address on out-of-band management > network > > If you did this you could make use of DNS search domains to allow > different parts of the network to resolve the unqualified name "firewall1" > differently. E.g. If you "ssh firewall1" from a management host it could > expand that to firewall1.*management*.example.com? > > Nick. > -- > 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 > -- 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: fixed rrset ordering - is this still a thing?
On 02/03/2024 03:42, Mike Mitchell via bind-users wrote: Our networking team is in the habit of entering the IP address of every network interface on a router under one name. The very first address entry is their out-of-band management interface. "rrset-order fixed" is used on their domain for address records, so they can ssh to the router by name reliably and not have to worry about interfaces that are down or that filter SSH. I wonder if an alternative (cleaner?) solution to your use case could be to use different sub-domains for the different networks (network interfaces)? For example: firewall1.example.com = Internet IP address firewall1./dmz/.example.com = IP address on DMZ network firewall1./management/.example.com = IP address on out-of-band management network If you did this you could make use of DNS search domains to allow different parts of the network to resolve the unqualified name "firewall1" differently. E.g. If you "ssh firewall1" from a management host it could expand that to firewall1./management/.example.com? Nick. -- 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: fixed rrset ordering - is this still a thing?
Our networking team is in the habit of entering the IP address of every network interface on a router under one name. The very first address entry is their out-of-band management interface. "rrset-order fixed" is used on their domain for address records, so they can ssh to the router by name reliably and not have to worry about interfaces that are down or that filter SSH. We also have cases where redundancy is being configured but is not yet complete. In that case only the first IP is active. If we don't use "rrset-order fixed" we get complaints that connections take too long and there must be a network error. Mike Mitchell -Original Message- From: bind-users On Behalf Of Ondrej Surý Sent: Thursday, February 29, 2024 4:40 PM To: BIND Users Mailing List Subject: fixed rrset ordering - is this still a thing? EXTERNAL Hey, BIND 9 supports a fixed rrset ordering (that is keeping the order of the RRSets from the zone file). It has to be configured at the compile time, it takes more memory (to record that order) and it's a #ifdef all over the places. So, henceforth, my question - does anyone still uses that? And if yes, what are the use cases? I think BIND is the only server that actually supports this, so it doesn't feel like the DNS can't function without it. Thanks, Ondřej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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 -- 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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
2nd $beverage consumed. I have never liked sortlist since I inherited it 16 years ago in my previous job. For me it suffers from at least one fundamental problem: - If a client, say at location "1", is given a bunch of sorted A records with the server at location "1" first, what does the client do when the server at location "1" is down? Clients come in many varieties. Some are capable of cacheing multiple answers, timing out and trying a different one, some are not. This leads to service reliability issues because, even though a perfectly healthy instance of the service may exist at site "2", clients (at site "1") are still told by DNS, go to site "1" The DNS service is not (by default) either application or client-aware. It just gives the answers you tell it to, whether they're working or not. If you want an efficient, reliable multi-site service, use load-balancers that can direct traffic from local clients to a local service instance, or use an application aware DNS server (I can think of one; I'm sure others exist) that monitors availability, delay and whatever other metrics are important and feeds the DNS resolvers with *the* answer they want them to give to a client at this moment in time. ECS would even allow said box to be aware of client location, to use as an additional metric when making this decision. In summary, Do the hard work of traffic steering somewhere else and let your DNS resolvers deliver the chosen answer. Don't make the resolvers themselves try to do this on the basis of incomplete information. On Fri, 1 Mar 2024 at 10:12, G.W. Haywood wrote: > Hi there, > > On Fri, 1 Mar 2024, Matus UHLAR wrote: > > On 01.03.24 08:24, Ond?ej Sur? wrote: > > > The "sortlist" option allows to define a complicated rules when and > > > how to reorder the resource records in the responses. The same > > > caveats as with the "rrset-order" apply - relying on any specific > > > order of resource records in the DNS responses is wrong. > > > > > > We are not aware of any other (major) DNS server that would have > > > similar behaviour as this was never specified in the DNS protocol. > > > If you know of any software or hardware relying on any specific > > > order of the resource records in the DNS messages, it needs to > > > be reported as a bug to the respective vendor. > > > > I don't know about _requirement_, but I have used this option as poor > > man's way to implement geographically local IP addresses > > - to anyone return topologically closer IP addresses first, others next. > > Maybe I need more of my morning $beverage but this sort of thing seems > to me to militate against other - existing - efficiency mechanisms. > > Network performance isn't just about topology, there are things like > performance and load to consider. Might your tweaked responses just > send clients to a nearby but tragically overloaded server? > > My preference would be to let those people whose job it is to think > about this stuff - which, reading this list, clearly they do - get on > with their job. > > Observations welcome of course. > > -- > > 73, > Ged. > -- > 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 > -- 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: fixed rrset ordering - is this still a thing?
On Fri, Mar 1, 2024 at 12:38 AM Matt Nordhoff wrote: > On Thu, Feb 29, 2024 at 9:40 PM Ondřej Surý wrote: > > Hey, > > > > BIND 9 supports a fixed rrset ordering (that is keeping the order of the > > RRSets from the zone file). It has to be configured > > at the compile time, it takes more memory (to record that order) and it's a > > #ifdef all over the places. > > > > So, henceforth, my question - does anyone still uses that? And if yes, what > > are the use cases? > > > > I think BIND is the only server that actually supports this, so it doesn't > > feel like the DNS can't function without it. > > For what it's worth, Knot DNS is fixed by default. I know because the > first setting in my knot.conf file is "answer-rotation: on". :-) Correction: It's fixed but sorted, rather than fixed in the original zone file order. Which is not necessarily the same as any of BIND's settings? I'll go hide in a cave and wish emails could be edited now. :-) > NSD also has a "round-robin" setting, which is also off by default. > > So other nameservers do support fixed order, but I personally don't > use it and don't mind if you remove it. > > > Thanks, > > Ondřej -- Matt Nordhoff -- 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: fixed rrset ordering - is this still a thing?
On Thu, Feb 29, 2024 at 9:40 PM Ondřej Surý wrote: > Hey, > > BIND 9 supports a fixed rrset ordering (that is keeping the order of the > RRSets from the zone file). It has to be configured > at the compile time, it takes more memory (to record that order) and it's a > #ifdef all over the places. > > So, henceforth, my question - does anyone still uses that? And if yes, what > are the use cases? > > I think BIND is the only server that actually supports this, so it doesn't > feel like the DNS can't function without it. For what it's worth, Knot DNS is fixed by default. I know because the first setting in my knot.conf file is "answer-rotation: on". :-) NSD also has a "round-robin" setting, which is also off by default. So other nameservers do support fixed order, but I personally don't use it and don't mind if you remove it. > Thanks, > Ondřej -- Matt Nordhoff -- 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: Deprecated DSCP support
Hi Wolfgang. Firstly let me say that I have never been a fan of QoS. So I'm slightly biased against the whole thing in the first place. But regarding your comment "It’s not easy for the network to guess the requirements of an application," I would disagree. Traffic classification and setting of DSCP values is something that edge routers have been capable of for decades. I would even argue that this is the place you *want* to do it, rather than trusting what the application itself says it wants. If you must do the whole QoS thing at all, use something like a policy-map (other manufacturers are available), match all port 53, set DSCP to an appropriate value for *your* network and prioritise/police as appropriate in the core. Cheers, Greg On Thu, 29 Feb 2024 at 09:00, Wolfgang Riedel via bind-users < bind-users@lists.isc.org> wrote: > Hi Folks, > > OK let me help you a bit as it’s really essential for DNS traffic which > need to be go through in all situations!!! > > Within the OS networking stack as also within the network there is always > a prioritisation of packets within the queues to serialise the packets of > an application to go on the wire. This prioritisation is being done based > on DSCP within a L3 domain and on COS when in a L2 domain. > > It’s not easy for the network to guess the requirements of an application, > therefore best case the application is setting the DSCP itself and the > network is just trusting the DSCP or if smart enough the checking and in > case of violation doing reclassification. > > In my case it’s dscp 24 in named.conf options but the value may be > different based on deployment scenarios and therefore needs to be a > configureable option. > > If you don't set it, it will default to 0 and all other traffic will get > higher priority. Saying if you do an ftp download with large frames, your > DNS request which will be running in parallel will not be making it through > and either get delayed or typically drooped. > > Maybe have a look at the following classification scheme: > > [image: 640px-IETF_Logo.svg.png] > > RFC 4594-Based 12-Class QoS Model > <https://www.f1-consult.com/qos/rfc4594/> > f1-consult.com <https://www.f1-consult.com/qos/rfc4594/> > <https://www.f1-consult.com/qos/rfc4594/> > > — > Hope that helps, > Wolfgang > __ > > Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559 > > > On 28. Feb 2024, at 22:01, Petr Menšík wrote: > > We may want to help fixing DSCP features, but I personally do not know any > usage, where this feature would be used and what for exactly. Recent bind9 > uses libuv to back its network core, instead of custom networking core > maintained by ISC. But I haven't found any trace of DSCP support at libuv > docs [1]. I haven't found a way to set at least type of service on UDP [2]. > > I think that would be the first place to support DSCP values for > connections or sockets. Then, once libuv can use it, its support could be > added back into named. > > It would help though if you were more verbose about why iptables cannot > replace it and what is use-case, when it is useful. Without simple > alternatives present. If you would describe it, it might motivate more > people to work on DSCP support. I haven't seen important reason, why it > needs to be done by the daemon itself. Perhaps we can find alternative way > to set DSCP tags for you, if you are more verbose about how you use it? > > Regards, > Petr > > 1. > https://docs.libuv.org/en/v1.x/search.html?q=dscp_keywords=yes=default > 2. https://docs.libuv.org/en/v1.x/udp.html > > On 28. 02. 24 13:50, Balazs Hinel (Nokia) via bind-users wrote: > > Hi, > I am working on a product in Nokia, and we currently use BIND provided by > Rocky Linux 8 with security patches. Recently the requirement came that we > should upgrade to at least 9.16. During the testing of this version we > realized that a feature we used, DSCP, has stopped working. Reading about > the topic, we found the article about it non-operational in 9.16, and > removal in 9.18. > We also saw the email on this mailing list, stating that "so far, nobody > has noticed" it is missing. Well, we noticed it just now, and I would like > to state that our product and most probably other telecom equipments using > BIND would miss it greatly. As I read in that mail, there was an > alternative plan which would re-implement this functionality. If it is > feasible, please consider doing it. The alternative options, e.g. setting > it via iptables cannot work in our use-case. > Best regards, > Balazs Hinel > > > -- > Petr Me
Re: Deprecated DSCP support
Hi Folks, OK let me help you a bit as it’s really essential for DNS traffic which need to be go through in all situations!!! Within the OS networking stack as also within the network there is always a prioritisation of packets within the queues to serialise the packets of an application to go on the wire. This prioritisation is being done based on DSCP within a L3 domain and on COS when in a L2 domain. It’s not easy for the network to guess the requirements of an application, therefore best case the application is setting the DSCP itself and the network is just trusting the DSCP or if smart enough the checking and in case of violation doing reclassification. In my case it’s dscp 24 in named.conf options but the value may be different based on deployment scenarios and therefore needs to be a configureable option. If you don't set it, it will default to 0 and all other traffic will get higher priority. Saying if you do an ftp download with large frames, your DNS request which will be running in parallel will not be making it through and either get delayed or typically drooped. Maybe have a look at the following classification scheme: https://www.f1-consult.com/qos/rfc4594/ RFC 4594-Based 12-Class QoS Model f1-consult.com — Hope that helps, Wolfgang __ Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559 > On 28. Feb 2024, at 22:01, Petr Menšík wrote: > > We may want to help fixing DSCP features, but I personally do not know any > usage, where this feature would be used and what for exactly. Recent bind9 > uses libuv to back its network core, instead of custom networking core > maintained by ISC. But I haven't found any trace of DSCP support at libuv > docs [1]. I haven't found a way to set at least type of service on UDP [2]. > > I think that would be the first place to support DSCP values for connections > or sockets. Then, once libuv can use it, its support could be added back into > named. > > It would help though if you were more verbose about why iptables cannot > replace it and what is use-case, when it is useful. Without simple > alternatives present. If you would describe it, it might motivate more people > to work on DSCP support. I haven't seen important reason, why it needs to be > done by the daemon itself. Perhaps we can find alternative way to set DSCP > tags for you, if you are more verbose about how you use it? > > Regards, > Petr > > 1. > https://docs.libuv.org/en/v1.x/search.html?q=dscp_keywords=yes=default > 2. https://docs.libuv.org/en/v1.x/udp.html > > On 28. 02. 24 13:50, Balazs Hinel (Nokia) via bind-users wrote: >> Hi, >> I am working on a product in Nokia, and we currently use BIND provided by >> Rocky Linux 8 with security patches. Recently the requirement came that we >> should upgrade to at least 9.16. During the testing of this version we >> realized that a feature we used, DSCP, has stopped working. Reading about >> the topic, we found the article about it non-operational in 9.16, and >> removal in 9.18. >> We also saw the email on this mailing list, stating that "so far, nobody >> has noticed" it is missing. Well, we noticed it just now, and I would like >> to state that our product and most probably other telecom equipments using >> BIND would miss it greatly. As I read in that mail, there was an alternative >> plan which would re-implement this functionality. If it is feasible, please >> consider doing it. The alternative options, e.g. setting it via iptables >> cannot work in our use-case. >> Best regards, >> Balazs Hinel > > -- > Petr Menšík > Software Engineer, RHEL > Red Hat, http://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > -- > 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 signature.asc Description: Message signed with OpenPGP -- 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
Deprecated DSCP support
Hi, I am working on a product in Nokia, and we currently use BIND provided by Rocky Linux 8 with security patches. Recently the requirement came that we should upgrade to at least 9.16. During the testing of this version we realized that a feature we used, DSCP, has stopped working. Reading about the topic, we found the article about it non-operational in 9.16, and removal in 9.18. We also saw the email on this mailing list, stating that "so far, nobody has noticed" it is missing. Well, we noticed it just now, and I would like to state that our product and most probably other telecom equipments using BIND would miss it greatly. As I read in that mail, there was an alternative plan which would re-implement this functionality. If it is feasible, please consider doing it. The alternative options, e.g. setting it via iptables cannot work in our use-case. Best regards, Balazs Hinel -- 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
AW: Problem upgrading to 9.18 - important feature being removed
> -Ursprüngliche Nachricht- > Von: bind-users Im Auftrag von Carsten ... > It would be nice to have a "dry-run" mode in BIND 9, where BIND 9 would > report steps it would do because of "dnssec-policy", but will not execute the > changes. If this Bind9 is only a hidden primary, disable all outgoing XFR for the respective zone, and make a copy of the Bind config and zone/journal files. That way you could test the new config and avoid leakage of broken/unwanted zones. Regards Klaus -- 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: Problem upgrading to 9.18 - important feature being removed
Hi Ondřej, > On 27. Feb 2024, at 16:43, Ondřej Surý wrote: > > Carsten, could you please fill a feature request in the GitLab? Done, #4606. Greetings Carsten -- 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: Problem upgrading to 9.18 - important feature being removed
Hi Jim, > On 27. Feb 2024, at 16:39, Jim P. via bind-users > wrote: > > There should also be an option to display the current configuration in > specific detail to easily create a new KASP (side question: why does DNS > need a new acronym?) The term “KASP” for “Key-and-signing-policy” has been around in the DNS community for many years. I remember first hearing that term when .SE (Sweden) started signing their TLD in 2005. In the beginning of DNSSEC deployment, the KASP was a document that defines how DNSSEC is implemented for a given DNS zone (that is still a good practice, writing down DNSSEC algorithms used, key sizes and rollover intervals etc). In the last years, improvements in the DNS server software (OpenDNSSEC, Knot DNS, but also BIND 9) made it possible to define the KASP in the software, which makes it easier to match the KASP document with the KASP configuration on the server itself. From my view, this is a good development. Greetings Carsten -- 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: Problem upgrading to 9.18 - important feature being removed
On Tue, 2024-02-27 at 16:06 +0100, Carsten Strotmann via bind-users wrote: > It would be nice to have a "dry-run" mode in BIND 9, where BIND 9 > would report steps it would do because of "dnssec-policy", but will > not execute the changes. **This** ^^^ There should also be an option to display the current configuration in specific detail to easily create a new KASP (side question: why does DNS need a new acronym?) I don't do DNS as a full time job, so I'm in the dark on a lot of the reasoning and needs for all these changes, BUT simple testing that I have done have shown me that dnssec-policy fails often enough that I'm planning on waiting until the last possible hour in hopes that there is better tooling and simpler documentation. Not everyone running a DNS server can afford the time to be an expert at bind9, and I doubt that ISC only wants to have bind9 used by the 42 people who are experts of bind9. -Jim P. -- 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: Problem upgrading to 9.18 - important feature being removed
Hi Matthijs, On 27 Feb 2024, at 15:54, Matthijs Mekking wrote: > - When migrating to dnssec-policy, make sure the configuration matches your > existing keys. the most problems I've seen so far have to do with this step: admins "think" they have created a configuration that matches the current keys, but they haven't (for one reason or other, it happens for me, despite working a lot with DNSSEC and BIND 9). It would be nice to have a "dry-run" mode in BIND 9, where BIND 9 would report steps it would do because of "dnssec-policy", but will not execute the changes. That way, admins can create a configuration with "dry-run" mode enabled, check the logfiles, and if the actions in the log-file match the expectations, the "dry-run" mode can be removed and the new configuration will become active. Greetings Carsten -- 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: Problem upgrading to 9.18 - important feature being removed
On 27/02/2024 13:22, Michael Sinatra wrote: On 2/26/24 13:41, Al Whaley wrote: Originally (under the above command) RR records for DNSSEC were maintained by bind, but the ZSK and KSK keys were maintained by me. This command is being discarded. I understand that bind "sort of" supports this feature in 9.18 by allowing the DNSSEC policy statement to declare unlimited lifetime, but after careful reading of the documentation and reading a number of complaints, it turns out that bind may under various circumstances decide that it is appropriate not to use existing keys and decide that it knows best, and then it makes new ones. This potential instability of course would be disastrous, and completely unnecessary. I have never experienced this, in either BIND 9.16 or BIND 9.18 (including the latter with KASP set to not rotate any keys). Can you elaborate as to where in the documentation and/or what complaints you have seen where correctly configured KASPs in 9.18.24+ decide to roll keys? I'd certainly like to know if that's the case, for reasons described below. The only example that I can recall (from this list) where this type of thing happened was where someone specified a different algorithm when transitioning to dnssec-policy. The advice for this type of situation is to transition to dnssec-policy with the same algorithm first, and make sure everything in your state files is "omnipresent", and only then update the dnssec-policy to use a different algorithm. My (somewhat uneducated) advice would also be to avoid implementing dnssec-policy if you were in the middle of a key roll-over. Not because I think it would necessarily create a problem, but more to reduce risk and make it easier to verify that nothing untoward has happened. In other words, if you aren't in the middle of a roll-over, and your current keys don't have any expiration set, then you can reconfigure your zone to use a dnssec-policy that specifies the same algorithm as what you previously had, and BIND should be happy to carry on using the existing keys -- indefinitely if you've specified an unlimited lifetime. The only difference you should notice is that after implementing dnssec-policy there are additional *.state files in your keys directory. The only other thing I'd add is that if (after transitioning to dnssec-policy) you do initiate a manual roll-over, keep an eye on your state files to verify that the new key becomes "omnipresent". This can take much longer than you might expect! For ZSK roll-overs don't be surprised if it takes 9-10 days. Also FYI for KSK (and CSK) roll-overs, you may need to run rndc commands to tell BIND when DS records are added/removed -- but that is possibly what you already do with auto-dnssec? Of course in life there are no absolute guarantees, so you should back up your configuration and make a plan to mitigate the impacts in the event that everything turns pear-shaped? Nick.-- 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
KeyTrap fix breaks resolving semi-bogus paste.debian.net/snow-crash.org
Hello, I'm not sure if this is a bug or a feature, but the recent CVE fixes prevent resolving paste.debian.net with DNSSEC validation on. It is a CNAME: $ dig +short paste.debian.net apu.snow-crash.org. p.snow-crash.org. 148.251.236.38 debian.net is fine, but snow-crash.org is misconfigured: It has an algorithm 13 DS record, is correctly signed with algorithm 13, but is also signed using algorithm 8 with signatures that expired a year ago(!). <https://dnsviz.net/d/paste.debian.net/ZczXYw/dnssec/> Other resolvers, and older versions of BIND, ignore the bad/irrelevant signatures and can still resolve the zone. With the recent CVE fixes, BIND sees the expired RRSIGs, decides it's bogus, logs the below, and returns SERVFAIL. I imagine it hits max-validation-failures-per-fetch or some internal limit. named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to bad signature (keyid=41523): RRSIG has expired named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN': 37.120.176.165#53 named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to bad signature (keyid=41523): RRSIG has expired named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN': 148.251.236.38#53 named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to bad signature (keyid=41523): RRSIG has expired named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN': 2a01:4f8:201:3437::2#53 snow-crash.org is clearly misconfigured, but resolvers usually succeed when they encounter both valid and invalid DNSSEC signatures. And this domain has no algorithm 8 DS records at all, so the signatures and keys can be ignored entirely. Regarding DoS attacks, a resolver can ignore signatures that are expired or use algorithms not included in the DS record without any expensive cryptography. I'm not necessarily saying this is a bug, but it might be an interesting data point regarding the experimental new limits, and you might want to consider changing the default or the accounting. I noticed the issue using Quad9's 9.9.9.11 DNS resolver, and then reproduced it on an Ubuntu 23.10 (amd64) VM by installing Ubuntu's bind9 1:9.18.18-0ubuntu2 package with the default configuration and then upgrading it to 1:9.18.18-0ubuntu2.1. Some copy-and-pasted information at <https://gist.github.com/mnordhoff/9286a264633fc12a262213a8d389f517>. (Since I couldn't use <https://paste.debian.net/>...) (I also did/will tell Quad9 about it for their information.) Cheers, -- Matt Nordhoff -- 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
error: 'allow-update' is not allowed in 'slave' zone
Hello,
I configured Bind 9.18.12 as slave DDNS with dynamic updates from DHCP (ISC
DHCP 4.4)
running on the same server (Ubuntu 22.04 server)
When I run "named-checkconf named.conf", I get the following error
"named.conf:2018: option 'allow-update' is not allowed in 'slave' zone
'zonename.com'"
Following is the named.conf file (part)
zone "zonename.com" {
type slave;
file "com/zonename/sec.zonename.com";
masters {
IP address;
};
allow-update {
key rndc-key;
};
allow-transfer {
IP address;
};
};
I am clueless what is going wrong. Any help is greatly appreciated
Thanks in advance,
Mounika
### Please consider the environment and print this email only if necessary . Go
Green
###
Disclaimer :
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents of this
information is strictly prohibited. The sender does not accept liability
for any errors or omissions in the contents of this message, which arise as a
result.
--
Open WebMail Project (http://openwebmail.org)
--
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: id.server on 9.18.24
Solved by adding 'server-id' to named.conf.options. Thank you Petr Špaček for the suggestion. Op 14/02/2024 om 10:23 schreef Marco Davids (SIDN): I have upgraded two servers to 9.18.24 and the funny thing is that on one server id.servers works well: ;; ANSWER SECTION: id.server. 0 CH TXT "one" And on the other it does not: ;; AUTHORITY SECTION: id.server. 86400 CH SOA id.server. hostmaster.id.server. 0 28800 7200 604800 86400 -- Marco OpenPGP_signature.asc Description: OpenPGP digital signature -- 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
id.server on 9.18.24
I have upgraded two servers to 9.18.24 and the funny thing is that on one server id.servers works well: ;; ANSWER SECTION: id.server. 0 CH TXT "one" And on the other it does not: ;; AUTHORITY SECTION: id.server. 86400 CH SOA id.server. hostmaster.id.server. 0 28800 7200 604800 86400 Also, the NSID-output is missing. I'm not sure where to look for clues as to what is actually happening, hence I'm dropping it here to check if it is just me. ANY queries give: ;; ANSWER SECTION: id.server. 0 CH TXT "xsauth" id.server. 86400 CH SOA id.server. hostmaster.id.server. 0 28800 7200 604800 86400 id.server. 0 CH NS id.server. and ;; ANSWER SECTION: id.server. 86400 CH SOA id.server. hostmaster.id.server. 0 28800 7200 604800 86400 id.server. 0 CH NS id.server. Other queries, like authors.bind, hostname.bind, version.bind, seem to work fine. -- Marco Davids Research Engineer SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 00 | www.sidnlabs.nl | Twitter: @marcodavids https://mastodon.social/@marcodavids | Matrix: @marco:sidnlabs.nl Nostr: 11ed01ff277d94705c2931867b8d900d8bacce6f27aaf7440ce98bb50e02fb34 OpenPGP_signature.asc Description: OpenPGP digital signature -- 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
dns_diff_apply / "del not exact" logging
Hi, since upgrading our secondary to 9.18.24 yesterday, I'm seeing the logging messages below. 14-Feb-2024 07:52:24.850 general: error: dns_diff_apply: wur1-ps003.ad01.geXXX/A/IN: del not exact 14-Feb-2024 07:53:28.732 general: error: dns_diff_apply: 1.0.e.4.1.1.0.0.2.ip6.arpa/SOA/IN: del not exact 14-Feb-2024 07:54:03.827 general: error: dns_diff_apply: ad01.idkXXX/RRSIG/IN: del not exact 14-Feb-2024 08:05:18.363 general: error: dns_diff_apply: HRO1-NB041.ad01.geXXX/A/IN: del not exact 14-Feb-2024 08:07:25.346 general: error: dns_diff_apply: lc7a5c2o2ur6umdqkvijckprpj74g6qr.ad01.idXXX/RRSIG/IN: del not exact 14-Feb-2024 08:17:58.873 general: error: dns_diff_apply: HRO1-NB002.ad01.geXXX/A/IN: del not exact 14-Feb-2024 08:18:34.160 general: error: dns_diff_apply: FUS1-MPC120.ad01.chXXX/A/IN: del not exact The zone names mentioned are anonymized by me. primary of each zone is some kind of windows server. Is this something to worry about? This kind of logging popped up since upgrading the secondary to 9.18.24. -- 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
RHEL, Centos, Rocky, Fedora rpm 9.18.24
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.five-ten-sg.com/mapper/bind contains links to the source rpm, and build instructions. This .src.rpm contains a .tar.gz file with the ARM documentation, so the rpm rebuild process does not need sphinx- build and associated dependencies. -BEGIN PGP SIGNATURE- iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCZcuVihUcY2FybEBmaXZl LXRlbi1zZy5jb20ACgkQL6j7milTFsEkLwCdF0KogNOgy3cYPjPU7uV7nlC8TfQA n0bzi9A+vDq3rmi69k4zLi2QVSaG =OPRR -END PGP SIGNATURE- -- 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: Answers from subzone even when superzone has a delegation elsewhere
Andy, The existence of 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa as an authoritative zone on the server has higher relevance than the delegation inside another zone. The answer comes from the authoritative zone, no need to follow the delegation. Don Friesen -Original Message- From: bind-users On Behalf Of Andy Smith Sent: Tuesday, February 13, 2024 6:46 AM To: bind-users@lists.isc.org Subject: Re: Answers from subzone even when superzone has a delegation elsewhere [You don't often get email from a...@strugglers.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] [EXTERNAL] This email came from an external source. Only open attachments or links that you are expecting from a known sender. Hi Don, Yes. If you want actual names to look at, these zones are both present on the same servers: 1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa However, the presence of 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa is a mistake and in the mean time someone has changed the delegation inside 1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa to be: 8.f.0.f NS ns-auto.bitfolk.com. A query for, say: 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa. IN PTR is answered NXDOMAIN because it does not exist inside the 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa zone file, instead of following that delegation to ns-auto.bitfolk.com. Thanks, Andy On Tue, Feb 13, 2024 at 02:31:32PM +, Friesen, Don CITZ:EX via bind-users wrote: > Andy, You do also have the A record glue for elsewhere.example.com in the > example.com zone, right? Just checking. > > Don Friesen -- 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 -- 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: Answers from subzone even when superzone has a delegation elsewhere
Andy, You do also have the A record glue for elsewhere.example.com in the example.com zone, right? Just checking. Don Friesen -Original Message- From: bind-users On Behalf Of Andy Smith Sent: Tuesday, February 13, 2024 6:23 AM To: bind-users@lists.isc.org Subject: Answers from subzone even when superzone has a delegation elsewhere [You don't often get email from a...@strugglers.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] [EXTERNAL] This email came from an external source. Only open attachments or links that you are expecting from a known sender. Hi, I'm running: 9.16.44-Debian (Extended Support Version) If I have zones example.com and sub.example.com both loaded, but example.com contains a record: sub.example.com. NS elsewhere.example.com. (i.e. the subzone is delegated to some other server) is it normal and expected that a query for foo.sub.example.com should be answered NXDOMAIN from the auth servers for example.com because the zone sub.example.com is also loaded there (and has no "foo" RR), rather than the delegation to elsewhere.example.com be followed? If that is expected, is there configuration that can alter that behaviour, or is that RFC required behaviour that should not be altered? Thanks, Andy -- 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 -- 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
How to use different views on DNS-over-HTTPS vs normal DNS on port 53
Hello, How can I configure BIND9 to reply to requests from DNS-over-HTTPS with view A, and if the requests is from normal DNS on port 53, reply with view B? Example: client 192.168.1.5 requests A record test.example.com with DNS over HTTPS, BIND should reply with view A client 192.168.1.5 requests A record test.example.com with DNS on port 53, BIND should reply with view B -- 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
Running systems for years without restart (was: I am provoked ...)
* Tim Daneliuk via bind-users: > But it did "provoke" a question. Does anyone think not restarting > *anything* for 10 years is a good idea? This isn't really BIND-related, so a different mailing list might be better suited for discussing the issue of ultra high availability. If you are interested, I can recommend looking into the amazing stuff Erlang based system can do (see https://www.erlang.org/). It includes software updates without taking down or blocking the system. I find the subject quite fascinating. -Ralph -- 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: I am provoked by ISC for the 10 years statement that ISC refuse to fulfill (Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?)
On 2/11/24 02:07, Ole Aamot wrote: "This whole “we support everything for 10 years” is just a sales pitch, not a something that can be fulfilled." – Ondřej Surý — ISC I realize that there was a whole kerfuffle here that I mercifully missed and have absolutely no interest in. But it did "provoke" a question. Does anyone think not restarting *anything* for 10 years is a good idea? I realize there were all these fanbois back in the day that wanted to prove *NIX could stay up longer and with greater stability than Windows. But best practices would suggest that you patch and restart monthly at a minimum and more often for zero-days and more immediate threats. I would include among this the OS itself as well as key infrastructure services. Oh, and for the record, I think ISC does a very fine job ;) -- 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: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?
Thank you for the detailed explanation! This is what I was wondering. All the dnssec configuration(s) only need to reside on the master then, correct? Looks like it a got a little clean-up to do. Appreciate everyones insight with this! ~Jordan On 2/9/24, 8:44 AM, "Björn Persson" wrote: Jordan Larson via bind-users wrote: > Was I wrong to enable “inline-signing yes” for my slave zones? I would assume > each slave would need its own DS key? Can I do that? That sounds very wrong. Your zone shall have one DNSsec key, or set of keys, that is the same on all slave servers. A client shall see the same set of DNSKEY records regardless of which DNS server it queries. If you sign the zone on the master, then you shouldn't sign it again on the slaves. The slaves shall receive RRSIG records from the master just like any other records, and serve them to clients. Only the master has the secret keys. If the master can't sign for some reason, then you can do "bump in the wire" signing: A single signing server receives the unsigned zone from the hidden master over a secure link, signs it, and distributes the signed zone to multiple slaves. Only the signing server has the secret keys. That way there's still a single consistent set of DNSKEY records. If you need to give different answers to different clients, then you configure separate views, and you must ensure that each client sees the same view – including the same keys – on all DNS servers it can query. Björn Persson -- 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: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?
Couple of things... Use the words Primary and Secondary... don't use Master and Slave - as it upsets many people. (I teach DNS/DNSSEC and still say dumb things at times, and I live in South Africa) The Secondary Nameservers should not have any additional DNSSEC configurations if the Primary is doing all the DNSSEC signing, and it sounds like the Primary is working fine from a DNSSEC point of view. You want the Secondaries to simply give the same responses (e.g. the same DNSKEY records) when queried - not a bunch of variations depending on who is asked. On the Primary Nameserver - there should now be some CDS records, or at least one. This should become the DS record in the Parent zone. Try and update the BIND software on all your servers to something that is supported by the community. There is no time delay required for this, just do it. (I've read the other comments regarding this and agree with them). Using Algorithm 13 is a good choice - well done. You only need to provide the (C)DS SHA-256 version (digest type 2) to the parent After providing the parent zone with the correct DS record, you then may need to tell the Primary nameserver that you have done this. On 2024/02/08 21:56, Jordan Larson via bind-users wrote: Greetings! I have what is hopefully a simple question regarding proper setup around DNS. I feel somewhat comfortable navigating around BIND but possibly am getting confused around the DNSSEC portion. This is for an internally facing DNS, not exposed to the internet. High level setup is as follows: We have 1 master/primary and 4 slaves/secondaries. These are running Ubuntu 20.04 with OS installed BIND (9.16.1). Any DNS updates/changes are made on the stealth master and the zones are propagated to the slaves and entries are added and removed. Slaves handle all DNS requests and forward out to google for any externally facing DNS requests. I have the dnssec-policy set to default on the master AND slaves at the global level via the named.conf.options. While reviewing the following doc https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy#ksk-rollover <https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy#ksk-rollover> it appeared that perhaps I was missing a critical settings for inline-signing set to yes for all of the zones on the slaves/secondaries. This is a recent addition as of a few days ago. I now have that set. While watching the key state and waiting for all them to go to omnipresent I noticed that DSState has been sitting at rumored for over 48+ hours. I saw this very helpful mailing list thread: https://lists.isc.org/pipermail/bind-users/2022-May/106182.html <https://lists.isc.org/pipermail/bind-users/2022-May/106182.html> I was hopeful that after 26 hours (default settings) that this would eventually roll over to omnipresent. However upon reading further down in the first link it makes mention of the following: “DSState stuck in rumoured? If you see the DSState stuck in rumoured after the migration, you need to run rndc dnssec -checkds published example.com to tell BIND that the DS is already published in the parent zone. Be sure and confirm that the DS has actually been published before performing the command (see KSK rollover for details about checking the DS state).” On my hidden master: root@master:~# cat /var/cache/bind/Kexample.com.+013+64370.state ; This is the state of key 64370, for example.com. Algorithm: 13 Length: 256 Lifetime: 0 KSK: yes ZSK: yes Generated: 20231117041456 (Fri Nov 17 04:14:56 2023) Published: 20231117041456 (Fri Nov 17 04:14:56 2023) Active: 20231117041456 (Fri Nov 17 04:14:56 2023) DNSKEYChange: 20231117061956 (Fri Nov 17 06:19:56 2023) ZRRSIGChange: 20231118051956 (Sat Nov 18 05:19:56 2023) KRRSIGChange: 20231117061956 (Fri Nov 17 06:19:56 2023) DSChange: 20231120071956 (Mon Nov 20 07:19:56 2023) DNSKEYState: omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent DSState: omnipresent GoalState: omnipresent Slaves can query the master (nothing else can and recursion is also off). If I do a check for the key, I can see it here: root@slave1:~# dig @10.0.0.20 example.com DNSKEY +multiline ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.0.20 example.com DNSKEY +multiline ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48018 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 766c81fa38f5d458010065c52a97cbca37018dd97375 (good) ;; QUESTION SECTION: ;example.com. IN DNSKEY ;; ANSWER SECTION: example.com. 3600 IN DNSKEY 257 3 13 ( rvOPupnLJkkYyrVI9dr7EygIBF3yLLnjR1UIpIj7+Wcy MeoUVuCY0lAEkOlseCm5d0RGlBtOXC6gpV6SZuFwRg== ) ; KSK; alg = ECDSAP256SHA256 ; key id = 64370 ;; Query time: 0 msec
Re: acl in also-nofify
Hi both.
You can't do it using ACLs. But you can do it using primaries. This is
hinted at in the section about the primaries statement, but not clearly
expanded on.
For example:
# define a primaries list called "also-notifed" (or anything you like).
Define as many lists as you need.
primaries also-notified {a.b.c.d; e.f.g.h;};
...
zone "example.com {
type primary;
file "db.example.com";
# apply the primaries list (or lists) to the also-notify statement.
also-notify {also-notified;};
};
I hope that helps.
Cheers, Greg
On Thu, 8 Feb 2024 at 21:55, Elmar K. Bins wrote:
> Randy,
>
> ra...@psg.com (Randy Bush) wrote:
>
> > can i use an acl{} or other macro in `also-notify`? i have a bunch of
> > zones where i want the same `also-notify` list.
>
> Been running into the same issue and tried to find out. My master lists
> and acls
> are identical as yours seem to be. I've been told that internally they are
> very
> different and handled differently, so I had to duplicate my work (yes,
> they're
> copy+paste for me) :-(
>
> Best,
> Elmar.
>
>
> --
> 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
>
--
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: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?
Thanks for the recommendation. I will step up to the latest 9.16.X and then 9.18.X and then reassess. Is there any period I should wait between 9.16 and the 9.18 update? Thanks! From: Ondřej Surý Date: Thursday, February 8, 2024 at 2:18 PM To: Jordan Larson Cc: bind-users@lists.isc.org Subject: Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys? 9.16.1 has bugs that have been fixed in more recent releases. There’s no point in trying to even start thinking what could be wrong in something old as this. It would be just a waste of time on both sides. You can do the upgrades in lockstep - first upgrade to latest 9.16 and then to latest 9.18 if that helps. Alternatively, you can bug Ubuntu to provide you with fixed packages ;). This whole “we support everything for 10 years” is just a sales pitch, not a something that can be fulfilled. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. On 8. 2. 2024, at 21:12, Jordan Larson wrote: This is/was the plan when I move to 22.04. I did a quick test of this (inplace upgrade to 22.04) but the slaves blew up because I didn’t have inline-signing set to yes on the zones. I rolled my snapshots back and figured I should sort this first. Is this issue easier to sort out on 9.18.x? If so I can do that but I was attempting to sort my issues before I attempt an upgrade. Thanks! Jordan From: Ondřej Surý Date: Thursday, February 8, 2024 at 2:03 PM To: Jordan Larson Cc: bind-users@lists.isc.org Subject: Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys? I would recommend to start with upgrading BIND (9.16.1) to a version: - that's not 4 years old - that's not going to be EOL in just couple of weeks e.g. latest 9.18.x version. ISC provides PPA for BIND 9.18 here: https://launchpad.net/~isc/+archive/ubuntu/bind Ondřej. -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 8. 2. 2024, at 20:56, Jordan Larson via bind-users > wrote: > > Greetings! > I have what is hopefully a simple question regarding proper setup around > DNS. I feel somewhat comfortable navigating around BIND but possibly am > getting confused around the DNSSEC portion. > This is for an internally facing DNS, not exposed to the internet. > High level setup is as follows: > We have 1 master/primary and 4 slaves/secondaries. These are running Ubuntu > 20.04 with OS installed BIND (9.16.1). > Any DNS updates/changes are made on the stealth master and the zones are > propagated to the slaves and entries are added and removed. Slaves handle all > DNS requests and forward out to google for any externally facing DNS requests. > I have the dnssec-policy set to default on the master AND slaves at the > global level via the named.conf.options. > While reviewing the following doc > https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy#ksk-rollover it > appeared that perhaps I was missing a critical settings for inline-signing > set to yes for all of the zones on the slaves/secondaries. This is a recent > addition as of a few days ago. I now have that set. > While watching the key state and waiting for all them to go to omnipresent I > noticed that DSState has been sitting at rumored for over 48+ hours. > I saw this very helpful mailing list thread: > https://lists.isc.org/pipermail/bind-users/2022-May/106182.html > I was hopeful that after 26 hours (default settings) that this would > eventually roll over to omnipresent. However upon reading further down in the > first link it makes mention of the following: > “DSState stuck in rumoured? > If you see the DSState stuck in rumoured after the migration, you need to run > rndc dnssec -checkds published example.com to tell BIND that the DS is > already published in the parent zone. Be sure and confirm that the DS has > actually been published before performing the command (see KSK rollover for > details about checking the DS state).” > On my hidden master: > root@master:~# cat /var/cache/bind/Kexample.com.+013+64370.state > ; This is the state of key 64370, for example.com. > Algorithm: 13 > Length: 256 > Lifetime: 0 > KSK: yes > ZSK: yes > Generated: 20231117041456 (Fri Nov 17 04:14:56 2023) > Published: 20231117041456 (Fri Nov 17 04:14:56 2023) > Active: 20231117041456 (Fri Nov 17 04:14:56 2023) > DNSKEYChange: 20231117061956 (Fri Nov 17 06:19:56 2023) > ZRRSIGChange: 20231118051956 (Sat Nov 18 05:19:56 2023) > KRRSIGChange: 20231117061956 (Fri Nov 17 06:19:56 2023) > DSChange: 20231120071956 (Mon Nov 20 07:19:56 2023) > DNSKEYState: omnipresent > ZRRSIGSta
Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?
This is/was the plan when I move to 22.04. I did a quick test of this (inplace upgrade to 22.04) but the slaves blew up because I didn’t have inline-signing set to yes on the zones. I rolled my snapshots back and figured I should sort this first. Is this issue easier to sort out on 9.18.x? If so I can do that but I was attempting to sort my issues before I attempt an upgrade. Thanks! Jordan From: Ondřej Surý Date: Thursday, February 8, 2024 at 2:03 PM To: Jordan Larson Cc: bind-users@lists.isc.org Subject: Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys? I would recommend to start with upgrading BIND (9.16.1) to a version: - that's not 4 years old - that's not going to be EOL in just couple of weeks e.g. latest 9.18.x version. ISC provides PPA for BIND 9.18 here: https://launchpad.net/~isc/+archive/ubuntu/bind Ondřej. -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 8. 2. 2024, at 20:56, Jordan Larson via bind-users > wrote: > > Greetings! > I have what is hopefully a simple question regarding proper setup around > DNS. I feel somewhat comfortable navigating around BIND but possibly am > getting confused around the DNSSEC portion. > This is for an internally facing DNS, not exposed to the internet. > High level setup is as follows: > We have 1 master/primary and 4 slaves/secondaries. These are running Ubuntu > 20.04 with OS installed BIND (9.16.1). > Any DNS updates/changes are made on the stealth master and the zones are > propagated to the slaves and entries are added and removed. Slaves handle all > DNS requests and forward out to google for any externally facing DNS requests. > I have the dnssec-policy set to default on the master AND slaves at the > global level via the named.conf.options. > While reviewing the following doc > https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy#ksk-rollover it > appeared that perhaps I was missing a critical settings for inline-signing > set to yes for all of the zones on the slaves/secondaries. This is a recent > addition as of a few days ago. I now have that set. > While watching the key state and waiting for all them to go to omnipresent I > noticed that DSState has been sitting at rumored for over 48+ hours. > I saw this very helpful mailing list thread: > https://lists.isc.org/pipermail/bind-users/2022-May/106182.html > I was hopeful that after 26 hours (default settings) that this would > eventually roll over to omnipresent. However upon reading further down in the > first link it makes mention of the following: > “DSState stuck in rumoured? > If you see the DSState stuck in rumoured after the migration, you need to run > rndc dnssec -checkds published example.com to tell BIND that the DS is > already published in the parent zone. Be sure and confirm that the DS has > actually been published before performing the command (see KSK rollover for > details about checking the DS state).” > On my hidden master: > root@master:~# cat /var/cache/bind/Kexample.com.+013+64370.state > ; This is the state of key 64370, for example.com. > Algorithm: 13 > Length: 256 > Lifetime: 0 > KSK: yes > ZSK: yes > Generated: 20231117041456 (Fri Nov 17 04:14:56 2023) > Published: 20231117041456 (Fri Nov 17 04:14:56 2023) > Active: 20231117041456 (Fri Nov 17 04:14:56 2023) > DNSKEYChange: 20231117061956 (Fri Nov 17 06:19:56 2023) > ZRRSIGChange: 20231118051956 (Sat Nov 18 05:19:56 2023) > KRRSIGChange: 20231117061956 (Fri Nov 17 06:19:56 2023) > DSChange: 20231120071956 (Mon Nov 20 07:19:56 2023) > DNSKEYState: omnipresent > ZRRSIGState: omnipresent > KRRSIGState: omnipresent > DSState: omnipresent > GoalState: omnipresent > Slaves can query the master (nothing else can and recursion is also off). If > I do a check for the key, I can see it here: > root@slave1:~# dig @10.0.0.20 example.com DNSKEY +multiline > ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.0.20 example.com DNSKEY +multiline > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48018 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: 766c81fa38f5d458010065c52a97cbca37018dd97375 (good) > ;; QUESTION SECTION: > ;example.com. IN DNSKEY > ;; ANSWER SECTION: > example.com.3600 IN DNSKEY 257 3 13 ( > > rvOPupnLJkkYyrVI9dr7EygIBF3yLLnjR1UIpIj7+Wcy >
DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?
Greetings! I have what is hopefully a simple question regarding proper setup around DNS. I feel somewhat comfortable navigating around BIND but possibly am getting confused around the DNSSEC portion. This is for an internally facing DNS, not exposed to the internet. High level setup is as follows: We have 1 master/primary and 4 slaves/secondaries. These are running Ubuntu 20.04 with OS installed BIND (9.16.1). Any DNS updates/changes are made on the stealth master and the zones are propagated to the slaves and entries are added and removed. Slaves handle all DNS requests and forward out to google for any externally facing DNS requests. I have the dnssec-policy set to default on the master AND slaves at the global level via the named.conf.options. While reviewing the following doc https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy#ksk-rollover it appeared that perhaps I was missing a critical settings for inline-signing set to yes for all of the zones on the slaves/secondaries. This is a recent addition as of a few days ago. I now have that set. While watching the key state and waiting for all them to go to omnipresent I noticed that DSState has been sitting at rumored for over 48+ hours. I saw this very helpful mailing list thread: https://lists.isc.org/pipermail/bind-users/2022-May/106182.html I was hopeful that after 26 hours (default settings) that this would eventually roll over to omnipresent. However upon reading further down in the first link it makes mention of the following: “DSState stuck in rumoured? If you see the DSState stuck in rumoured after the migration, you need to run rndc dnssec -checkds published example.com to tell BIND that the DS is already published in the parent zone. Be sure and confirm that the DS has actually been published before performing the command (see KSK rollover for details about checking the DS state).” On my hidden master: root@master:~# cat /var/cache/bind/Kexample.com.+013+64370.state ; This is the state of key 64370, for example.com. Algorithm: 13 Length: 256 Lifetime: 0 KSK: yes ZSK: yes Generated: 20231117041456 (Fri Nov 17 04:14:56 2023) Published: 20231117041456 (Fri Nov 17 04:14:56 2023) Active: 20231117041456 (Fri Nov 17 04:14:56 2023) DNSKEYChange: 20231117061956 (Fri Nov 17 06:19:56 2023) ZRRSIGChange: 20231118051956 (Sat Nov 18 05:19:56 2023) KRRSIGChange: 20231117061956 (Fri Nov 17 06:19:56 2023) DSChange: 20231120071956 (Mon Nov 20 07:19:56 2023) DNSKEYState: omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent DSState: omnipresent GoalState: omnipresent Slaves can query the master (nothing else can and recursion is also off). If I do a check for the key, I can see it here: root@slave1:~# dig @10.0.0.20 example.com DNSKEY +multiline ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.0.20 example.com DNSKEY +multiline ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48018 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 766c81fa38f5d458010065c52a97cbca37018dd97375 (good) ;; QUESTION SECTION: ;example.com. IN DNSKEY ;; ANSWER SECTION: example.com.3600 IN DNSKEY 257 3 13 ( rvOPupnLJkkYyrVI9dr7EygIBF3yLLnjR1UIpIj7+Wcy MeoUVuCY0lAEkOlseCm5d0RGlBtOXC6gpV6SZuFwRg== ) ; KSK; alg = ECDSAP256SHA256 ; key id = 64370 ;; Query time: 0 msec ;; SERVER: 10.0.0.20#53(10.4.2.36) ;; WHEN: Thu Feb 08 19:25:11 UTC 2024 ;; MSG SIZE rcvd: 152 Since I enabled inline-signing on my slaves I also have a key there now: root@slave1:~# cat /var/cache/bind/Kexample.com.+013+12698.state ; This is the state of key 12698, for example.com. Algorithm: 13 Length: 256 Lifetime: 0 KSK: yes ZSK: yes Generated: 20240206042516 (Tue Feb 6 04:25:16 2024) Published: 20240206042516 (Tue Feb 6 04:25:16 2024) Active: 20240206042516 (Tue Feb 6 04:25:16 2024) DNSKEYChange: 20240206063016 (Tue Feb 6 06:30:16 2024) ZRRSIGChange: 20240207053017 (Wed Feb 7 05:30:17 2024) KRRSIGChange: 20240206063016 (Tue Feb 6 06:30:16 2024) DSChange: 20240207053017 (Wed Feb 7 05:30:17 2024) DNSKEYState: omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent DSState: rumoured GoalState: omnipresent I feel like that I might be stuck here and some sort of manual intervention is required? Am I not patient enough? Also some of the “rndc dnssec” commands don’t exist in 9.16 which make it harder to follow some of the examples. Was I wrong to enable “inline-signing yes” for my slave zones? I would assume each slave would need its own DS key? Can I do that? Trying to sort through some of this before I start cutting clients over.
feature request for improving named-compilezone
Hi, How hard would it be to let named-compilezone keep any remarks that are present in the source file? Because now it strips them and that is problematic. -- Marco OpenPGP_signature.asc Description: OpenPGP digital signature -- 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: Question about authoritative server and AA Authoritative Answer
Dear Greg, Björn Persson gave a reply with seems satisfying. With dig +norecurse I always get "AUTHORITY: 1". For the sake of comprehensiveness, please find attached the files you asked for. De : "Greg Choules" A : pub.dieme...@laposte.net,ma...@isc.org,bind-users@lists.isc.org Envoyé: mercredi 17 Janvier 2024 16:00 Objet : Re: Question about authoritative server and AA Authoritative Answer Hi again. Please start a packet capture on the auth server. This should do it: sudo tcpdump -nvi any -c 1 -w mydns.pcap port 53 Then from pc1, please do these and copy/paste text output, not screenshots: dig @172.16.0.254 pc1.reseau1.lan NS +norecurse dig @172.16.0.254 pc1.reseau1.lan SOA +norecurse dig @172.16.0.254 pc1.reseau1.lan A +norecurse dig @172.16.0.254 pc1.reseau1.lan +norecurse Now stop the packet capture on the auth server and send all the information. The reason for using @ with dig is to eliminate the stub resolver on pc1 itself. Thanks, Greg On Wed, 17 Jan 2024 at 12:59, wrote: Dear Greg, Dear Mark, Once more thank you for your replies. Please see highlighted words below. I confirm that 172.16.0.254 is the dns authoritative server. 'pc1' means 'a generic computer on a local area network'. It could be a web server, a file server, a mail server. For a small structure with fixed ip addresses only, it could be a user's pc. On pc1 there is a fresh install of ubuntu 22.04 with only a few network settings (dhcp, dns, gateway). I created it only to test various network settings (dynamic dns, fixed ip address, dhcp provided ip address, ...). For this specific question about authoritative server, pc1 has a fixed ip address. Ubuntu's networkd-resolved local dns caching and stub is disabled, (Cache=no, DNSStubListener=no). For this specific question, I have only two computers, one authoritative non-recursive dns server and a generic computer named pc1. Please have a look at the highlighted text below to understand my question : Command dig pc1.reseau1.lan ns ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56002 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 AUTHORITY: 1 : this is ok. Command dig pc1.reseau1.lan ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 Why AUTHORITY: 0 and not AUTHORITY: 1 ??? De : "Greg Choules" A : pub.dieme...@laposte.net,bind-users@lists.isc.org Envoyé: lundi 15 Janvier 2024 18:27 Objet : Re: Question about authoritative server and AA Authoritative Answer Hi again and thanks for that. I'm still not exactly clear on the setup. I think the auth server is 172.16.0.254 (I don't know what pc1 is). But anyway, looking at your results I see the AA bit for everything. It appears that these queries both went directly to the auth server because recursion is disabled and it told you so. == # pc1@pc1:~ dig pc1.reseau1.lan ``` ```txt ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available # ns1@ns1:~ dig pc1.reseau1.lan ``` ```txt ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2379 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available == So unless I'm missing something I don't see your problem. Cheers, Greg On Mon, 15 Jan 2024 at 15:24, wrote: Dear Greg, Thank you for your reply. Please find attached the markdown file with all the commands and text from the terminal. In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener from systemd-resolved. I have netplan and networkd. Kind Regards, Michel Diemer. De : "Greg Choules" A : pub.dieme...@laposte.net,bind-users@lists.isc.org Envoyé: dimanche 14 Janvier 2024 23:28 Objet : Re: Question about authoritative server and AA Authoritative Answer Hi Michel. Please can you send the following information: - name and IP address of the authoritative server - the full contents of the zone file for "reseau1.lan" - name and IP address of the other server - what does this server do? - What is the machine "pc1", on which you are running the digs? - the file "/etc/resolv.conf" on "pc1" Please also re-send the digs with full output. When you send information, please send it as text, not screenshots. Thanks, Greg On Sun, 14 Jan 2024 at 22:04, Michel Diemer
Re: Question about authoritative server and AA Authoritative Answer
Hi again. Please start a packet capture on the auth server. This should do it: sudo tcpdump -nvi any -c 1 -w mydns.pcap port 53 Then from pc1, please do these and copy/paste text output, not screenshots: dig @172.16.0.254 pc1.reseau1.lan NS +norecurse dig @172.16.0.254 pc1.reseau1.lan SOA +norecurse dig @172.16.0.254 pc1.reseau1.lan A +norecurse dig @172.16.0.254 pc1.reseau1.lan +norecurse Now stop the packet capture on the auth server and send all the information. The reason for using @ with dig is to eliminate the stub resolver on pc1 itself. Thanks, Greg On Wed, 17 Jan 2024 at 12:59, wrote: > > > Dear Greg, > Dear Mark, > > Once more thank you for your replies. Please see highlighted words below. > > I confirm that 172.16.0.254 is the dns authoritative server. > > 'pc1' means 'a generic computer on a local area network'. It could be a > web server, a file server, a mail server. For a small structure with fixed > ip addresses only, it could be a user's pc. On pc1 there is a fresh install > of ubuntu 22.04 with only a few network settings (dhcp, dns, gateway). I > created it only to test various network settings (dynamic dns, fixed ip > address, dhcp provided ip address, ...). > > For this specific question about authoritative server, pc1 has a fixed ip > address. Ubuntu's networkd-resolved local dns caching and stub is disabled, > (Cache=no, DNSStubListener=no). For this specific question, I have only > two computers, one authoritative non-recursive dns server and a generic > computer named pc1. > > > Please have a look at the highlighted text below to understand my question > : > > Command dig pc1.reseau1.lan *ns* > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56002 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > *AUTHORITY: 1 : this is ok.* > > > Command dig pc1.reseau1.lan > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > *Why AUTHORITY: 0 and not AUTHORITY: 1 ???* > > De : "Greg Choules" > A : pub.dieme...@laposte.net,bind-users@lists.isc.org > Envoyé: lundi 15 Janvier 2024 18:27 > Objet : Re: Question about authoritative server and AA Authoritative Answer > > Hi again and thanks for that. > I'm still not exactly clear on the setup. I think the auth server is > 172.16.0.254 (I don't know what pc1 is). > But anyway, looking at your results I see the AA bit for everything. It > appears that these queries both went directly to the auth server because > recursion is disabled and it told you so. > > == > > # pc1@pc1:~ > dig pc1.reseau1.lan > ``` > > ```txt > ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > # ns1@ns1:~ > dig pc1.reseau1.lan > ``` > > ```txt > ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2379 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > == > > So unless I'm missing something I don't see your problem. > Cheers, Greg > > On Mon, 15 Jan 2024 at 15:24, wrote: > >> Dear Greg, >> >> Thank you for your reply. >> >> >> Please find attached the markdown file with all the commands and text >> from the terminal. >> >> In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener >> from systemd-resolved. I have netplan and networkd. >> >> >> Kind Regards, >> >> Michel Diemer. >> >> >> >> De : "Greg Choules" >> A : pub.dieme...@laposte.net,bind-users@lists.isc.org >> Envoyé: dimanche 14 Janvier 2024 23:28 >> Objet : Re: Question about authoritative server and AA Authoritative >> Answer >> >> Hi Michel. >> Please can you send the following information: >> - name and IP address of the authoritative server >> - the full contents of the zone file for "reseau1.lan" >> - name and IP address of the other server - what does this server do? >> - What is the machine "pc1", on which you are running the digs? >> - the file "/etc/resolv.conf" on "pc1" >> >> Please also re-send the digs with
Re: Question about authoritative server and AA Authoritative Answer
Dear Greg, Dear Mark, Once more thank you for your replies. Please see highlighted words below. I confirm that 172.16.0.254 is the dns authoritative server. 'pc1' means 'a generic computer on a local area network'. It could be a web server, a file server, a mail server. For a small structure with fixed ip addresses only, it could be a user's pc. On pc1 there is a fresh install of ubuntu 22.04 with only a few network settings (dhcp, dns, gateway). I created it only to test various network settings (dynamic dns, fixed ip address, dhcp provided ip address, ...). For this specific question about authoritative server, pc1 has a fixed ip address. Ubuntu's networkd-resolved local dns caching and stub is disabled, (Cache=no, DNSStubListener=no). For this specific question, I have only two computers, one authoritative non-recursive dns server and a generic computer named pc1. Please have a look at the highlighted text below to understand my question : Command dig pc1.reseau1.lan ns ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56002 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 AUTHORITY: 1 : this is ok. Command dig pc1.reseau1.lan ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 Why AUTHORITY: 0 and not AUTHORITY: 1 ??? De : "Greg Choules" A : pub.dieme...@laposte.net,bind-users@lists.isc.org Envoyé: lundi 15 Janvier 2024 18:27 Objet : Re: Question about authoritative server and AA Authoritative Answer Hi again and thanks for that. I'm still not exactly clear on the setup. I think the auth server is 172.16.0.254 (I don't know what pc1 is). But anyway, looking at your results I see the AA bit for everything. It appears that these queries both went directly to the auth server because recursion is disabled and it told you so. == # pc1@pc1:~ dig pc1.reseau1.lan ``` ```txt ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available # ns1@ns1:~ dig pc1.reseau1.lan ``` ```txt ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2379 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available == So unless I'm missing something I don't see your problem. Cheers, Greg On Mon, 15 Jan 2024 at 15:24, wrote: Dear Greg, Thank you for your reply. Please find attached the markdown file with all the commands and text from the terminal. In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener from systemd-resolved. I have netplan and networkd. Kind Regards, Michel Diemer. De : "Greg Choules" A : pub.dieme...@laposte.net,bind-users@lists.isc.org Envoyé: dimanche 14 Janvier 2024 23:28 Objet : Re: Question about authoritative server and AA Authoritative Answer Hi Michel. Please can you send the following information: - name and IP address of the authoritative server - the full contents of the zone file for "reseau1.lan" - name and IP address of the other server - what does this server do? - What is the machine "pc1", on which you are running the digs? - the file "/etc/resolv.conf" on "pc1" Please also re-send the digs with full output. When you send information, please send it as text, not screenshots. Thanks, Greg On Sun, 14 Jan 2024 at 22:04, Michel Diemer via bind-users wrote: Ders bind users, I have already asked a similar question which was more about DNS in general , this one is very specific about the AA bit. Today's question is : « "dig pc1.reseau1.lan ns" show AUTHORITY: 1 and "dig pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I missing ? If possible, how to get AA answers for QNAME queries ? » I have set up two virtual machines on a virtual local network using Oracle VirtualBox. One machine is a DNS authoritative-only server. The zone is named "reseau1.lan" and defined only in bind9 zone files. If I really have to, I will name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan inspired by RFC 6762 appendix G). The IP address of the DNS server is 172.16.0.254 and the IP address of pc1 is 172.16.0.21. dig soa reseau1.lan : the AA bit is set, which is what I am looking for ͏ ͏ ͏ dig pc1.reseau1.lan ns : the AA bit is set ͏ ͏ ͏ ͏ dig pc1.reseau1.lan : the AA bit is not set. Why ? Which setting or knowledge am I missing ?
DiG DoH TLS Error
Hello, I am trying to resolve a DNS record with DNS over HTTPS with DiG on our DNS server. However DiG is returning a TLS error. See following anonymized result ➜ dig +trace +https @dns.example.com www.example.com ;; Connection to 192.168.132.5#443(192.168.132.5) for www.example.com failed: TLS error. ;; no servers could be reached ;; Connection to 192.168.132.5#443(192.168.132.5) for www.example.com failed: TLS error. ;; no servers could be reached ;; Connection to 192.168.132.5#443(192.168.132.5) for www.example.com failed: TLS error. ;; no servers could be reached I can confirm that the server can be reached and with openssl s_client -connect, the certificate returned OK result Connecting to 192.168.132.5 CONNECTED(0003) depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1 verify return:1 depth=1 C=US, O=Let's Encrypt, CN=R3 verify return:1 depth=0 CN=*.example.com verify return:1 --- Certificate chain 0 s:CN=*.example.com i:C=US, O=Let's Encrypt, CN=R3 a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256 v:NotBefore: Jan 2024 GMT; NotAfter: Apr 2024 GMT 1 s:C=US, O=Let's Encrypt, CN=R3 i:C=US, O=Internet Security Research Group, CN=ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT --- Server certificate -BEGIN CERTIFICATE- -END CERTIFICATE- subject=CN=*.example.com issuer=C=US, O=Let's Encrypt, CN=R3 --- No client certificate CA names sent Peer signing digest: SHA384 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 2816 bytes and written 392 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256 Server public key is 384 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher: TLS_AES_128_GCM_SHA256 Session-ID: Session-ID-ctx: Resumption PSK: PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 604800 (seconds) TLS session ticket: . Start Time: 1705398062 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK Any idea what is causing the TLS error? -- 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: Question about authoritative server and AA Authoritative Answer
Hi again and thanks for that. I'm still not exactly clear on the setup. I think the auth server is 172.16.0.254 (I don't know what pc1 is). But anyway, looking at your results I see the AA bit for everything. It appears that these queries both went directly to the auth server because recursion is disabled and it told you so. == # pc1@pc1:~ dig pc1.reseau1.lan ``` ```txt ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available # ns1@ns1:~ dig pc1.reseau1.lan ``` ```txt ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2379 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available == So unless I'm missing something I don't see your problem. Cheers, Greg On Mon, 15 Jan 2024 at 15:24, wrote: > Dear Greg, > > Thank you for your reply. > > > Please find attached the markdown file with all the commands and text > from the terminal. > > In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener > from systemd-resolved. I have netplan and networkd. > > > Kind Regards, > > Michel Diemer. > > > > De : "Greg Choules" > A : pub.dieme...@laposte.net,bind-users@lists.isc.org > Envoyé: dimanche 14 Janvier 2024 23:28 > Objet : Re: Question about authoritative server and AA Authoritative Answer > > Hi Michel. > Please can you send the following information: > - name and IP address of the authoritative server > - the full contents of the zone file for "reseau1.lan" > - name and IP address of the other server - what does this server do? > - What is the machine "pc1", on which you are running the digs? > - the file "/etc/resolv.conf" on "pc1" > > Please also re-send the digs with full output. > When you send information, please send it as text, not screenshots. > > Thanks, Greg > > On Sun, 14 Jan 2024 at 22:04, Michel Diemer via bind-users < > bind-users@lists.isc.org> wrote: > >> Ders bind users, >> >> I have already asked a similar question which was more about DNS in >> general , this one is very specific about the AA bit. >> >> Today's question is : *« "dig pc1.reseau1.lan ns"** show AUTHORITY: 1 >> and "dig pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am >> I missing ? If possible, how to get AA answers for QNAME queries ? »* >> >> I have set up two virtual machines on a virtual local network using >> Oracle VirtualBox. One machine is a DNS authoritative-only server. The >> zone is named "reseau1.lan" and defined only in bind9 zone files. If I >> really have to, I will name it "reseau1.home.arpa" according to RFC 8375. >> (I chose .lan inspired by RFC 6762 appendix G). The IP address of the DNS >> server is 172.16.0.254 and the IP address of pc1 is 172.16.0.21. >> >> >> *dig soa reseau1.lan* : the AA bit is set, which is what I am looking for >> >> ͏ ͏ ͏ >> >> * dig pc1.reseau1.lan ns* : the AA bit is set >> >> ͏ ͏ ͏ ͏ >> >> *dig pc1.reseau1.lan* : *the AA bit is not set. Why ? Which setting or >> knowledge am I missing ?* >> >> >> >> Below my "named.conf.options" file >> >> ͏ >> >> >> ͏ ͏ ͏ ͏ >> -- >> 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 > > -- 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: Question about authoritative server and AA Authoritative Answer
Dear Greg, Thank you for your reply. Please find attached the markdown file with all the commands and text from the terminal. In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener from systemd-resolved. I have netplan and networkd. Kind Regards, Michel Diemer. De : "Greg Choules" A : pub.dieme...@laposte.net,bind-users@lists.isc.org Envoyé: dimanche 14 Janvier 2024 23:28 Objet : Re: Question about authoritative server and AA Authoritative Answer Hi Michel. Please can you send the following information: - name and IP address of the authoritative server - the full contents of the zone file for "reseau1.lan" - name and IP address of the other server - what does this server do? - What is the machine "pc1", on which you are running the digs? - the file "/etc/resolv.conf" on "pc1" Please also re-send the digs with full output. When you send information, please send it as text, not screenshots. Thanks, Greg On Sun, 14 Jan 2024 at 22:04, Michel Diemer via bind-users wrote: Ders bind users, I have already asked a similar question which was more about DNS in general , this one is very specific about the AA bit. Today's question is : « "dig pc1.reseau1.lan ns" show AUTHORITY: 1 and "dig pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I missing ? If possible, how to get AA answers for QNAME queries ? » I have set up two virtual machines on a virtual local network using Oracle VirtualBox. One machine is a DNS authoritative-only server. The zone is named "reseau1.lan" and defined only in bind9 zone files. If I really have to, I will name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan inspired by RFC 6762 appendix G). The IP address of the DNS server is 172.16.0.254 and the IP address of pc1 is 172.16.0.21. dig soa reseau1.lan : the AA bit is set, which is what I am looking for ͏ ͏ ͏ dig pc1.reseau1.lan ns : the AA bit is set ͏ ͏ ͏ ͏ dig pc1.reseau1.lan : the AA bit is not set. Why ? Which setting or knowledge am I missing ? Below my "named.conf.options" file ͏ ͏ ͏ ͏ ͏ -- 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 dns-authoritative-question.md Description: Binary data -- 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: Question about authoritative server and AA Authoritative Answer
Hi Michel. Please can you send the following information: - name and IP address of the authoritative server - the full contents of the zone file for "reseau1.lan" - name and IP address of the other server - what does this server do? - What is the machine "pc1", on which you are running the digs? - the file "/etc/resolv.conf" on "pc1" Please also re-send the digs with full output. When you send information, please send it as text, not screenshots. Thanks, Greg On Sun, 14 Jan 2024 at 22:04, Michel Diemer via bind-users < bind-users@lists.isc.org> wrote: > Ders bind users, > > I have already asked a similar question which was more about DNS in > general , this one is very specific about the AA bit. > > Today's question is : *« "dig pc1.reseau1.lan ns"** show AUTHORITY: 1 and > "dig pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I > missing ? If possible, how to get AA answers for QNAME queries ? »* > > I have set up two virtual machines on a virtual local network using Oracle > VirtualBox. One machine is a DNS authoritative-only server. The zone is > named "reseau1.lan" and defined only in bind9 zone files. If I really have > to, I will name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan > inspired by RFC 6762 appendix G). The IP address of the DNS server is > 172.16.0.254 and the IP address of pc1 is 172.16.0.21. > > > *dig soa reseau1.lan* : the AA bit is set, which is what I am looking for > > ͏ ͏ ͏ > > * dig pc1.reseau1.lan ns* : the AA bit is set > > ͏ ͏ ͏ ͏ > > *dig pc1.reseau1.lan* : *the AA bit is not set. Why ? Which setting or > knowledge am I missing ?* > > > > Below my "named.conf.options" file > > ͏ > > > ͏ ͏ ͏ ͏ > -- > 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 > -- 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
Question about authoritative server and AA Authoritative Answer
Ders bind users, I have already asked a similar question which was more about DNS in general , this one is very specific about the AA bit. Today's question is : « "dig pc1.reseau1.lan ns" show AUTHORITY: 1 and "dig pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I missing ? If possible, how to get AA answers for QNAME queries ? » I have set up two virtual machines on a virtual local network using Oracle VirtualBox. One machine is a DNS authoritative-only server. The zone is named "reseau1.lan" and defined only in bind9 zone files. If I really have to, I will name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan inspired by RFC 6762 appendix G). The IP address of the DNS server is 172.16.0.254 and the IP address of pc1 is 172.16.0.21. dig soa reseau1.lan : the AA bit is set, which is what I am looking for ͏ ͏ ͏ dig pc1.reseau1.lan ns : the AA bit is set ͏ ͏ ͏ ͏ dig pc1.reseau1.lan : the AA bit is not set. Why ? Which setting or knowledge am I missing ? Below my "named.conf.options" file ͏ ͏ ͏ ͏ ͏ -- 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: dnssec-key 'unknown algorithm RSASHA512'
Hello,
Bind version - 9.18.12
-->This is the command I used for generating dnssec-keygen keys -
root@dhcpt: /etc/bind# dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.com
Kexample.com.+013+43215.key
Kexample.com.+013+43215.private
root@dhcpt:/etc/bind# cat Kexample.com.+013+43215.private
Private-key-format: v1.3
Algorithm: 13 (ECDSAP256SHA256)
PrivateKey: ESkrVALONh7Rj4UZVsOy54Y2SIJiY5HYhoQdxJLuWPk=
Created: 20240111045202
Publish: 20240111045202
Activate: 20240111045202
-->With help of the private key i generated one file with name
"named.conf.tsigkeys" at
/etc/bind -
root@dhcpt:/etc/bind# cat named.conf.tsigkeys
key "my-tsig" {
algorithm "ECDSAP256SHA256";
secret "ESkrVALONh7Rj4UZVsOy54Y2SIJiY5HYhoQdxJLuWPk=";
};
--> below is the error received when i restart named service
root@dhcpt:/etc/bind# named-checkconf
/etc/bind/named.conf.tsigkeys:2: unknown algorithm 'ECDSAP256SHA256'
Any help is greatly appreciated.
Regards,
Mounika
On Thu, 11 Jan 2024 15:49:18 +1100, Mark Andrews wrote
> Firstly show what you are actually doing. It it too much for you to actually
> cut-and-paste what you are doing?
>
> Secondly BIND 9.18 is at 9.18.22. Version 9.18.8 is seriously out of date.
>
> > On 11 Jan 2024, at 15:21, pvs via bind-users
> > wrote:
> >
> > Hello,
> >
> > I'm using ubuntu 22.04 server on which bind 9.18.8 service is running.
> > I'm trying to generate dnssec-key by using the command "dnssec-keygen -a
> > RSASHA512
-b 2048 -n zone example.com"
> >
> > After doing this, it is generating both public key and private key. When I
> > generate
a file with aprivate key in /etc/bind directory, it is throwing error 'unknown
algorithm 'RSASHA512'
> > Same error is thrown when tried with other algorithms like ECDSAP256SHA256,
> > RSASHA1,
RSASHA256 etc
> > Any help is greatly appreciated.
> >
> > --
> > Regards,
> >
> > पं. विष्णु शंकर P. Vishnu Sankar
> > टीम लीडर Team Leader-Network Operations
> > सी-डॉट C-DOT
> > इलैक्ट्रॉनिक्स सिटी फेज़ I Electronics City Phase I
> > होसूर रोड बेंगलूरु Hosur Road Bengaluru – 560100
> > फोन Ph 91 80 25119466
> > --
> > Disclaimer :
> > This email and any files transmitted with it are confidential and intended
> > solely
for the use of the individual or entity to whom they are addressed.
> > If you are not the intended recipient you are notified that disclosing,
> > copying,
distributing or taking any action in reliance on the contents of this
information is
strictly prohibited.
> > The sender does not accept liability for any errors or omissions in the
> > contents of
this message, which arise as a result.
> > --
> > 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: ma...@isc.org
>
> --
> 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
### Please consider the environment and print this email only if necessary . Go
Green
###
Disclaimer :
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents of this
information is strictly prohibited. The sender does not accept liability
for any errors or omissions in the contents of this message, which arise as a
result.
--
Open WebMail Project (http://openwebmail.org)
--
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
dnssec-key 'unknown algorithm RSASHA512'
Hello, I'm using ubuntu 22.04 server on which bind 9.18.8 service is running. I'm trying to generate dnssec-key by using the command "dnssec-keygen -a RSASHA512 -b 2048 -n zone example.com" After doing this, it is generating both public key and private key. When I generate a file with aprivate key in /etc/bind directory, it is throwing error 'unknown algorithm 'RSASHA512' Same error is thrown when tried with other algorithms like ECDSAP256SHA256, RSASHA1, RSASHA256 etc Any help is greatly appreciated. -- Regards, पं. विष्णु शंकर P. Vishnu Sankar टीम लीडरTeam Leader-Network Operations सी-डॉट C-DOT इलैक्ट्रॉनिक्स सिटी फेज़ IElectronics City Phase I होसूर रोड बेंगलूरु Hosur Road Bengaluru – 560100 फोन Ph91 80 25119466 -- Disclaimer : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. The sender does not accept liability for any errors or omissions in the contents of this message, which arise as a result. -- 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
NOTIFY and TSIG
Hi list.
I've been trying to understand whether it is necessary for the NOTIFY
request (i.e. sent from primary to secondary server) to use TSIG, in the
case where the secondary server specifies a key in its zone's
"primaries" option?
For example, assume the following set-up:
The primary server (192.0.2.1) specifies the following configuration:
key "secret-key.example.com" { ... };
zone "example.com" {
type primary;
file "/etc/bind/db.example.com";
notify yes;
allow-transfer { key "secret-key.example.com"; };
};
And the secondary server (192.0.2.2) specifies:
key "secret-key.example.com" { ... };
zone "example.com" {
type secondary;
file "db.example.com";
*primaries { 192.0.2.1 key "secret-key.example.com"; };*
notify no;
};
And if the zone file db.example.com (on the primary server) contained:
$TTL 3600
@ IN SOA server1 root.server1 1 86400 7200 2419200 1800
@ IN NS server1
@ IN NS server2
server1 IN A 192.0.2.1
server2 IN A 192.0.2.2
In this case when the zone is changed on the primary server, it will
send an /unsigned/ NOTIFY to the secondary server. The question I was
trying to answer was: /With the configuration above, will the secondary
server accept the unsigned notification?/
I was hoping to find an RFC that answered this question, but didn't have
any luck Googling. However the BIND documentation for "allow-notify"
(https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-allow-notify)
contains the following text:
*allow-notify*
...
Defines an address_match_list that is allowed to send NOTIFY
messages for the zone, in addition to addresses defined in the
primaries option for the zone.
...
If not specified, the default is to process NOTIFY messages only
from the configured primaries for the zone. allow-notify can be used
to expand the list of permitted hosts, not to reduce it.
My interpretation of the above was that if a key is specified in the
"primaries" option, then the secondary would require the NOTIFY to be
signed by the same key? However when I tested this theory, I found the
secondary did accept (and process) the unsigned NOTIFY.
While I understand (and agree) that this behaviour makes the most sense,
given my confusion based on the documentation, I wonder if the
documentation could be made clearer? E.g. Add the sentence: "In the case
where the primaries option specifies a TSIG key, it is not necessary for
the received NOTIFY to be signed by the same key."
Thanks,
Nick.
--
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
[Windows] [9.16.45] Missing IPv4 DNS prevents tools from working
Hello there, Due to an accident my local network is missing IPv4 DNS but has IPv6 DNS so it has little impact on accessing the internet. But I found that neither `dig `nor `nslookup` worked, and reported an error: ``` C:\Program Files\ISC BIND 9\bin\dig.exe: parse of C:\Program Files\ISC BIND 9\etc\resolv.conf failed ``` There is actually no "resolv.conf" there, they get the DNS from the system and if IPv4 DNS is missing it will throw an error. Creating "resolv.conf" manually also does not prevent the problem. I noticed that version 9.16 is about to be EOL. I wonder if this BUG can be fixed before EOL? After all, this is the only version of BIND 9 that still supports the Windows platform. Best regards, Gentry -- 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
AW: migration from auto-dnssec to dnssec-policy deletes keys immediately
Hi all!
I also know a colleague which was hit by the same issue, causing problems to
their zone.
Migrating from auto-dnssec to dnssec-policy can lead to operational issues. For
example that problem with different algos should be mentioned in
https://kb.isc.org/docs/dnssec-key-and-signing-policy
Further, I suggest to add something like the following sentence to that
article: Changing DNSSEC configuration can lead to unexpected zone changes and
should be tested on dedicated test systems before. If you do this on a hidden
master, you could also temporarily disable outgoing XFR by configuring
'allow-transfer {"none";};' on that zone to prevent leakage of broken DNSSEC
zones. This way you can check the zone after migration and only after
successful testing (i.e. using https://dnsviz.net/d/ops.nic.at/analyze/ with
advanced options, pointing directly to the hidden master) re-enable outgoing
XFR.
Regards
Klaus
Von: bind-users Im Auftrag von Nick Tait via
bind-users
Gesendet: Donnerstag, 28. Dezember 2023 04:01
An: bind-users@lists.isc.org
Betreff: Re: migration from auto-dnssec to dnssec-policy deletes keys
immediately
On 28 Dec 2023, at 1:05 PM, Adrian Zaugg
mailto:lists.isc@mailgurgler.com>> wrote:
2023-12-27 23:51:24: zone myzone.ch/IN (signed): reconfiguring zone keys
2023-12-27 23:51:24: keymgr: retire DNSKEY myzone.ch/ECDSAP256SHA256/14076
(KSK)
2023-12-27 23:51:24: keymgr: retire DNSKEY myzone.ch/ECDSAP256SHA256/3654
(ZSK)
2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/2336 (KSK) created for
policy mypolicy
2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/35413 (ZSK) created for
policy mypolicy
Your DNSSEC policy “mypolicy” specifies a different algorithm (ED25519) to what
was previously in effect (ECDSAP256SHA256), which is why Bind generated new
keys. If you want Bind to keep the old keys when transitioning to dnssec-policy
you should initially specify the same algorithm in your policy.
My understanding is that after you’ve transitioned to using dnssec-policy you
should be able to change the algorithm and Bind should do a graceful roll-over?
Just make sure everything is “omnipresent” in your state files (in the keys
directory) first.
Nick.
--
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: Unable to Query DoH with `tls none` and Plain HTTP
On Tue, Jan 2, 2024 at 4:38 AM Jakob Bohm via bind-users wrote: > Having the DoH server as a standalone process talking to DNS/TCP would > be a solid implementation given the constant flow of changes made to > HTTP(S) by the Big 5. Perhaps, but for reference here is the relevant section of the DoH spec: https://datatracker.ietf.org/doc/html/rfc8484#section-5.2 HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use with DoH. The messages in classic UDP-based DNS [RFC1035] are inherently unordered and have low overhead. A competitive HTTP transport needs to support reordering, parallelism, priority, and header compression to achieve similar performance. Those features were introduced to HTTP in HTTP/2 [RFC7540]. Earlier versions of HTTP are capable of conveying the semantic requirements of DoH but may result in very poor performance. That ISC has chosen to follow the minimum HTTP version as recommended by the RFC is solid ground on which to be standing. -- tale -- 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: Unable to Query DoH with `tls none` and Plain HTTP
On 2024-01-01 16:38, Ondřej Surý wrote: On 1. 1. 2024, at 15:19, r1wcp...@bbqporkmccity.com wrote: Thank you very much, I was unaware of the HTTP/2 requirement and was assuming it is a bug. Is there any reason for omitting the HTTP/1.1 upgrade part of the protocol? It would be additional complexity that's really not needed. The HTTP/2 library (libnghttp) doesn't provide HTTP/1.1 implementation, so we would have to bolt something own for a little gain. And it would increase an attack surface as it would be yet another protocol open to the world that can have bugs in it. Funny, given that HTTP/2 (the spec) had a CVE against it last October, while HTTP/0.9 and HTTP/1.x did not. Having the DoH server as a standalone process talking to DNS/TCP would be a solid implementation given the constant flow of changes made to HTTP(S) by the Big 5. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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: Unable to Query DoH with `tls none` and Plain HTTP
Hello,
Thank you very much, I was unaware of the HTTP/2 requirement and was
assuming it is a bug. Is there any reason for omitting the HTTP/1.1
upgrade part of the protocol?
On 2024/01/01 22:30, Ondřej Surý wrote:
Hi,
BIND 9 DoH implementation always uses HTTP/2, so you
can't talk to it via HTTP/0.9, so your proxy balancer needs
to talk HTTP/2.
curl --http2-prior-knowledge -v -H 'accept: application/dns-message'
'http://172.23.0.2:80/dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB'
should work if I am reading the curl man page correctly (I don't have bind with
doh no-tls here)
dig +http-plain @172.23.0.2
will definitely work.
Ondřej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
On 1. 1. 2024, at 13:35, r1wcp42w--- via bind-users
wrote:
Hello,
Hope you are having a great day.
I am trying to setup a BIND9 DNS over HTTP (DoH but in plain HTTP) server with
the ubuntu/bind9:latest docker image behind a HTTPS load balancer however I am
unable to perform any DNS query with the newly installed BIND9 server(not
through the load balancer).
I am getting the following when I try to perform the query:
➜ curl -v -H 'accept: application/dns-message'
'http://172.23.0.2:80/dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB'
* Trying 172.23.0.2:80...
* Connected to 172.23.0.2 (172.23.0.2) port 80
GET /dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/1.1
Host: 172.23.0.2
User-Agent: curl/8.5.0
accept: application/dns-message
* Received HTTP/0.9 when not allowed
* Closing connection
curl: (1) Received HTTP/0.9 when not allowed
and here is my named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://psrp.bbqporkmccity.com/vye5rn/vXKoBzwW
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See
http://psrp.bbqporkmccity.com/vye5rn/WflSTkLF
//
dnssec-validation auto;
listen-on-v6 { any; };
// Custom Options From Here
allow-query { any;};
allow-transfer { none; };
listen-on port 53 { any; };
listen-on port 80 tls none http default { any; };
};
Am I doing something wrong?
Thank you very much and I am looking forward to a solution.
--
Visit http://psrp.bbqporkmccity.com/vye5rn/jprjhJwF to unsubscribe from this
list
ISC funds the development of this software with paid support subscriptions.
Contact us at http://psrp.bbqporkmccity.com/vye5rn/HiPEm7Fv for more
information.
bind-users mailing list
bind-users@lists.isc.org
http://psrp.bbqporkmccity.com/vye5rn/pgPJe84v
--
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
Unable to Query DoH with `tls none` and Plain HTTP
Hello,
Hope you are having a great day.
I am trying to setup a BIND9 DNS over HTTP (DoH but in plain HTTP)
server with the ubuntu/bind9:latest docker image behind a HTTPS load
balancer however I am unable to perform any DNS query with the newly
installed BIND9 server(not through the load balancer).
I am getting the following when I try to perform the query:
➜ curl -v -H 'accept: application/dns-message'
'http://172.23.0.2:80/dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB'
* Trying 172.23.0.2:80...
* Connected to 172.23.0.2 (172.23.0.2) port 80
GET /dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/1.1
Host: 172.23.0.2
User-Agent: curl/8.5.0
accept: application/dns-message
* Received HTTP/0.9 when not allowed
* Closing connection
curl: (1) Received HTTP/0.9 when not allowed
and here is my named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://psrp.bbqporkmccity.com/vye5rn/iw5hSZ1O
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See
http://psrp.bbqporkmccity.com/vye5rn/nH13n27l
//
dnssec-validation auto;
listen-on-v6 { any; };
// Custom Options From Here
allow-query { any;};
allow-transfer { none; };
listen-on port 53 { any; };
listen-on port 80 tls none http default { any; };
};
Am I doing something wrong?
Thank you very much and I am looking forward to a solution.
--
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
named is creating excessive number of tmp-xxxxx files.
Hello, I am running a named service on the OpenSuSE 15.4 platform. # named -v BIND 9.16.44 (Extended Support Version) and I am getting an excessive number of binary tmp-xx files created in the named chroot directory - /var/lib/named. (xx is just a bunch of random characters.) What are these files and how to I automatically manage the creation and deletion of them? Could I simply add an 'ExecStartPre=+/bin/rm -rf /var/lib/named/tmp-* to the named.service file in order to delete all these tmp-* files whenever the named service is started/restarted or would this be an unsafe practice? I don't know if these files are being used to persist information across restarts of the named service or not... These tmp files contain binary information and as such are unreadable. Much appreciate, and thanks in advance for some advice... Marc C -- *"The Truth is out there" - Spooky* -- *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed. My public key for sending encrypted email to me can be found at - https://keys.openpgp.org/search?q=m...@domesweetdome.us.com or just ask me for it and I will send it to you as an attachment. If you don't understand, no worries, just ignore it and/or ask me to explain it further./) OpenPGP_0xD23D75B63BF0E8B7.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- 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: migration from auto-dnssec to dnssec-policy deletes keys immediately
> On 28 Dec 2023, at 1:05 PM, Adrian Zaugg > wrote: > > 2023-12-27 23:51:24: zone myzone.ch/IN (signed): reconfiguring zone keys > 2023-12-27 23:51:24: keymgr: retire DNSKEY myzone.ch/ECDSAP256SHA256/14076 > (KSK) > 2023-12-27 23:51:24: keymgr: retire DNSKEY myzone.ch/ECDSAP256SHA256/3654 > (ZSK) > 2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/2336 (KSK) created for > policy mypolicy > 2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/35413 (ZSK) created for > policy mypolicy Your DNSSEC policy “mypolicy” specifies a different algorithm (ED25519) to what was previously in effect (ECDSAP256SHA256), which is why Bind generated new keys. If you want Bind to keep the old keys when transitioning to dnssec-policy you should initially specify the same algorithm in your policy. My understanding is that after you’ve transitioned to using dnssec-policy you should be able to change the algorithm and Bind should do a graceful roll-over? Just make sure everything is “omnipresent” in your state files (in the keys directory) first. Nick. -- 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
assertion error while querying?
This happens in both MacOS and in debian (multiple systems), I’m
wondering what could be causing it: (same with krd.iq)
```
$ host -4 -C id.iq
id.iq has no SOA record
Nameserver 64.96.1.1:
id.iq has SOA record ns.tucowsregistry.net. ops.tucowsregistry.net.
1703469021 1800 900 604800 86400
Nameserver 64.96.2.1:
id.iq has SOA record ns.tucowsregistry.net. ops.tucowsregistry.net.
1703469021 1800 900 604800 86400
Nameserver 194.117.57.105:
id.iq not found: 2(SERVFAIL)
fobispo@mail:~$ host -4 -C id.iq
id.iq has no SOA record
Nameserver 64.96.1.1:
id.iq has SOA record ns.tucowsregistry.net. ops.tucowsregistry.net.
1703469021 1800 900 604800 86400
Nameserver 64.96.2.1:
id.iq has SOA record ns.tucowsregistry.net. ops.tucowsregistry.net.
1703469021 1800 900 604800 86400
netmgr/netmgr.c:1736: REQUIREhandle) != ((void *)0) && ((const
isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H')
<< 8 | ('D' && __extension__ ({ __auto_type __atomic_load_ptr =
(&(handle)->references); __typeof__ ((void)0, *__atomic_load_ptr)
__atomic_load_tmp; __atomic_load (__atomic_load_ptr, &__atomic_load_tmp,
(5)); __atomic_load_tmp; }) > 0)) failed, back trace
/lib/x86_64-linux-gnu/libisc-9.18.19-1~deb12u1-Debian.so(+0x39b20)[0x7f6d44fecb20]
/lib/x86_64-linux-gnu/libisc-9.18.19-1~deb12u1-Debian.so(isc_assertion_failed+0xa)[0x7f6d44feca7a]
/lib/x86_64-linux-gnu/libisc-9.18.19-1~deb12u1-Debian.so(isc__nmhandle_attach+0x63)[0x7f6d44fd4173]
host(+0x11be8)[0x56106ed38be8]
host(+0x10374)[0x56106ed37374]
host(+0x14f70)[0x56106ed3bf70]
/lib/x86_64-linux-gnu/libisc-9.18.19-1~deb12u1-Debian.so(isc__nm_async_readcb+0xac)[0x7f6d44fd7a5c]
/lib/x86_64-linux-gnu/libisc-9.18.19-1~deb12u1-Debian.so(isc__nm_readcb+0xa8)[0x7f6d44fd7b98]
/lib/x86_64-linux-gnu/libisc-9.18.19-1~deb12u1-Debian.so(+0x34f20)[0x7f6d44fe7f20]
/lib/x86_64-linux-gnu/libisc-9.18.19-1~deb12u1-Debian.so(isc__nm_udp_read_cb+0x46)[0x7f6d44fe9666]
/lib/x86_64-linux-gnu/libuv.so.1(+0x1f14c)[0x7f6d44f1a14c]
/lib/x86_64-linux-gnu/libuv.so.1(+0x22e3c)[0x7f6d44f1de3c]
/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0xc4)[0x7f6d44f0a9e4]
/lib/x86_64-linux-gnu/libisc-9.18.19-1~deb12u1-Debian.so(+0x27664)[0x7f6d44fda664]
/lib/x86_64-linux-gnu/libisc-9.18.19-1~deb12u1-Debian.so(isc__trampoline_run+0x15)[0x7f6d45014945]
/lib/x86_64-linux-gnu/libc.so.6(+0x89044)[0x7f6d44aa8044]
/lib/x86_64-linux-gnu/libc.so.6(+0x10961c)[0x7f6d44b2861c]
```
Francisco--
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
HEL, Centos, Rocky, Fedora rpm 9.18.21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.five-ten-sg.com/mapper/bind contains links to the source rpm, and build instructions. This .src.rpm contains a .tar.gz file with the ARM documentation, so the rpm rebuild process does not need sphinx- build and associated dependencies. This is my first 9.18 build. It seems to work for me. -BEGIN PGP SIGNATURE- iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCZYeF+hUcY2FybEBmaXZl LXRlbi1zZy5jb20ACgkQL6j7milTFsH6IgCfZ2X6pE9f2WGwqqIzcUMpXl0QnI8A nj/2N6vWXFKB5/rPuc6jb4E7rZIP =2pik -END PGP SIGNATURE- -- 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: DNSSec mess with SHA1
Hi Folks, Many thanks for you feedback and insights. I didn’t wanted to say that this is an ISC issue or something I expected someone to fix. I just wanted to get your opinions and maybe provide a solution as I am not the only one facing that challenge ;-) Yes, it may be a distribution packing or installation issue outside of BIND but nevertheless it’s impacting DNS resolution in a negative way. Anyway, the easy solution to get it working without creating DNSSEC exceptions lists is: update-crypto-policies --set LEGACY … but I still think the right way would be getting people signing their zones with ED25519 or ED448 as mentioned by Scott. The following table lists the implementation recommendations for DNSKEY algorithms [DNSKEY-IANA]. +++-+---+ | Number | Mnemonics | DNSSEC Signing | DNSSEC Validation | +++-+---+ | 1 | RSAMD5 | MUST NOT| MUST NOT | | 3 | DSA| MUST NOT| MUST NOT | | 5 | RSASHA1| NOT RECOMMENDED | MUST | | 6 | DSA-NSEC3-SHA1 | MUST NOT| MUST NOT | | 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST | | 8 | RSASHA256 | MUST| MUST | | 10 | RSASHA512 | NOT RECOMMENDED | MUST | | 12 | ECC-GOST | MUST NOT| MAY | | 13 | ECDSAP256SHA256| MUST| MUST | | 14 | ECDSAP384SHA384| MAY | RECOMMENDED | | 15 | ED25519| RECOMMENDED | RECOMMENDED | | 16 | ED448 | MAY | RECOMMENDED | +++-+---+ I still puzzled why root zones can’t get it done to re-singn their zones with a decent algorithm and that organisations like NIST are still on SHA1… Cheers and many thanks, Wolfgang On 15. Dec 2023, at 23:11, Mark Andrews wrote: They haven’t removed sha1 they have removed certain uses of sha1. If they ever remove sha1 we will just add an implementation for sha1. -- Mark Andrews On 16 Dec 2023, at 01:09, Scott Morizot wrote: On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček mailto:pspa...@isc.org>> wrote: We do runtime detection at startup because it's configurable, build time would not work properly. Okay, that makes sense. However, if I understood the scenario correctly, it seems like that configuration should then generate a runtime error or at least report that DNSSEC validation has been disabled. The description involved removing support for SHA1 entirely from the underlying system configuration. If that's the case then I don't see how DNSSEC validation can be reliably performed at all. It's not like introducing a new DNSSEC algorithm or removing support for an older DNSSEC algorithm. SHA1 is used to generate the hash label in NSEC3. I know that's been discussed on dnsops, but it hasn't changed. And from algorithm 8 on, there haven't been separate algorithms with and without NSEC3. Rather it's an option that can be configured for signing on a zone by zone basis. So if SHA1 isn't available, I don't see how any of the DNSSEC algorithms could truly be considered supported on the system. That's making me curious enough that I might see if I can set up a system where I could reproduce that scenario and see what happens. Unless it's already part of your test suite and you know the answer, of course. Scott -- 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 -- 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 -- 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: Re: zone not loaded in one of view
Hi. The existence of a `.jnl` file for the zone means that, at some point in the past anyway, you *did* allow dynamic updates to this zone and some updates were made, which were stored in the journal file. I would like to ask a couple of questions: 1) What is the timeline of your investigation? Map out file creation and modification dates and times along with log messages and times you made changes to see if you can build a picture of what actually happened when. 2) How many instances of 'named' are running on this server? I have seen in the past people have two or more 'named' processes running that they were not aware of, which *might* cause problems if they are trying to use the same data files. Cheers, Greg On Tue, 19 Dec 2023 at 08:26, wrote: > I found there was a db.ynu.edu.cn.intranet.jnl beside db.ynu.edu.cn.intranet, > I tried to remove it, then restarted and checked the new cache_dump.db, no > `zone not loaded` anymore. > > For the original problem, because I modified serial of SOA and updated bind9 > to the latest version, it could not reproduce. Maybe it's also the similar > issue, but in the older bind 9.11, no jnl file generated via named. > > > > > 2023-12-17 15:47:43 "Mark Andrews" 写道： > > Read your logs and/or use named-checkzone and/or tell name-checkconf to > load the zones. > > -- > Mark Andrews > > On 17 Dec 2023, at 15:22, liudong...@ynu.edu.cn wrote: > > Hi, I have a bind9 authoritative name server running, but I found a > strange problem. One of zone in a specific view not loaded when I view the > cache_dump.db after I execute `rndc dumpdb -all`. > > > The zone data file is almost the same for difference views execpted some > few domain resolution. > > > [root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.cernet > $TTL 86400 ; 1 day > @ IN SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. ( > 2023121601; serial number > 10800 ; Refresh interval, every 3 hours > 3600; Retry interval, every 30 > minutes > 604800 ; Expire after 1 week > 86400 ) ;Minimum TTL of 1 day > > > $INCLUDE /etc/named.data/db.ynu.edu.cn.common > > > > > ; RR of type A > ; > vpn110800 IN A 113.55.110.251 > ; > lb-http-jz IN A 113.55.14.52 > ynucdn 600 IN A 202.203.208.4 > ; > vpn2IN A 202.203.208.9 > > > [root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.intranet > $TTL 86400 ; 1 day > @ IN SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. ( > 2023121601; serial number > 10800 ; Refresh interval, every 3 hours > 3600; Retry interval, every 30 > minutes > 604800 ; Expire after 1 week > 86400 ) ;Minimum TTL of 1 day > > > $INCLUDE /etc/named.data/db.ynu.edu.cn.common > > > > > ; RR of type A > ; > lb-http-jz IN A 113.55.14.52 > ; > vpn110800 IN A 192.168.208.3 > ynucdn 600 IN A 202.203.208.4 > ; > vpn2IN A 202.203.208.9 > > > [root@pridns data]# > [root@pridns data]# named-checkconf /etc/named.conf > [root@pridns data]# echo $? > 0 > [root@pridns data]# > [root@pridns data]# rndc zonestatus ynu.edu.cn in CERNET > name: ynu.edu.cn > type: primary > files: db.ynu.edu.cn.cernet, /etc/named.data/db.ynu.edu.cn.common > serial: 2023121601 > nodes: 576 > last loaded: Sat, 16 Dec 2023 08:00:49 GMT > secure: no > dynamic: no > reconfigurable via modzone: no > [root@pridns data]# > [root@pridns data]# rndc zonestatus ynu.edu.cn in INTRANET > rndc: 'zonestatus' failed: zone not loaded > [root@pridns data]# > [root@pridns data]# named-checkzone ynu.edu.cn > /etc/named.data/db.ynu.edu.cn.intranet > zone ynu.edu.cn/IN: loaded serial 2023121601 > OK > [root@pridns data]# > [root@pridns data]# ll /etc/named.data/db.ynu.edu.cn.cernet > /etc/named.data/db.ynu.edu.cn.intranet > -rw-r--r-- 1 root root 1.3K Dec 16 16:00 > /etc/named.data/db.ynu.edu.cn.cernet > -rw-r--r-- 1 root root 1.3K Dec 16 16:00 > /etc/named.data/db.ynu.edu.cn.intranet > [root@pridns data]# > > > And here is parts of content in /var/named/data/cache_dump.db > > > ; Zone dump of 'ynu.edu.cn/IN/INTRANET' > ; > ; zone not loaded > ; > ; Z
Re: Zone file got updated via named process unexpected
On 17/12/2023 5:30 pm, liudong...@ynu.edu.cn wrote:
I found this zone file got updated in about 15 minutes when I made
changes or restarted named, and this behavior seems match the docs
bind9.readthedocs.io/en/latest/chapter6.html#dynamic-update, but I can
confirm I DO NOT configure allow-update or update-policy. I even add
"allow-update {none;}; // no DDNS by default" in the zone block of the
problematic view. Is there any chances this configuration comes from
other config file or named build options?
Are you using DNSSEC with this zone? Your config extract doesn't show
it, but what you described sounds like BIND might be resigning the zone
file and writing the new signed zone over top of the original file? If
so, the solution is to use inline-signing:
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-inline-signing
Note that there have been many improvements in BIND's support for DNSSEC
over the last few years, so if this is a server that you've inherited,
it is probably worth reviewing the DNSSEC configuration options to see
if it can be improved?
Nick.
--
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: unable-resolve-bank=domain
Some additional information 17-Dec-2023 11:14:20.737 queries: debug 3: client @0x7f2a1027d6f8 88.213.90.92#64617 (www.services.online-banking.gslb.sabbnet.com): looking for relevant NSEC 17-Dec-2023 11:14:20.737 queries: debug 3: client @0x7f2a1027d6f8 88.213.90.92#64617 (www.services.online-banking.gslb.sabbnet.com): ignoring nsec because name is past end of range Ejaz -Original Message- From: MEjaz [mailto:me...@cyberia.net.sa] Sent: Sunday, December 17, 2023 11:16 AM To: 'Ondřej Surý' Cc: 'bind-users@lists.isc.org' Subject: RE: unable-resolve-bank=domain My queries logs shows the below, [root@ns10 ~]# tail -f /var/log/querylog | grep www.services.online-banking.gslb.sabbnet.com. 17-Dec-2023 11:06:03.438 queries: info: client @0x7f29940013a8 167.86.165.83#64231 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN +E(0)D (212.119.64.2) 17-Dec-2023 11:10:20.186 queries: info: client @0x7f294c64f3c8 213.210.238.28#30304 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN HTTPS +E(0)D (212.119.64.2) 17-Dec-2023 11:13:55.798 queries: info: client @0x7f2970c9fe18 212.119.64.2#53159 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A +E(0)K (212.119.64.2) 17-Dec-2023 11:13:57.480 queries: info: client @0x7f295411def8 46.152.39.165#15007 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A +E(0)D (212.119.64.2) 17-Dec-2023 11:13:57.505 queries: info: client @0x7f2a0060db68 46.152.39.165#25046 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN +E(0)D (212.119.64.2) 17-Dec-2023 11:13:57.513 queries: info: client @0x7f29c419e0b8 46.152.39.165#42489 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A + (212.119.64.2) Ejaz -Original Message- From: Ondřej Surý [mailto:ond...@isc.org] Sent: Sunday, December 17, 2023 11:01 AM To: MEjaz Cc: bind-users@lists.isc.org Subject: Re: unable-resolve-bank=domain > On 17. 12. 2023, at 8:20, MEjaz via bind-users > wrote: > > Any hint would be highly appreciated.. Paraphrasing: Logs or it didn’t happen… Always start with logs. The dig output is useless as we can’t possibly know what is happening inside named on that server. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: unable-resolve-bank=domain
My queries logs shows the below, [root@ns10 ~]# tail -f /var/log/querylog | grep www.services.online-banking.gslb.sabbnet.com. 17-Dec-2023 11:06:03.438 queries: info: client @0x7f29940013a8 167.86.165.83#64231 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN +E(0)D (212.119.64.2) 17-Dec-2023 11:10:20.186 queries: info: client @0x7f294c64f3c8 213.210.238.28#30304 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN HTTPS +E(0)D (212.119.64.2) 17-Dec-2023 11:13:55.798 queries: info: client @0x7f2970c9fe18 212.119.64.2#53159 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A +E(0)K (212.119.64.2) 17-Dec-2023 11:13:57.480 queries: info: client @0x7f295411def8 46.152.39.165#15007 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A +E(0)D (212.119.64.2) 17-Dec-2023 11:13:57.505 queries: info: client @0x7f2a0060db68 46.152.39.165#25046 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN +E(0)D (212.119.64.2) 17-Dec-2023 11:13:57.513 queries: info: client @0x7f29c419e0b8 46.152.39.165#42489 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A + (212.119.64.2) Ejaz -Original Message- From: Ondřej Surý [mailto:ond...@isc.org] Sent: Sunday, December 17, 2023 11:01 AM To: MEjaz Cc: bind-users@lists.isc.org Subject: Re: unable-resolve-bank=domain > On 17. 12. 2023, at 8:20, MEjaz via bind-users > wrote: > > Any hint would be highly appreciated.. Paraphrasing: Logs or it didn’t happen… Always start with logs. The dig output is useless as we can’t possibly know what is happening inside named on that server. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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
unable-resolve-bank=domain
8OpyIcR7GmK1NhQtYQZXqPMmcFS6We G0c3ohwJSMSN8L2LpCx44Z1crr9CvA== ;; Received 650 bytes from 192.55.83.30#53(m.gtld-servers.net) in 63 ms gslb.sabbnet.com. 7200IN NS ns3.sabb.com. gslb.sabbnet.com. 7200IN NS ns4.sabb.com. ;; Received 161 bytes from 108.59.171.0#53(ns21.hsbc.net) in 16 ms www.services.online-banking.gslb.sabbnet.com. 900 IN A 193.27.7.78 ;; Received 89 bytes from 193.27.7.38#53(ns3.sabb.com) in 3 ms When we dig without +trace, no response [root@ns10 ~]# dig www.services.online-banking.gslb.sabbnet.com ;; communications error to 212.119.64.2#53: timed out ;; communications error to 212.119.64.2#53: timed out ; <<>> DiG 9.18.11 <<>> www.services.online-banking.gslb.sabbnet.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17592 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 14886f221081fc8e0100657e9abb46c04b22e6da4f29 (good) ;; QUESTION SECTION: ;www.services.online-banking.gslb.sabbnet.com. IN A ;; Query time: 1990 msec ;; SERVER: 212.119.64.2#53(212.119.64.2) (UDP) ;; WHEN: Sun Dec 17 09:52:43 +03 2023 ;; MSG SIZE rcvd: 101 -- 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: DNSSec mess with SHA1
Hello, To answer my own question, the following will work: <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening> [shadowman-200.png] Chapter 4. Using system-wide cryptographic policies Red Hat Enterprise Linux 8 | Red Hat Customer Portal<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening> access.redhat.com<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening> With:dnssec-validation auto; Not working: sudo update-crypto-policies —show DEFAULT working: update-crypto-policies --set LEGACY sudo update-crypto-policies --show LEGACY — Cheers, Wolfgang __ Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559 On 15. Dec 2023, at 12:46, Wolfgang Riedel via bind-users wrote: Hello Petr, The issue is not just BIND local, as you can see on dnsviz.net<http://dnsviz.net/>. The whole chain of trust is broken. <https://dnsviz.net/d/nist.gov/dnssec/> nist.gov<https://dnsviz.net/d/nist.gov/dnssec/> dnsviz.net<https://dnsviz.net/d/nist.gov/dnssec/> <https://dnsviz.net/d/nist.gov/dnssec/> My question is more how you all deal with the fact on current and updates systems??? Attached the requested information. 1) Error Messages: 15-Dec-2023 12:36:38.772 lame-servers: info: insecurity proof failed resolving 'nist.gov/DNSKEY/IN': 2600:1480:800::43#53 15-Dec-2023 12:36:39.302 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2600:1401:1::42#53 15-Dec-2023 12:36:40.151 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2610:20:6b01:3::10#53 15-Dec-2023 12:36:40.681 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2600:1401:2::d8#53 15-Dec-2023 12:36:40.779 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2600:1480:9000::40#53 15-Dec-2023 12:36:41.304 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2600:1406:32::43#53 15-Dec-2023 12:36:41.321 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2600:1480:f000::41#53 15-Dec-2023 12:36:41.784 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2610:20:6005:92::10#53 15-Dec-2023 12:36:41.828 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2.22.230.67#53 15-Dec-2023 12:36:43.094 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 132.163.3.10#53 15-Dec-2023 12:36:43.148 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 193.108.91.216#53 15-Dec-2023 12:36:43.237 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 72.246.46.64#53 15-Dec-2023 12:36:43.288 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 23.61.199.67#53 15-Dec-2023 12:36:43.305 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 184.26.160.65#53 15-Dec-2023 12:36:43.771 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 129.6.92.10#53 15-Dec-2023 12:36:43.823 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 23.211.133.66#53 15-Dec-2023 12:36:43.824 lame-servers: info: broken trust chain resolving 'www.nist.gov/A/IN': 2610:20:6005:92::10#53 15-Dec-2023 12:36:45.905 lame-servers: info: broken trust chain resolving 'www.nist.gov/A/IN': 2600:1480:f000::41#53 15-Dec-2023 12:36:47.403 lame-servers: info: broken trust chain resolving 'csrc.nist.gov/A/IN': 2600:1480:f000::41#53 15-Dec-2023 12:38:26.064 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 2a01:8840:3a::1#53 15-Dec-2023 12:38:26.880 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 2a01:8840:3d::1#53 15-Dec-2023 12:38:27.148 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.62.1#53 15-Dec-2023 12:38:27.415 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.60.1#53 15-Dec-2023 12:38:27.753 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.61.1#53 15-Dec-2023 12:38:27.770 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.63.1#53 15-Dec-2023 12:38:28.037 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 2a01:8840:3c::1#53 15-Dec-2023 12:41:23.114 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 2a01:8840:3d::1#53 15-Dec-2023 12:41:23.380 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 2a01:8840:3a::1#53 15-Dec-2023 12:41:23.648 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.62.1#53 15-Dec-2023 12:41:23.986 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.61.1#53 15-Dec-2023 12:41:24.003 lame
DNSSec mess with SHA1
Hi Folks, I just wonder what's your take is on the current DNSSec mess with SHA1? There are still a lot of top level domains being signed with SHA1 and look like nobody really cares? Current OS releases like RHEL9 and others simply removed SHA1 from the code so if you're running BIND with "dnssec-validation auto" all those domains fails to resolve and the only way is to "dnssec-validation no" which eliminated the whole idea of DNSSec! The worst is that even nist.gov fails WFT! https://dnsviz.net/d/nist.gov/dnssec/ Any advice or ideas? Thank you, Wolfgang Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559 Am Leitenbruennlein 22 | D-91056 Erlangen | Bayern | Germany phone: +49-9131-610-310 fax: +49-9131-610-333 email: wolfgang.rie...@f1-consult.com web: www.f1-consult.com OpenPGP key: CAF005CEC96C30CF4DBA5AFA3DBAFBAF63364 Zoom: https://zoom.us/j/5776157658 WebEx: https://f1-consult.webex.com/meet/wolfgang.riedel __ This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. -- 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: Instructions to use delv to test DNS configured domain before DS uploaded to parent
and to answer my own question as I finally found the section in the manual here: https://bind9.readthedocs.io/en/latest/dnssec-guide.html#verification On Wed, 13 Dec 2023, Brett Delmage via bind-users wrote: Sorry, I pasted the wrong version (too many remote shells open today) Should be: ii bind9 1:9.18.19-1~deb12u1 amd64Internet Domain Name Server ii bind9-utils1:9.18.19-1~deb12u1 amd64Utilities for BIND 9 On Wed, 13 Dec 2023, Brett Delmage wrote: I previously used delv with a manually made trust/key file to test that a DNSSEC-enabled zone was generated correctly. Despite sarching for all kinds of terms I cannot find those instructions (in readthedocs I believe). Could someone please point me there? bind9, bind9-dnsutils: 9.18.15 Thanks. Brett -- 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: Question about DNS / bind9 / authoritative and NXDOMAIN vs NOERROR (NODATA)
Hi Michel.
You will get an authoritative answer (AA bit = 1) if the server is either
primary (master) or secondary (slave) for the QNAME (query name); in this
case "reseau1.lan". From the config snip you provided this is because you
have the config:
zone "reseau1.lan" {
type master;
...
};
If you make a query for "xxx.reseau1.lan" to this server, the response you
get back will depend on whether you have anything in the zone file
("db.reseau1.lan")
that would match that QNAME. If you do not have "xxx" or "*" (wildcard)
then there will be no match and the response will be (authoritative)
NXDOMAIN - this name does not exist at all.
Personally I would not use a wildcard because it gives the impression that
any name exists when really it doesn't.
NOTE that the existence of "reseau1.lan" means that ALL names beneath this
point will be swallowed by the server, e.g. "a.b.c.d.e.f.reseau1.lan" will
all return NXDOMAIN +AA=1
What behaviour do you think you would like to see?
Looking at another part of your config, you should not need this at all:
options {
forwarders {8.8.8.8;};
...
};
If your server can reach the Internet it can recurse all on its own.
I hope that helps.
Greg
On Wed, 13 Dec 2023 at 16:29, Michel Diemer via bind-users <
bind-users@lists.isc.org> wrote:
>
>
> Dear Bind user,
>
> I am a teacher and trying to understand how dns works. I am spending hours
> reading various sources without finding satisfying information. For
> teaching purposes I have created a virtual machine with isc dhcp server and
> bind9 and another virtual machine that uses the first one as ics dhcp and
> dns server.
>
> I have disabled IPv6 by setting link-local: [] in netplan's setting.
>
> The name of the network (dns zone) is "reseau1.lan". When I "dig -4
> reseau1.lan" the AUTHORITY bit is set to 1.
>
> Why or when should the AUTHORITY bit set to 1 ? What does it take for
> nslookup to give me an authoritative answer ?
>
> If I "ping xxx.reseau1.lan" I get an NXDOMAIN answer. Why NXDOMAIN and not
> NOERROR (NODATA) ? The domain "reseau1.lan" exists and my dns server is
> authoritative for this zone (SOA record) but the computer "xxx" on this
> domain does not. Should I use a wildcard dns record ?
>
> I have tryed to empty the list of forwarders and disable the dns cache ...
> should I configure a dns-resolver only for the domain reseau1.lan and then
> a dns forwared for external dns queries ? Or maybe configure the resolver
> for the lan network interface and the forwarder on the internet network
> interface on the dns server ?
>
> I managed to get "AUTHORITY: 1" when typing "dig -4 soa reseau1.lan" by
> disabling the forwarders and the cache so I guess I should configure bind
> per network interface. But when typing "dig -4 pc1.reseau1.lan" the
> AUTHORITY bit is always set to 0.
>
>
> ͏
>
>
>
> ͏
>
>
> Kind Regards,
>
> Michel Diemer
> --
> 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
>
--
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
Question about DNS / bind9 / authoritative and NXDOMAIN vs NOERROR (NODATA)
Dear Bind user, I am a teacher and trying to understand how dns works. I am spending hours reading various sources without finding satisfying information. For teaching purposes I have created a virtual machine with isc dhcp server and bind9 and another virtual machine that uses the first one as ics dhcp and dns server. I have disabled IPv6 by setting link-local: [] in netplan's setting. The name of the network (dns zone) is "reseau1.lan". When I "dig -4 reseau1.lan" the AUTHORITY bit is set to 1. Why or when should the AUTHORITY bit set to 1 ? What does it take for nslookup to give me an authoritative answer ? If I "ping xxx.reseau1.lan" I get an NXDOMAIN answer. Why NXDOMAIN and not NOERROR (NODATA) ? The domain "reseau1.lan" exists and my dns server is authoritative for this zone (SOA record) but the computer "xxx" on this domain does not. Should I use a wildcard dns record ? I have tryed to empty the list of forwarders and disable the dns cache ... should I configure a dns-resolver only for the domain reseau1.lan and then a dns forwared for external dns queries ? Or maybe configure the resolver for the lan network interface and the forwarder on the internet network interface on the dns server ? I managed to get "AUTHORITY: 1" when typing "dig -4 soa reseau1.lan" by disabling the forwarders and the cache so I guess I should configure bind per network interface. But when typing "dig -4 pc1.reseau1.lan" the AUTHORITY bit is always set to 0. ͏ ͏ Kind Regards, Michel Diemer -- 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: Instructions to use delv to test DNS configured domain before DS uploaded to parent
Sorry, I pasted the wrong version (too many remote shells open today) Should be: ii bind9 1:9.18.19-1~deb12u1 amd64Internet Domain Name Server ii bind9-utils1:9.18.19-1~deb12u1 amd64Utilities for BIND 9 On Wed, 13 Dec 2023, Brett Delmage wrote: I previously used delv with a manually made trust/key file to test that a DNSSEC-enabled zone was generated correctly. Despite sarching for all kinds of terms I cannot find those instructions (in readthedocs I believe). Could someone please point me there? bind9, bind9-dnsutils: 9.18.15 Thanks. Brett -- 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
Instructions to use delv to test DNS configured domain before DS uploaded to parent
I previously used delv with a manually made trust/key file to test that a DNSSEC-enabled zone was generated correctly. Despite sarching for all kinds of terms I cannot find those instructions (in readthedocs I believe). Could someone please point me there? bind9, bind9-dnsutils: 9.18.15 Thanks. Brett -- 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: How do I debug if the queries are not getting resolved?
I really wouldn't recommend that.
If you have to, create exceptions for domains that won't validate correctly
by using the "validate-except {..." statement.
In parallel with that, encourage people with broken domains to fix them,
which makes life better for all of us.
Cheers, Greg
On Tue, 12 Dec 2023 at 17:42, Blason R wrote:
> Thanks folks
>
> I just disabled DNSSEC validation from bind config file (globally) and
> those domains started resolving fine.
>
>
> On Tue, Dec 12, 2023, 13:25 Greg Choules <
> gregchoules+bindus...@googlemail.com> wrote:
>
>> Hello.
>> There are well known and documented issues with the zone "gov.in" and
>> there were some recent problems with "gov" as well.
>> Please search this mailing list archive for those domains and you may
>> find some useful hints, tips and information that explain and help you with
>> your own problem.
>>
>> Cheers, Greg
>>
>> On Tue, 12 Dec 2023 at 00:48, Blason R wrote:
>>
>>> Oh I forgot to tell you that. This is BIND RPZ and all the queries are
>>> recursive.
>>>
>>> Dig output just dies out and does not spit anything.
>>>
>>> And this specifically i noticed with .gov and .gov.in domain. This is
>>> the reason I thing it might be related with DNSSEC.
>>>
>>> Also wanted to understand overall how do I debug any queries.
>>>
>>> On Tue, Dec 12, 2023, 00:28 Marco Moock wrote:
>>>
>>>> Am 11.12.2023 um 23:37:36 Uhr schrieb Blason R:
>>>>
>>>> > I require assistance in troubleshooting the resolution issue for
>>>> > specific domains that are not being resolved properly. The version of
>>>> > BIND I am currently using is BIND 9.18.20-1.
>>>>
>>>> First, tell us if those queries are authoritative on that server or not.
>>>>
>>>> Try using dig and post the output here.
>>>> --
>>>> 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
>>>>
>>> --
>>> 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
>>>
>>
--
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: How do I debug if the queries are not getting resolved?
Hello. There are well known and documented issues with the zone "gov.in" and there were some recent problems with "gov" as well. Please search this mailing list archive for those domains and you may find some useful hints, tips and information that explain and help you with your own problem. Cheers, Greg On Tue, 12 Dec 2023 at 00:48, Blason R wrote: > Oh I forgot to tell you that. This is BIND RPZ and all the queries are > recursive. > > Dig output just dies out and does not spit anything. > > And this specifically i noticed with .gov and .gov.in domain. This is the > reason I thing it might be related with DNSSEC. > > Also wanted to understand overall how do I debug any queries. > > On Tue, Dec 12, 2023, 00:28 Marco Moock wrote: > >> Am 11.12.2023 um 23:37:36 Uhr schrieb Blason R: >> >> > I require assistance in troubleshooting the resolution issue for >> > specific domains that are not being resolved properly. The version of >> > BIND I am currently using is BIND 9.18.20-1. >> >> First, tell us if those queries are authoritative on that server or not. >> >> Try using dig and post the output here. >> -- >> 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 >> > -- > 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 > -- 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: How do I debug if the queries are not getting resolved?
On 12/11/23 18:47, Blason R wrote: Oh I forgot to tell you that. This is BIND RPZ and all the queries are recursive. Okay, what RPZ configuration do you have? Is it messing with the queries you're testing in any way? What configuration do you have for RPZ related to DNSSEC? Dig output just dies out and does not spit anything. Please elaborate on "just dies". Does the dig abort / terminate / fail and immediately return you to a command prompt? Or does it simply take longer than you are allowing it to run? What happens if you allow dig to run for 5-8 minutes? It should timeout sometime long before 8 minutes and print something germane to the terminal. I think that a network sniffer while running dig tests above is a very helpful thing. #trustTheBitsOnTheWire And this specifically i noticed with .gov and .gov.in <http://gov.in> domain. This is the reason I thing it might be related with DNSSEC. RPZ and DNSSEC have an interesting relationship. What happens if you do a `\dig +trace` on the name you're testing? N.B. the leading backslash is important to disable any local shell aliasing. Also, `which dig` to confirm that you are running the binary that you think you are running. Also wanted to understand overall how do I debug any queries. Something somewhere will give you diagnostically relevant data. You need to find it and understand it. Even strace / dtrace on dig will be helpful at times. There's a possibility that there is a missing library and dig can't even run. But that's unlikely -- but not impossible -- with dig installed via standard repo commands. -- Grant. . . . -- 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: dnssec-delegation seems to be broken from .gov to bls.gov
Point taken and understood. But you know how it is when there is major outage the push from upper management is always for "fix it now" and get us up and running do your RCA later. Thanks Sandeep -Original Message- From: Mark Andrews Sent: Wednesday, December 6, 2023 10:19 PM To: Bhangui, Sandeep - BLS CTR Cc: Nick Tait ; bind-users@lists.isc.org Subject: Re: dnssec-delegation seems to be broken from .gov to bls.gov CAUTION: This email originated from outside of BLS. DO NOT click (select) links or open attachments unless you recognize the sender and know the content is safe. Please report suspicious emails through the "Phish Alert Report" button on your email toolbar. More to the point why was the old KSK removed *before* checking that the DS record for the new KSK was published and had been for the TTL of the DS RRset? With proper procedures this should not happen. When something goes wrong / is delayed in a key rollover the process should stall until that step is complete, not proceed blindly ahead. > On 7 Dec 2023, at 07:35, Bhangui, Sandeep - BLS CTR via bind-users > wrote: > > The problem has been resolved. > The automatic KSK rollover on the dotgov.gov did not happen properly and > once we manually updated the DS record with the correct KSK keytags and keys > things were fixed. > All is good now. > Now to see if we can find out as to why the automatic KSK failover on the > dotgov.gov did not happen correctly. > Thanks > Sandeep > From: bind-users On Behalf Of Nick > Tait via bind-users > Sent: Wednesday, December 6, 2023 3:23 PM > To: bind-users@lists.isc.org > Subject: Re: dnssec-delegation seems to be broken from .gov to bls.gov > CAUTION: This email originated from outside of BLS. DO NOT click (select) > links or open attachments unless you recognize the sender and know the > content is safe. Please report suspicious emails through the “Phish Alert > Report” button on your email toolbar. On 7/12/2023 9:05 am, Nick Tait via > bind-users wrote: > I could be wrong, but based on the output above it looks like the current TTL > is 0, which means that doing this should provide immediate relief. > Sorry it looks like the DNS server on the Wi-Fi network I'm connected to has > done something weird with the TTL. > This is what I get when querying one of the "gov." authoritative servers > directly: > $ dig -t ds bls.gov @a.ns.gov +norecurse > > ; <<>> DiG 9.18.18-0ubuntu2-Ubuntu <<>> -t ds bls.gov @a.ns.gov > +norecurse ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32241 ;; flags: qr > aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ;; QUESTION SECTION: > ;bls.gov. IN DS > > ;; ANSWER SECTION: > bls.gov.3600IN DS 50951 8 2 > E6B0A294066904F20A2B8EBA3FA9920F9A1822802977F59D706B30A1 77F7DC0C > > ;; Query time: 16 msec > ;; SERVER: 2001:503:ff40::1#53(a.ns.gov) (UDP) ;; WHEN: Thu Dec 07 > 09:19:24 NZDT 2023 ;; MSG SIZE rcvd: 84 This means when you remove > the DS record, it will take 1 hour to fully take effect (assuming no delay > replicating between authoritative servers). > Nick. > -- > 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: ma...@isc.org -- 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: dnssec-delegation seems to be broken from .gov to bls.gov
The problem has been resolved. The automatic KSK rollover on the dotgov.gov did not happen properly and once we manually updated the DS record with the correct KSK keytags and keys things were fixed. All is good now. Now to see if we can find out as to why the automatic KSK failover on the dotgov.gov did not happen correctly. Thanks Sandeep From: bind-users On Behalf Of Nick Tait via bind-users Sent: Wednesday, December 6, 2023 3:23 PM To: bind-users@lists.isc.org Subject: Re: dnssec-delegation seems to be broken from .gov to bls.gov CAUTION: This email originated from outside of BLS. DO NOT click (select) links or open attachments unless you recognize the sender and know the content is safe. Please report suspicious emails through the “Phish Alert Report” button on your email toolbar. On 7/12/2023 9:05 am, Nick Tait via bind-users wrote: I could be wrong, but based on the output above it looks like the current TTL is 0, which means that doing this should provide immediate relief. Sorry it looks like the DNS server on the Wi-Fi network I'm connected to has done something weird with the TTL. This is what I get when querying one of the "gov." authoritative servers directly: $ dig -t ds bls.gov @a.ns.gov +norecurse ; <<>> DiG 9.18.18-0ubuntu2-Ubuntu <<>> -t ds bls.gov @a.ns.gov +norecurse ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32241 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;bls.gov. IN DS ;; ANSWER SECTION: bls.gov.3600IN DS 50951 8 2 E6B0A294066904F20A2B8EBA3FA9920F9A1822802977F59D706B30A1 77F7DC0C ;; Query time: 16 msec ;; SERVER: 2001:503:ff40::1#53(a.ns.gov) (UDP) ;; WHEN: Thu Dec 07 09:19:24 NZDT 2023 ;; MSG SIZE rcvd: 84 This means when you remove the DS record, it will take 1 hour to fully take effect (assuming no delay replicating between authoritative servers). Nick. -- 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: dnssec-delegation seems to be broken from .gov to bls.gov
On 7/12/2023 9:05 am, Nick Tait via bind-users wrote: I could be wrong, but based on the output above it looks like the current TTL is 0, which means that doing this should provide immediate relief. Sorry it looks like the DNS server on the Wi-Fi network I'm connected to has done something weird with the TTL. This is what I get when querying one of the "gov." authoritative servers directly: $ dig -t ds bls.gov @a.ns.gov +norecurse ; <<>> DiG 9.18.18-0ubuntu2-Ubuntu <<>> -t ds bls.gov @a.ns.gov +norecurse ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32241 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;bls.gov. IN DS ;; ANSWER SECTION: bls.gov.3600IN DS 50951 8 2 E6B0A294066904F20A2B8EBA3FA9920F9A1822802977F59D706B30A1 77F7DC0C ;; Query time: 16 msec ;; SERVER: 2001:503:ff40::1#53(a.ns.gov) (UDP) ;; WHEN: Thu Dec 07 09:19:24 NZDT 2023 ;; MSG SIZE rcvd: 84 This means when you remove the DS record, it will take 1 hour to fully take effect (assuming no delay replicating between authoritative servers). Nick. -- 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: dnssec-delegation seems to be broken from .gov to bls.gov
On 7/12/2023 1:53 am, Bhangui, Sandeep - BLS CTR via bind-users wrote: Hi It seems the DNSSEC delegation is broken from “.gov” to bls.gov domain and due to which the records for bls.gov are considered as bogus and we are having issues at our site. It looks like we were in the process of KSK rollover and that may have caused the issue as things were fine till yesterday. As we troubleshoot this issue was wondering whether from our master DNS server can we use some option in named.conf so that dnssec verification is NOT done for any bls.gov DNS lookups from outside to get a quick fix to this problem. Currently DNS lookups from outside are flaky and I believe the reason behind that being that the DNSSEC delegation is broken. From the output at dnsviz.net analyzing for bls.gov it seems that KSK rollover for bls.gov is the issue. Basically, trying to see if I can get a quick interim fix till we resolve the issue correctly. Please advise. Thanks Sandeep Hi Sandeep. Probably the simplest workaround for broken chain of trust would be to remove your zone's DS records from the parent zone. $ dig -t ds bls.gov ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> -t ds bls.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27975 ;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;bls.gov. IN DS ;; ANSWER SECTION: bls.gov. 0 IN DS 50951 8 2 E6B0A294066904F20A2B8EBA3FA9920F9A1822802977F59D706B30A1 77F7DC0C ;; Query time: 0 msec ;; SERVER: 172.20.192.1#53(172.20.192.1) (UDP) ;; WHEN: Thu Dec 07 09:01:33 NZDT 2023 ;; MSG SIZE rcvd: 80 I could be wrong, but based on the output above it looks like the current TTL is 0, which means that doing this should provide immediate relief. Add a new DS record once you've fixed your KSK issues. Nick. -- 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
dnssec-delegation seems to be broken from .gov to bls.gov
Hi It seems the DNSSEC delegation is broken from ".gov" to bls.gov domain and due to which the records for bls.gov are considered as bogus and we are having issues at our site. It looks like we were in the process of KSK rollover and that may have caused the issue as things were fine till yesterday. As we troubleshoot this issue was wondering whether from our master DNS server can we use some option in named.conf so that dnssec verification is NOT done for any bls.gov DNS lookups from outside to get a quick fix to this problem. Currently DNS lookups from outside are flaky and I believe the reason behind that being that the DNSSEC delegation is broken. >From the output at dnsviz.net analyzing for bls.gov it seems that KSK rollover >for bls.gov is the issue. Basically, trying to see if I can get a quick interim fix till we resolve the issue correctly. Please advise. Thanks Sandeep -- 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
