Re: What does it mean "lame-servers: info: success resolving"?
Yeah, right. Thank you. However, does that allow to infer anything about the
result of the queries that were put a few seconds before the resolver reached
that conclusion?
Best
Ale
--
On Fri 01/Dec/2023 11:17:25 +0100 Mark Andrews wrote:
It means that the servers for the zone doesn’t fully implement the DNS
protocol. NS queries for intermediate names are not getting the expected
answer.
-- Mark Andrews
On 1 Dec 2023, at 21:10, Alessandro Vesely wrote:
Hi all,
I have this in BIND 9.18.19-1~deb12u1-Debian' logs:
north:log$ grep '148.19.188.64.list.dnswl.org' named-qu.log.0
30-Nov-2023 15:58:23.901 queries: info: client @0x7f281e72ff68 127.0.0.1#54827
(148.19.188.64.list.dnswl.org): view internal: query:
148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
30-Nov-2023 15:58:28.909 queries: info: client @0x7f281e6add68 127.0.0.1#54827
(148.19.188.64.list.dnswl.org): view internal: query:
148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
30-Nov-2023 15:58:30.357 queries: info: client @0x7f2817485f68 127.0.0.1#53802
(148.19.188.64.list.dnswl.org): view internal: query:
148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
30-Nov-2023 15:58:31.621 queries: info: client @0x7f281f459f68 127.0.0.1#53122
(148.19.188.64.list.dnswl.org): view internal: query:
148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
north:log$ grep '148.19.188.64.list.dnswl.org' named.log.0
30-Nov-2023 15:58:35.689 lame-servers: info: success resolving
'148.19.188.64.list.dnswl.org/A' after disabling qname minimization due to
'ncache nxdomain'
north:log$ grep '148.19.188.64.list.dnswl.org' named-dnssec.log.0
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: starting
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: attempting negative response validation from
message
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: in validator_callback_nsec
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: resuming validate_nx
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: nonexistence proof(s) not found
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: checking existence of DS at 'org'
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: checking existence of DS at 'dnswl.org'
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: marking as answer (proveunsecure (4))
The success arrived several seconds after. Does this mean that the (first)
queries failed? The dnssec log seems to indicate that the IP was not listed.
The queries in the first half of the 15:58 minute were part of an SPF evaluation. (The
SPF record contains an exists:%{ir}.list.dnswl.org mechanism.). The SPF evaluation
returned "error". I'm trying to understand whether the cause was a DNS hiccup.
Is this a kind of error that could be orchestrated remotely?
TIA
Ale
--
--
Visithttps://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 athttps://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
What does it mean "lame-servers: info: success resolving"?
Hi all,
I have this in BIND 9.18.19-1~deb12u1-Debian' logs:
north:log$ grep '148.19.188.64.list.dnswl.org' named-qu.log.0
30-Nov-2023 15:58:23.901 queries: info: client @0x7f281e72ff68 127.0.0.1#54827
(148.19.188.64.list.dnswl.org): view internal: query:
148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
30-Nov-2023 15:58:28.909 queries: info: client @0x7f281e6add68 127.0.0.1#54827
(148.19.188.64.list.dnswl.org): view internal: query:
148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
30-Nov-2023 15:58:30.357 queries: info: client @0x7f2817485f68 127.0.0.1#53802
(148.19.188.64.list.dnswl.org): view internal: query:
148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
30-Nov-2023 15:58:31.621 queries: info: client @0x7f281f459f68 127.0.0.1#53122
(148.19.188.64.list.dnswl.org): view internal: query:
148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
north:log$ grep '148.19.188.64.list.dnswl.org' named.log.0
30-Nov-2023 15:58:35.689 lame-servers: info: success resolving
'148.19.188.64.list.dnswl.org/A' after disabling qname minimization due to
'ncache nxdomain'
north:log$ grep '148.19.188.64.list.dnswl.org' named-dnssec.log.0
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: starting
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: attempting negative response validation from
message
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: in validator_callback_nsec
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: resuming validate_nx
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: nonexistence proof(s) not found
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: checking existence of DS at 'org'
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: checking existence of DS at 'dnswl.org'
30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
148.19.188.64.list.dnswl.org/A: marking as answer (proveunsecure (4))
The success arrived several seconds after. Does this mean that the (first)
queries failed? The dnssec log seems to indicate that the IP was not listed.
The queries in the first half of the 15:58 minute were part of an SPF evaluation. (The
SPF record contains an exists:%{ir}.list.dnswl.org mechanism.). The SPF evaluation
returned "error". I'm trying to understand whether the cause was a DNS hiccup.
Is this a kind of error that could be orchestrated remotely?
TIA
Ale
--
--
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
Local network IPv6 addresses
Hi, DHCP server has options to insert leased addresses in a dynamic zone. That works for IPv4. PCs connected to the LAN somehow discover the gateway has a routable IPv6 address and self-assign an address in that range, besides the fe80:: thing, without talking to a DHCP server. Is there a method to get those addresses into the DNS? Apologies if this is the wrong list to ask. Best Ale -- -- 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: Controlling which interface named uses
On Sat 10/Jun/2023 19:32:31 +0200 Ondřej Surý wrote: The other approach might be the up/down scripts on your ppp connection that will reconfigure the query-source(-v6) address as the connection is established or tore down. Cute! Thank you. Best Ale -- -- 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: Controlling which interface named uses
On Fri 09/Jun/2023 18:32:25 +0200 Anand Buddhdev wrote: On 09/06/2023 17:26, Alessandro Vesely wrote: Having two WANs, it would be reasonable, in case one doesn't work, to try the other one. However, it's always useless to try the LAN. Is there any way to configure which interface is used for outgoing queries? You can configure "query-source" and "query-source-v6" in named.conf, to tell BIND which interface to use for outgoing queries. Thank you, Anand; I hadn't found those statements. However, they take a single address only. I'm not as much concerned about IP version as about availability. Enabling IPv6 looks nice as I see queries going out through an interface which is not the default. But will named turn back to the default interface in case the IPv6 link goes down? Keep in mind that links sometimes seem to be up, as they're connected to a PPP peer or router, for example, but don't actually work. Knowing that UDP entails multiple attempts, it would be great to have, say, even attempts on wan0 and odd ones on wan1. If that's not possible, perhaps I could look for ways to configure it using dscp. Any hint? Best Ale -- -- 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
Controlling which interface named uses
Hi, I have two WANs. As a leftover from the times when I had no IPv6 address, I was running named with -4 option. I just removed it a couple of minutes ago. However, I still have IPv4 precedence in gai.conf: precedence ::1/128 50 0 precedence ::/0 40 1 precedence 2002::/16 30 2 precedence ::/96 20 3 precedence :::0:0/96100 4 Before removing -4, I had the problem that when the interface to the default route was down, named couldn't resolve any query. The problem disappeared because the routable IPv6 addresses are on the other WAN. But what is going to happen when it goes down? It seems named only uses IPv6 to resolve queries, gai.conf notwithstanding. Having two WANs, it would be reasonable, in case one doesn't work, to try the other one. However, it's always useless to try the LAN. Is there any way to configure which interface is used for outgoing queries? Best Ale -- -- 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
Independent DNS cache in mail servers
Hi, I forked libopendkim, an abandonware library implementing DKIM signatures for email messages. It has a QUERY_CACHE compile-time option which enables usage of a Berkeley DB to store DKIM keys. If the option is enabled, the local cache is looked up before querying the DNS, and keys are cached after retrieving them from DNS. TTLs are also cached and checked. That happens on each received email message. I never used that option. I think a mail server deserves a dedicated caching resolver. However, a user of mine succeeded, with some difficulty, to enable that option, although he says he doesn't know whether it's actually useful. Hence I thought to ask here about opinions: Is QUERY_CACHE a totally useless code bloat that I should remove? Or is it possibly useful and I should integrate it better? DKIM keys typically use RSA, resulting in fatty keys, but usually within UDP sizes. Albeit someone generates a new key for every message, most domains use the same key for months if not years. Nevertheless, TTLs range from a few minutes to a few hours. What you think? Best Ale -- -- 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: Documentation suggestion for Ubuntu PPA http://ppa.launchpad.net/isc/bind/ubuntu
On Wed 23/Nov/2022 16:54:56 +0100 Niall O'Reilly wrote: With "APT-Sources: http://ppa.launchpad.net/isc/bind/ubuntu focal/main amd64 Packages", the file /usr/share/doc/bind9/README.Debian recommends: Zones subject to automatic updates (such as via DHCP and/or nsupdate) should be stored in /var/lib/bind, and specified with full pathnames. Do I understand correctly that this advice also applies to zones for which a dnssec-policy and inline-signing (rather than update-policy) are specified? If so, it might be well to extend the parenthesis "(such as ...)" to mention this case also. Wouldn't it be possible to store just the signed stuff (.jnl, .jbk) in /var/lib? That directory is not used in current releases. I have: $ ls -lt /var/lib/bind total 4 -rw-r--r-- 1 root root 53 May 14 2013 bind9-default.md5sum Best Ale -- -- 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: Mailing list questions (DMARC, ARC, more?)
Hi Dan, On Sat 24/Sep/2022 01:10:12 +0200 Dan Mahoney wrote: On Aug 23, 2022, at 07:39, G.W. Haywood via bind-users wrote: On Tue, 23 Aug 2022, Alessandro Vesely wrote: I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? We check the ARC seal and I would be alerted to a failure. That's all. Are there other advantages that ARC brings about? It's a comfort to know that it's all working as designed, but I can't get excited about munged addresses. Otherwise, RFC9057 introduced the Author: header field. Using it to save the original From: would allow trusting receivers to de-munge the message at a later stage. I'm happy to use cut'n'paste for replies, but I can offer to help you with your testing. The milters here can do more or less anything. :) Hey there GW (and others). [...] * We're trying not to deal with the blowback that would occur if we *just decided to* one day start munging everyone's mail addresses. Lots of people would start posting about not-bind-things. Like this :) I apologize again for wasting bandwidth on non-DNS issues. While munging everyone would look more coherent, I propose to stop munging everyone, at least as an option for those recipient who accept broken DMARC. * Mailman 2.x (which we run) has some sender-munging features that have been necessary in the past to ensure delivery, but they haven't been the only problem. We're presently only doing those on domains with p=reject (or p=quarantine, which is rare). ARC was designed to avoid this. [...] DKIM Validation/Arc Sealing: * Everything gets validated at our MXes. However, the list doesn't seem to apply DMARC policies on entry. It would have to be, because only the MX has access to the IP address info required to check SPF. That's the right way to do it. Let me quote Mailman developers about doing ARC sealing: 1. It's a bad idea to do it in Mailman. 2. It was implemented in Mailman 3 three or four years ago as a proof of concept during the development of ARC. 3. There is a milter available for Postfix and Sendmail from the Trusted Domain Project https://github.com/trusteddomainproject/OpenARC as is the basic implementation which I presume is adaptable to Exim, qmail, and other MTAs. This is the preferred approach, as matter of conformance because it should be implemented by the edge MTA(s), and as a practical matter because Mailman *can't* do SPF since it is never an edge MTA. There is also a pure Python implementation on PyPI, I believe (this is the basis for the Mailman 3 plugin, or maybe it was dkimpy). https://mail.python.org/archives/list/mailman-develop...@python.org/message/RLSANJHTFTYQPAQQIBAOK3VDM3U4E5EU/ [...] ARC on lists: * The logic I applied is: What if a message comes in from sender X, is modified through listserv Y, and is sent out to subscribers Z[n]. We want to assert that we received the message with headers A, B, and C, and validated them, and even if they'd been re-written (as often happens on mailing lists) that they were valid at each point in the step. Thus, yes, you need two arc-seals, one in each point where there's a handoff and potential message modification. Can internal handoff modify the message? (Except Mailman, I mean.) [...] To the best of my knowledge, we're the only folks doing this -- mailman 3 is supposed to implement its own arc-sealing, but 2.x won't ever. Mailman 2.x is largely EOL (but receiving security fixes -- XKCD 2347 applies) but there's movements to port it to work on a more modern python. As pointed out above, ARC should not be done by Mailman in any case. For the record, dnswl-users also do ARC sealing. In 2016 they stopped modifying messages, and hence they don't do From: munging. If people want to ask me questions directly, I'm here. And on mailop. What I want to ask is to experiment sending messages without From: munging. That would entail setting up a twin mailing list, configured to not do From: munging. Users would subscribe to the latter if their MX accepts broken DMARC, possibly because of ARC, or some other authentication, or even no authentication check at all; presumably users who can get their hands on their MTA, not Gmail accounts. The idea is outlined as the first one of three methods to get rid of From: munging, here: https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform Best Ale -- -- 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: Mailing list questions (DMARC, ARC, more?)
On Sat 24/Sep/2022 00:23:03 +0200 Matus UHLAR - fantomas wrote: another test done Thanks for reporting. This is slightly OT, as it concerns the list functioning rather than DNS. I hope it doesn't afflict... I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. On 25.08.22 18:10, Alessandro Vesely wrote: Please tell us. On Fri 02/Sep/2022 14:27:55 +0200 Matus UHLAR - fantomas wrote: so far, not ex - opendmarc only uses header that's inserted by openarc milter - openarc milter for bind-users inserts arc.chain="isc.org:isc.org:isc.org" On 04.09.22 12:56, Alessandro Vesely wrote: They produce an ARC set on each internal passage, all having d=isc.org. That's undoubtedly redundant, yet valid. I haven't studied the ARC standard, but this looks correct. However, I was repeatedly unable to make opendmarc to accept arc result: Authentication-Results: fantomas.fantomas.sk; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: fantomas.fantomas.sk; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=itqgpF3K; dkim-atps=neutral IMHO, it is correct to say dkim=fail, but DMARC should have been redeemed by ARC if trusted. Authentication-Results: [...] Authentication-Results: fantomas.fantomas.sk; arc=pass smtp.remote-ip=149.20.1.60 arc.chain="isc.org:isc.org:isc.org" That arc=pass doesn't say if it was trusted or not. As you say, trust doesn't seem to make any difference. Paradoxical. From: frank picabia Gmail has p=none. However, I tried to send to this list an unauthenticated message from a domain with p=reject and spf-all. It was rejected by: 550 5.7.1 Blocked by SpamAssassin That looks like accumulating a score, not a formal rejection after policy requirements. - opendmarc seems to ignore "DomainWhitelist isc.org" perhaps I need to put isc.org:isc.org:isc.org (will try) I have tried both, no result. There is a school of thought according to which receivers should blindly trust ARC headers, except spam or known bad actors. When enabled, arc=pass should override dmarc=fail p=reject. We never get this, because bind-users rewrite From: if author's domain has p=reject. This should not be a problem, since we should trust isc.org servers when they provide wortking ARC-Seal: Yes, but we still receive munged From:'s. The idea was that with ARC they could be avoided. The way to do it is the 1st method in my draft[*], but I cannot find a list willing to experiment. Trusting isc.org should suffice. Logically, when multiple domains applied message modifications, a receiver has to trust all of them. Not necessarily any disposition of them. do you mean, I should trust all domains in ARC-Seal, listed in Authentication-Results header? RFC8617 talks about "sealing domain" of a given ARC set, surmising that the d= tag should have the same value in ARC-Seal and ARC-Message-Signature. - openarc (I have installed beta from debian experimental) seems to insert Authentication-Result: header when no ARC seal is present, though not always. - arc for bind-users seems to fail when mailman rewrites From: header (but DKIM is fine in this case) I tried the Perl ARC verifier included in Mail::DKIM. On your message it outputs: ale@pcale:~/tmp$ arc-verify.pl < arc1.eml this is not in debian distribution. when tried it, it shows correct: uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arc1.eml RESULT: pass uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arctest RESULT: pass however, I was unable to make my dkim/dmarc PASS on a mail from this list that was: - arc-signed by ISC - DKIM fail (not munged) The header is ok, but the body has an added footer. Using zdkimfilter (3rd method in that draft[*]) I get the following on your message: INFO: zfilter: zdkimfilter[13097]:ip=NULL: domain isc.org whitelisted by list.dnswl.org DEBUG: zfilter: zdkimfilter[13097]:ip=NULL: retrieved fantomas.sk->fantomas: rsa-sha256, 2048 bits INFO: zfilter: zdkimfilter[13097]:ip=NULL: enabling body parse (sigs pass: 1, could pass: 0) INFO: zfilter: zdkimfilter[13097]:ip=NULL: enabling retry (badsig, bh ok: 0; badsig, bh bad: 0; pass, bh bad: 1) INFO: zfilter: zdkimfilter[13097]:ip=NULL: transformation enabled for "Matus UHLAR - fantomas " retry body only INFO: zfilter: zdkimfilter[13097]:ip=NULL: transform message from base64 back to identity with footer. INFO: zfilter: zdkimfilter[13097]:ip=NULL: sig failure d
Re: Mailing list questions (DMARC, ARC, more?)
On Sun 04/Sep/2022 14:17:25 +0200 Benny Pedersen wrote: ARC-Authentication-Results: i=1; mx.pao1.isc.org; dmarc=pass (p=none dis=none) header.from=tana.it; spf=pass smtp.mailfrom=tana.it; dkim=permerror (0-bit key) header.d=tana.it header.i=@tana.it That stanza is faulty. The key at epsilon._domainkey.tana.it is 256 bits, like all ed25519 keys, not 0. Presumably ISC's DKIM filter doesn't support RFC8463. header.b=j8VJHYFh; dkim=pass (1152-bit key; unprotected) header.d=tana.it header.i=@tana.it header.b=DBspF3JP The second signature, rsa, succeeds. However, why unprotected? Presumably the library used by ISC's DKIM filter doesn't support DNSSEC. you have a invalid dkim signing, fix that Nothing to fix on my side. note you on top of that dkim double sign one is working, one is failing That's why I put two. Best Ale -- -- 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: Mailing list questions (DMARC, ARC, more?)
On Fri 02/Sep/2022 14:27:55 +0200 Matus UHLAR - fantomas wrote: On 25.08.22 18:10, Alessandro Vesely wrote: I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. Please tell us. so far, not ex - opendmarc only uses header that's inserted by openarc milter - openarc milter for bind-users inserts arc.chain="isc.org:isc.org:isc.org" They produce an ARC set on each internal passage, all having d=isc.org. That's undoubtedly redundant, yet valid. - opendmarc seems to ignore "DomainWhitelist isc.org" perhaps I need to put isc.org:isc.org:isc.org (will try) When enabled, arc=pass should override dmarc=fail p=reject. We never get this, because bind-users rewrite From: if author's domain has p=reject. Trusting isc.org should suffice. Logically, when multiple domains applied message modifications, a receiver has to trust all of them. Not necessarily any disposition of them. - openarc (I have installed beta from debian experimental) seems to insert Authentication-Result: header when no ARC seal is present, though not always. - arc for bind-users seems to fail when mailman rewrites From: header (but DKIM is fine in this case) I tried the Perl ARC verifier included in Mail::DKIM. On your message it outputs: ale@pcale:~/tmp$ arc-verify.pl < arc1.eml ARC-Seal: v=3 pass ARC-Message-Signature: v=3 pass ARC-Seal: v=2 pass ARC-Message-Signature: v=2 fail (body has been altered) ARC-Seal: v=1 pass ARC-Message-Signature: v=1 fail (body has been altered) (arc-verify.pl is a copy of the module's synopsis[*].) Then I tried it on Ged's message, earlier in this thread, and got: ale@pcale:~/tmp$ arc-verify.pl < arc2.eml ARC-Seal: v=3 pass ARC-Message-Signature: v=3 pass ARC-Seal: v=2 pass ARC-Message-Signature: v=2 fail (message has been altered) ARC-Seal: v=1 pass ARC-Message-Signature: v=1 fail (message has been altered) So both messages seem to be valid, if you trust isc.org. The failure in the signature reflects that only the body was altered in your message, while also the header was altered in Ged's one. As ARC allows mediators to modify messages, only the last signature is significant. Mailman should know about your setting in order to skip From: munging in the copies sent to you. Currently, the copies sent to pipermail for archiving seem to be non-munged, so this functionality exists. do you mean I can turn off From: munging in mail sent to me? Mailman options[†] don't include something like *From munging*: Set this option to /Disabled/ to receive messages with the original From: line intact. Keep in mind that disabling this option will fail DMARC, so keep it enabled unless your MTA either doesn't check DMARC or accepts ARC overrides. It doesn't seem difficult to implement. It requires trusting the users, though. I'm going to ask Mailman developers. Best Ale -- [*] https://metacpan.org/pod/Mail::DKIM::ARC::Verifier [†] https://lists.isc.org/mailman/options/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: Mailing list questions (DMARC, ARC, more?)
On Mon 29/Aug/2022 12:09:10 +0200 Matus UHLAR - fantomas wrote: On 25.08.22 18:10, Alessandro Vesely wrote: The lack of interest by others proves that From: munging is not so much of a nuisance as they say... This will come sooner or later, however: earlier this year I've done small dmarc research for our client: - microsoft software (on-premise exchange and 365) does not DKIM-sign DSN e-mail (delivery and non-delivery notifications) although those have sending domain in From: (I guess domain is added after sig generated) So do I, relying on SPF for DNSs. - only a few % of domains has other DMARC policy than none - mailman 2 (used here) only munges From: when domain DMARC policy for the sending domain is other than none. Which is insecure. While I keep p=none, anyone can post a spoof using my email address as From: and pretend to be me. It never happens, but some people believe it /cannot/ happen. I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. Please tell us. Mailman should know about your setting in order to skip From: munging in the copies sent to you. Currently, the copies sent to pipermail for archiving seem to be non-munged, so this functionality exists. Best Ale -- -- 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: Mailing list questions (DMARC, ARC, more?)
Thanks Ged for all the feedback. The lack of interest by others proves that From: munging is not so much of a nuisance as they say... Best Ale On Tue 23/Aug/2022 16:39:33 +0200 Bind Users wrote: Hi there, On Tue, 23 Aug 2022, Alessandro Vesely wrote: I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? When it comes to email, I don't trust *anything*. :) Generally speaking I think these technological fixes are very much over-engineered as compared with, say, inspecting the headers. :/ We check the ARC seal and I would be alerted to a failure. That's all. There have been two failures since ISC implemented ARC - the first two ARC-signed messages we received, on 25th April - all after that passed: Date: Mon, 22 Aug 2022 12:00:00 + X-ARCverify: pass (All ARC Seals and the most recent ARC Signature passed verification) There were a few DKIM failures in the early days too, I don't remember if I investigated any of the failures. In that case, do they get non-munged messages? Nope. I'm on the digest list anyway. Are there other advantages that ARC brings about? It's a comfort to know that it's all working as designed, but I can't get excited about munged addresses. I've experienced no issues on the BIND list to which I've thought ARC might be relevant. Unfortunately that's by no means the case for some of the other lists to which I am (or have in the past been) subscribed. Otherwise, RFC9057 introduced the Author: header field. Using it to save the original From: would allow trusting receivers to de-munge the message at a later stage. I'm trying to elaborate a draft[*] to formalize such method. Would this list be interested in experimenting that? I'm happy to use cut'n'paste for replies, but I can offer to help you with your testing. The milters here can do more or less anything. :) PS: Please don't be offended if mail sent directly to me is rejected. We can get around it. PPS: [Page 18] s/Content-Tyep:/Content-Type:/; -- 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
Mailing list questions (DMARC, ARC, more?)
Hi all and list admins, I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? In that case, do they get non-munged messages? Are there other advantages that ARC brings about? Otherwise, RFC9057 introduced the Author: header field. Using it to save the original From: would allow trusting receivers to de-munge the message at a later stage. I'm trying to elaborate a draft[*] to formalize such method. Would this list be interested in experimenting that? Best Ale -- [*] https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ -- 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 questions
On Thu 28/Oct/2021 09:34:42 +0200 Matthijs Mekking wrote: On 27-10-2021 18:48, Alessandro Vesely wrote: 3. The server produces new .signed and .signed.jnl files every day, which is inconvenient as the zone files directory is checked by tripwire. Is that timing determined by the dnskey-ttl? Would it be okay to set it to one month? The zone is signed if a signature is about to expire. It is not determined by dnskey-ttl. I would exclude these files from tripwire because they need to written out anyway. Then, why does it have to rewrite it every day, if the zone didn't change? dnskey-ttl is the only one-day timing thing, except parent-ds-ttl. It shouldn't. It should only rewrite if there are changes, for example due to zone updates or due to resigning. Nope. It logs these lines: 28-Oct-2021 04:50:23.230 notify: info: zone ext.tana.it/IN/external: sending notifies (serial 2009110701) 28-Oct-2021 04:50:23.318 general: info: zone tana.it/IN/external (signed): receive_secure_serial: unchanged 28-Oct-2021 04:50:23.374 notify: info: zone tana.it/IN/external (signed): sending notifies (serial 2021102409) 28-Oct-2021 04:50:23.390 general: info: zone tana.it/IN/internal (signed): receive_secure_serial: unchanged (Note that the serial for both views is 2021101902. I don't know where th logged numbers come from.) And then Access/Modify/Change dates of .signed and .signed.jnl are 2021-10-28 04:50:47.0 +0200. Furthermore, all the files in the keys directory, .key, .private, .state, are marked 12:50 today, which is a few minutes ago. All, except the ones for a zone still in "auto-dnssec maintain" mode, and has no .state. The log says nothing about this. How can I investigate why? I run BIND 9.16.15-Debian (Stable Release) . BTW, DS RR has a ttl of 10800 at the parent; should I copy that to parent-ds-ttl in my policy definition? Yes. Done. However, I don't think I'll notice if they change it. What for? To make sure the key rollovers are timed correctly. In addition, I took a closer look at your policy. publish-safety P3W; retire-safety P3W; The publish-safety and retire-safety are intended to be small margins added to rollover timings to give some extra time to cover unforeseen events. The defaults are 1 hour. Maybe you have good reasons to set them to 3 weeks, but it is remarkably long. I thought if "unforeseen events" require manual intervention, I might be in a hospital for a liver transplant, say, and need 3 weeks to be dismissed. Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC questions
Hi Matthijs, thanks for clarifications. On Wed 27/Oct/2021 17:53:46 +0200 Matthijs Mekking wrote: On 27-10-2021 12:54, Alessandro Vesely wrote: I also switched to dnssec-policy. Somewhere I read that I should have defined a policy with keys matching the existing keys. I also defined a "combined" key. Now I have two DS, two CDS, and two CDNSKEY RRs. I attach a picture of a zone and paste the policy below. Adding the combined key to the policy means you did not create a policy that matched the existing keys. BIND notices that you want three keys, you only have two, so it creates the CSK. Yup, the intention was (and still is) to migrate to CSK, as it's simpler, without breaking existing status. So now I need to get rid of the old keys. 1. Now, how do I get rid of the extra ksk and zsk? Is it enough to remove them from the policy? You can remove them from the policy yes, but make sure the migration is complete. You can check with "rndc dnssec -status " and make sure that your key states are in "omnipresent". Thanks, that's what I was looking for. I have to check all zones (and two views each). I'll write a script for that. 2. I have double CDS/CDNSKEY records, but they're not in the zone files. Do I have to run rndc dnssec -checkds to remove them? That's because you added the additional CSK to the policy. It is probably best to remove it again from the policy and only change the policy if the migration is complete. Right. So the script must also check that the new keys have a parental DS. 3. The server produces new .signed and .signed.jnl files every day, which is inconvenient as the zone files directory is checked by tripwire. Is that timing determined by the dnskey-ttl? Would it be okay to set it to one month? The zone is signed if a signature is about to expire. It is not determined by dnskey-ttl. I would exclude these files from tripwire because they need to written out anyway. Then, why does it have to rewrite it every day, if the zone didn't change? dnskey-ttl is the only one-day timing thing, except parent-ds-ttl. BTW, DS RR has a ttl of 10800 at the parent; should I copy that to parent-ds-ttl in my policy definition? What for? 4. Is rndc managed-keys status supposed to display anything meaningful, given my setup? It talks about a non-existing key id. The sync option produces no output at all. How do I know the overall dnssec status? "rndc managed-keys status" is for trust anchors, use "rndc dnssec -status " instead. OK. Thanks again, Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC questions
Hi all,
I recently installed version 9.16, and have a number of doubts. During the
upgrade, named didn't want to load signed zones because of CDS/CDNSKEY
inconsistency. There were CDS records in the zone files, which I removed.
I also switched to dnssec-policy. Somewhere I read that I should have defined
a policy with keys matching the existing keys. I also defined a "combined"
key. Now I have two DS, two CDS, and two CDNSKEY RRs. I attach a picture of a
zone and paste the policy below.
The questions:
1. Now, how do I get rid of the extra ksk and zsk? Is it enough to remove them
from the policy?
2. I have double CDS/CDNSKEY records, but they're not in the zone files. Do I
have to run rndc dnssec -checkds to remove them?
3. The server produces new .signed and .signed.jnl files every day, which is
inconvenient as the zone files directory is checked by tripwire. Is that
timing determined by the dnskey-ttl? Would it be okay to set it to one month?
4. Is rndc managed-keys status supposed to display anything meaningful, given
my setup? It talks about a non-existing key id. The sync option produces no
output at all. How do I know the overall dnssec status?
Here's my policy setting:
dnssec-policy "explicit" {
// Keys
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk key-directory lifetime unlimited algorithm rsasha256 2048;
csk key-directory lifetime unlimited algorithm rsasha256 2048;
};
nsec3param iterations 1 optout false salt-length 16;
// Key timings
dnskey-ttl 86400;
publish-safety P3W;
retire-safety P3W;
purge-keys P1Y;
// Signature timings
signatures-refresh P2M;
signatures-validity P6M;
signatures-validity-dnskey P6M;
// Zone parameters
max-zone-ttl 86400;
zone-propagation-delay PT1H;
// Parent parameters
parent-ds-ttl 86400;
parent-propagation-delay PT1H;
};
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Address match lists syntax, was Managing localhost
Ooops, sorry. Please forget that. On Fri 25/Jun/2021 12:50:55 +0200 Alessandro Vesely wrote: However, named-checkconf doesn't complain. I could fix that by defining an acl named localhost. But do I need to? Now I tried to redefine and got: /etc/bind/named.conf.options:37: attempt to redefine builtin acl 'localhost' Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Address match lists syntax, was Managing localhost
Hi,
I found a number of allow-query {localhost;}; and similar stuff in my .conf
files. It doesn't seem to be allowed, since the manual says:
The elements which constitute an address match list can be any of the
following:
* an IP address (IPv4 or IPv6)
* an IP prefix (in `/' notation)
* a key ID, as defined by the key statement
* the name of an address match list defined with the acl statement
* a nested address match list enclosed in braces
However, named-checkconf doesn't complain. I could fix that by defining an
acl named localhost. But do I need to?
Best
Ale
--
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: No more support for windows
On Fri 04/Jun/2021 22:51:01 +0200 Ondřej Surý wrote: And if I had to answer the question whether I and my team should spend time improving BIND 9 just for everybody or invest the precious time into fixing yet another incompatibility between POSIX/SUSv2 and Windows world, I think the answer would be always: Let’s improve things for majority of our users. It’s just simple as that. Certainly you tried Cygwin and WSL[*]. What's wrong with them? (Isn't Windows a kind of Unix any more? ;-) Best Ale -- [*] https://docs.microsoft.com/en-us/windows/wsl/faq ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: FW: Preventing a particular type of nameserver abuse
On Wed 14/Apr/2021 00:37:22 +0200 Richard T.A. Neal wrote: Julien Salort wrote: Reading this thread, I considered simply enabling the fail2ban named-refused jail, but they advise against it because it would end up blocking the victim rather than the attacker. I'm happy to be corrected by more knowledgeable people than me, but I don't necessarily agree with fail2ban's recommendation. By blocking traffic to the victim (which is what I'm doing by blocking traffic from the spoofed Source IP, because no inbound traffic means no outgoing replies) then I'm helping to protect the victim, or at least prevent my server being used in the reflection attack against that victim. That behavior might expose the victim to some kind of spear DoS. If the attackers know the victim is going to seek services from .myzone, they can spray the authoritative servers of .myzone with illegal requests apparently coming from the victim's resolvers. That way, when the victim tries to resolve needed.service.myzone it will be DoSsed. Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RES_TRUSTAD, was Trying again on SERVFAIL
On Thu 11/Feb/2021 17:44:20 +0100 Havard Eidnes wrote: Yeah, by the time it lands on Debian's glibc we'll have grown a long long beard. I'm still missing RES_TRUSTAD... Oh, this set me off on a tangent. I hadn't heard of RES_TRUSTAD before, so I found https://man7.org/linux/man-pages/man5/resolv.conf.5.html which under "trust-ad" contains this text: If the trust-ad option is active, the stub resolver sets the AD bit in outgoing DNS queries (to enable AD bit support), [...] It's similar to dig's man page: +[no]adflag Set [do not set] the AD (authentic data) bit in the query. This requests the server to return whether all of the answer and authority sections have all been validated as secure according to the security policy of the server. AD=1 indicates that all records have been validated as secure and the answer is not from a OPT-OUT range. AD=0 indicate that some part of the answer was insecure or not validated. This bit is set by default. I could not get that to rhyme with what I had perceived to be the semantics of the AD bit, so I looked up RFC 4035 where near the end of section 3 (just before 3.1), I find this text: The AD bit is controlled by name servers; a security-aware name server MUST ignore the setting of the AD bit in queries. That's the name server, not the resolver. So ... I can't get the glibc behaviour to mesh with the standard on this particular point. It's set in RFC 6840: 5.7. Setting the AD Bit on Queries The semantics of the Authentic Data (AD) bit in the query were previously undefined. Section 4.6 of [RFC4035] instructed resolvers to always clear the AD bit when composing queries. This document defines setting the AD bit in a query as a signal indicating that the requester understands and is interested in the value of the AD bit in the response. This allows a requester to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit. Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying again on SERVFAIL
On Thu 11/Feb/2021 14:47:13 +0100 Ondřej Surý wrote: Mark is right. The internet isn’t always on and it isn’t only composed of big tech companies with lots of resources. The internet consists of lot small systems made by people like you and me and we don’t have infinite resources to keep everything always on. 100% agreed. And honestly I find your quote about Cargo Cult very offensive to all those normal people maintaining the rest of the internet infrastructure that isn’t the current -umvirate. I don't share that point of view. I cited it as evidence of a way of thinking. I find it somewhat green, happy-go-lucky, but not offensive. After all, if you limit the range to personal messages, it's a legitimate way to conceive email services. Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying again on SERVFAIL
On Wed 10/Feb/2021 22:38:05 +0100 J Doe wrote: Out of curiosity, what servers have you encountered that no longer use the five day cutoff ? I didn't take note, but I read discussions on the topic. Users expect mail to be delivered almost instantly. The "warning, still trying" messages should come sometime in between. If it comes the next day, by various people's experience, it is unacceptably too late. If you reduce that to a few hours, the total max queue lifetime cannot remain five days. At mine, although I keep the default 5d, I cut queue time for specific messages, such as complaints or dmarc reports, to ten hours. Quoting from the web: Queue lifetimes over a day is just Cargo Cult system administration, and a holdover from when the internet was much less "always on". https://serverfault.com/questions/735269/is-it-a-good-idea-to-reduce-the-give-up-time-for-e-mail-delivery#answer-826351 Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying again on SERVFAIL
On Thu 11/Feb/2021 10:44:58 +0100 Havard Eidnes wrote: Still, being able to differentiate a local network congestion from a remote bad configuration would help. That's true. There's https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16 which look promising, trying to make it possible to distinguish between the various reasons a recursor might choose to return a SERVFAIL response. It uses an EDNS option to communicate the additional information. Commendable effort! As for its implementation status in general or in BIND in particular I'll admit that I don't know off-hand. Yeah, by the time it lands on Debian's glibc we'll have grown a long long beard. I'm still missing RES_TRUSTAD... Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying again on SERVFAIL
Hi Havard, thanks for your reply. On Tue 09/Feb/2021 18:15:43 +0100 Havard Eidnes wrote: is there a way to know that a query has already been tried a few minutes ago, and failed? From whose perspective? A well-behaved application could remember it asked the same query a short while ago, of course, but that's up to the application. For an application, caching queries feels like stealing the resolver's job. Or is the perspective that of a recursive resolver? As far as I remember, BIND used as a recursive resolver will "cache" this knowledge, but I'm not entirely certain for how long, since it can't use the method from an NXDOMAIN reply which includes the SOA record (and uses the re-purposed "minimum" field for the TTL for the negative cache entry). I too recall that NXDOMAIN can be cached for a while. I'd guess some kinds of failures are also cached. It happens seldomly, but sometimes the DKIM mail filter gets a SERVFAIL when it tries to authenticate an incoming message. SERVFAIL occurs when DNSSEC check fails. ...or when none of the name servers for the containing zone responds with an answer. I.e. it's not *just* DNSSEC failure which can trigger SERVFAIL. Yes, of course. Yet, however sporadic, DNSSEC failure seems to be the most frequent case. Trying again is useless, it has to be treated as a permanent error. Well, now... Basically nothing in the DNS is permanent, because it is not completely static; hence most information in the DNS has a TTL attached to it. So the question then becomes how an application, say a mail server should treat SERVFAIL. It may very well be that the "maximum retry time" of the mail server is far longer than any of the TTLs for the pieces of DNS data that you could not look up, so it may be appropriate to treat SERVFAIL as a signal to "re-queue the message and try again in 30 minutes", so in essence converting SERVFAIL into a "temporary failure" in the context of the mail server. That's what I've been doing. For an incoming message, a temporary failure means replying a 4xx code. The sender keeps the message in its queue, and eventually gives up. Once upon a time, MTAs used to retry sending for five days. Nowadays, several servers don't let queued messages grow older than one day. In the most severe case, a failed DKIM signature might entail a reject. So the best course of action seems to be to reserve temporary failures to this case. Still, being able to differentiate a local network congestion from a remote bad configuration would help. Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Trying again on SERVFAIL
Hi, is there a way to know that a query has already been tried a few minutes ago, and failed? It happens seldomly, but sometimes the DKIM mail filter gets a SERVFAIL when it tries to authenticate an incoming message. SERVFAIL occurs when DNSSEC check fails. Trying again is useless, it has to be treated as a permanent error. Any idea about how to tell a really temporary error? Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Getting "query failed (REFUSED) for ./IN/ANY"
On Wed 13/Jan/2021 14:31:58 +0100 John Kristoff wrote: Some may be sourced from a security/research survey project, but some sources performing this may be for more nefarious purposes - building a list of open resolvers that will answer for the purposes of maintaining an amplication/reflection hit list. I see some IPs are the same. However, my attacker seems rather to be (blindly) attempting an amplification attack than building a list of open resolvers, because the same IP is usually retried 4~6 times. Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Getting "query failed (REFUSED) for ./IN/ANY"
On Wed 13/Jan/2021 11:03:01 +0100 Matus UHLAR - fantomas wrote: On 13.01.21 10:21, Alessandro Vesely wrote: Are the queries refused because of the dot (.)? In the query log, I also found some 28 IN ANY queries from 7 IPs for xxx.at.fragolina.it, which probably got away with a NXDOMAIN. no. the dot is just the root domain. I see. This morning, queries for IN ANY are filling up a 63% of total queries. Named seems to be pretty quick at discarding them. I'm wondering whether it takes more resources to track and firewall those IPs or just ignore them. fail2ban should help not to see those messages Ditto for grep -v :-) I use a sort of fail2ban-lite, but hadn't bothered to firewall UDP. Indeed, if the intent is an amplification attack, the IPs I'd find are those of the victims, not the attackers. I'd be also curious of what they are after. Is there a protest against RFC 8482? It looks pretty nonsensical. Any insight? often, nameservers respond with list of delegations for this query: % dig +noall +stats -t any . @localhost ;; Query time: 17 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jan 13 11:01:08 CET 2021 ;; MSG SIZE rcvd: 2272 this way, server will respond with >2KB packet which may flood the destination IP. Aha, thanks for the tip! That may make sense, except that the server won't amplify: ; <<>> DiG 9.16.1-Ubuntu <<>> @north.tana.it . any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 29022 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ee8e36f499f24056c063244b5ffece98904d8e19b39c94a8 (good) ;; QUESTION SECTION: ;. IN ANY ;; Query time: 287 msec ;; SERVER: 62.94.243.227#53(62.94.243.227) ;; WHEN: mer gen 13 11:42:32 CET 2021 ;; MSG SIZE rcvd: 56 Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Getting "query failed (REFUSED) for ./IN/ANY"
Hi,
I'm getting lots of log lines like the following:
Jan 12 04:35:18 30 north named[22233]: client @0x7fe0fc2a3b80 74.74.74.8#24048
(.): view external: query failed (REFUSED) for ./IN/ANY at
../../../bin/named/query.c:7144
Jan 12 04:35:18 30 north named[22233]: client @0x7fe0fc2784d0 74.74.74.8#24048
(.): view external: query failed (REFUSED) for ./IN/ANY at
../../../bin/named/query.c:7144
Jan 12 04:35:27 30 north named[22233]: client @0x7fe0fc2953f0 74.74.74.8#57620
(.): view external: query failed (REFUSED) for ./IN/ANY at
../../../bin/named/query.c:7144
Is that meant to be a DoS attack?
Yesterday I got 42639 of those, from 41 different IPs, the most frequent
clients looking like so:
821-north:~$ sed -rn 's/^.{15} 30 north named[^:]*: client @0x[0-91-f]*
([0-9.]*)#[0-9]* ...: view external: query failed .REFUSED. for ..IN.ANY at
.bin.named.query.c:7144/\1/p' < /var/log/daemon.log.0 |sort |uniq -c
|sort -rn |head
4957 68.42.225.19
2914 73.73.73.73
2868 24.21.125.251
2783 193.70.81.112
2440 73.73.3.73
2273 101.71.138.9
2032 74.74.74.8
1814 98.25.235.45
1785 209.94.134.20
1756 73.109.143.81
I looked up some of these on AbuseIPDB, and I see there are a few people
reporting them for the same DDoS.
Are the queries refused because of the dot (.)? In the query log, I also found
some 28 IN ANY queries from 7 IPs for xxx.at.fragolina.it, which probably got
away with a NXDOMAIN.
This morning, queries for IN ANY are filling up a 63% of total queries. Named
seems to be pretty quick at discarding them. I'm wondering whether it takes
more resources to track and firewall those IPs or just ignore them.
I'd be also curious of what they are after. Is there a protest against RFC
8482? It looks pretty nonsensical. Any insight?
Best
Ale
--
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: How can I launch a private Internet DNS server?
On Thu 05/Nov/2020 12:59:37 +0100 Michael De Roover wrote: On Thu, 2020-11-05 at 11:31 +0100, Alessandro Vesely wrote: A good secondary offloads your server noticeably, and keeps the domain alive in case of temporary failures. AFAIK, authoritative slave servers are only used when the master is confirmed to be down. Lookups take significantly longer in such cases since for every request, the master will be asked first. This can take between 2-4s. There are no performance benefits to running multiple name servers as master-slave, though it's fairly easy and offers good redundancy (a slow lookup is still better than no lookup). IME, slave servers[*] are queried all the time, and since they have a better connection than I do, they reply faster. A commercial service will have to support zone transfer from your master, and said master has to have that commercial service authorized to pull your zone(s). Yes I haven't personally heard of such services, and would probably just run another BIND box somewhere else (different hosting provider or something like that). It costs much more. Best Ale -- [*] Oops, *secondary* servers --they said not to use /slave/ since gone with the wind was censored, lest the DNS gets censored as well... Oh gosh! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How can I launch a private Internet DNS server?
On Thu 15/Oct/2020 18:57:16 +0200 Jason Long via bind-users wrote: Excuse me, I just have one server for DNS and that tutorial is about secondary DNS server too. Just skip the chapter about the secondary. You're better off buying secondary DNS services externally. A good secondary offloads your server noticeably, and keeps the domain alive in case of temporary failures. Best Ale On Thu, Oct 15, 2020 at 8:15 PM, Michael De Roover wrote: There are various tutorials online for making authoritative DNS servers, such as this one: https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-an-authoritative-only-dns-server-on-ubuntu-14-04 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How can I launch a private Internet DNS server?
On Thu 15/Oct/2020 20:59:32 +0200 Stephane Bortzmeyer wrote: On Thu, Oct 15, 2020 at 11:16:05AM -0700, Fred Morris wrote a message of 50 lines which said: 2) If you want to run your own DNS nameservers, you will need to buy a book, read the (BIND) Administrator's Reference Manual, and/or some RFCs Very bad advice. RFCs are not for the faint of heart and the RFC on DNS (RFC 1034 and 1035) are among the most difficult. And they were never kept up-to-date so there are a lot of obsolete things in it. Yet, some RFCs seem to make for a good introductory course. For example: https://tools.ietf.org/html/rfc8499 Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Deconstructing the Great Firewall of China
On 2020-06-05 9:29 p.m., Paul Kosinski via bind-users wrote: > A very interesting article on how China uses DNS (among other things) > to "control" Internet usage. > > https://blog.thousandeyes.com/deconstructing-great-firewall-china/ The term "DNSSEC" appears just once in that article, after the picture. Yet, maps[*] show China as a fully operational country in that respect. [*] https://www.dnssec-deployment.org/tag/maps/ Best Ale -- Always late reading the backlog ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to define a name with an empty RRset?
Great! Thank you Ondrej Ale On 29/04/2020 12:26, Ondřej Surý wrote: > Hi, > > to create a empty non-terminal (ENT) you should do: > > non-empty.an-empty-name.example.com. IN TXT > > Ondrej > -- > Ondřej Surý > ond...@isc.org > >> On 29 Apr 2020, at 12:22, Alessandro Vesely wrote: >> >> Hi all, >> >> the doc says each node has a set of resource information, which may be empty. >> But how do I create such a node? If I just write, say: >> >>an-emty-name.example.com. >> >> named-checkzone complains about unexpected end of input. >> >> NULL is not usable in master files. For the time being, I try: >> >>an-emty-name.example.com. IN RP . . >> >> However, querying ANY reveals that the name is not actually empty. >> >> Is there a specific syntax to create an empty name? >> >> >> Best >> Ale >> -- >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
How to define a name with an empty RRset?
Hi all, the doc says each node has a set of resource information, which may be empty. But how do I create such a node? If I just write, say: an-emty-name.example.com. named-checkzone complains about unexpected end of input. NULL is not usable in master files. For the time being, I try: an-emty-name.example.com. IN RP . . However, querying ANY reveals that the name is not actually empty. Is there a specific syntax to create an empty name? Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On Wed 15/Apr/2020 10:15:09 +0200 Ondřej Surý wrote: > The renaming was done as it was a logical choice, the service is starting a > daemon, > and not a package, and daemon name is `named`. Also it is the name used by RPM > based systems and Arch Linux and Gentoo, so it was also made to make BIND 9 > packages > in Debian/Ubuntu more unified with rest of the Linux world. > Calling it /renamed/ would have been beyond criticism... Best Ale -- signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reasons of SERVFAIL
Hi On Sat 08/Feb/2020 12:05:23 +0100 Ondřej Surý wrote: > If `dig +dnssec +cd emeraldonion.org mx` will give you answers and `dig > +dnssec emeraldonion.org mx` does not, then it’s most probably validation > failure. Aha, +cd is what I wanted to learn. Thanks a lot! > > Then of course based on your logging setup, the validation failures might be > visible in BIND 9 log. Indeed: /var/log/named.log:08-Feb-2020 10:46:34.703 lame-servers: info: no valid RRSIG resolving '_mta-sts.emeraldonion.org/DS/IN': 45.76.136.88#53 /var/log/named.log:08-Feb-2020 10:46:34.971 lame-servers: info: no valid DS resolving '_mta-sts.emeraldonion.org/TXT/IN': 45.76.37.222#53 /var/log/named.log:08-Feb-2020 10:46:34.990 lame-servers: info: broken trust chain resolving '_mta-sts.emeraldonion.org/TXT/IN': 45.76.136.88#53 /var/log/named.log:08-Feb-2020 10:46:35.010 lame-servers: info: insecurity proof failed resolving 'emeraldonion.org/MX/IN': 45.32.180.186#53 [...] Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reasons of SERVFAIL
Hi, thank you for your prompt reply! On Sat 08/Feb/2020 11:39:05 +0100 Ondřej Surý wrote: >> How do I fix this issue? > > > You don’t, their DNSSEC is broken: > > https://dnsviz.net/d/emeraldonion.org/dnssec/ I see. Is there a command to diagnose that locally? > They have to either start signing again or remove DS record from the parent > (org). Fine, I'll forward your suggestion direct-to-mx Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Reasons of SERVFAIL
Hi! I find I'm unable to send mail to a domain. I get an NDR saying DNS lookup failed. Indeed, when I try manually, I get: 906-north:src$ dig emeraldonion.org mx ; <<>> DiG 9.10.3-P4-Debian <<>> emeraldonion.org mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5098 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;emeraldonion.org. IN MX ;; Query time: 289 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Feb 08 11:29:41 CET 2020 ;; MSG SIZE rcvd: 45 SERVFAIL doesn't tell me /which/ server failed. I infer it's my one, because of the trace below. How do I fix this issue? TIA Ale 908-north:src$ dig +trace emeraldonion.org mx ; <<>> DiG 9.10.3-P4-Debian <<>> +trace emeraldonion.org mx ;; global options: +cmd . 493940 IN NS h.root-servers.net. . 493940 IN NS d.root-servers.net. . 493940 IN NS c.root-servers.net. . 493940 IN NS k.root-servers.net. . 493940 IN NS f.root-servers.net. . 493940 IN NS l.root-servers.net. . 493940 IN NS j.root-servers.net. . 493940 IN NS m.root-servers.net. . 493940 IN NS g.root-servers.net. . 493940 IN NS i.root-servers.net. . 493940 IN NS e.root-servers.net. . 493940 IN NS a.root-servers.net. . 493940 IN NS b.root-servers.net. . 516974 IN RRSIG NS 8 0 518400 2020022105 2020020804 33853 . 2aZlI+r3A/LaC2VEM7BSAupOBbXS/fSNZds49PjuhR38CmDEq6WddgXW XbxGAJaNBBUOXRYB1U093FqP725t29VoFpSuUfmD8YGwzcbu1gtvBbyW clLu3OK6X2m5V6AWvQuumcDA/qJRdnQ0/8EepqKL8f+vniQLCKxA5kR1 HkZAG36QBhj0poGet9no8kQkz5/wBkI88fyId6ZasSbSCrX+68QuNcV/ N0BwQNhuvY0JEMHEJVjDzTkoJghKySTylWE5R7wxc/p5HuBtBy5v+ITF zGbbC3ZoXlVdRF3//QzW4aqdcCCBG+0yXDlRQ5ZevZfWABLJV8ds5VEG aXCLpg== ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms org.172800 IN NS a0.org.afilias-nst.info. org.172800 IN NS a2.org.afilias-nst.info. org.172800 IN NS b0.org.afilias-nst.org. org.172800 IN NS b2.org.afilias-nst.org. org.172800 IN NS c0.org.afilias-nst.info. org.172800 IN NS d0.org.afilias-nst.org. org.86400 IN DS 9795 7 1 364DFAB3DAF254CAB477B5675B10766DDAA24982 org.86400 IN DS 9795 7 2 3922B31B6F3A4EA92B19EB7B52120F031FD8E05FF0B03BAFCF9F891B FE7FF8E5 org.86400 IN RRSIG DS 8 1 86400 2020022105 2020020804 33853 . QcNTGf7LnnW7XgHNC4VFs9e2hsMw9ruiWZ2J1Ev2+aCRdyuk0ECpxMPd 8Gb4MYmAsbljnELkPNSCUdlLv7LeN0+mDoESBe9AKQ++l7DMSZXQ5jJh 9ThjNs12lxWAFLIcRDFb0HXnwVG5bvYFovrorG01TxGDyrPp56eVd2GT Udprf8kPkyatYVTvthFZrIU72wClEBjBGirOiiWEkPtzOKYSYv+gXKOn v4lpxcfbgdGdFZLlrv406FqP/1hsGpY5u2dO0ToAuUZ9hBrmJnAYut17 YXnplS5yD+ZMmXDaOCn6rmeUPkOXNjV7/Onwlo7dDZhFC6QVqt6HVHXJ 8egMVA== ;; Received 818 bytes from 192.203.230.10#53(e.root-servers.net) in 1 ms emeraldonion.org. 86400 IN NS ns0.1984.is. emeraldonion.org. 86400 IN NS ns1.1984.is. emeraldonion.org. 86400 IN NS ns2.1984.is. emeraldonion.org. 86400 IN NS ns1.1984hosting.com. emeraldonion.org. 86400 IN NS ns2.1984hosting.com. emeraldonion.org. 86400 IN DS 58282 8 2 C853155321349E86D675DBB87E839E689582FC193F447DE120242828 31A92EFE emeraldonion.org. 86400 IN RRSIG DS 7 2 86400 20200222152504 20200201142504 63887 org. HuTit6Jz4FEFoTRpRiWpUFN87YYeLqa5P/rnVnFmC7cm563fklPammF/ uUUYzAK4JhekTZmrSGG0P3SGrk85nS8A0tcngc8qGdfnmYaE6YRfT7E7 GsugewjF17oQ+9BwyeeoCorNqXNnBBw6gSSzyywkumTAAAjLCLfyeiLj olE= ;; Received 368 bytes from 199.249.120.1#53(b2.org.afilias-nst.org) in 16 ms emeraldonion.org. 900 IN MX 10 emeraldonion-org.mail.protection.outlook.com. emeraldonion.org. 86400 IN NS ns1.1984.is. emeraldonion.org. 86400 IN NS ns1.1984hosting.com. emeraldonion.org. 86400 IN NS ns2.1984hosting.com. emeraldonion.org. 86400 IN NS ns0.1984.is. emeraldonion.org. 86400 IN NS ns2.1984.is. ;; Received 604 bytes from 45.32.180.186#53(ns2.1984.is) in 19 ms -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org
Re: VL: DNSSEC zones not updated
Same here
See also
https://serverfault.com/questions/897894/bind-is-not-resigning-dnssec-zone-after-zone-update-and-service-restart
Ale
On Thu 23/Jan/2020 09:57:02 +0100 Jukka Pakkanen wrote:
> Yes, that worked. Also had to delete the .jnl, to prevent the "not exact"
> error..
>
> Jukka
>
> -Alkuperäinen viesti-
> Lähettäjä: Mark Andrews
> Lähetetty: 23. tammikuuta 2020 0:53
> Vastaanottaja: Jukka Pakkanen
> Kopio: bind-us...@isc.org; Browne, Stuart
> Aihe: Re: DNSSEC zones not updated
>
> On the master stop the server, remove the signed zones and restart. The
> server will regenerate the signed zones and the slaves will answer in the
> meantime. I’ve opened a ticket to add a code path to address the reported
> error automatically.
>
> Marl
>
>> On 23 Jan 2020, at 10:21, Jukka Pakkanen wrote:
>>
>> Unfortunately here a reload or a restart Does not fix it. And the problem of
>> course is critical... no zone updates are working. So if no reason and fix
>> is quickly found, need to step back and remove dnssec altogether.
>>
>> Get Outlook for Android
>>
>> From: Browne, Stuart
>> Sent: Thursday, January 23, 2020 12:14:29 AM
>> To: Jukka Pakkanen ; bind-us...@isc.org
>>
>> Subject: RE: DNSSEC zones not updated
>>
>> Sadly, no ideas other than a shared experience. It's not just the Windows
>> release nor is it just the 9.14 series of releases; we've been witnessing
>> this since the 9.10 releases on Linux (whilst using inline-signing). I don't
>> recall off the top of my head if we saw it in the 9.9 series; even for my
>> memory that is too many iterations ago.
>>
>> It isn't a regular occurrence by any means and it is fixed with a service
>> restart. Sadly we only see this in our production environment and coupled
>> with the time between the occurrence of the issue and the detection of the
>> issue, getting decent debugging information has been challenging (which is
>> why we haven't done much else about it other than restarting it when we see
>> it occur).
>>
>> Stuart
>>
>> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf
>> Of Jukka Pakkanen
>> Sent: Thursday, 23 January 2020 9:41 AM
>> To: Jukka Pakkanen; bind-us...@isc.org
>> Subject: VS: DNSSEC zones not updated
>>
>> Anyone, any ideas?
>>
>>
>> Lähettäjä: bind-users Puolesta
>> Jukka Pakkanen
>> Lähetetty: 22. tammikuuta 2020 13:30
>> Vastaanottaja: bind-us...@isc.org
>> Aihe: Re: DNSSEC zones not updated
>>
>> And we also get after a change and a reload the "secure_serial: not exact"
>> error, of course because the signed zone is not in sync with the non-signed
>> anymore. So I guess the question is why it is not signing automatically
>> after updates to zone.
>>
>>
>> Get Outlook for Android
>> From: jukka.pakka...@qnet.fi
>> Sent: Wednesday, January 22, 2020 1:13:11 PM
>> To: Ondřej Surý
>> Cc: bind-us...@isc.org
>> Subject: Re: DNSSEC zones not updated
>>
>> Yed we have quite several times by now when trying to find the culprit.
>> Also the whole windows 2019 server. And it is not only this domain/zone, but
>> all of them.
>>
>> Get Outlook for Android
>>
>> From: Ondřej Surý
>> Sent: Wednesday, January 22, 2020 1:08:22 PM
>> To: Jukka Pakkanen
>> Cc: bind-us...@isc.org
>> Subject: Re: DNSSEC zones not updated
>>
>> Hi,
>>
>> did you try stopping BIND, removing journal files and then starting BIND
>> again?
>>
>> If the signed copy of the zone got corrupted in the memory, you might be
>> dumping the corrupted version on disk again with `rndc reload`.
>>
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>>
>> > On 22 Jan 2020, at 12:11, Jukka Pakkanen wrote:
>> >
>> >
>> > Running BIND 9.14.9 Windows. The zone data is not updated for some
>> > reason anymore, and same problem in all our signed zones. Example
>> > "gemtrade.fi":
>> >
>> > zone "gemtrade.fi" {
>> > type master;
>> > file "named.gemtrade";
>> > inline-signing yes;
>> > auto-dnssec maintain;
>> > };
>> >
>> >
>> > ;
>> > ;File: named.gemtrade
>> > ;
>> > $TTL 60
>> > @IN SOAns1.qnet.fi. helpdesk.qnet.fi. (
>> > 202001234 ; serial number
>> > 28800 ; refresh every 12 hours
>> > 7200 ; retry after 2 hours
>> > 604800 ; expire after 2 weeks
>> > 33600) ; default ttl is 2 days
>> > gemtrade.fi.IN A 62.142.217.154
>> > IN MX 55 qntsrv8.qnet.fi.
>> > IN MX 25 qntsrv9.qnet.fi.
>> > IN NS ns1.qnet.fi.
>> > IN NS ns2.qnet.fi.
>> > IN NS ns3.qnet.fi.
>> > www IN A 62.142.217.154
>> > _autodiscover._tcp IN SRV0 5 443 mail.qnet.fi.
>> > localhost.gemtrade.fi. IN A 127.0.0.1
>> >
>> >
>> > Used to work fine, now no matter what change I make to
Re: The signed domain file rewritten
On Tue 12/Nov/2019 18:18:52 +0100 Tony Finch wrote: > Alessandro Vesely wrote: >> >> It doesn't seem to happen every day, but can happen again on the next day. >> Can >> the period be controlled? > > It depends on the size of the zone (bigger zone -> more frequent upates), > how widely scattered the RRSIG expiry times are (which depends on how the > zone is updated and how it was originally signed), how long ago it was > signed (the expiry times have a bit of jitter so they should gradually > spread out over) and on the sig-validity-interval setting. That makes sense. I left sig-validity-interval at its default (30 days) and from October 19 to November 11 (the dates of the files) there are 23 days, while 30 * (1 - 1/4) = 22.5. Looking closer, I realized that the next day signature was not rewritten in the same view. Perhaps the jitter can be cured by setting a multiple of 4 as the validity interval... Thank you for the detailed explanation Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: The signed domain file rewritten
On Tue 12/Nov/2019 13:39:30 +0100 Jim Popovitch via bind-users wrote:
> On 11/12/19 4:42 AM, Alessandro Vesely wrote:
>> Hi,
>>
>> I have a signed domain, with inline-signing yes and auto-dnssec maintain.
>>
>> Although the domain is static, the .signed and .signed.jnl files are being
>> rewritten without apparent reason. They are about a month newer than the
>> corresponding .jbk and base files.
>>
>> I notice that because of tripwire complaints. I guess I have to tweak that
>> config, unless there's a way to prevent or foresee those rewritings.
>>
>
> I use this in twpol.txt:
>
> {
> /etc -> $(SEC_BIN) (recurse=true) ;
> !/etc/bind/zone ;
>
>
Yeah, that's a possibility.
Not that I rely on tripwire more than I should, but leaving the zone outside
the controlled area means to blindly sign whatever happens to be in the zone.
Best
Ale
--
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: The signed domain file rewritten
On Tue 12/Nov/2019 12:09:06 +0100 Mark Andrews wrote: > The RRSIGs need to be regenerated periodically. This is the changes you are > seeing. > It doesn't seem to happen every day, but can happen again on the next day. Can the period be controlled? Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
The signed domain file rewritten
Hi, I have a signed domain, with inline-signing yes and auto-dnssec maintain. Although the domain is static, the .signed and .signed.jnl files are being rewritten without apparent reason. They are about a month newer than the corresponding .jbk and base files. I notice that because of tripwire complaints. I guess I have to tweak that config, unless there's a way to prevent or foresee those rewritings. Why does bind rewrite that file? Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Is inline-signing recommended?
Hi all,
reading about the various ways to sign zones, inline-signing seems to be the
simplest one. However, a 2014 Swiss howto I found has this obscure warning:
Update Nov 2017: DNSSEC zone signing as described here is outdated.
We strongly recommend against the method described in this blog post.
Newer BIND versions or other DNS software have greatly simplified
DNSSEC signing.
https://securityblog.switch.ch/2014/11/13/dnssec-signing-your-domain-with-bind-inline-signing/
The (old) text has inline signing exemplified like so:
zone example.com {
type master;
file "/etc/bind/zones/db.example.com”;
# publish and activate dnssec keys
auto-dnssec maintain;
# use inline signing
inline-signing yes;
};
Did a better way arrive between 2014 and 2017? What does that warning mean?
Thank you
Ale
--
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
