Re: Migration to inline-signing
I tried it again to get the logs,
*21-May-2025 20:57*:12.064 general: zone sub.example.com/IN/internal:
(primary) removed
*21-May-2025 20:57*:12.064 general: reloading configuration succeeded
*21-May-2025 20:57*:12.064 general: scheduled loading new zones
*21-May-2025 20:57*:12.511 zoneload: zone sub.example.com/IN/internal
(unsigned):
loaded serial 462767 (DNSSEC signed)
*21-May-2025 20:57*:12.600 general: zone sub.example.com/IN/internal (signed):
CDS/CDNSKEY consistency checks failed
*21-May-2025 20:57*:12.600 zoneload: zone sub.example.com/IN/internal (signed):
not loaded due to errors.
*21-May-2025 20:57*:12.600 general: zone sub.example.com/IN/internal (signed):
receive_secure_db: bad CDS
I wanted to reduce it to a minimum configuration to reproduce and present
that, but I also was working on the approach of purging the zone file of
DNSSEC records. Didn't have time to do both. Removing the records wasn't as
bad as I thought, simple awk script seems to work,
{
sub(/;.*/,"")
}
/\s(DNSKEY|CDNSKEY|DS|CDS|RRSIG|NSEC|TYPE65534)/ {
if (/\(/) {
while (!(/\)/)) {
getline
}
}
next
}
{
print
}
Although I can imagine some cases where that logic is too simple.
Purging the records and then loading the zone worked, but still wasn't as
smooth as I liked, I tried,
1. freeze
2. sync -clean
3. Copy the de-DNSSECed fzone file over the old one
4. thaw
But that would write the zone back with DNSSEC records in the file. The
only way I got it to work was to kill and restart named.
Given the actual primary is a hidden master, brief named outages for a
restart are not a big concern. That's probably good enough.
On Tue, May 20, 2025 at 1:45 AM Matthijs Mekking wrote:
>
>
> On 17-05-2025 06:39, Crist Clark wrote:
> > Tired of looking at the log messages warning me that inline-signing will
> > be the default in 9.20. I want to convert my 9.18 to using
> > inline-signing. Right now all of the zones use dnssec-policy and are
> > dynamic.
> >
> > I tried just simply adding the "inlien-signing yes" line to a zone with
> > dynamic updates that has the DNSSEC records in the file, but it flat out
> > stopped the zone from loading at all when I issued a reconfig.
>
> Can you tell me the error message? I would not expect the zone stopping
> from loading, but it's hard to tell without full configuration.
>
> Note that when switching, signatures and NSEC records from the dynamic
> zone would be removed and moving to inline-signing requires a full
> re-sign of the zone.
>
> - Matthijs
>
> > I assume I could freeze, sync, clean DNSSEC records in the file, and
> > reload with inline-signing. But manually cleaning the zone file isn't
> > trivial. Not hard, but takes some work to get right.
> >
> > Is there a right way to just reconfigure named.conf to make this work
> > without messing with the zone file directly? Even if it maybe takes
> steps?
> >
> > If this really takes cleaning the DNSSEC from the zone file, is there a
> > way to coax the existing BIND tools to do this? Took a quick look at
> > named-compilezone, dnssec-signzone, etc. None seem to have the
> capability.
> >
> --
> 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: Dns tunnel detection/prevention
On 5/22/25 9:23 AM, Karol Nowicki via bind-users wrote: Does ISC Bind software by native has any dns tunneling prevention embedded ? I don't think there is anything that I would describe that way. But there may be some rate limiting option(s) that you could use to at least cripple using DNS queries & replies as a tunnel mechanism. -- 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: Dns tunnel detection/prevention
On Fri, 23 May 2025, Grant Taylor via bind-users wrote: On 5/22/25 9:23 AM, Karol Nowicki via bind-users wrote: Does ISC Bind software by native has any dns tunneling prevention embedded ? I don't think there is anything that I would describe that way. But there may be some rate limiting option(s) that you could use to at least cripple using DNS queries & replies as a tunnel mechanism. Yes, exactly. Generally speaking and it comes with its own constellation of adversary responses but failing softly, or failing to brokenness: I think this is preferable to failing outright. If you fail in an outright, reproducible, measurable fashion you give your opponent predictability and confidence. As a defender you want to undermine that and look like an under-resourced, poorly administered network that somehow, we don't know exactly how but somehow: it's just bad luck. There's a crappy network and every time your adversary messes with it they just have inexplicable bad luck. The footnotes would be longer than what I've written. File it generally under "chaos engineering". Dnstap offers application-level logging (DNS is an application protocol along with a wire protocol) and you can combine that with e.g. fail2ban and/or RPZ, or other things if it keeps you up at night and you like picking the legs off of web spiders. -- Fred Morris, internet plumber -- 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: Dns tunnel detection/prevention
On Saturday, May 24, 2025 3:53:57 AM CEST Fred Morris wrote: > On Fri, 23 May 2025, Grant Taylor via bind-users wrote: > > I don't think there is anything that I would describe that way. But there > > may be some rate limiting option(s) that you could use to at least cripple > > using DNS queries & replies as a tunnel mechanism. > > Yes, exactly. Generally speaking and it comes with its own constellation > of adversary responses but failing softly, or failing to brokenness: I > think this is preferable to failing outright. > > If you fail in an outright, reproducible, measurable fashion you give your > opponent predictability and confidence. As a defender you want to > undermine that and look like an under-resourced, poorly administered > network that somehow, we don't know exactly how but somehow: it's just > bad luck. There's a crappy network and every time your adversary messes > with it they just have inexplicable bad luck. Generally, this is what I would describe good security practice to be like. Let's put on a former hacker's hat, dark grey seems good. What I would probe for is first and foremost low hanging fruit. Scan the whole IPv4 Internet in about 20 minutes. God bless good VPS providers. And all hail masscan. What I would probe next is the the servers running interesting applications, like mailers and whatnot. Then dial into those that allow for SMTP auth. Doesn't matter if they actually do or not. (unpredictability) Whatever sticks, abuse the living shit out of it. Not like they're going to live long anyway, and neither are we. Rinse and repeat. Profit. > The footnotes would be longer than what I've written. File it generally > under "chaos engineering". > > Dnstap offers application-level logging (DNS is an application protocol > along with a wire protocol) and you can combine that with e.g. fail2ban > and/or RPZ, or other things if it keeps you up at night and you like > picking the legs off of web spiders. This, alongside tcpdump, is an excellent defense mechanism. -- Met vriendelijke groet, Michael De Roover Mail: i...@nixmagic.com Web: michael.de.roover.eu.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: Dns tunnel detection/prevention
On 5/23/25 8:53 PM, Fred Morris wrote: If you fail in an outright, reproducible, measurable fashion you give your opponent predictability and confidence. As a defender you want to undermine that and look like an under-resourced, poorly administered network that somehow, we don't know exactly how but somehow: it's just bad luck. There's a crappy network and every time your adversary messes with it they just have inexplicable bad luck. I understand the active and hidden (as in not overtly obvious) defender mentality. But sometimes doing that brings it's own complexities and vulnerabilities. There's also the fact that allowing a small percentage to leak through as the hey you beat the odds on a bad network link, is still allowing things to leak through. Different environments have different security posture and are willing to tolerate different things. -- 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
