Re: Updated Docker images (9.18, 9.20, 9.21) - now based on Alpine Linux

[Michael Dahlberg]

On Tuesday, August 27th, 2024 at 4:21 AM, Ondřej Surý  wrote:
 
> the Docker images have been updated to use Alpine Linux as the base image
> and the bind9 binaries are now compiled from the source while building the
> Docker images. This is more in-line with the expected Docker (Podman) 
> workflow.

This sounds very cool!  Would it be possible to share how these container 
images were created, like what sort of dockerfile was used to generate them?

Thanks for the valuable work.

Mike
-- 
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: SERVFAIL error during the evening

[Michael Batchelder]

 EOL'd versions are less likely to be 
addressed by listmembers (beyond indicating that you should upgrade).

> How can we ensure that this is a network-level issue?

Through standard network troubleshooting techniques, such as packet captures 
and firewall log inspection. Beyond that, you'll need to inquire elsewhere, as 
I indicated at the top of this message, as this is a list about BIND-related 
issues.

Michael
-- 
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: SERVFAIL error during the evening

[Michael Batchelder]

>> Hello Michael
>> Thank you for your response. Here is a pcap file and some logs.
> 
> Hello Sami,
>
> Your pcap shows your resolver making thousands of queries that get
> no responses (or at least the pcap does not contain them). There's
> not much I can say, beyond that this does not appear to be a > problem
> related to BIND.

Sami,

My co-worker helpfully pointed out something I missed when reviewing your 
packet capture. A large number of your resolution failures are because your 
BIND is configured to use QNAME minimization (a.k.a. "qmin") and the queries 
are to zones whose configuration is done incorrectly and breaks qmin.

The pcap indicates you have the 'qname-minimization strict' setting in your 
BIND configuration file. See the "qname-minimization" statement in the Options 
section of the BIND ARM 
(https://bind9.readthedocs.io/en/v9.16.25/reference.html#options-statement-definition-and-usage).
 For the general background on qmin, read RFCs 7816 and 9156.

I don't know of a reason why you would experience more qmin failures in the 
evening, other than the requests that fail are only made at that time. 
Regardless, if you want to stop the failures completely, you can change the 
'qname-minimization strict' setting to 'qname-minimization disabled'. The 
drawback is that your queries will no longer be minimized, so all authoritative 
servers will see the full query name during recursion.

As a compromise between doing nothing and fully disabling qmin, you can use the 
'qname-minimization relaxed' setting which will try qmin and if BIND encounters 
a zone which breaks qmin, then BIND will switch to not doing qmin and do normal 
recursion (equivalent to 'qname-minimization disabled') for that query.

Also, you should upgrade your version of BIND, as we can see that the qmin 
queries are those used in older versions of BIND. 

Michael
-- 
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: SERVFAIL error during the evening

[Michael Batchelder]

> Hello Michael
> Thank you for your response. Here is a pcap file and some logs.

Hello Sami,

Your pcap shows your resolver making thousands of queries that get no responses 
(or at least the pcap does not contain them). There's not much I can say, 
beyond that this does not appear to be a problem related to BIND. You will need 
to look at your infrastructure and beyond to determine why you are not getting 
responses to your queries.

One possibility may be in your infrastructure/network, where a firewall or 
other stateful inspection device is running out of resources to make additional 
state table entries. You will need to speak with the technical support of that 
device's vendor if you need help in assessing this.

Michael
-- 
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: qname minimization: me too :(

[Michael Batchelder]

> Yes, sure. I grabbed three typical cases to analyze further, and
> currently trying to understand the proceedings - unsuccessfully, up
> to now. :(
>
> Case 1:
> ---
> Jun 19 17:42:12  conr named[24481]: lame-servers:
>info: success resolving '26.191.165.185.in-addr.arpa/PTR'
>after disabling qname minimization due to 'ncache nxdomain'
> 
> This one does not point back to me, but nevertheless I do not
> see the lame server.
> 
> Case 2:
> ---
> Jun 19 18:02:44  conr named[24481]: lame-servers:
>info: success resolving 'reactivite.fr.intra.daemon.contact/'
>after disabling qname minimization due to 'ncache nxdomain'
> 
> Here, for whatever reason, the client was not happy with the official
> answer on "reactivite.fr", and tried to append the search domain for
> internal hosts on my LAN.
> So this does absolutely point to me, only. The recursing LAN server
> asks the authoritative LAN server (same image, different view), and>
> that one basically says, this is bogus.
> 
> Case 3:
> ---
> Jun 19 18:28:48  conr named[24481]: lame-servers:
>info: success resolving
>
> '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.1.0.0.3.2.f.1.0.7.4.0.1.0.0.2.ip6.arpa/PTR'
>after disabling qname minimization due to 'ncache nxdomain'

Peter,

Case 1:

The 191.165.185.in-addr.arpa zone (@200.3.13.14) responds with NXDOMAIN to 
queries for any QTYPE for QNAME 191.165.185.in-addr.arpa.

Case 2:

The intra.daemon.contact zone (@195.154.230.217) responds with NXDOMAIN to 
queries for any QTYPE of QNAME intra.daemon.contact.

Case 3:

The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with NXDOMAIN to 
queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa

You'll need to fix these zones so that the response is NOERROR rather than 
NXDOMAIN.

b.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: can I provide invalid HTTPS values for testing?

[Michael Richardson]

Mark Andrews  wrote:
> Named and nsupdate validate input for types they know about (both text
> and wire). You would have to use versions that are not HTTPS aware and
> use unknown type format.

So, he could code it in Perl or Python or something which had a dynamic DNS
library.  Bind itself wouldn't validate the "ascii-hex" part when it receives
it.



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

SERVFAIL error during the evening

[Michael Batchelder]

Sami, 

After you regenerate your rndc key as Mark advised, you will need to provide us 
with more information, as what you've sent is not sufficient to troubleshoot 
your symptom. As a first step, take a packet capture on the resolver that shows 
incoming queries from the client and the corresponding outgoing queries from 
the resolver to upstream servers. When you capture packets, do not filter out 
TCP or ICMP or ARP. A tcpdump filter such as 'icmp or arp or port 53' should be 
sufficient. I would capture on all interfaces of the server (-i any). 

Send that capture file along with the BIND log segment which contains the 
failed queries. 

Michael Batchelder 
ISC Support 
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

named -C, ...: Re: dnssec-policy default - where/how to determine what all its settings are?

[Michael Paoli via bind-users]

Excellent, thanks, looks like that very well covers it (and also the
"insecure" policy too).
And
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/9092/diffs
looks good ... including Suzanne Goldlust's additional suggestions too.

Thanks!

On Fri, Jun 7, 2024 at 1:08 AM Petr Špaček  wrote:
>
> Hello,
>
> and thank you for reaching out. I agree this was poorly documented.
>
> In recent versions you can use command `named -C` which prints out
> default configuration, including the default DNSSEC policy.
>
> I'm going to update documentation to reflect that:
> https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/9092/diffs
>
> Petr Špaček
> Internet Systems Consortium
>
> On 06. 06. 24 21:01, Michael Paoli via bind-users wrote:
> > Ah, thanks!
> >
> > Yeah, that's what I was looking to find:
> > https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf
> > https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf
> > Alas, not in the ISC distribution tarballs,
> > and the documentation refers to
> > doc/misc/dnssec-policy.default.conf
> > without indicating where to find that.
> >
> > On Thu, Jun 6, 2024 at 8:31 AM Andrew Latham  wrote:
> >>
> >> I took a quick look
> >>
> >> * 
> >> https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf
> >> * 
> >> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf
> >>
> >> On Thu, Jun 6, 2024 at 8:19 AM Michael Paoli via bind-users 
> >>  wrote:
> >>>
> >>> dnssec-policy default - where/how to determine what all its settings are?
> >>> Documentation
> >>> doc/bind9-doc/arm/reference.html#dnssec-policy-default
> >>> https://bind9.readthedocs.io/en/v9.18.27/reference.html#dnssec-policy-default
> >>> says:
> >>> A verbose copy of this policy may be found in the source tree, in the
> >>> file doc/misc/dnssec-policy.default.conf
> >>> But I'm not finding that in source nor elsewhere.
> >>> There doesn't even seem to be an rndc command that can list
> >>> defined dnssec-policy sets that are in place, nor that
> >>> can list how they're configured.  This information should be much more
> >>> visible/findable, so ... where is it?  I'm sure it must be present
> >>> somewhere in the source, but haven't easily located it by searching.
> >>> Shouldn't be necessary to run debugging to track down where this is
> >>> and where in the source it comes from.  So ... where does one find it?
> >>>
> >>> I've been looking at Debian BIND9 packages:
> >>> bind9  1:9.18.24-1
> >>> bind9-doc  1:9.18.24-1
> >>> and also ISC BIND 9.18.24 source and 9.18.27 source and documentation.
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
>
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-policy default - where/how to determine what all its settings are?

[Michael Paoli via bind-users]

Ah, thanks!

Yeah, that's what I was looking to find:
https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf
Alas, not in the ISC distribution tarballs,
and the documentation refers to
doc/misc/dnssec-policy.default.conf
without indicating where to find that.

On Thu, Jun 6, 2024 at 8:31 AM Andrew Latham  wrote:
>
> I took a quick look
>
> * 
> https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf
> * 
> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf
>
> On Thu, Jun 6, 2024 at 8:19 AM Michael Paoli via bind-users 
>  wrote:
>>
>> dnssec-policy default - where/how to determine what all its settings are?
>> Documentation
>> doc/bind9-doc/arm/reference.html#dnssec-policy-default
>> https://bind9.readthedocs.io/en/v9.18.27/reference.html#dnssec-policy-default
>> says:
>> A verbose copy of this policy may be found in the source tree, in the
>> file doc/misc/dnssec-policy.default.conf
>> But I'm not finding that in source nor elsewhere.
>> There doesn't even seem to be an rndc command that can list
>> defined dnssec-policy sets that are in place, nor that
>> can list how they're configured.  This information should be much more
>> visible/findable, so ... where is it?  I'm sure it must be present
>> somewhere in the source, but haven't easily located it by searching.
>> Shouldn't be necessary to run debugging to track down where this is
>> and where in the source it comes from.  So ... where does one find it?
>>
>> I've been looking at Debian BIND9 packages:
>> bind9  1:9.18.24-1
>> bind9-doc  1:9.18.24-1
>> and also ISC BIND 9.18.24 source and 9.18.27 source and documentation.
>> --
>> 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
>
>
>
> --
> - Andrew "lathama" Latham -
-- 
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-policy default - where/how to determine what all its settings are?

[Michael Paoli via bind-users]

dnssec-policy default - where/how to determine what all its settings are?
Documentation
doc/bind9-doc/arm/reference.html#dnssec-policy-default
https://bind9.readthedocs.io/en/v9.18.27/reference.html#dnssec-policy-default
says:
A verbose copy of this policy may be found in the source tree, in the
file doc/misc/dnssec-policy.default.conf
But I'm not finding that in source nor elsewhere.
There doesn't even seem to be an rndc command that can list
defined dnssec-policy sets that are in place, nor that
can list how they're configured.  This information should be much more
visible/findable, so ... where is it?  I'm sure it must be present
somewhere in the source, but haven't easily located it by searching.
Shouldn't be necessary to run debugging to track down where this is
and where in the source it comes from.  So ... where does one find it?

I've been looking at Debian BIND9 packages:
bind9  1:9.18.24-1
bind9-doc  1:9.18.24-1
and also ISC BIND 9.18.24 source and 9.18.27 source and documentation.
-- 
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

Problem with a certain domain

[Michael Batchelder]

Thomas, 

I just incorrectly wrote: 

> So at minimum add "icmp and arp" to your filter expression. 

I did not mean to use the logical "and". Your minimum filter should be 
something like: 

"src port 53 or icmp or arp" 

Sorry for the confusion, 
Michael 

Michael Batchelder 
ISC Support 
-- 
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

Problem with a certain domain

[Michael Batchelder]

> The newsletter is only sent out once a day, so I would have to wait 
> until tomorrow. I'll record it then. I have already experimented with 
> tshark and recorded port 53. 

When you run your packet capture, do not restrict your capture to only port 53. 
As a general rule, always keep your filtering as open as possible. That will 
allow for capturing potentially critical evidence such as ICMP error messages, 
ARP broadcasts, etc... or the absence of such things when they should be there. 
So at minimum add "icmp and arp" to your filter expression. 

> What I noticed as a network layman is that a certain 
> response takes much longer on server 1 with the problems than 
> on server 2. 

Your tshark snippets do not show "a certain response" taking much longer. That 
might be the explanation, but what you show is not proof of that. Your snippets 
only show response packets with varying amounts of separation between them. 
Without the request packet which generated the response, we can't calculate an 
actual time to respond, and have no way of knowing with certainty what the 
situation really is. Another general rulle: don't limit the amount of 
information you provide to those who are trying to help you or make them infer 
information. It's fine to mention only certain packets in an email, but put the 
full packet capture on a public resource somewhere accessible. 

Michael Batchelder 
ISC Support 
-- 
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

Problem with a certain domain

[Michael Batchelder]

> My go-to DNS debugging site at 
> 
> https://dnsviz.net/d/s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es/dnssec/
>  
> 
> appears to indicte there is more than one problem, but the most 
> serious one is probably this one: 
> 
> It might look like one or more of the publishing name servers responds 
> incorrectly when queried for an "empty non-terminal" name 
> (e.g. _domainkey...), which probably itself doesn't have any data on 
> that node, but has data on "names below". The correct response code 
> is then NOERROR with answer count=0 (aka. "NODATA"), not NXDOMAIN. 
> 
> When a recursor gets NXDOMAIN back, it is free to assume that the 
> queried-for name does not exist (which is obvious), and nothing exists 
> below that node either. See RFC 8020. 
> 
> Regards, 
> 
> - Håvard 

Håvard, w hat you say is correct about the NXDOMAIN RCODE . However, Thomas's 
logs and dig output suggest that the failure is a timeout, possibly because 
BIND/named is not responding. So I don't think that DNSViz error matches the 
problem description. Having said that, one or more problems with the relevant 
zones could be triggering something in BIND... 

Thomas, can you clarify whether all queries to 127.0.0.1/53 result in: 
;; communications error to 127.0.0.1#53: timed out 
when this problem occurs, or do just queries for 
s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es fail (or some level of 
failure in between all queries and the ones for that one domain)? And at that 
time, can you successfully query from the same system using a public resolver 
(e.g. "dig @9.9.9.9 s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es TXT")? 
And do you have BIND's logging for the queries that fail? 

Thanks, 
b. 

Michael Batchelder 
ISC Support 
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problem upgrading to 9.18 - important feature being removed

[Michael Richardson]

Matthijs Mekking  wrote:
> As the main developer of dnssec-policy, I would like to confirm that
> what has been said by Michael and Nick are correct.

Cool.

> - When migrating to dnssec-policy, make sure the configuration matches
> your existing keys.

Is there a way to validate the policy against what's in a specific 
zone/directory?
Effectively, "do your key management stuff --just-kidding --verbose"?

> - Most issues that were shared on this list have to do with migrating
> to dnssec-policy.

Agreed: and it bit me, and I am still a bit shell shocked.

> - If you feel like the DS is stuck in 'rumoured' state you might need
> to run 'rndc dnssec -checkds seen' on the key.

okay, good to know this.
. o O ( Umbrella Academy )

> - It is not recommended to switch to dnssec-policy if you are currently
> in a rollover.

> I acknowledge that migration takes some care and I wish the process was
> easier. We have some ideas to make it less error prone, but I haven't
> found the time to work on that.

Are there open issues?



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problem upgrading to 9.18 - important feature being removed

[Michael Sinatra]

On 2/26/24 13:41, Al Whaley wrote:
As far as I have been able to determine through some fairly extensive 
reading, a feature I depend on has fallen out of favor with the BIND 
developers, and is being removed.
DNSSEC in 9.18 has two automatic actions where the original code had 
just one, and the second cannot be disabled.

I am referring to the deprecated feature:

|auto-dnssec maintain;|

||Originally (under the above command) RR records for DNSSEC were 
maintained by bind, but the ZSK and KSK keys were maintained by me.  
This command is being discarded.  I understand that bind "sort of" 
supports this feature in 9.18 by allowing the DNSSEC policy statement to 
declare unlimited lifetime, but after careful reading of the 
documentation and reading a number of complaints, it turns out that bind 
may under various circumstances decide that it is appropriate not to use 
existing keys and decide that it knows best, and then it makes new 
ones.  This potential instability of course would be disastrous, and 
completely unnecessary.


I have never experienced this, in either BIND 9.16 or BIND 9.18 
(including the latter with KASP set to not rotate any keys).  Can you 
elaborate as to where in the documentation and/or what complaints you 
have seen where correctly configured KASPs in 9.18.24+ decide to roll 
keys?  I'd certainly like to know if that's the case, for reasons 
described below.


I am sure there are the usual people that will assure me I don't or 
shouldn't want to do what I am doing, but I am experienced and have good 
reasons.  Yes I know that I can have bind update the DS records, but for 
good reason I definitely do not want to do that.  I need some syntax 
that assures my use of existing KSK and ZSK keys and prevents bind from 
changing them.


Actually, I do exactly what you're doing in several circumstances.  I 
use the deprecated `dnssec-keymgr` on a few different systems, including 
a signing service that I run, in order to maintain keys.  (As is 
probably the case with you, there's already some tooling built around 
generating, rotating, backing up, etc. of keys that I have not yet 
integrated with the newer KASP regime.) I *do* plan to refactor these 
different services to use KASP, but I still need to do some more 
testing/QA/etc.  On my personal domains (including the ironically-named 
one I am sending this from), I have mostly switched to 100% KASP.  KSKs 
properly don't rotate, and ZSKs do only if I request.


I wonder if the bind developers are open to allowing a command in the 
new policy statement structure that blocks this 'feature' of 
automatically updating ZSK and KSK?  If there is such a thing already, I 
will be delighted to hear that I had missed seeing it.


I believe the following KASP will do what you want it to do:

dnssec-policy pkcs11 {
keys {
zsk lifetime unlimited algorithm 13;
ksk lifetime unlimited algorithm 13;
};
signatures-refresh P26D;
signatures-validity P30D;
signatures-validity-dnskey P30D;
};

This policy has been running for about 6 months and BIND has never seen 
fit to roll any keys, ZSK or KSK.  (You can safely ignore the sig 
validity/refresh stuff; I add that for other reasons.)



A lot of pain and suffering in this world comes from people being sure 
they have a 'better idea' and everybody needs to do whatever.  This 
feels a bit like that.  A command that gives choice and real certainty 
would be great.


That's certainly true in a lot of cases.  We hear stories all of the 
time (and sometimes experience them) about how well-intentioned software 
developers try to reduce code complexity and end up inadvertently 
generating work for users and admins.  Some of that's inevitable as we 
keep up with evolving software and best-practices.  (It also provides 
some level of job security :-D.)


But in this case, I think the BIND developers did a good job ensuring 
there was a way to create policies that integrate well with 
key-management regimes external to BIND.


michael
--
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: tsig key not found

[Michael Lipp]

Thanks a lot! I spent almost a day on testing different configurations 
and key names (examples often use fqdns for the key names and I thought 
this might be the cause of the problem).


I suppose I would eventually have found out about this if the response 
had been BADSIG (as decribed here 
https://bind9.readthedocs.io/en/v9.16.42/advanced.html#errors). As it 
is, I was too focused on finding a problem with defining a key at all. 
Maybe pointing out this would be an acceptable issue...


Thanks again!

 - Michael

Am 17.01.24 um 18:26 schrieb Anand Buddhdev:

On 17/01/2024 18:18, Michael Lipp wrote:

Hi Michael,


I have defined a key in named.conf:

|key "acme-dns01" { algorithm hmac-sha256; secret 
"+m8fujTWD3qb0LkJFP7HPCZAbLlWBMtwtbNPEkvAt7E="; };|


Your key algorithm is hmac-sha256, but see below...

[snip]


I'm using the key in a |grant| (but this doesn't really matter):

|update-policy { grant acme-dns01 zonesub txt; };|

When I try to make use of the "key:secret" using |nsupdate|, it is 
sent as expected:


|;; TSIG PSEUDOSECTION: acme-dns01. 0 ANY TSIG 
hmac-md5.sig-alg.reg.int. 1705509748 300 16 tcU/8lYs1VEPZfcM5C3hZw== 
13850 NOERROR 0 |


But I get a |BADKEY| in the response, which means that the key is 
unknown <https://bind9.readthedocs.io/en/v9.16.42/advanced.html#errors>.


Note the hmac-md5 there. You need to precede the key with hmac-sha256, 
without which, nsupdate defaults to hmac-md5 (documented in the 
nsupdate man page).


Regards,
Anand Buddhdev
RIPE NCC



--
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

tsig key not found

[Michael Lipp]

I'm running v9.16.42.

I have defined a key in named.conf:

|key "acme-dns01" { algorithm hmac-sha256; secret 
"+m8fujTWD3qb0LkJFP7HPCZAbLlWBMtwtbNPEkvAt7E="; };|


This has worked:

|$ rndc tsig-list view "Default"; type "static"; key "acme-dns01"; view 
"Default"; type "static"; key "local-ddns"; view "Default"; type 
"static"; key "rndc-key"; view "_bind"; type "static"; key "acme-dns01"; 
view "_bind"; type "static"; key "local-ddns"; view "_bind"; type 
"static"; key "rndc-key";|


I'm using the key in a |grant| (but this doesn't really matter):

|update-policy { grant acme-dns01 zonesub txt; };|

When I try to make use of the "key:secret" using |nsupdate|, it is sent 
as expected:


|;; TSIG PSEUDOSECTION: acme-dns01. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 
1705509748 300 16 tcU/8lYs1VEPZfcM5C3hZw== 13850 NOERROR 0 |


But I get a |BADKEY| in the response, which means that the key is 
unknown <https://bind9.readthedocs.io/en/v9.16.42/advanced.html#errors>.


This information can also be found in the log:

|| Jan 17 17:46:10 | named | 23910 | dnssec: debug 2: tsig key 
'acme-dns01': unknown key|


I couldn't find any additional required action to make the key known in 
the manual 
<https://bind9.readthedocs.io/en/v9.16.42/reference.html#key-statement-definition-and-usage>. 
It is defined globally and should be available in all views (and the 
output from tsig-list confirms this).


As this has been rejected as an error within minutes 
(https://gitlab.isc.org/isc-projects/bind9/-/issues/4539) it must be a 
user error. However, I have gone through the manual and a dozen of 
posting about how to set this up and couldn't find a single information 
about what's wrong. Could somebody please provide a hint? Thank you!


 - Michael

-- 
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 should I configure internal and external DNS servers

[Michael Richardson]

Greg Choules via bind-users  wrote:
> What would be better (IMHO) is for you to keep "example.com" as your
> external zone in an external (hopefully in a DMZ) primary server,
> serving the world with public addresses they need to reach, and
> internally create a new zone - "internal.example.com" (maybe also other
> "somethingX.example.com" too) as your internal zone in an internal
> primary server for serving internal clients with the addresses they
> need.

Would anyone be interested in formulating this into an IETF BCP RFC?
Or maybe a RIPE BCOP.
Your write up is excellent.  Worth keeping it somewhere.

> The reason for the delegation is DNSSEC. If you enable DNSSEC

Yes.

> That was a bit of an essay, but I hope at least some of it made sense.

:-)



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How should I configure internal and external DNS servers

[Michael Richardson]

Given VPNs, RemoteAccess and the like, I strongly recommend against split-DNS
configurations.  They were great ideas in 1993, when all sites were concave,
but that's just not the case anymore.

Instead, I recommend having a sub-zone, "internal.example.com", or some other
convenient name.  Put a zone split ("NS" and "DS" records) there, and then
limit who can do queries to this zone by IP address.  You'd acceptlist all of
your VPN sites, the v4 (RFC1918) and v6 (subnet) prefixes for your remote
access clusters.

Split-DNS finally has some actual IETF definition at:
  
https://datatracker.ietf.org/doc/draft-ietf-add-split-horizon-authority/

I'm specifically arguing to do:
  
https://www.ietf.org/archive/id/draft-ietf-add-split-horizon-authority-06.html#name-internal-only-subdomains

It's just so much easier, particularly if you are starting from scratch.


signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: 9.18 BIND not iterated over all authoritative nameservers

[Michael Martinell via bind-users]

Thanks to all who responded. Putting qname-minimization disabled; in named.conf 
resolves the issue in my testing.

I did try specifying relaxed (which appears to be the default), but that didn’t 
work either.
I agree it would be great if the far ends would make sure what they publish is 
correct, but it will take a large company to push them to do so.



Michael Martinell
Network/Broadband Technician
Interstate Telecommunications Coop., Inc.
From: bind-users  On Behalf Of Paul Stead
Sent: Saturday, October 28, 2023 11:35 AM
Cc: bind-users@lists.isc.org
Subject: Re: 9.18 BIND not iterated over all authoritative nameservers

I wasn't

On Sat, Oct 28, 2023, 5:23 PM Ondřej Surý 
mailto:ond...@isc.org>> wrote:
Please don’t use Postel’s Law as excuse for implementations that break 
standards: 
https://datatracker.ietf.org/doc/html/rfc9413<https://datatracker.ietf.org/doc/html/rfc9413>
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.


On 28. 10. 2023, at 17:50, Paul Stead 
mailto:paul.st...@gmail.com>> wrote:

As a previous ISP admin I too have come across similar situations and 
frustrations.

I can only say that Google and Cloudflare seem to follow Postel's Law moreso 
than BIND.

I agree this perpetuates bad practices but end users aren't interested in 
technical reasoning, especially when "it works everywhere else, you must be 
broken"

Paul

On Sat, Oct 28, 2023, 3:56 PM Rick Frey 
mailto:grib...@gmail.com>> wrote:
As Mark mentions, the NS records gtm.bankeasy.com<http://gtm.bankeasy.com> need 
to be corrected and failure is not due to lack of iterating through all auth 
nameservers (all of the auth nameservers have the bad NS record anyway).

Not sure how many other domains you are running into similar problem, but you 
could disable qname-minimization in 9.18 to mimic previous behavior of 9.16 if 
that number is large.  I believe qname-minimization is a global directive so it 
would remove privacy benefits of QNAME minimization for all recursive queries 
from your nameserver.

As DNS admin of another ISP, I sympathize dealing with failures caused by 
non-compliant authoritative nameservers.  These non-compliant auth nameservers 
can have little motivation to fix, especially when other large ISPs or public 
resolvers (looking at you Google and Cloudflare) don’t enforce DNS standards.   
Many non-compliant nameservers/records would be cleaned up if 
public/centralized DNS providers such as Google/Cloudflare would enforce since 
it would inflict those failures on a much larger user base.

 - Rick




On Oct 27, 2023, at 6:31 PM, Mark Andrews mailto:ma...@isc.org>> 
wrote:



Named now uses NS lookups to perform QNAME minimisation.  If one puts garbage 
in the NS
records then they should expect lookups to fail.  The NS records on both sides 
of a zone
cut are supposed to be IDENTICAL.  This is not a new requirement.  It has been 
this way
since the very beginning.

The bank needs to fix what they publish.

Mark


On 28 Oct 2023, at 02:36, Michael Martinell via bind-users 
mailto:bind-users@lists.isc.org>> wrote:

Hello,
At this point I am hoping that somebody might have a workaround so that we can 
exclude domains from this behavior if they are broken on the far end. Does 
anybody have a workaround for this?
We are a small ISP and run BIND compiled from source. We currently run 9.16.x
Every time we try to move forward with 9.18 customers start to complain that 
they are unable to reach certain websites.  This includes banks, universities, 
and other organizations.
I understand the goal is to get all DNS to RFC 6891, but from a practical 
standpoint, this isn’t working for customers, so we are prevented from 
upgrading either.
Related website:
https://gitlab.isc.org/isc-projects/bind9/-/issues/3152<https://gitlab.isc.org/isc-projects/bind9/-/issues/3152>
Our source code compile options:
./configure --with-gnu-ld --with-libxml2 --with-json-c 
--with-openssl=/usr/local/openssl && make && make install && ldconfig



Interstate Telecommunications Coop., Inc.
312 4th Street West • Clear Lake, SD 57226
Phone: (605) 874-8313
michael.martin...@itccoop.com<mailto:michael.martin...@itccoop.com>
www.itc-web.com<http://www.itc-web.com>


--
Visit 
https://lists.isc.org/mailman/listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users>
 to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/<https://www.isc.org/contact/> for 
more information.


bind-users mailing list
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users>
--
Visit 
https://lists.isc.org/mailman/lis

9.18 BIND not iterated over all authoritative nameservers

[Michael Martinell via bind-users]

Hello,

At this point I am hoping that somebody might have a workaround so that we can 
exclude domains from this behavior if they are broken on the far end. Does 
anybody have a workaround for this?

We are a small ISP and run BIND compiled from source. We currently run 9.16.x
Every time we try to move forward with 9.18 customers start to complain that 
they are unable to reach certain websites.  This includes banks, universities, 
and other organizations.

I understand the goal is to get all DNS to RFC 6891, but from a practical 
standpoint, this isn't working for customers, so we are prevented from 
upgrading either.

Related website:
https://gitlab.isc.org/isc-projects/bind9/-/issues/3152

Our source code compile options:
./configure --with-gnu-ld --with-libxml2 --with-json-c 
--with-openssl=/usr/local/openssl && make && make install && ldconfig

When I do a dig against a server running 9.18 I get the following:

dig @dns1.itctel.com view.bankeasy.com

; <<>> DiG 9.16.42 <<>> @dns1.itctel.com view.bankeasy.com

; (2 servers found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46906

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: d8ce8161641fbfdf0100653bcf9ad1fff99d24914278 (good)

;; QUESTION SECTION:

;view.bankeasy.com. IN A

;; Query time: 8 msec

;; SERVER: 
2607:d600:1000:330:75:102:161:227#53(2607:d600:1000:330:75:102:161:227)

;; WHEN: Fri Oct 27 09:56:26 CDT 2023

;; MSG SIZE rcvd: 74


The same command resolves just fine when I run it against 9.16
dig @dns2.itctel.com view.bankeasy.com

; <<>> DiG 9.16.42 <<>> @dns2.itctel.com view.bankeasy.com

; (2 servers found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30969

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: b0ec30c4ddfeacd30100653bcf9ff140c249344242e0 (good)

;; QUESTION SECTION:

;view.bankeasy.com. IN A

;; ANSWER SECTION:

view.bankeasy.com. 3133 IN CNAME view.gtm.bankeasy.com.

view.gtm.bankeasy.com. 300 IN A 96.2.250.200

;; Query time: 11 msec

;; SERVER: 
2607:d600:9000:330:75:102:160:227#53(2607:d600:9000:330:75:102:160:227)

;; WHEN: Fri Oct 27 09:56:31 CDT 2023

;; MSG SIZE rcvd: 125

[root@brkr-dns2 bind-9.18.12]#


Michael Martinell
Network/Broadband Technician

Interstate Telecommunications Coop., Inc.
312 4th Street West * Clear Lake, SD 57226
Phone: (605) 874-8313
michael.martin...@itccoop.com
www.itc-web.com
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind forgets my changes with nsupdate

[Michael Richardson]

201907-b...@planhack.com wrote:
>> My solution is not to mix dynamic update with other access.  Instead,
>> I put in CNAMEs in the signed zone to a sub-zone (or other zone) where
>> I do exclusive dynamic update.  This isn't perfect, but it works well
>> enough to allow dns-01 (certbot/LetsEncrypt) to be able to refresh my
>> certificates.

> Not perfect? What issues did you see? Thanks!

a) there are still a number of situations where systems do not follow CNAMEs 
when
   they should.  Particularly relating to RFC2317 reverse delegations.

b) using a second zones introduces additional possibilities for DNSSEC to be
   broken.

c) cruft accumulates in the second zone, and some of it does not get deleted.

d) updates to secondaries sometimes take longer than certbot is able to cope 
with.
   ("up-arrow-return" solves the problem if interactive.  Cron running a week
   later usually works)

--
]   Never tell me the odds!     | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[






signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind forgets my changes with nsupdate

[Michael Richardson]

In general, you don't want to mix dynamic update zones with ones that you
want to edit by hand.  I see that you are doing manual DNSSEC signing in your
cron job.

Your choices are:
a) do everything with dynamic update, and turn on automatic DNSSEC management
   in bind9.

b) do your DNSSEC signing inline.
   I blogged poorly about my setup:
   https://www.sandelman.ca/mcr/blog/sysadmin/bind9-dnssec-formula/

c) a mix of the above.
   My solution is not to mix dynamic update with other access.
   Instead, I put in CNAMEs in the signed zone to a sub-zone (or other zone)
   where I do exclusive dynamic update.  This isn't perfect, but it works
   well enough to allow dns-01 (certbot/LetsEncrypt) to be able to refresh my
   certificates.





signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Hyperlocal RFC8806 Root Mirror

[Michael Richardson]

Silva Carlos  wrote:
> On server A I configured HyperLocal. On Server B I did NOT configure
> HyperLocal.

> I ran the command "dig @localhost EXAMPLES" on both servers.
> EXAMPLES: blabla.sdf.dd or teste.com.eroterrter or world.nanana

> Problem: Both Servers report that "Query TIme = 0 ms". I understand that
> Server A should result in 0ms and Server B should have a non-zero time as
> Server B does not have a copy of the Root Zone DB.

> Question: Where am I going wrong? Am I missing some basic principle?

1. Server B could have cached the result already.
   Make sure you start it cold.
2. The query is probably taking between 0ms and 1ms, but rounds down to 0ms.

To be sure, you could tcpdump the network on server B.



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 9.18 unable to successfully transfer zone from axfrdns primary

[Michael Sinatra]

Right, BIND 9.18 now enforces Section 2.2 of RFC 5936, specifically, this:
   "The AXFR server MUST copy the
   Question section from the corresponding AXFR query message into the
   first response message's Question section.  For subsequent messages,
   it MAY do the same or leave the Question section empty."

There are some older implementations out there that don't do this 
correctly.  I have a vendor supported IPAM implementation, where I have 
gone back to the vendor and quoted the above, and they have fixed the 
implementation.


michael

On 8/31/23 17:34, Ian Bobbitt wrote:
That gets me more information, and I think puts the problem onto 
axfrdns. Thanks.


xfer-in: info: zone example.net/IN: Transfer started.
xfer-in: debug 1: zone example.net/IN: forced reload, requesting AXFR of 
initial version from 198.51.100.1#53
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
connected using 198.51.100.1#53
xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: 
sent request data
xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: 
missing question section
xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: 
failed while receiving responses: FORMERR

xfer-in: debug 1: zone example.net/IN: zone transfer finished: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer status: FORMERR


Looks like this isn't going to be solvable on my side. 
https://gitlab.isc.org/isc-projects/bind9/-/blob/v9.18.17/lib/dns/xfrin.c?ref_type=tags#L1657-1663


Packet capture confirms that we are indeed not getting a response with 
the question section.


I'm running the same version of dig, on the same system. Interesting 
that dig isn't as strict about this.


-- Ian

On 8/31/23 7:58 PM, Mark Andrews wrote:
Set debug level 3 on the xfrin channel.  There are some debug level 
messages that really should be set to error level in lib/dns/xfrin.c 
on FORMERR.


Also make sure you are running dig from the same version as later 
versions are more strict in parsing responses from the wire.



On 1 Sep 2023, at 09:23, Ian Bobbitt  wrote:

I have a system running BIND 9.18.17 that needs to transfer a zone 
from djbdns/axfrdns. I receive FORMERRs, and haven't been able to get 
any log messages indicating the problem.


xfer-in: info: zone example.net/IN: Transfer started.
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
connected using192.0.2.1 #53
xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: 
failed while receiving responses: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer status: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer completed: 0 messages, 0 records, 0 bytes, 0.008 secs (0 
bytes/sec) (serial 0)


This replaced a long obsolete system running 9.8.2 that was able to 
successfully transfer the zone. I can also successfully transfer the 
zone with `dig -t axfr ...` from the new system, which gives no 
errors. named-checkzone on the resulting data also gives no errors, 
and BIND is able to successfully load it as a primary.


How do I go about finding the cause of the FORMERR and resolve it?

-- Ian
--
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: Master file permission denied

[Michael Richardson]

Mark Andrews  wrote:
> where wrong and wouldn’t normally be that way.  Something or someone
> changed them.  It may have happened again.  We can’t see what you see

And, AppArmor can turn things into permission denied, which are rather
mysterious.  So, I'd ask for dmesg output too.



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dnssec not automatically updating on 1 server

[Michael Martinell via bind-users]

Anybody have any ideas on why my dnssec records don't always automatically 
update on my NS2 authoritative server?  On my NS1 authoritative server the 
records update without issue.
NS2 is an exact copy of NS1. We SCP all of the config files from the first 
server to the second server and do "rndc reconfig && rndc reload && systemctl 
restart bind" on both servers.
They are both Centos 7 running Bind 9.16.40.

When it fails, I get this message:
[root@ns2 ~]# delv itctel.com @ns2.itctel.com
;; validating itctel.com/A: verify failed due to bad signature (keyid=3593): 
RRSIG has expired
;; validating itctel.com/A: no valid signature found
;; RRSIG has expired resolving 'itctel.com/A/IN': 75.102.160.231#53
;; validating itctel.com/A: verify failed due to bad signature (keyid=3593): 
RRSIG has expired
;; validating itctel.com/A: no valid signature found
;; RRSIG has expired resolving 'itctel.com/A/IN': 
2607:d600:9000:300:75:102:160:231#53
;; resolution failed: RRSIG has expired


I have this policy in named.conf
dnssec-policy "itc-no-rotate" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};

I have this set up in a custom includes file:
zone "itctel.com" in {
type master;
file "forward/itctel.com.zone";
dnssec-policy itc-no-rotate;
inline-signing yes;
};

No changes to my actual zone files. The inline signing takes care of everything.

Here is a list of my files for this domain
/var/named/forward/itctel.com.zone  /var/named/forward/itctel.com.zone.jnl  
/var/named/forward/itctel.com.zone.signed
/var/named/forward/itctel.com.zone.jbk   /var/named/forward/itctel.com.zone.new 
 /var/named/forward/itctel.com.zone.signed.jnl




Michael Martinell
Network/Broadband Technician

Interstate Telecommunications Coop., Inc.
312 4th Street West * Clear Lake, SD 57226
Phone: (605) 874-8313
michael.martin...@itccoop.com
www.itc-web.com
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Reverse Policy Zone to make MS Azure stuff work?

[Michael De Roover]

Another thing I forgot to mention, is the need to express these parameters in 
the options clause in named.conf:

options {
// RPZ zone
// Source: https://deteque.com/m3aawg-bind-training/named.conf
response-policy {
zone "rpz.local";
};
};

My apologies for not double-checking earlier, but I think this should be 
everything.

-- 
Met vriendelijke groet / Best regards,
Michael De Roover

signature.asc
Description: This is a digitally signed message part.
-- 
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: Reverse Policy Zone to make MS Azure stuff work?

[Michael De Roover]

On Friday, 14 April 2023 00:28:24 CEST John Thurston wrote:
> Due to a requirement to use something Microsoft crafted, we are being
> asked to assert (internally) authority over 3rd-level names under
> appserviceenvironment.net
> 
> I've pushed back on this, because I don't think it's nice to publish
> "authoritative" answers in domains we have not been delegated. But I'm
> told it's all ok, because Microsoft says its ok* Having accepted that
> the ship has sailed, it's now a question of how to deliver such answers.
> 
> One obvious way is to define a zone for each 3rd level under
> appserviceenvironment.net, and publish them in a way our resolvers can
> find them. In the absence of catalog-zones, this could be a lot of
> additional work (for me).
> 
> Then I wondered if adding these 'hijacked' names to our RPZ would meet
> the need. I first thought, "Yeah. It'll work.", but then I re-read the
> statement from MS saying each 3rd level was going to need to have a 4th
> level zone defined. A zone definition requires at least an SOA and NS
> record  . . and last time I checked, an RPZ would not deliver an NS
> record. So it seems that idea may be squashed.
> 
> Who else has need to publish locally-defined appserviceenvironment.net
> names? Were you able to do it with your RPZ?
> 
> *
> https://learn.microsoft.com/en-us/azure/app-service/environment/create-ilb-a
> se


Hello John,

For what it's worth, I've been working on Microsoft related domains in an RPZ 
recently as 
well. The way I've done this is by defining a zone "rpz.local" in my 
named.conf, as shown 
below.

// Response Policy Zone
zone "rpz.local" {
type master;
file "/etc/bind/zones/rpz.local.db";
allow-update { none; };
allow-transfer { internal; };
allow-query { localhost; };
};

Then I define in this rpz.local.db file, entries like the ones below.

$TTL 300

@   IN  SOA localhost. need.to.know.only. (
202303131   ; Serial number
60  ; Refresh every minute
60  ; Retry every minute
43200   ; Expire in 5 days
60 ); Negative cache TTL 1 minute
IN  NS  LOCALHOST.

; Examples
block.example.com   IN  CNAME   .
passthrough.example.com IN  CNAME   rpz-passthru.
redirect.example.comIN  CNAME   example.com.

Pay special attention to the lack of a final dot in the records themselves, 
this is important. 
As far as I understand, this makes them relative to your rpz.local zone, not 
the actual 
domain on the internet. The only major issue I've been facing with this so far, 
is that AXFR 
to secondary and tertiary name servers has some issues, and at least Windows 10 
Home 
will query those when the primary name server does not give a satisfactory 
answer.

-- 
Met vriendelijke groet / Best regards,
Michael De Roover
-- 
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: Bind listener to an IPv6 from AnyIP subnet

[Michael Richardson]

m...@at.encryp.ch wrote:
> Regarding the usage of [::] - due to usage of firewall I am able to
> block connections to the 53/udp and 53/tcp which are not coming to
> specific IP addresses or ranges, I do not need such filtering
> functionality within bind itself.

Bind doesn't listen to specific sockets because of security.
It does so because of connectivity and plumbing.

I think you are making your life hard for no benefit.



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind listener to an IPv6 from AnyIP subnet

[Michael Richardson]

Serg via bind-users  wrote:
> As an alternative approach I have tried to run with a configuration
> "listen-on-v6 { any; }", but it does behave in a way I need - it binds
> separate socket for each discovered IP address rather wildcard address
> of [::].

Bind needs to bind a new socket for each address so that it can easily know
which address is being communicated with.  While there are newer ways to do
this, they aren't that portable.

What is the problem with binding to all the addresses, if you then filter
which addresses will actually respond?

Many large authoritative resolvers put the anycast address on the lo, and then 
use
BGP to announce connectivity, and AFAIK, they all just listen on all
addresses, because sometimes you want to ask a specific server a question.



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Something other than port 53 is blocking the LAN based BIND9 Servers

[Michael Richardson]

Mike Lieberman  wrote:
> The newer router blocks my local BIND servers (ONLY not clients using
> downstream servers) from receiving anything from the Internet. OUR BIND
> servers still have the local networks, but nothing else.

Your explanation is rather obtuse, but I think you mean that your BIND
servers can not do recursive lookups.  Rather than receive/answer
authoritative queries.

Do your queries originate from port-53?  That is not the default anymore, AFAIK.

> The question I need resolved by the proper group/forum is: What port or
> technology is doing the blocking? The ISP has no idea.

No, the ISP probably has no idea.  Might even be their FTTH ONT system.

> I have tried three of the new routers but all blocked my servers. I
> tried a replacement EoL router and that works. Without changing
> anything on the network, other than the physical router, it was like
> flipping a switch.

I assume it's a GPON, and therefore you can't easily tcpdump on the outside
like you can with a plan PPPoE with VDSL.





signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: converting from opendnssec/openhsm?

[Michael Richardson]

Can you share a bit about why you want to get out of using
opendnssec/openhsm?

I would regard this as an opportunity to test key rollover with your parent
zone :-)

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Finding dnssec validation failures in the logs

[Michael Richardson]

John Thurston  wrote:
> On a resolver running ISC BIND 9.16.36 with "dnssec-validation auto;" I am
> writing "category dnssec" to a log file  at "severity info;"  When I look 
in
> the resulting log file, I'm guessing that lines like this:

> validating com/SOA: got insecure response; parent indicates it should be
> secure

> Are an indication I have a problem I should investigate.

Maybe.
It could be that DNSSEC is simply defending you against attackers who are
trying to race insecure answers to your queries in the belief that "nobody 
validates"

If it were systematic (every query, every query to some servers...) then you
should suspect that there is a on-path attacker modifying the responses.
That's unlikely in general,  but it's why we have DNSSEC.
It could also be the result of corrupted packets that survive the UDP
checksum, or which go through a middle box that "fixes" that.  Some satellite
systems do that.  I imagine that Alaska might have at least one satellite link.

It doesn't sound like it's systematic, so I think they are off-path
attackers, and it looks like it's queries on .com?

Most likely, there is little you can do.



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC With Primary Hidden - Clarifying Question from Documentation

[Michael Richardson]

E R  wrote:
> I am planning on implementing the current version of BIND to replace the
> aging, undocumented authoritative servers I inherited.  I want to hide the
> primary server on our internal network and have two secondary servers be
> publicly available.  While reading the DNSSEC Guide
>  
recipes
> it seems to imply that I cannot have a hidden primary that handles all the
> DNSSEC stuff.

Many people do exactly that.
Check out the: “Bump in the Wire” Signing section.

In my opinion, this is the best way to do things, and the in-place signing is
just a total pain.



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: General DNS / SPF question

[Michael Muller via bind-users]

Hi G,

Thanks for responding to my question. Again, if there's a better place 
to ask this question, I can go there. I did not see an SPF list on the 
community list sign-up page <https://www.isc.org/mailinglists/>.


I updated the SPF to include:_spf.google.com instead of include:gmail.com

Here's a log entry for one attempt to my Yahoo address, today (below). 
Email did not arrive in Inbox, nor to Spam.


I have sent you an email from the account. You can reply to me directly 
if you wish, t...@montaguewebworks.com, not the customer's address.


Thanks,

Mik



[2023.01.09] 14:04:20.505 [209.85.221.43][16101147] rsp: 220 
mail.montaguewebworks.com
[2023.01.09] 14:04:20.505 [209.85.221.43][16101147] connected at 
1/9/2023 2:04:20 PM

[2023.01.09] 14:04:20.505 [209.85.221.43][16101147] Country code: US
[2023.01.09] 14:04:20.709 [209.85.221.43][16101147] cmd: EHLO 
mail-wr1-f43.google.com
[2023.01.09] 14:04:20.709 [209.85.221.43][16101147] rsp: 
250-mail.montaguewebworks.com Hello [209.85.221.43]250-SIZE 
41943040250-AUTH LOGIN CRAM-MD5250-8BITMIME250-DSN250 OK

[2023.01.09] 14:04:20.834 [209.85.221.43][16101147] cmd: AUTH LOGIN
[2023.01.09] 14:04:20.834 [209.85.221.43][16101147] rsp: 334 VXNlcm5hbWU6
[2023.01.09] 14:04:20.927 [209.85.221.43][16101147] Authenticating as 
off...@gelinascompany.com

[2023.01.09] 14:04:20.927 [209.85.221.43][16101147] rsp: 334 UGFzc3dvcmQ6
[2023.01.09] 14:04:21.037 [209.85.221.43][16101147] rsp: 235 
Authentication successful
[2023.01.09] 14:04:21.037 [209.85.221.43][16101147] Authenticated as 
off...@gelinascompany.com
[2023.01.09] 14:04:21.130 [209.85.221.43][16101147] cmd: MAIL 
FROM: SIZE=2589
[2023.01.09] 14:04:21.130 [209.85.221.43][16101147] senderEmail(1): 
off...@gelinascompany.com parsed using: 
[2023.01.09] 14:04:21.130 [209.85.221.43][16101147] rsp: 250 OK 
 Sender ok
[2023.01.09] 14:04:21.130 [209.85.221.43][16101147] Sender accepted. 
Weight: 0. Block threshold: 30.
[2023.01.09] 14:04:21.240 [209.85.221.43][16101147] cmd: RCPT 
TO:
[2023.01.09] 14:04:21.240 [209.85.221.43][16101147] rsp: 250 OK 
 Recipient ok

[2023.01.09] 14:04:21.334 [209.85.221.43][16101147] cmd: DATA
[2023.01.09] 14:04:21.334 [209.85.221.43][16101147] Performing PTR host 
name lookup for 209.85.221.43
[2023.01.09] 14:04:21.334 [209.85.221.43][16101147] PTR host name for 
209.85.221.43 resolved as mail-wr1-f43.google.com
[2023.01.09] 14:04:21.334 [209.85.221.43][16101147] rsp: 354 Start mail 
input; end with .
[2023.01.09] 14:04:21.443 [209.85.221.43][16101147] senderEmail(2): 
off...@gelinascompany.com parsed using: Gelinas Office 


[2023.01.09] 14:04:21.443 [209.85.221.43][16101147] rsp: 250 OK
[2023.01.09] 14:04:21.459 [209.85.221.43][16101147] Received message 
size: 2593 bytes
[2023.01.09] 14:04:21.459 [209.85.221.43][16101147] Successfully wrote 
to the HDR file. (c:\SmarterMail\Spool\proc\122619776.hdr)
[2023.01.09] 14:04:21.459 [209.85.221.43][16101147] Data transfer 
succeeded, writing mail to 122619776.eml (MessageID: 
)

[2023.01.09] 14:04:21.552 [209.85.221.43][16101147] cmd: QUIT
[2023.01.09] 14:04:21.552 [209.85.221.43][16101147] rsp: 221 Service 
closing transmission channel
[2023.01.09] 14:04:21.552 [209.85.221.43][16101147] disconnected at 
1/9/2023 2:04:21 PM




Mik Muller, president
Montague WebWorks
20 River Street, Greenfield, MA
413-320-5336
http://MontagueWebWorks.com
Powered by ROCKETFUSION

On 1/7/2023 6:24 PM, G.W. Haywood via bind-users wrote:

Hi there,

On Sat, 7 Jan 2023, Michael Muller wrote:


This is my first time posting here, and I'm not sure if it's the
right place or not to ask my question. This is a general DNS
question, specifically, I think, SPF.


Probably not really the right place but the SPF users' list has been a
bit dead for a while so let's see what happens.

I host email using SmarterMail, and all 400+ customers either use a 
regular email client (desktop app/mobile device) or the webmail 
interface.


One particular customer wants to use Gmail as their email client for
sending email from their domain.


What's the domain?


I helped set up the settings at gmail for the SMTP server, and did
the google-siteverification and added _include:gmail.com_ to the SPF
TXT record,


The gmail.com SPF record is just a redirect - wasteful.  I'd suggest

include:_spf.google.com

instead.


as well as DKIM and DMARC configured. I get green lights for the
domain from Dmarcian (well, they said I had a duplicate SPF value,
which I have removed).

The emails that get sent *do* arrive for other users on my email 
server, but *not* to email addresses off-server, ie; @live.com


I can see the traffic from gmail in my logs, and it appears the 
emails are sent, but they do not arrive.


Stumped. Any spare brain cells available out there would be appreciated.


Can you show us a log of one of the transactions?  Or perhaps get the
customer to try to send mail to me, I should be able to see everythin

General DNS / SPF question

[Michael Muller via bind-users]

Hello everyone,

This is my first time posting here, and I'm not sure if it's the right 
place or not to ask my question. This is a general DNS question, 
specifically, I think, SPF.


(Btw, I do use Bind in my system, so that's why I'm here.)

I host email using SmarterMail, and all 400+ customers either use a 
regular email client (desktop app/mobile device) or the webmail interface.


One particular customer wants to use Gmail as their email client for 
sending email from their domain. I helped set up the settings at gmail 
for the SMTP server, and did the google-siteverification and added 
_include:gmail.com_ to the SPF TXT record, as well as DKIM and DMARC 
configured. I get green lights for the domain from Dmarcian (well, they 
said I had a duplicate SPF value, which I have removed).


The emails that get sent *do* arrive for other users on my email server, 
but *not* to email addresses off-server, ie; @live.com


I can see the traffic from gmail in my logs, and it appears the emails 
are sent, but they do not arrive.


Stumped. Any spare brain cells available out there would be appreciated.

Thanks,

Mik

Mik Muller, president
Montague WebWorks
20 River Street, Greenfield, MA
413-320-5336
http://MontagueWebWorks.com
Powered by ROCKETFUSION

On 1/7/2023 3:11 PM, Anders Löwinger wrote:


Hi

I have some trouble with the parental-agents. Anyone seen this 
before/can give me a clue to get this working?


Tried with my two recursive resolvers first, then localhost. No 
difference.


From the log

named[3420650]: zone lowinger.se/IN (signed): checkds: empty DS 
response from 2a00:f680:100:1501::32#53
named[3420650]: zone lowinger.se/IN (signed): checkds: empty DS 
response from 2a00:f680:10:1501::33#53
named[3428351]: zone lowinger.se/IN (signed): checkds: empty DS 
response from 127.0.0.1#53


zone "lowinger.se" {

    type primary;
    file "lowinger.se";
    dnssec-policy lowinger-policy;
    inline-signing yes;
    // parental-agents {
    //     2a00:f680:100:1501::32;
    //     2a00:f680:100:1501::33;
    // };
    parental-agents { 127.0.0.1; };
};

BIND 9.18.10-1+ubuntu22.04.1+isc+1-Ubuntu (Stable Release) *

*

dig has no problem resolving the DS record.

# dig @127.0.0.1 lowinger.se ds +short
59647 14 2 825E888C2FAA4F70241467A257C02C66AD5DAFDB818253B7FEB52DA4 
BEB071CA


# dig @2a00:f680:100:1501::32 lowinger.se ds +short
59647 14 2 825E888C2FAA4F70241467A257C02C66AD5DAFDB818253B7FEB52DA4 
BEB071CA


# dig @2a00:f680:100:1501::33 lowinger.se ds +short
59647 14 2 825E888C2FAA4F70241467A257C02C66AD5DAFDB818253B7FEB52DA4 
BEB071CA



--
Regards / Med vänlig hälsning
Anders Löwinger, CEO, Abundo AB, +46 72 206 0322
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How do subdomains get discovered by adversaries?

[Michael De Roover]

On Thu, 2022-12-22 at 05:19 +, Michael De Roover wrote:
> Hello,
> 
> I have been running BIND 9 on my external and internal networks for a
> few years now -- as such I have a basic understanding of the most
> common RR types and activities such as zone transfers. However, I
> have been seeing something that's been baffling me for quite a while
> now. Somehow there are services like c99.nl [1] and Criminal IP [2],
> which can enumerate various subdomains on a given target domain. I am
> confused as to how they can enumerate this information.
> 
> As far as I know, a NS record returns the name servers authoritative
> for a domain. Alright, now you've got authoritative information when
> querying these domains. No useful information about the zone data
> they are responsible for though.
> 
> Then there is an A record, which returns an IPv4 address of a server
> responsible for a domain. Alright, now you can talk to a server.
> Maybe that would be a webserver, and now you may perform a HTTP
> exchange to that server (GET /whatever, with a given Host header).
> You still have to guess what the Host: header would have to be.
> 
> Maybe it would be an MX record. Brilliant, now you could talk to a
> mail server. Its EHLO message (sometimes called a "banner" in
> security circles) would contain a domain, alright. It would also only
> be one of them -- AFAICT only one domain that the organization wants
> to actually primarily send from.
> 
> Another interesting record would be the CNAME record. As far as I
> know, this is used to redirect to another domain from within the DNS,
> with its own bespoke entries (bringing us back to A records). Getting
> from a CNAME to an A record seems easy enough, but what about getting
> these CNAME records in the first place?
> 
> This is what I am thinking of so far, but it may well be that I've
> been talking crap in all of the above and know nothing about the DNS.
> That's fine, and in that case please correct me where necessary.
> Either way, I'm very confused on how these services can actually
> enumerate these subdomains, and find most -- if not all -- reliably.
> This seems a bit concerning to me with regards to unwanted
> information disclosure, hence my curiosity. If it is at all possible
> to mitigate, I would of course also appreciate discourse on this
> matter. Thank you!
> 
> [1] https://subdomainfinder.c99.nl
> [2] https://criminalip.io/domain
> 
> Best regards,
> Michael
> 
On an unrelated note, I found that Apple Mail (which I checked for on
various ISC employees' email headers in the past due to curiosity,
several seem to use it) is unable to deal very well with text emails
and its formatting (particularly regarding new lines). Which format is
preferred on this list? For now, I have set my email client to default
to HTML messages, and edited my original message to remove these
newlines. Chances are that it would send a text-only message too. But
in modern clients, I find text-only emails to insert a lot of unwanted
newlines, going back to the 80-column terminals which I don't think
anyone uses anymore (though I most certainly approve of the efficiency-
driven sentiment these people tend to hold).

Back on topic, I forgot about PTR records. But at least in a VPS
instance (or a multiple thereof), it would only be configurable to one
domain in the hosting provider's configuration panel, no? I am aware of
PTR delegation, but that seems to be only for entire public network
ranges (which at this point are only /24 and beyond in IPv4 afaict).
While my hosting provider is very friendly to me, I certainly do not
consider them a party who's willing to delegate it to me. With that
tangent out of the way -- one record, configured by them on my behalf.
And that's it. Not much information to get subdomains from there.
Meanwhile, larger organizations are very likely to delegate every
service that cares about PTR records to others. Their PTR records would
just point to those instead.

So PTR records don't seem to be very useful in getting this information
either. As such, I am still stranded.

Thanks again for your attention,
Michael
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

How do subdomains get discovered by adversaries?

[Michael De Roover]

Hello,

I have been running BIND 9 on my external and internal networks for a
few years now -- as such I have a basic understanding of the most
common RR types and activities such as zone transfers. However, I have
been seeing something that's been baffling me for quite a while now.
Somehow there are services like c99.nl [1] and Criminal IP [2], which
can enumerate various subdomains on a given target domain. I am
confused as to how they can enumerate this information.

As far as I know, a NS record returns the name servers authoritative
for a domain. Alright, now you've got authoritative information when
querying these domains. No useful information about the zone data they
are responsible for though.

Then there is an A record, which returns an IPv4 address of a server
responsible for a domain. Alright, now you can talk to a server. Maybe
that would be a webserver, and now you may perform a HTTP exchange to
that server (GET /whatever, with a given Host header). You still have
to guess what the Host: header would have to be.

Maybe it would be an MX record. Brilliant, now you could talk to a mail
server. Its EHLO message (sometimes called a "banner" in security
circles) would contain a domain, alright. It would also only be one of
them -- AFAICT only one domain that the organization wants to actually
primarily send from.

Another interesting record would be the CNAME record. As far as I know,
this is used to redirect to another domain from within the DNS, with
its own bespoke entries (bringing us back to A records). Getting from a
CNAME to an A record seems easy enough, but what about getting these
CNAME records in the first place?

This is what I am thinking of so far, but it may well be that I've been
talking crap in all of the above and know nothing about the DNS. That's
fine, and in that case please correct me where necessary. Either way,
I'm very confused on how these services can actually enumerate these
subdomains, and find most -- if not all -- reliably. This seems a bit
concerning to me with regards to unwanted information disclosure, hence
my curiosity. If it is at all possible to mitigate, I would of course
also appreciate discourse on this matter. Thank you!

[1] https://subdomainfinder.c99.nl
[2] https://criminalip.io/domain

Best regards,
Michael

-- 
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: automatic reverse and forwarding zones

[Michael Richardson]

Havard Eidnes via bind-users  wrote:
>To "fill" an ip6.arpa zone for a /64 requires 18446744073709551616
> records (yes, that's about 18 x 10^18 if my math isn't off).  I predict
> you do not posess a machine capable of running BIND with that many
> records loaded -- I know we don't.

It sure would be nice to be able to set some kind of default (static) answer for
reverse zones.  While it has limited useability for IPv4, it would actually
be nice, and it seems a win for IPv6 reverse.

It probably does not play well with DNSSEC, although I was thinking about
whether some amount of wildcards in the signed reverse could help, but I
don't think so.




signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Zone transfer over VPN

[Michael De Roover]

On Wednesday, September 7, 2022 1:14:00 AM WEST John Thurston wrote:
> If you are dealing with two totally private networks, do you even need
> the ACL?
> 
> But if you do need to limit access, then I suggest using TSIG to
> identify and authorize. This avoids the whole question of
> source/destination IP addresses. If the transfer request is made using
> the correct key, it will work.
> 
> I do this by defining a specific key for each secondary server. Then, in
> the appropriate view on the hidden primary, I use:
> 
>match-clients { none; };
>allow-transfer { key nameofkeyhere; };
> 
> and on each secondary, I define a 'primaries' and use that in the zone
> definitions:
> 
>primaries hiddenprimary { 10.20.30.40 key nameofkeyhere; };
>zone "foo.bar.com" { type secondary;  primaries { hiddenprimary; }; };
> 
> The address of the secondary does not matter. As long as it makes the
> connection to the primary using the key 'nameofkeyhere', it can do the
> zone transfers.

Hi John,

Thank you so much for getting back to me, I really appreciate it. I have used 
your advice and looked further into how to configure TSIG, and came across this 
article on nixCraft [1]. However, while the setup seems like it is fairly 
straightforward, the usage of HMAC-MD5 they mention seems to be deprecated. I 
have checked which ciphers dnssec-keygen supports in 9.18.5 (I have taken the 
time to upgrade the Alpine boxes while I was at it) and it seems like ED25519 
is supported, which I like and use extensively in SSH already. But when using 
the command below, it doesn't seem to work properly, exiting with the error 
message below that.

ns1:~# cd /etc/bind
ns1:/etc/bind# dnssec-keygen -a ED25519 -n HOST rndc-key
dnssec-keygen: fatal: invalid DNSKEY nametype HOST

Using this command without the -n parameter works fine, but (as per defaults) 
generates a zone key instead. Is ED25519 supported for host keys? If not, what 
would be the best current practice algorithm to generate a key of this type? 
Apparently the options in my installation of BIND are among these:

-a :
RSASHA1 | NSEC3RSASHA1 |
RSASHA256 | RSASHA512 |
ECDSAP256SHA256 | ECDSAP384SHA384 |
ED25519 | ED448 | DH
-b :
RSASHA1:[1024..4096]
NSEC3RSASHA1:   [1024..4096]
RSASHA256:  [1024..4096]
RSASHA512:  [1024..4096]
DH: [128..4096]
ECDSAP256SHA256:ignored
ECDSAP384SHA384:ignored
ED25519:ignored
ED448:  ignored
(key size defaults are set according to
algorithm and usage (ZSK or KSK)

[1] https://www.cyberciti.biz/faq/unix-linux-bind-named-configuring-tsig/

Thanks again for your time to read this email, and for your insights.

-- 
Met vriendelijke groet / Best regards,
Michael De Roover


-- 
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

Zone transfer over VPN

[Michael De Roover]

Hello everyone,

I have currently 2 internal networks under my control, both of which have BIND 
name servers in them. The "main" network uses the 192.168.10.0/24 subnet, 
while the "satellite" network uses the 192.168.20.0/24 subnet. Following this, 
I will refer to these as main and satellite. You may consider the satellite 
network sort of like a road warrior setup, though both are fully-fledged 
networks with hosts in them.

The main network has a set of two gateways with IP addresses 192.168.10.51, 
and 192.168.10.52. They perform VRRP to each other, with floating IP 
192.168.10.9. Both of them make a VPN connection to two VPS's using WireGuard.

The VPS's have IP ranges 10.8.2.0/24 and 10.8.3.0/24 respectively. Pretty much 
all traffic that's relevant here (AXFR/IXFR on TCP 53) goes through the former.

The satellite network does the same thing, it also connects to the VPS's but 
does not perform VRRP with another node. The gateway on the satellite network 
uses IP address 192.168.20.1.

The name servers on these networks are 192.168.10.4, 192.168.10.5 and 
192.168.10.6 on the main network, and 192.168.20.3 on the satellite network.

This is running on BIND 9.16.25 for Alpine on the main network, and BIND 
9.11.5-P4-5.1+deb10u7-Debian for Debian on the satellite network. All of them 
are running in LXC with bridged networking.

Now I would like to get both of these networks to share their local zones. So 
in the name servers' configs I would initially declare an ACL for this and add 
that to the zone entries, on the main network. This worked fine for those, 
being in the same subnet. But once I tried to do the same on the satellite 
network, BIND on the main network would see the zone transfer as coming from 
192.168.10.51 or 192.168.10.52 -- instead of coming from 192.168.20.3 -- and 
refuse it. The same is true the other way around, where the name server on the 
satellite network sees zone transfers from the main network as coming from 
192.168.20.1 instead.

In other words, only the first hop (or the last, depending on how you look at 
it) is being considered, with zone transfers seemingly being expected to occur 
from within the same subnet. Surely I'm not the only one who dealt with this? 
If anything, I consider myself still a newbie. Is it possible to get BIND to 
consider the original source of the zone transfer instead?

For now I have added an "external" ACL to these networks, and made the 
respective local zones authorized to transfer from this ACL, which has the 
gateways of their local networks in there. However, this means that anything 
on the main network can transfer from the satellite network, and anything from 
the satellite network can transfer from the main network. After all, the name 
servers have no way to tell where it's really coming from. While everything on 
these networks is owned or otherwise controlled to a reasonable extent by me, 
I don't like this. In my book, this is a security issue. I think I need a 
better solution for this.

Configuration-wise, this would be a snippet from ns1.lan on the main network 
with the relevant bits.

acl external {
   admin; 
   192.168.10.9; 
   192.168.10.51; 
   192.168.10.52; 
};
; ...
zone "lan" { 
   type master; 
   file "/etc/bind/zones/fwd.lan.db"; 
   allow-transfer { internal; external; }; 
}; 
zone "10.168.192.in-addr.arpa" { 
   type master; 
   file "/etc/bind/zones/rev.lan.db"; 
   allow-transfer { internal; external; }; 
};

The satellite network's name server has a similar configuration to this, but 
the other way around.

I have skimmed over these articles so far, but couldn't find anything relevant 
in them.
- https://kb.isc.org/docs/aa-00726 
- https://www.zytrax.com/books/dns/ch7/xfer.html 

Thank you so much for taking your time to read this, and thanks in advance for 
any insights.

-- 
Met vriendelijke groet / Best regards,
Michael De Roover


-- 
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: Stopping ddos

[Michael De Roover]

For my servers I'm using iptables rules to achieve ratelimiting. They
look as follows:
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent --
update --seconds 600 --hitcount 4 --name DEFAULT --mask 255.255.255.255
--rsource -j DROP
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent --set
--name DEFAULT --mask 255.255.255.255 --rsource

It should be fairly trivial to convert these to use UDP 53, and tweak
the timings you want. These rules are intended to allow 4 connections
(which normally should be entire SMTP transactions) every 10 minutes.
Since I have 2 edge nodes with these rules, that is doubled to 8
connections total. If you're an authoritative name server only,
realistically mostly recursors / caching servers would query your
servers and not too often. You can easily restrict traffic here. If
you're a recursor too, this becomes a bit more complicated.

Regarding the legitimate queries, it would be prudent to allow common
recursors (Google, Cloudflare, Quad9 etc) to have exceptions to this
rule. Just allow their IP addresses to send traffic either
unrestricted, or using a more relaxed version of the above.

HTH,
Michael

On Tue, 2022-08-02 at 16:02 -0400, Robert Moskowitz wrote:
> Recently I have been having problems with my server not responding to
> my 
> requests.  I thought it was all sorts of issues, but I finally looked
> at 
> the logs and:
> 
> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
> 114.29.194.4#11205 
> (.): view external: query (cache) './A/IN' denied
> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
> 114.29.216.196#64956 (.): view external: query (cache) './A/IN'
> denied
> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
> 64.68.114.141#39466 
> (.): view external: query (cache) './A/IN' denied
> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
> 209.197.198.45#13280 (.): view external: query (cache) './A/IN'
> denied
> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
> 114.29.202.117#41955 (.): view external: query (cache) './A/IN'
> denied
> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
> 62.109.204.22#4406 
> (.): view external: query (cache) './A/IN' denied
> Aug  2 15:47:49 onlo named[6155]: client @0xa9420720
> 64.68.104.9#38518 
> (.): view external: query (cache) './A/IN' denied
> Aug  2 15:47:50 onlo named[6155]: client @0xaa882dc8
> 114.29.202.117#9584 
> (.): view external: query (cache) './A/IN' denied
> 
> grep -c denied messages
> 45868
> 
> And that is just since Jul 31 3am.
> 
> This is fairly recent so I never looked into what I might do to
> protect 
> against this.  I am the master for my domain, so I do need to allow
> for 
> legitimate queries.
> 
> Any best practices on this?
> 
> I am running bind 9.11.4
> 
> thanks
> 
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Using nsupdate remotely

[Michael Richardson]

Philip Prindeville  wrote:
> What do I need to do on both ends (remote DHCP server and central DNS
> server) to push updates over?

Your list is pretty accurate.

One thing that bites me regularly is that names of the TSIG keys matters, and
that if you have a trailing . in the key name, it matters too.



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: understanding keymgr handling of KSK

[Michael Richardson via bind-users]

I found this message:

May  8 16:41:18 tilapia named[1268]: zone ox.org/IN: 
zone_rekey:dns_dnssec_keymgr failed: error occurred writing key to disk

It would be great if it could tell me the file name that failed to write, and
ideally what the error was (EPERM is my guess, but there could also be
AppArmor stupids for some people which are really hard to diagnose).

Is there a way to put all the keymgr logging into a different debug stream?
Ideally, I think I need it emailed to me daily :-)

-- 
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

understanding keymgr handling of KSK

[Michael Richardson via bind-users]

CFE80835B1FCAE94BE8ED2CF26D31942E1628C3D1E7A9 A026535A

No change in the key at .org, and I checked and I don't have a CDS published.

So what happened?  I shall troll my logs and see what else I can find out,
but there sure is a lot of stuff going on.  Maybe lots of flotsam from my
previous situation that needs to expunged.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How to allow recursion on my own (cross) domains only after upgrade to 9.16.27 (lack of additional-from-auth option) ?

[Michael Richardson]

Mark Andrews  wrote:
> Unless you are pointing recursive clients directly at your
> authoritative servers there is no need. The recursive servers will
> lookup the CNAME target themselves. Additionally recursive servers just
> process the CNAME and ignore the rest of the response to prevent cache
> poisoning if there is more there.

I think that implicit in Mark's answer is that the additional data that was
being returned was just wasted bytes, since it could never be trusted by
clients so why waste bytes.   Thus the change?


signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

invalid prefix

[Michael Richardson]

I upgraded to 9.18 from 9.11 or something that was in debian nulleye.

Mar 11 18:14:27 tilapia named[9206]: /etc/bind/named.conf.options:40: invalid 
prefix, bits [64..71] must be zero

Alas, line 40 has multiple IPv6 prefixes on it:

40   dns64 2607:f0b0:f:0:::/96 {
41  clients { 2607:f0b0:f::/56; 2a00:1098::/64; };
42  exclude { !2607:f0b0:f:3::184/128; 
!2607:f0b0:f:3:216:3eff:fe7c:d1f3/128; !2607:f0b0:f:2::30/128; };
42   mapped { !172.30.0.0/16; !10/8; !209.217.85.0/24; any; };
43};

I feel a bit annoyed by this error, because it's kinda nice to be able to
just paste in stuff from ifconfig output, etc. and then say, yeah, let's do
the entire subnet but I understand that often it's a clue that someone is
clueless.

But, it would be great if the message told me which prefix was actually a
problem.



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Nice new logging feature

[Michael Sinatra]

On 12/16/21 06:42, Borja Marcos wrote:




On 16 Dec 2021, at 14:55, Reindl Harald  wrote:



Am 16.12.21 um 14:49 schrieb Borja Marcos:


bind-9.16.23-1.fc34.x86_64

16-Dec-2021 13:08:10.598 lame-servers: connection refused resolving 
'ns2.serverion.eu/A/IN': 94.228.210.122#53
16-Dec-2021 13:11:29.269 lame-servers: host unreachable resolving 
'250.84.141.45.in-addr.arpa/PTR/IN': 45.79.19.196#53
16-Dec-2021 13:11:31.804 lame-servers: host unreachable resolving 
'250.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
16-Dec-2021 13:12:10.567 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 198.58.118.167#53
16-Dec-2021 13:12:13.903 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.18.44#53
16-Dec-2021 13:12:14.034 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.2.79#53
16-Dec-2021 13:12:15.773 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.23.183#53
16-Dec-2021 13:12:15.938 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53

Not for me definitely, but I am not running Linux. This is a FreeBSD port of 
the ISC release.
Does that version include some back ported code from bind 9.17?


i doubt that Fedora does any functional patching, maybe some of the build flags 
while i'm not sure if the stuff shown at startup is really all


Hmm. Doesn’t look like that, I have compared the build options and it doesn’t 
explain it.


I can confirm the same logs are appearing in my 'lamers.log' file on a 
FreeBSD 12.2 system running BIND 9.16.22 (about to be upgraded).  Maybe 
your `logging {}` stanza is missing the appropriate incantation?


Mine are fairly plain:
[...]
  channel lamers {
file "/var/log/named/lamers.log" versions 9;
print-time yes;
  };
[...]
  category lame-servers { lamers; };
[...]

michael
___
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: BIND 'max-cache-size' Value on FreeBSD-13.0

[Michael Sinatra]

On 9/2/21 2:59 PM, Mark Tinka wrote:



On 9/2/21 23:51, Michael Sinatra wrote:



I have noticed this also and have opened a (similar but different) 
issue, but it's a bit weird how it manifests itself.


On your freebsd installation, make sure that all of your interfaces 
are configured and that bind can listen on them.  (They don't 
necessarily need to be up; they just need to be configured.)


Also, 'listen-on[-v6] any;' is more likely to prevent this kind of 
memory leaking than having it listen on explicit addresses.  But the 
way I can (more) reliably reproduce it is to have a 'listen-on' 
statement that references a non-existent interface/address.


I think this is a libuv problem, but I have been really short on time 
to troubleshoot.  But in the meantime, I would check on your 
'listen-on' statements and make sure there aren't any stray addresses 
in there.


What we have on all of our name servers is the below:

// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
//  listen-on   { 127.0.0.1; };

// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver.  To give access to the network, specify
// an IPv6 address, or the keyword "any".
     listen-on-v6    { ::1; };


It *feels* like the above ^^ could be the culprit.  'listen-on any' 
ought to listen on the loopback interface in addition to all other 
configured ethernets and loopbacks.  OTOH, the libuv-based versions of 
BIND (e.g. >=9.16.x) appear to get kind of weird/confused with certain 
types of listen-on statements.



     listen-on-v6    { any; };

We are running dual-stack on all name servers, and both IPv4 and IPv6 
reachability is confirmed solid.


On IPv4, we are listening on just the main interface. On IPv6, we are 
listening on both the localhost and the main interface. Not sure if this 
matters.


For local resolution on each name server, it refers to localhost for 
both IPv4 and IPv6 in '/etc/resolv.conf'. Given our configuration, it's 
using ::1 for local resolution, whenever that may be required, since 
127.0.0.1 has nothing listening on it. Thanks.


'listen-on any;' is the default for v4, so you should actually be 
listening on 127.0.0.1 in addition to everything else (since all of your 
listen-on's for v4 appear to be commented out).  You *should* be able to 
remove 'listen-on-v6{ ::1; };' and just leave the 'listen-on-v6{ 
any; };' in place.  Doing a 'sockstat | grep named' on FreeBSD should 
confirm this once you restart named (pretty sure you already knew that, 
but I thought I'd mention it for completeness).


michael

___
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: BIND 'max-cache-size' Value on FreeBSD-13.0

[Michael Sinatra]

On 9/2/21 2:35 PM, Mark Tinka wrote:

Not sure if this issue offers some clue:

https://gitlab.isc.org/isc-projects/bind9/-/issues/2575

I see its maintainer just closed it 11hrs ago...


I have noticed this also and have opened a (similar but different) 
issue, but it's a bit weird how it manifests itself.


On your freebsd installation, make sure that all of your interfaces are 
configured and that bind can listen on them.  (They don't necessarily 
need to be up; they just need to be configured.)


Also, 'listen-on[-v6] any;' is more likely to prevent this kind of 
memory leaking than having it listen on explicit addresses.  But the way 
I can (more) reliably reproduce it is to have a 'listen-on' statement 
that references a non-existent interface/address.


I think this is a libuv problem, but I have been really short on time to 
troubleshoot.  But in the meantime, I would check on your 'listen-on' 
statements and make sure there aren't any stray addresses in there.


michael
___
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

Does BIND support "conservative" (RFC 6781, sec 4.1.4) algorithm rollovers?

[Michael Sinatra]

Hi,

I have, in the past, used the "conservative" approach to performing 
algorithm rollovers for various domains.  For many domains, this is 
probably overkill, but I'd prefer to have the option of doing it, 
especially for those mission-critical domains where you really don't 
want to rely simply on the hope that nobody who needs to reach you (or 
your org/company) is using a resolver that is still following the 
strictest interpretation of RFC 4035, section 2.2.


In the past, I have handled this completely manually, signing the zone 
using dnssec-signzone to sign the zone with keys of both algs before 
(again manually) including the the new alg keys in the DNSKEY RRSET. 
But for zones which I am inline-signing as a provider for someone else, 
I would like to use a more automated method.  It doesn't appear that 
BIND currently supports this, either with dnssec-keymgr and 
'inline-signing' or with KASP.


I did try the trick of setting the key metadata manually ('publish' in 
the future and 'activate' in the past), but BIND 'inline-signing' would 
not sign the zone prior with the key prior to its publication, despite 
my timing metadata settings.


So I am assuming that only the "liberal" approach is supported.  One 
thing I thought of was trying a "moderate" approach, where the various 
TTLs are manipulated so that the zone RRSIGs expire quickly before the 
new alg is added and then flipping it so that the DNSKEY RRSET expires 
quickly and the zone/RRSIG TTLs stay in cache longer.  But that is still 
a fairly tricky approach and I am not sure it would work...


michael
___
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

Important: A significant flaw is present in June BIND releases 9.16.17 and 9.17.14

[Michael McNally]

Dear BIND users:

Yesterday, 16 June 2021, we released monthly maintenance snapshot releases of
our currently supported release branches of BIND.

Specifically, we released BIND 9.11.33, 9.16.17, and 9.17.14

There's no way to say this that isn't embarrassing, but only after the release
was an error in a recently optimized routine discovered by a user -- an error
that will definitely cause operational problems for almost all server operators
who upgrade to either of these affected versions:

-  BIND 9.16.17
-  BIND 9.17.14

BIND 9.11.33 is NOT affected.

If you have not yet updated to the 16 June releases, we ask that you hold off
on any plans to install 9.16.17 or 9.17.14 until replacement releases can be
prepared and tested.

The specific issue in question is being tracked in our issue tracker:

   https://gitlab.isc.org/isc-projects/bind9/-/issues/2779

and more information about our plans for issuing replacement releases will be
provided later; at the moment our priority is getting the news to parties as
quickly as possible so that those who have not already adopted the new releases
can postpone until corrected versions are available.

Michael McNally
Internet Systems Consortium
___
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

New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13

[Michael McNally]

The May 2021 maintenance releases of BIND are available and can be downloaded
from the ISC software download page, https://www.isc.org/download

A summary of changes in the new releases can be found in their release notes:

current supported stable branches:

  9.11.32 - 
https://downloads.isc.org/isc/bind9/9.11.32/RELEASE-NOTES-bind-9.11.32.html
  9.16.16  - 
https://downloads.isc.org/isc/bind9/9.16.16/RELEASE-NOTES-bind-9.16.16.html

experimental development branch:

  9.17.13  - 
https://downloads.isc.org/isc/bind9/9.17.13/RELEASE-NOTES-bind-9.17.13.html

Please note:

   The 9.17 experimental development branch is produced on a best-effort basis.
   In this particular set of releases, an issue in our build tools prevented
   the creation of the usual installer package for Windows users.  Rather than
   delay the release, we went ahead, with the consequence that there are no
   Windows zips provided for the 9.17 branch this month.

   Zip files with Windows packages were provided as usual for the 9.11 and
   9.16 branches.

Michael McNally
ISC Support
___
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: Possibly stupid Q

[Michael De Roover]

If the chroot location is set to /var/named/chroot, then this should be
the case yes. As far as the software running in the chroot is
concerned, the chroot directory is its rootfs at /. It does not have
access to anything above that.

On Wed, 2021-01-20 at 16:42 -0500, Rick Dicaire wrote:
> On Wed, Jan 20, 2021 at 2:19 PM Bruce Johnson <
> john...@pharmacy.arizona.edu> wrote:
> > channel default_log {  
> > file "/var/named/log/default" versions 3 size 20m;
> >   print-time  yes;
> >   print-category yes;
> >   print-severity yes;
> >   severity info; 
> > };
> > 
> > in named-chroot do these go to the actual system /var/named/log or
> > does the named-chroot process put them in /var/named/chroot/var
> > directory? 
> > 
> 
> The path should be inside the chroot.
> ___
> 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
-- 
Michael De Roover 

___
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?

[Michael De Roover]

On Thu, 2020-11-05 at 11:27 -0600, Chuck Aurora wrote:
> On 2020-11-05 07:36, Bob Harold wrote:
> > You appear to have confused 'secondary' authoritative servers with
> > a
> > second 'resolver'.
> > Authoritative servers - listed in the NS records - are used by
> > other
> > DNS servers, not by end users, and they will get used equally with
> > the
> > slaves, if your parent zone has the right NS records also.  Those
> > are
> > good to outsource the secondaries.
> 
> It should perhaps be pointed out here that the DNS protocol has no
> means to distinguish among different types of NS host.  (Yes, there
> is
> the SOA MNAME, but that is not used by resolvers.)  One NS is as good
> as any other NS.

These (SOA and behavior for resolvers) probably describe where I got
confused, thanks for the explanations!
-- 
Michael De Roover 

___
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?

[Michael De Roover]

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). 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). 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).
-- 
Michael De Roover 

___
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?

[Michael De Roover]

Interesting article, thanks for sharing this! I'm slightly confused
about some things in it though. Does this mean that any traffic will be
put on the connection tracker and be treated as stateful unless we use
CT --notrack, or can the kernel make a heuristic based on what's in the
iptables rule (i.e. if it only covers a port or a network range, it
must be stateless)?

What constitutes a busy server? For a recursor it'd be easy to achieve
high throughput, but does an authoritative name server for a single
website need it?

On Thu, 2020-10-15 at 20:42 -0500, Chuck Aurora wrote:
> Absolutely right; I wrote this Linux-centric article about it:
> 
> https://kb.isc.org/docs/aa-01183
> 
> It has not been updated to cover nftables.
> 
> Note also that this is a good reason NOT to use the NAT that
> other posters have encouraged.
-- 
Michael De Roover 

___
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: [External] Re: How can I launch a private Internet DNS server?

[Michael De Roover]

Simply stateless. Something along the lines of this (iptables):

# SSH may be internal only or moved to a different port
iptables -A INPUT -m tcp -p tcp --dport 22 -j ACCEPT
# Enable DNS on both TCP and UDP
iptables -A INPUT -m tcp -p tcp --dport 53 -j ACCEPT
iptables -A INPUT
-m udp -p udp --dport 53 -j ACCEPT
# Allow ping
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
# Allow internal network traffic
iptables -A INPUT -s $internal -j
ACCEPT
# Set the general input policy to drop traffic.
iptables -P INPUT DROP

What I'm concerned with security-wise is that if BIND has an RCE
vulnerability, an unprivileged user might be able to "upload a shell"
that gets executed and listens on another port. With all other ports
closed, this can be prevented. It does not prevent against privilege
escalation vulnerabilities though, as root can of course adjust the
firewall at will. But I wouldn't consider security as "being
unhackable", rather making it as hard as possible to get in. A firewall
is a good starting point for that.

On Thu, 2020-10-15 at 21:38 +0200, sth...@nethelp.no wrote:
> > I would run a firewall even for BIND alone on a box in case the box
> > gets compromised through BIND. Allowing remote access and DNS, then
> > dropping everything else as the general firewall policy should be
> > pretty straightforward. But with the IP on this particular BIND box
> > being public, it's really like any other server on the internet.
> Port
> > forwarding or NAT in that case would be unnecessary.
> 
> Do you mean a simple stateless ACL, or a stateful firewall? If you
> really mean a stateful firewall: Think about the effect of DNS
> queries - they are usually UDP based, and every new query is going
> to create state. Read up on state table exhaustion.
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
-- 
Michael De Roover 

___
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: [External] Re: How can I launch a private Internet DNS server?

[Michael De Roover]

I would run a firewall even for BIND alone on a box in case the box
gets compromised through BIND. Allowing remote access and DNS, then
dropping everything else as the general firewall policy should be
pretty straightforward. But with the IP on this particular BIND box
being public, it's really like any other server on the internet. Port
forwarding or NAT in that case would be unnecessary.

On Thu, 2020-10-15 at 21:01 +0200, Stephane Bortzmeyer wrote:
> On Thu, Oct 15, 2020 at 02:03:52PM -0400,
>  Kevin A. McGrail  wrote 
>  a message of 8 lines which said:
> 
> > Firewalls are cheap and the level of effort to run a bastion host
> > are
> > significant.
> 
> Firewalls are useful when you want to protect unamanaged printers and
> Windows boxes (or Web servers with a lot of crappy PHP) but a BIND
> server on a reasonably managed Unix box do not need them.
> 
-- 
Michael De Roover 

___
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?

[Michael De Roover]

Are these static IP's local or public? If local, you can instruct your
router to port forward to these. If these are public, I guess these
machines make a direct connection to the internet with a public IP on
their interface then? In that case you can omit any port forwarding.

The secondary DNS server is for redundancy. You can omit any
instructions regarding it when following the tutorial if you intend to
only make one. The server type would indeed be authoritative - the
other type would be recursive which is generally what ISP's have for
their customers, but I would avoid that because they can be used for
DNS amplification attacks (the authoriative ones can too but it's less
of an issue with those).

On Thu, 2020-10-15 at 16:57 +, Jason Long wrote:
> Yes, I have two static IP addresses. One is for DNS server and one is
> for my website.
> Excuse me, I just have one server for DNS and that tutorial is about
> secondary DNS server too. Can you show me another tutorial with one
> server and same goal?
> The Internet DNS server for my goal is "Authoritative DNS" ? 
-- 
Michael De Roover 

___
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?

[Michael De Roover]

Assuming that this is running off a home network, yes you could
technically do it. Probably the registrar's name servers will be more
reliable however. I'll also assume that your public IP is static.
Otherwise it may only be suitable for the website, with a Dynamic DNS
service that can regularly update the records as your IP changes. This
means that you'll have to use someone else's DNS servers to host your
records.

You can run BIND locally and make it an authoritative name server. Your
router can port forward traffic to port 53/udp to your local IP that
your DNS server is on. 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
.

At the registrar you'll need to select "custom name server" or
something along those lines. Then you have to insert NS records there
that point to the nameserver addresses for your domain(s). Check your
registrar's documentation for instructions on how to add NS records.

On Thu, 2020-10-15 at 16:36 +, Jason Long via bind-users wrote:
> Hello,
> I have a question about launching a DNS server with CentOS for
> hosting a web server. Excuse me, if my question is so basic and
> funny. I need expert advice about it.
> I registered a domain name for my web site and in the panel of it, I
> can enter my DNS server IP addresses. I want to launch a CentOS DNS
> server that my Web site using it and users can visit my website from
> the Internet. These two servers (DNS and Web server) are in a local
> network and connected to the Internet with a Gateway. Each server has
> an internal and a public IP address.
> I want to enter my DNS server IP address in my website panel and
> after it, users can visit my website from the Internet. I'm thankful
> if anyone show me a tutorial to launch my DNS server for this goal.
> All tutorials that I found on the internet are about internal DNS
> servers, but I want to launch a DNS server for hosting my website.
> Is Internet DNS server just possible for providers?
> 
> Thank you.
> 
> 
> ___
> 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
-- 
Michael De Roover 

___
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: It is too hard for me to read from this mailing list

[Michael De Roover]

On Mon, 2020-09-21 at 16:15 -0400, Allen Chen wrote:
> I am using Thunderbird to read the emails. Should I use something
> else 
> to read it? Any suggestions are welcome.

Here I use Evolution these days, since it does a lot of "stuff" that
Thunderbird can't or needs add-ons to do. Especially mailing lists
ended up being so underwhelming in Thunderbird, while in Evolution I
find them pretty straightforward to browse. Also GPG integration in
Evolution (actually integrates with the system keyring without needing
add-ons etc) and how it shows you which parts of an email are signed by
putting a green square around it (useful for signed emails from e.g.
security mailing lists), and so on. Definitely recommended!
-- 
Michael De Roover 

___
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: distribution of Bind software through our website

[Michael De Roover]

The BIND software is released under the Mozilla Public License 2.0. You
can refer to the LICENSE file to learn about your rights in BIND or
most other open source projects. The only exception to my knowledge
would be projects with no license - those are all rights reserved by
default to protect authors who do not wish to grant additional rights
for their software.

I'm also hosting a mirror of BIND at git.ghnou.su/mir/bind without
issues.

On Mon, 2020-08-24 at 10:28 +0530, ShubhamGoyal wrote:
>  
>  
>   
>Dear All ,
>   
>  
>   
>We host a public DNS Recursive Resolver and also cater training on
> hosting the same using Bind.
>   
>  
>   
>Kindly let us know if we can host and distribute a version of bind
> software in our own website in order to facilitate our training
> process.
>   
>  
>   
> 
>   
>  
>   
> 
>   
>  
>   
>Best Regards,
>
> Shubham Goyal
>
> Cyber Security Group
>
> Centre for Development of Advanced Computing
>
> Bangalore
>   
> 
>  
> 
> 
> 
> 
> 
> 
> ---
> -
> 
> [ C-DAC is on Social-Media too. Kindly follow us at:
> 
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
> 
> 
> 
> This e-mail is for the sole use of the intended recipient(s) and may
> 
> contain confidential and privileged information. If you are not the
> 
> intended recipient, please contact the sender by reply e-mail and
> destroy
> 
> all copies and the original message. Any unauthorized review, use,
> 
> disclosure, dissemination, forwarding, printing or copying of this
> email
> 
> is strictly prohibited and appropriate legal action will be taken.
> 
> ---
> -
> 
> ___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 listbind-us...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: BIND, nsupdate and acme.sh DNS authentication

[Michael De Roover]

On 7/23/20 9:13 PM, Brett Delmage wrote:

To get this topic back on topic for this list:

When you are creating Let's Encrypt wildcard certificates you must use 
a DNS authenticiation protocol with letsencrypt. I am using the 
acme.sh client which was recommended for wildcard certificates. 
https://github.com/acmesh-official/acme.sh


If you are running your own nameserver you also need to enable dynamic 
updates so that the acme.sh client can create TXT records during 
certificate acqusition and renewal.


However I have found that getting zone dynamic updates 
(authentication, specifically) working with nsupdate (which acme.sh 
uses) and BIND have been a PITA. I haven't been overly impressed with 
the debug capabilities to help get nsupdate working properly.


Interesting, I wasn't aware of this. Looking at Manjaro's site again, I 
found that their main website indeed uses a wildcard certificate while 
the forum (which was affected by the certificate renewal issues if 
memory serves me right) uses its own dedicated cert. Granted these 
renewal issues were already a few years ago so perhaps they changed some 
things here and there by now.


I had heard of Let's Encrypt's wildcard certs but never looked further 
into it. Would certainly be useful though, as subdomains are an easy way 
to separate services. Unfortunately bacme (which I currently use) 
doesn't seem to support the DNS-based ACME challenges. I've cloned the 
acme.sh repository and will look further into it.


--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Michael De Roover]

The idea is pretty interesting, seems like they provide a repository 
with packages compiled with their own compiler that changes various 
memory-related elements. It is true that memory is usually the culprit 
behind security flaws.


According to their page at 
https://polyverse.com/products/polymorphing-linux-security/ :


"Polymorphing takes source code and runs it through a polymorphic 
compiler, changing register usage, function locations, import tables and 
other targets. This produces individually unique binaries that are 
semantically equivalent to the source. Polymorphing applies the compiler 
to the totality of the Linux stack."


For this to work at all though, they'd have to provide all packages 
simply as source code (why not use the distribution's own source 
repositories?) and compile it on the target. But even then I think it's 
more of a security by obscurity thing. Sure it makes it more difficult 
to exploit a memory flaw by means of automated exploits and other such 
scripts. But nothing stops you from taking the unmodified source code, 
the binary and a disassembler to find out how exactly the resulting 
binary has been changed / polymorphed. I'm not very familiar with 
reverse engineering and disassemblers but I don't think there's much 
more to it than that, at least to thwart this defense. All of it is 
possible if an attacker can read, retrieve and execute a binary on the 
affected server. The flaws are still there, only their memory locations 
have changed. It would probably defend against script kiddies, but I 
doubt it would keep out a determined attacker.


Personally I prefer Google's approach to this for Chromium. They 
documented it at 
https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md 
. Implementing programs in memory safe languages where possible is 
something I believe to be a more solid long-term solution. Additionally 
Google's Project Zero team is behind a lot of the security research and 
disclosures. They audit the actual code instead, which I believe to be 
far more suitable.


While the idea is valid to some extent (and could be worth it in highly 
confidential environments), I wouldn't consider it worth compiling 
everything from source for, with a nonstandard compiler no less. If 
servers would just be updated more often and (security) bug fixes 
actually make their way through to the distribution releases reliably, 
we'd already go a long way I think. Of course there are also 
configuration mistakes that could compromise a network component. From 
what I've seen so far, this seems to be more often the case with those 
leaked databases and whatnot.


On 7/23/20 2:39 PM, Fred Morris wrote:
Perhaps slightly OT, but here's a company which has a whole business 
model based on one nonobvious (?) reason to compile from source: 
https://polyverse.com/


--

Fred Morris

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Michael De Roover]

I do have that option. It's just not as convenient and I certainly 
wouldn't want every distro to turn into a Gentoo for increased merit or 
reasons like that. If the distro makes compiling from source (be it 
upstream or their downstream version) easy, either to compare or to 
actually put it to use, all the better.


(My preferred term for for crashing and burning servers would probably 
not be suitable for this list)


--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Michael De Roover]

On 7/23/20 6:28 AM, Ted Mittelstaedt wrote:
Linux is 10 times worse because they aren't even including the c 
compiler or development tools

anymore.
Every distribution I've laid my hands on so far has GCC packages and 
most development packages affixed with either -dev or -devel (most of 
the time).

But many "systemadmins" out there think they are Unix admins
yet are afraid to compile programs.  They will go to the FreeBSD port or
the Linux precompiled apt-get stuff.  The reason is more and more
non-technical people are getting their hands on this stuff.


I don't disagree with this but I also think there's more to it than 
that. For me personally I avoid compiling from source when I can get 
away with it - not because I can't run make - but simply because binary 
packages are convenient. Having a package manager take care of updates 
in the whole system is convenient. Having distribution maintainers that 
say "okay we are going to go stable, bleeding edge or whatever with the 
whole project" is useful when they can spend the time looking at the 
upstream projects, and choose the most fitting software versions and 
such to suit that goal. And when there's billions of machines running 
very similar architectures, there is an argument to be made that making 
every single one of them compile everything from source is rather 
pointless. Why should every machine in existence be tasked with 
CPU-intensive compilation workloads when a handful of dedicated 
compilation servers can do exactly that, and a million times better?


--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Michael De Roover]

Sorry about that, the email might've been a bit too emotionally loaded. 
The issues pile up.. and that's eventually the result.


I'm not using FreeBSD anywhere anymore but found some resources online 
suggesting that the package name is bind916. The closest I could find to 
unwinded is Unbound which apparently is what replaced BIND in FreeBSD 
and OpenBSD. Is this the case?


Generally speaking all I'd ask for is consistency. Currently that does 
not appear to be present anywhere. Everyone gives things their own (new) 
names even if they're supposed to describe the same thing. It's 
extremely confusing.


On 7/20/20 9:05 PM, Ted Mittelstaedt wrote:



On 7/20/2020 11:23 AM, Michael De Roover wrote:

If that is true, I hereby lost all faith in humanity.. well whatever
faith I had left. This has been going on for like half a decade now.



Nobody ever went broke catering to the human desire for ease
___


--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Michael De Roover]

If that is true, I hereby lost all faith in humanity.. well whatever 
faith I had left. This has been going on for like half a decade now.


A few weeks ago I saw here on the list someone suggesting that BIND is a 
reference to bondage in BDSM, so perhaps it has to do with that... Lest 
we forget that BIND is an abbreviation for Berkeley Internet Name 
Domain. Software made at Berkeley, to serve domain names on the 
internet. The name is pretty descriptive about its intended purpose I 
would say. Perfectly fine! Just because an abbreviation coincidentally 
becomes the same as a word in another context doesn't mean that it 
suddenly /became/ that word. Western languages simply don't have enough 
characters and words to make everything unique and special. And the best 
part is.. banning certain words from general usage (for rather odd 
reasons) only exacerbates that problem.


But with that said, if BSD thinks that BIND stands for bondage, I 
suggest that BSD drops the D because it's clearly a reference to 
criminally masculine dicks. Everything else is bullshit.


(My apologies if bad words are disallowed here, but I had to get this 
off my chest)


Back to the thread's original topic, I happened to be configuring BIND 
on Alpine yesterday. I was pleased to see that the package in Alpine is 
simply called "bind". The service file in /etc/init.d is called "named". 
While those decisions are entirely up to the distribution vendors, I 
also think that version numbers don't really belong in the name of a 
piece of software. However even upstream the repository is called 
"bind9"... The branch name has already changed, so perhaps the same 
could be done for the repository name?


On 7/17/20 8:35 PM, John W. Blue wrote:

Speaking about things to be annoyed over ..

I am still ticked that FreeBSD dropped BIND from the distribution for something 
called unwinding or whatever it is.

John

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: issue of Amplification attack

[Michael De Roover]

There was a very interesting conversation about this last week. See 
https://www.mail-archive.com/bind-users@lists.isc.org/msg29187.html.


On 7/12/20 6:23 AM, ShubhamGoyal wrote:

Dear sir,
 Thank you  for give me answer for my previous 
question,  Sir now we are suffer from amplification attack so is there 
any method in bind to stop DNS Amplification attack.
I am thinking to stop or drop ANY type queries from our DNS Recursive 
resolver , so please tell me how can we drop or stop ANY type queries 
from bind.

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: [DoD Source -- ssshhhh Top Secret] Re: Dumb Question is an A or AAAA record required?

[Michael De Roover]

On 7/9/20 5:03 PM, Reindl Harald wrote:

but it still has nothing to do with your domain by definition, the PTR
could be anything
Of course it can be, they're completely separate name spaces. However 
would it make any sense in practice to point it somewhere else entirely? 
You'd probably be better off not setting it at all then. I'd argue that 
they're meant to match each other.

but how does that change anything in the simple fact that "Would the
lack of A records affect pointer records? Seems like it would" given
that the PTR zone is a dns zone like anything else
while it's smart (at least when you want to send mails) that your IP has
a sane PTR and that the name maps back to the IP the dns system couldn't
care less
My thoughts exactly. They can technically be different and the DNS 
itself indeed couldn't care less (but applications checking for that 
might).. but would it make sense to? I mean yeah I suppose that they can 
exist without the other. Not uncommon for A records to be without PTR 
records, and I guess that a PTR record without an A record could work 
too..? But again, aside from the theoretical possibility, why would you 
want to set your PTR records to not match at least one of your A records?

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: [DoD Source -- ssshhhh Top Secret] Re: Dumb Question is an A or AAAA record required?

[Michael De Roover]

You do have control over that.. kind of. As far as I'm aware hosting 
providers generally offer control over PTR records in their admin 
panels. However delegation of them to your own authoritative name 
servers is.. complicated. A lot more so than delegation of forward 
lookups would be anyway (A, , MX, yada yada). Apparently the hosting 
provider would have to delegate (as far as I understand it's like 
sharing?) control over just that/those IP(s), and remember to revoke it 
after you leave their hosting services too. See 
https://www.arin.net/resources/manage/reverse or 
https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns 
for more information... But I don't understand this part very well myself.


On my own hosting provider it appears that I can adjust the PTR records 
on their admin interface, however I can't delegate it to my own name 
servers.. since it's apparently a rather manual process. And I'm 
probably not paying my hosting provider enough for that.


Whichever methods are available, for email in particular it's advisable 
to publish a PTR record of some kind. IRC networks may also ask to do 
this before they apply your domain as your vhost (and A and PTR have to 
match). On Freenode at least they do.


On 7/9/20 3:36 PM, Reindl Harald wrote:

and typically you have no control over PTR records at all given that
they have nothing to do with your domain

while it's smart (at least when you want to send mails) that your IP has
a sane PTR and that the name maps back to the IP the dns system couldn't
care less

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: DNS security, amplification attacks and recursion

[Michael De Roover]

On 7/7/20 4:06 PM, Tony Finch wrote:


An auth-only server can also be used for amplification attacks that use
its authoritative zones - these attacks don't have to use recursion.
There are a few ways to mitigate auth-only amplification attacks.

Response rate limiting is very effective. Start off by putting the
following in your options{} section, and look in the BIND ARM for other
directives you can put in the rate-limit{} section.

rate-limit {
responses-per-second 10;
};
That's a really useful option to have, I didn't know about this yet. It 
seems like that could take care of the brunt of amplification attacks 
already. Definitely going to add this in, thanks!

Set a maximum UDP packet size, to suppress fragmented packets. The DNS
flag day 2020 campaign will make this a standard setting. For a long time
I have used:

max-udp-size 1420;

https://dnsflagday.net/2020/

A downside of small UDP responses is more truncated packets and more
queries over TCP, but there are still more ways to reduce response size
which also reduce truncation.
Interesting, I wasn't aware of this campaign. I don't know if I'm 
knowledgeable enough on UDP to be able to make educated decisions on 
this myself but I look forward to its eventual release.

Reduce the size of responses to ANY queries, which are a favourite tool of
amplification attacks. There's basically no downside to this one, in my
opinion, but I'm biased because I implemented it.

minimal-any yes;


I've heard of these ANY queries being preferred for amplification 
attacks as well, since the responses are often so large... I don't think 
that there would be any downsides to this either, in fact I've never 
actually seen a legitimate application use it... Probably best to lock 
down indeed.



You can also reduce the size of other answers. In theory this option might
force resolvers to make more queries to get records that by default would
appear in the additional section, but I think in practice resolvers make
these queries anyway because of RFC 2181 trustworthiness logic, and
because applications (such as SMTP servers) find it easier to query
directly than use additional records. So on my auth servers I set:

minimal-responses yes;


Hmm, for the authoritative name servers this might be a good idea yeah.. 
Those are authoritative only (i.e. `recursion no`). So for clients 
querying those, the NS records served in the additional section at least 
should already be known to the client anyway... I mean that's why 
they're there to begin with, so they must already know that information 
from the DNS servers higher up the chain. And another query if needed, 
saves traffic either way I suppose.


Thanks a lot for the detailed reply, I really appreciate it :)

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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

DNS security, amplification attacks and recursion

[Michael De Roover]

Hello,

Recently I discussed with a friend of mine the idea of NTP and DNS in 
the context of denial of service attacks. In NTP this amplification 
attack is done with the monlist command (that should honestly never have 
been publicly available due to its purpose being pretty much entirely 
debugging-related). The DNS version was rather unclear to me however.


Said friend said to me that he tested my authoritative name servers and 
found them to be not vulnerable. I don't run the latest and greatest of 
BIND at all, I mean it's Debian distribution packages we're talking 
about there... But they were set up to be exclusively authoritative. 
They do not respond to recursive queries. It appears that the test of 
whether a server is "vulnerable" or not has to do with this. The command 
used to test this was apparently "dig +short test.openresolver.com TXT 
@your.name.server". That's simply a recursive query of what appears to 
be an arbitrary record to me.


This also meant that supposedly the recursive DNS servers from Google, 
Cloudflare and Quad9 were all considered vulnerable. I find this very 
hard to believe. Authoritative name servers may not need a huge DNS 
infrastructure for a small-ish zone (say under 1k records), but 
recursors on the scale of Google and Cloudflare in particular (not sure 
how popular Quad9 is so far).. those use massive infrastructure 
including anycast and everything! I'd consider it safe to assume that 
their servers are at least on the order of 100Gbps cumulatively, if not 
more. If these would be vulnerable to amplification attacks just because 
they allow recursion, wouldn't skids be jumping on this like there's no 
tomorrow? It doesn't make any sense to me.


This seems to be not very well documented online (or more likely my 
search terms aren't right), so yeah... I wonder why the idea of 
recursion became associated with a vulnerable server in the first place.


--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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:

[Michael De Roover]

I just tried to make an exception like this in 
/etc/bind/named.conf.local for .oss (at least its lack of ICANN 
accreditation is useful for something now) and it did indeed use the 
other name server (theirs rather than my usual Cloudflare).


On 6/28/20 6:43 AM, baalchina wrote:

Hi all,

I had a bind 9.16.4 as recursive name server. I want to forward all 
queries to a specific dns server out of my net such as 8.8.8.8. While 
I have a new domain( such as abc.com <http://abc.com>) I want to 
forward to a new dns server such as 9.9.9.9.


Here is my named.conf:


options {
        listen-on port 53 {192.168.1.1;};
        recursion yes;
        allow-recursion {any;};
        forwarders {
                8.8.8.8;
        };
};

zone "abc.com <http://abc.com>" {
        type forward;
        forwarders {1.1.1.1;};

};

So, in this configuration, the abc.com <http://abc.com> will be 
forward to 8.8.8.8 or 1.1.1.1?


Thanks.




--
from:baalchina

___
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

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: BIND Masters and slaves

[Michael De Roover]

:
>> After I feel I have mastered DNS and BIND after slaving over the docs
>> and code for years (I'm not there yet, and I have not) how am I going
>> to communicate this to people?

>> How will I be able to master anything technical anymore? Should I just
>> stop trying?


>> Thesaurus.com suggests that one could call one type of DNS server the
>> "crackerjack" server instead. I guess that's an improvement over
>> "cracked". "Ace" server is a suggested alternative too, and it's
>> nicely terse.

*>> https://www.thesaurus.com/browse/master?s=t 
<https://www.thesaurus.com/browse/master?s=t>


___
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

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: BIND Masters and slaves

[Michael De Roover]

Completely aside from the topic at hand, I often like to think that 
after a few years I mastered something. System administration, 
electronics, programming, whatever has piqued my interest for several 
years already and got me to invest in it. It is never true. The first 
profession I pursued was system administration and Linux in general. 
Even today I still learn so much on the daily. Mastery? I may be 
experienced with Linux but mastery is still far ahead... It's quite 
interesting how deep the rabbit hole can go. What matters is how deep we 
want it to go I guess.


Crackerjack is an interesting name, if anything I'd just want it for 
shits and giggles :D


On 6/15/20 9:07 PM, Brett Delmage wrote:
After I feel I have mastered DNS and BIND after slaving over the docs 
and code for years (I'm not there yet, and I have not) how am I going 
to communicate this to people?


How will I be able to master anything technical anymore? Should I just 
stop trying?



Thesaurus.com suggests that one could call one type of DNS server the 
"crackerjack" server instead. I guess that's an improvement over 
"cracked". "Ace" server is a suggested alternative too, and it's 
nicely terse.


https://www.thesaurus.com/browse/master?s=t


--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: [Non-DoD Source] Re: BIND Masters and slaves

[Michael De Roover]

Of course I could, but I do not feel like the effort to change 
nomenclature is either beneficial or worth taking for granted the 
requests of some people on Twitter - as the slave to peer authority I am 
- given how much it affects documentation, code, comments, general 
environment of the projects themselves. I enjoy being surrounded by 
people much smarter than I am when it comes to the mailing list here. 
Let's keep it that way and not derange ourselves into meaningless 
blabber from social media.


What I did notice over time however that most of the projects affected 
are also those who do have to maintain a good public image, usually 
corporations. Meanwhile projects such as Opal 
<https://github.com/opal/opal/issues/941> and recently Rubocop 
<https://github.com/rubocop-hq/rubocop/issues/8091> as well were not. 
The latter one I'd like to draw attention to. The maintainer clearly 
didn't ask for this and asked everyone who shamed him, why are you doing 
this? None of the complainers were affiliated to the project at all. 
Chances are that they weren't even using it and just searched for 
projects with the name "cop" in it instead. These are not the people I 
want to support in my effort to end racism, which I /do/ support, and 
quite heavily so.


On 6/15/20 8:00 PM, DeCaro, James John (Jim) CIV DISA FE (USA) wrote:

Or you can call the slave servers 'secondary' servers.

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: BIND Masters and slaves

[Michael De Roover]

I concur with this. I'm still fairly new to BIND and DNS myself. I 
maintain 7 name servers (3 internal, 4 external) and master does signify 
to me that this is the server in control of the zone files for the other 
ones in that pool. The slaves are pretty much that to me, they take the 
zone files and apply them while not having any further control over the 
zone files themselves. In my external name servers it also goes paired 
with authority - slave authorities that are authoritative to the 
internet but slaves in that they replicate from an internal master. This 
is not something you'd see in real slavery, signifying that this is mere 
technical jargon. Is it a heavy term? Yes. Should we support "black 
lives matter" and condemn the completely egregious actions committed by 
the police officers towards George Floyd? Absolutely, and I hope that 
the former officers get convicted for not just manslaughter but murder, 
and that more protests will emerge (minus the plundering which was the 
case here in Brussels).


However, changing a name and going for censorship of technical jargon 
which will only confuse newcomers who will now face duplicate 
nomenclature changes NOTHING. George Floyd wouldn't have been able to 
survive just because we give things a different name. Instead we'd 
border closer to censorship which we had during the wars, and still do 
in heavily oppressed countries like North Korea, China etc. It's ironic 
that what these people are pushing for in practice is exactly the thing 
they seemingly seek to eradicate.


There is another relevant case where GitHub will apparently replace 
master branches in all their repositories. I'm really glad to be 
unaffected with my Gitea server. I may have to adjust my repository 
mirrors from GitHub however. For GitHub users, that change will likely 
break every one of their repositories that defaults to master and 
require adjustments from GitHub users of which many might not even know 
what branches are. That's the real impact of that and I find it deeply 
worrying.


I do not want such a thing to happen to BIND just to please some people 
with large followings on Twitter who other than that, often have no 
affiliation with the project whatsoever.


On 6/15/20 12:53 AM, Vinícius Ferrão via bind-users wrote:
ISC had a statement about it a time ago: 
https://twitter.com/ISCdotORG/status/942815837299253248


You can now call primary and secondary zones. But the prevalence of 
terms are still master and slave. And I really hope this thing of 
changing nomenclatures doesn’t go any further due to political 
correctness.


For the newcomers it’s not OK to break years of terms, software and 
documentation just because some people can’t handle terms like master 
and slave. Slavery still exists today and making the word disappear 
will not solve the issue.


And you’re correct about the BDSM thing. It’s a waste of time, efforts 
and lines of code.



--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: DNS Misconfiguration on- http://cyberia.net.sa/

[Michael De Roover]

Wholeheartedly agreed. Not to mention that it's extremely rude to demand 
fame/money like that. These are not security researchers, they're skids.


(Please disregard the previous email, pressed the wrong reply button and 
realized it too late..)


On 6/5/20 11:53 AM, Ondřej Surý wrote:

The localhost. is not scam, but the

„I found this on HackerOne and I now want money“ is scam.

Remove the localhost entry from the zone, but you should not pay money
for issues that can be produced by automated scanners.

HackerOne is doing everyone disfavor by paying nonsensical amounts of
money[*] for small issues like this. They (and other wealthy companies)
should be paying money only for original security research and not this
nonsense.

* $100 is a helluva money in some economies...

Ondrej
--
Ondřej Surý
ond...@isc.org

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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

Experimenting with a new practice for pre-announcing vulnerability disclosures

[Michael McNally]

Hey BIND-users,

I hope that most of you are already subscribed to the bind-announce list.
But for those who are not, bind-announce is another public list operated
by Internet Systems Consortium.  It is a low-traffic list which ISC staff
use to make announcements concerning the BIND project -- most frequently
about the release of new versions of BIND or occasionally when we disclose a
serious security vulnerability.  You can subscribe by going to: 
https://lists.isc.org

The reason I bring it up is that ISC is experimenting with a new practice
to extend our Security Vulnerability Disclosure Process.  After observing
this practice being used successfully by other open-source projects, we
have modified our disclosure policy to allow us to (optionally) make a
limited pre-announcement giving a "heads up" a few days before a public
disclosure occurs.

Such pre-announcements, should they occur, will be posted to the bind-announce
list and you can see the first example of one in the list archives even if
you are not a subscriber:

  https://lists.isc.org/pipermail/bind-announce/2020-May/001153.html

Michael McNally
ISC Support
___
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: DoH plugin for BIND

[Michael De Roover]

Interesting, I wasn't aware of that. Until now I subscribed to the whole 
business-only IP idea the whole time. I never thought that ISP's or 
other mail servers would allow this (though granted, mine doesn't 
discriminate either). Meanwhile Microsoft still blocks one of my sender 
IP's (e3.nixmagic.com which was the last one to enter the set of edge 
servers). Maybe phasing out my edge servers wouldn't be a bad idea then, 
at least in the long run. My ISP doesn't change the IP address for my 
residential connection as long as I don't reboot my router anyway. 
Assuming that I check whether my ISP allows 25 in- and outbound first, 
that could work.


On 5/2/20 6:25 PM, Brett Delmage wrote:

On Sat, 2 May 2020, Michael De Roover wrote:

Even if your ISP allows it, chances are that other mail servers will 
reject it


Nope, not always.

My residential-class static IP mail server has never had problems 
delivering mail. I've checked it many times over the years on many 
blacklist checkers and never had anything but green lights.


Of course I have met all the email best practices for years: SPF, 
DKIM, reverse pointer, etc.


Even though email is not secure, I still feel better knowing that 
emails end up in MY server via opportunistic TLS transport. and not in 
some Yahoo's or surveillance capitalist's data store.


Underlying all this are my own DNSSEC-enabled BIND servers, of course.

___
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

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: DoH plugin for BIND

[Michael De Roover]

I'm sure that most of the list members here are aware of how net 
neutrality and the internet in general works - we're internet operators 
after all. What we're here for is ports and protocols, not policy or 
internet culture. On that subject, we are not policy makers. Let's leave 
that to politicians who studied for it. Vote some technical people in 
government while we're at it, but I digress.


The DoT/DoH argument or what a mail server could be operated from is not 
one of policy.. well maybe mail servers are, to some extent. Perhaps 
there's some ISP employees here too. Those are in power to allow or 
disallow things on their network. But DoT/DoH certainly isn't. What are 
we supposed to worry about? How do we implement this new encrypted DNS. 
Do we piggyback off an existing port and rely on its ubiquitous 
allowance on the internet or do we create a new port for it, where we 
can make a dedicated new protocol suite?


On 5/2/20 5:03 PM, Reindl Harald wrote:


Am 02.05.20 um 16:39 schrieb Paul Kosinski via bind-users:

I wasn't complaining about port 25, I was just citing it as a
counterexample to the claim that ISPs "must" pass all traffic.

https://en.wikipedia.org/wiki/Net_neutrality


I think that most ISPs tell customers how to set up their email clients
(NUAs) including what port to use. Of course it seems that now most
people use Web based email like Gmail, Yahoo (and even Comcast/Xfinity)
so they never see port numbers.


On Sat, 2 May 2020 15:51:58 +0200
Reindl Harald  wrote:


Am 02.05.20 um 15:41 schrieb Michael De Roover:

In my experience and from what I've heard, very few.

if that would be true how comes that most mail clients still default to
25 for submission and years after closing port 25 on our mailserver i
still struggle with customers smartphones still not using 587?

in fact 10 years ago some ISP's *tried* to kill outbound port 25 because
there is no point in using it from a homemachine and at that time we
struggeled also to explain our customers that 25 is plain wrong

finally they gave up because the damage of open port 25 is killed with
dnsbl but the customer support went crazy with "why can't i send email
with my internet connection"


Even if your ISP allows it, chances are that other mail servers will reject it

that's a completl different story


On 5/2/20 3:30 PM, Paul Kosinski via bind-users wrote:

How many ISPs allow traffic on port 25? My impression is that even many
(non-enterprise) business customers can't use port 25

___
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

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: DoH plugin for BIND

[Michael De Roover]

To put it very simply, I consider myself very lucky that I have control 
over every mail client that interfaces with my mail server. Most of them 
are well-behaved and use 587 for submission. My mail server has also 
disabled it on port 25 to reduce spam. Port 587 on my mail server is 
also only visible within my VPN's to allow submission only within. That 
is an edge case and a privilege since all the mail clients are local. If 
your mail clients go outside your network or VPN's, that's when you'll 
need to either expose 587 to the internet or allow it on 25, with all 
those related issues.


Submission on port 25 is something I disabled on my mail server since it 
reduces the amount of spamhausen that try to submit email to my mail 
server, assuming that it's an open relay. It's purely traffic- and 
load-related. The reason why residential ISP's disallow it - to my 
knowledge which is admittedly limited - is because few postmasters 
consider the limitations that are applied to residential connections in 
general endurable. That includes dynamic IP's, down-/upload ratio, 
blocked ports, lack of SLA, and many other things.


As far as the "completl different story" goes, it's part of a whole. 
Good luck getting deliverability to other mail servers from a 
residential range even if the ISP itself allows it. Mail servers are an 
inherently reputation-driven thing. Reputation of your sender IP 
addresses to be precise. Is it good? No, email sucks. If you can get 
away with not running a mail server, don't run one. They suck so much. 
But if you do, a home IP is not where you'll want to start regardless. 
Get a VPS if anything.


On 5/2/20 3:51 PM, Reindl Harald wrote:


Am 02.05.20 um 15:41 schrieb Michael De Roover:

In my experience and from what I've heard, very few.

if that would be true how comes that most mail clients still default to
25 for submission and years after closing port 25 on our mailserver i
still struggle with customers smartphones still not using 587?

in fact 10 years ago some ISP's *tried* to kill outbound port 25 because
there is no point in using it from a homemachine and at that time we
struggeled also to explain our customers that 25 is plain wrong

finally they gave up because the damage of open port 25 is killed with
dnsbl but the customer support went crazy with "why can't i send email
with my internet connection"


Even if your ISP allows it, chances are that other mail servers will reject it

that's a completl different story


On 5/2/20 3:30 PM, Paul Kosinski via bind-users wrote:

How many ISPs allow traffic on port 25? My impression is that even many
(non-enterprise) business customers can't use port 25

___
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

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: DoH plugin for BIND

[Michael De Roover]

In my experience and from what I've heard, very few. Even if your ISP 
allows it, chances are that other mail servers will reject it, since 
residential areas aren't really suited for and aren't generally used for 
long-term mail servers. I would recommend against running your mail 
server (directly) on your home connection. Here I rent 3 VPS's as pretty 
much edge servers and connect my mail, web, Gitea and other servers from 
there (possibly my DoT service as well since almost everything is 
already reverse proxied with nginx from there). VPN connections are made 
from all of those local servers to there but it's far from ideal (70 
servers x 3 VPN connections each and you've got 210 total.. and that's 
where I more or less screwed up). Nowadays I'd rather consider either 
making my VPS's connect to my home, or make a single server be the 
gateway at home that makes VPN connections to those VPS's instead. 
Probably the latter since home connections have dynamic IP's too.. that 
complicates things a bit.


On 5/2/20 3:30 PM, Paul Kosinski via bind-users wrote:

How many ISPs allow traffic on port 25? My impression is that even many
(non-enterprise) business customers can't use port 25.

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: DoH plugin for BIND

[Michael De Roover]

I don't live in the US myself, but from what I've heard it's actually 
among the least censored countries out there at the DNS level. Again, I 
don't consider it right to block content, at least if said content 
doesn't break local laws. If anything I'd like to actually retain my 
ability to bypass DNS blocks by simply changing my DNS server to a more 
favorable one. With DoH that would likely become much harder. Not to 
mention that HTTPS isn't the holy grail for bypassing that either. The 
Facebooks and Googles out there use HSTS to mitigate TLS stripping but 
that requires a list to be hardcoded in every web browser that supports 
it. It doesn't scale up at all. At that point we might as well go back 
to hosts files.


On 5/2/20 9:28 AM, Reindl Harald wrote:

Am 02.05.20 um 09:00 schrieb Michael De Roover:

That's actually my biggest concern with DoH, ISP blocking. It doesn't
seem as obvious as it is with DoT, but deep packet inspection (DPI) is
already a thing. Don't expect an ISP that wants to block DoT to not
(want to) block DoH either. The crux of the problem at that point is not
the technology, it is the ISP's incentives. If the ISP wants to block
DoT for whatever reason, personally I'd consider it.. not exactly fine
but at least their right to do so. That's their decision to make.

seriously?

that seems to be some US attitude, no wonder what happens there with
user attitudes like "but at least their right to do so"

the ISP by definition has exactly one right: get money for his service
which is described as "route and transfer every package, don't look at
it, don't mangle it, you have no business about the content of my traffic"
___
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

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: DoH plugin for BIND

[Michael De Roover]

That's actually my biggest concern with DoH, ISP blocking. It doesn't 
seem as obvious as it is with DoT, but deep packet inspection (DPI) is 
already a thing. Don't expect an ISP that wants to block DoT to not 
(want to) block DoH either. The crux of the problem at that point is not 
the technology, it is the ISP's incentives. If the ISP wants to block 
DoT for whatever reason, personally I'd consider it.. not exactly fine 
but at least their right to do so. That's their decision to make. The 
problem is that if they want to block DoH too, they'd more or less have 
to break HTTPS altogether. And at that point, I'd expect them already 
more than willing to do so.


As far as content blocking goes, currently DNS is used for that too. In 
my country that is mainly Torrent sites, which are illegal. In 
workplaces it'd be for websites employees aren't allowed to visit at 
work. Most users use their ISP's / workplace's DNS servers and thus a 
simple DNS block ended up being fine. If that wasn't the case, more 
invasive methods would've been necessary. DNS blocking is easy to bypass 
but not many people do it. Personally I'd much rather keep technology 
away from policy. Encrypting DNS is important and both methods are fine 
for their own reasons, but policy is something that ISP's and workplaces 
will enforce regardless. Making this harder with technology could very 
well have adverse effects in the long run.


On 5/1/20 11:51 PM, @lbutlr wrote:

On 29 Apr 2020, at 14:19, Tony Finch  wrote:

DoT is easier since you only need a raw TLS reverse proxy, and there are
lots of those, for example, nginx:

DOH is better because it cannot be blocked without blocking all https traffic.

(FSVO of better, of course. I am sure there is a vi/emacs space/tab trek/wars 
religious canonical war here, but being able to guarantee access to secure DNS 
is definitely better for users).

All that its need to subvert DoT is to block port 853.

If DoT takes off, I expect all US ISPs to block port 853 universally. There’s 
nothing they can do about DoH.

Not that it is all sunshine and rainbows in DoH-land, of course. Use of cookies 
is “discouraged” but not prevented, most obviously.





--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: DoH plugin for BIND

[Michael De Roover]

Thanks a lot for the detailed reply. That should be pretty 
straightforward to set up then, as I'm already using nginx for some 
other things and Debian appears to be using BIND 9.11.5 now. Until BIND 
gets native DoT/DoH support I'll probably run it behind nginx as well then.


On 4/29/20 10:19 PM, Tony Finch wrote:

Michael De Roover  wrote:


On that subject, how about DoT?

DoT is easier since you only need a raw TLS reverse proxy, and there are
lots of those, for example, nginx:

http://dotat.at/cgi/git/doh101.git/blob/HEAD:/roles/doh101/files/nginx.conf#l48

Note that if you enable DoT on port 853 on your normal DNS resolvers then
Android devices will use it automatically. (I get a lot more DoT traffic
than DoH traffic!) So it's worth tuning timeouts to control the number of
concurrent TLS and TCP sessions on your server. Android's DoT client is
very well-behaved so the server-side configuration knobs work nicely. Use
BIND 9.11 or newer so you can support concurrent queries on one
connection. As well as the nginx timeouts you can see at the link above,
my named.conf has:

tcp-clients 1234;
tcp-idle-timeout 50; # 5 seconds
tcp-initial-timeout 25; # 2.5s minimum permitted
tcp-keepalive-timeout 50; # 5 seconds
tcp-advertised-timeout 50; # 5 seconds

The timeouts are short because they don't need to allow for much slowness
on our metropolitan-area fibre network. 5 seconds is based on my rough
eyeball assessment of when typical DoT connections are unlikely to be
re-used. The number of TCP clients is a guess.

Tony.

--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: DoH plugin for BIND

[Michael De Roover]

On that subject, how about DoT? I have mixed feelings about using 443 as 
a kitchen sink port but encrypting DNS seems like a good idea.


On 4/29/20 9:40 AM, Evan Hunt wrote:

Does BIND have a DoH plugin official?
Or is there any guide to customize that one?

Not yet, but we plan to have a DoH implementation in named by the end of
this year.

In the meantime, there are DoH proxies that can run BIND as the back-end.


--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: BIND-9.16.1 memory leak?

[Michael Sinatra]

On 2020-04-17 06:45, sth...@nethelp.no wrote:
> We have what appears to be a significant memory leak in BIND-9.16.1.
> 
> Environment:
>  FreeBSD 12.1-STABLE.
>  BIND-9.16.1 installed from packages.
>  Also uses libuv-1.35.0 installed from packages.
>  Authoritative only.
>  Around 800 zones of varying sizes. DNSSEC in use.

Additional datum, as I am seeing the same thing:

- FreeBSD 12.1-RELEASE-p3
- BIND-9.16.1 compiled from ports/poudriere via a local package build
server (no options changed, though, so it likely could have been
installed from the FreeBSD package repo).
- Authoritative only
- `rndc status` reports 1058 zones (69 automatic)
- Host is a VM with 16GiB allocated and 4 CPU cores
- named running for approx 2.5 weeks (wall-clock)

Current BIND status (from `top`):

  PID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU
COMMAND
 1707 bind 14  520  5312M  5260M sigwai   2  34.4H   5.79% named

A recursive-only server, running the same versions of all software, on
an identically-provisioned VM, running for the same amount of wall-clock
time (approximately 2.5 weeks) looks like this:

  PID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU
COMMAND
 1485 bind 14  520   927M   890M sigwai   3  89.6H  32.86% named

The recursive memory footprint looks normal.

Contrast that with a separate server:

- FreeBSD 11.3-RELEASE-p7
- BIND 9.14.11 compiled from ports/poudriere via a local package build
server (no options changed, though, so it likely could have been
installed from the FreeBSD package repo).
- Authoritative only + recursive only running in a separate jail
- Same configuration as above, only a bit busier
- Host is standalone with 96GiB RAM and 8 cores

In the `top` output below, both the jailed named processes are shown.
The busier one is the authoritative-only:

  PID USERNAME  THR PRI NICE   SIZERES STATE   C   TIMEWCPU
COMMAND
  896 bind   18  520   956M   927M sigwai  0  99.2H  30.03%
named
 1584 bind   18  520  1171M  1080M sigwai  2 166.2H  13.47%
named

It definitely looks like a memory leak in 9.16.1 when configured as
authoritative-only.  The leak seems slow enough as to be manageable, but
the footprint does appear to growing monotonically (and is still
growing--by another 4M as I wrote this email).

michael
___
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: bind 9.16 vs. 9.14 tcp client connections

[Michael McNally]

On 3/5/20 4:34 AM, Ondřej Surý wrote:
>> On 5 Mar 2020, at 10:11, Arsen STASIC  wrote:
>>
>> Hi,
>>
>> Bind 9.16 was installed on 3/2 15:45 and tcp connections ramped up to 
>> maximum:
>>   rndc status | grep -i tcp
>>   tcp clients: 102/150
>>   TCP high-water: 150
>>
>> Switching back to bind 9.14 on 3/4 15:45 shows "normal" tcp client behavior:
>>   rndc status | grep -i tcp
>>   tcp clients: 29/150
>>   TCP high-water: 67
>>
>> I have found some tcp related changes in the later versions of 9.15
<https://ftp.isc.org/isc/bind/9.16.0/CHANGES>,>> but nothing which is 
explaining this kind
of behaviour.
>>
>> Has someone else experienced this too?
>
> Hi Arsen,
> 
> we think you are hitting a problem that was reported to us earlier.  Since it
> has been now circulated on the bind-users, we made the merge request public:
> 
> https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3163
> 
...
> 
> ISC will be issuing a proper Operational Notification later this week
> and the fix will be included in BIND 9.16.1 due in March.
> 
> Sorry for the inconvenience.

Hello --

Subscribers who are also subscribed to the bind-announce list will now
have received our Operational Notification concerning this issue.
If you're not a subscriber to that list..  why not?  (it's low
traffic and only carries important announcements, generally about releases
and security issues). But in any case you can view the Operational Notification
via the list archives:

  https://lists.isc.org/pipermail/bind-announce/2020-March/001150.html

or via our knowledge base:


https://kb.isc.org/docs/operational-notification-an-error-in-handling-tcp-client-quota-limits-can-exhaust-tcp-connections-in-bind-9160

The short version, though, is that we introduced a problem with TCP client
quota enforcement during the later releases of the 9.15 development branch
which was not noticed until 9.16.0.  A fix is available and a patch diff can
be found linked from either version of the Operational Notification links
above.

Apologies,

Michael McNally
ISC Support
___
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

Internet Systems Consortium has a position open (Support Engineer III)

[Michael McNally]

Hello, bind-users list members,

I hope you'll excuse me for posting something a little bit out of
the ordinary for this list, but there are perhaps some in this
community who will be interested to know that we are looking for
a candidate to fill the position of Support Engineer III at
Internet Systems Consortium.

It was via this list (a number of years ago) that I myself
learned of a similar opening and thereby gained the opportunity
to join a crew of intelligent, friendly, and talented colleagues
working together to further the mission of an organization
whose vision is to develop free open-source software in order
to promote a free and open internet.

If you'd like to know more about ISC you can read about our mission
here:

  https://www.isc.org/about/

and if you are interested in learning more about the open position
you can find details here:

  https://jobs.isc.org/o/support-engineer-iii

The successful candidate will have excellent communication skills,
strong technical knowledge and troubleshooting skills, and domain-
specific experience in DNS and DHCP.  Full details and links to
submit an application can be found on the job description page.

Thank you for your time and (for those who are not interested)
please accept my apologies for the digression from the usual list content.


Michael McNally
ISC Support
___
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

Dynamic DNS Updates fail once in a while against AD DNS

[Osipov, Michael]

Hi folks,

we experience sporadic failures in DNS updates with nsupdate 9.11.6 
against Active Directory with GSS-TSIG.


The input is:

$ less /usr/local/etc/register-hostnames.in
zone ad001.siemens.net
update add deblndw011x1j.ad001.siemens.net 3600 A 147.54.64.149
send
update add sitex-ldadw.ad001.siemens.net 3600 A 147.54.64.149
send


The update runs a crontab with @daily on FreeBSD 12.0-RELEASE:

in a negative case we see:

;; UPDATE SECTION:
deblndw011x1j.ad001.siemens.net. 3600 IN A  147.54.64.149

;; TSIG PSEUDOSECTION:
2194433436.sig-demchadc02a.ad001.siemens.net. 0	ANY TSIG gss-tsig. 1554588001 300 28 BAQE//8AH1sNRDyJ/ysz/YCKzFftFw== 45424 NOERROR 0 


07-Apr-2019 00:00:01.897 dns_request_destroy: request 0x8010d3bc0
07-Apr-2019 00:00:01.897 req_destroy: request 0x8010d3bc0
07-Apr-2019 00:00:01.897 requestmgr_detach: 0x8010c7a40: eref 1 iref 1
07-Apr-2019 00:00:01.913 req_connected: request 0x8010d3a40
07-Apr-2019 00:00:01.913 req_send: request 0x8010d3a40
07-Apr-2019 00:00:01.913 req_senddone: request 0x8010d3a40
07-Apr-2019 00:00:01.930 req_response: request 0x8010d3a40: success
07-Apr-2019 00:00:01.930 req_cancel: request 0x8010d3a40
07-Apr-2019 00:00:01.930 req_sendevent: request 0x8010d3a40
07-Apr-2019 00:00:01.930 dns_request_getresponse: request 0x8010d3a40
07-Apr-2019 00:00:01.930 GSS verify error: GSSAPI error: Major = A token had an 
invalid Message Integrity Check (MIC), Minor = Unknown code 0.
07-Apr-2019 00:00:01.930 tsig key '2194433436.sig-demchadc02a.ad001.siemens.net' 
(): signature failed to verify(1)
; TSIG error with server: tsig verify failure


If necessary, I can provide both (positive and negative) output from 
cron and pcap files.


Is there anything I can do to solve this issue or is this another 
Microsoft DNS quirk (domain name compression or alike) I have to live 
with? Is issue #45854 back in the game?


Regards,

Michael

___
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

Undefined symbol: .isc_string_strlcpy compiling bind-9.11.6 on powerpc-ibm-aix7.1.0.0

[Michael Niksch]

Compiling bind-9.11.6 on AIX (powerpc-ibm-aix7.1.0.0) stops with


ld: 0711-317 ERROR: Undefined symbol: .isc_string_strlcpy


when trying to build


bin/tests/system/dlzexternal/driver.so


On the other hand, .isc_string_strlcpy seems to be defined in 
lib/isc/libisc.a, originating from lib/isc/string.o, both of which is 
built previously. bind-9.11.5-P4 compiled without problems using the 
same configuration.


Any ideas?

... > making all in 

/u/nik/tarfiles/bind/bind-9.11.6/bind-9.11.6/bin/tests/system/dlzexternal

  gcc  -I/u/nik/tarfiles/bind/bind-9.11.6/bind-9.11.6 -I../../../.. 
-I/u/nik/tarfiles/bind/bind-9.11.6/bind-9.11.6/lib/dns/include  
-I../../../../lib/dns/include 
-I/u/nik/tarfiles/bind/bind-9.11.6/bind-9.11.6/lib/isc/include  
-I../../../../lib/isc  -I../../../../lib/isc/include  
-I../../../../lib/isc/unix/include  -I../../../../lib/isc/pthreads/include  
-I../../../../lib/isc/powerpc/include-D_REENTRANT  -D_THREAD_SAFE -g -O2  
-Wa,-many -fPIC -fPIC   -W -Wall -Wmissing-prototypes -Wcast-qual 
-Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing 
-fno-delete-null-pointer-checks  -c driver.c
  gcc -shared -o driver.so driver.o
ld: 0711-317 ERROR: Undefined symbol: .isc_string_strlcpy
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
make: 1254-004 The error code from the last command is 1.


Stop.


--
Michael Niksch /Zurich/IBM @ IBMCH
IBM Zurich Research Laboratory n...@zurich.ibm.com
Saeumerstrasse 4   http://www.zurich.ibm.com/~nik/
CH-8803 Rueschlikon / Switzerland  P: +41-44-724-8913 F: +41-44-724-8080

___
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

redundant bump-in-the-wire signers using BIND

[Michael Sinatra]

To close the loop a bit on this...

On 05/22/18 03:22, Tony Finch wrote:
> Michael Sinatra  wrote:
>>
>> My only concern is that serial numbers might get out of sync between the
>> two signers at some point.
> 
> You can avoid this problem with `serial-update-method unixtime`.
> 
> HOWEVER! I think you are going to have problems with inconsistent IXFRs
> depending on which signer the public authoritative servers talk to. You
> can work around this by only using AXFR, by turning off `provide-ixfr` and
> `request-ixfr`.

Thanks, Tony, that's a great point, and it ultimately led me to the work
done on by the yeti-dns project.  One of their experiments was a
multi-signer, multi-ZSK setup.[1]  That's a bit different from what I am
doing, as I am actually synching the private keys.  However, since I am
also signing with ECDSA, and the major crypto libraries don't yet
support deterministic ECDSA, I am going to have differing sigs no matter
how synchronized they are.

In testing this setup over the past several weeks, it appears that BIND
operates in the same way as NSD, in that, if it tries an ixfr and can't
cleanly diff the updated zone into the old one, it falls back to axfr.
Here's an example log:

18-Jun-2018 14:25:42.698 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: connected using
cleverly:obfuscated:ipv6:client-address#41964
18-Jun-2018 14:25:42.724 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: failed while receiving
responses: not exact
18-Jun-2018 14:25:42.724 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer status: IXFR failed
18-Jun-2018 14:25:42.724 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer completed: 0
messages, 11 records, 0 bytes, 0.025 secs (0 bytes/sec)
18-Jun-2018 14:25:43.203 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: connected using
cleverly:obfuscated:ipv6:client-address#41965
18-Jun-2018 14:25:43.229 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer status: success
18-Jun-2018 14:25:43.229 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer completed: 1
messages, 61 records, 5366 bytes, 0.025 secs (214640 bytes/sec)


The fallback to AXFR is not an issue for the zones I am currently
signing because they are not that big and don't change very often (there
are no dynamic DHCP names in these zones, for example).  So it does seem
like this will work, but I am doing some more testing (and have run into
another issue, which will be in a different thread).  Thanks, though for
the heads up.

michael

[1] See
https://raw.githubusercontent.com/BII-Lab/Yeti-Project/master/doc/Report-MZSK.md
and https://tools.ietf.org/html/draft-song-yeti-testbed-experience-06
(section 4.2.1) for more info.  To be on the safe side, it may make
sense to just configure AXFR all of the time, but BIND seems to be doing
a good job of falling back to AXFR when it detects an inconsistency.


___
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

Test mail to bind-users

[Michael McNally]

We have had reports that posts to bind-users are (in at least
some cases) triggering unwelcome direct-to-the-submitter messages
from spammers.

Please disregard this message while I try to gather some information
in the hopes of stopping this unwelcome behavior.
___
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

redundant bump-in-the-wire signers using BIND

[Michael Sinatra]

Hi all:

First, let me explain the trade-off I am trying to manage (as succinctly
as possible):

My current setup has an DNS/IPAM system that backs up to a redundant one
in a different location, a bump-in-the-wire hardware signing appliance
(different from the IPAM), and a bunch of authoritative slaves running
BIND in an anycast cloud.

+-+ +---+
|  IPAM   | --> | HW Signer | --> (Slaves)
+-+ +---+

The HW signer also backs up to a redundant one elsewhere.  Failover for
both can either be manual or a complex combination of heartbeats and
synchronization that yields an active-standby arrangement.  I choose
manual here because our needs don't require immediate, seamless
failover, and I don't want the complexity.

Now, I'd like to replace the HW signers with VMs running BIND.  HSM is
not a requirement for me.  I can run dnssec-keymgr to generate keys on
one of the BIND VMs and then rsync the keys to the other (again,
geographically redundant).  The configurations are similarly synched
between the two.

I am trying to go for reasonable, practical security for the secret
keys, but I also want them backed up to one other location.  So having 2
geographically redundant VMs that can be locked down so that they only
talke to the IPAM and the slaves seems reasonable.  Putting secret keys
on all of the slaves, and having them do inline signing seems a bit more
reckless.  (There are other reasons I'd like to maintain the
bump-in-the-wire method, but I won't go into them now.)

My initial thought is that, as long as I can keep the keys and config in
sync between the two signing VMs, I can keep both VMs running bind *and*
can treat them both as stealth masters and have all of the slaves
configured to use both VMs as masters.  This obviates the need for
manual failover of the *signers*.

This seems to work in practice with a legacy zone that I am using for
testing.  The two signers sometimes sign at slightly different times, so
the signatures are different, but they both produce valid signatures.

My only concern is that serial numbers might get out of sync between the
two signers at some point.  If signer 1 is down for an extended period
of time, signer 2 may go through a few re-sign cycles and have a
consistently higher serial number in the case of a zone that isn't
modified much.

I can see two possible solutions: 1. manually "jiggle the handle" on the
IPAM by bumping the serial number to be greater than that of the larger
signer's SOA serial.  (The IPAM uses date/time serial format, so this
should be easy.) 2. use 'rndc signing -serial' to set the serial number,
possibly in concert with a monitoring script that checks to see if the
serial is out of sync.

Has anyone implemented anything like this?  Any other gotchas I should
be thinking about?  BIND does a good job of doing the right thing with
serial numbers, but I have yet to see (via google-foo or even bing-foo)
any evidence of anyone trying to do an active-active redundant
configuration with BIND inline-signing.

thanks!
michael
___
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

CVE-2018-5737: BIND 9.12's serve-stale implementation can cause an assertion failure in rbtdb.c or other undesirable behavior, even if serve-stale is not enabled.

[Michael McNally]

CVE: CVE-2018-5737
Document Version:2.0
Posting date:18 May 2018
Program Impacted:BIND
Versions affected:   9.12.0, 9.12.1
Severity:Medium
Exploitable: Remotely

Description:

   A problem with the implementation of the new serve-stale feature
   in BIND 9.12 can lead to an assertion failure in rbtdb.c, even
   when stale-answer-enable is off.  Additionally, problematic
   interaction between the serve-stale feature and NSEC aggressive
   negative caching can in some cases cause undesirable behavior
   from named, such as a recursion loop or excessive logging.

   Deliberate exploitation of this condition could cause operational
   problems depending on the particular manifestation -- either
   degradation or denial of service.

Impact:

   Servers running a vulnerable version of BIND (9.12.0, 9.12.1)
   which permit recursion to clients and which have the max-stale-ttl
   parameter set to a non-zero value are at risk.

CVSS Score:  5.9
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

For more information on the Common Vulnerability Scoring System and
to obtain your specific environmental score please visit:
https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Workarounds:

   Setting "max-stale-ttl 0;" in named.conf will prevent exploitation
   of this vulnerability (but will effectively disable the serve-stale
   feature.)

   Setting "stale-answer enable off;" is not sufficient to prevent
   exploitation, max-stale-ttl needs to be set to zero.

Active exploits:

   No known active exploits.

Solution:

   The error which can be exploited in this vulnerability is present
   in only two public release versions of BIND, 9.12.0 and 9.12.1.
   If you are running an affected version then upgrade to BIND
   9.12.1-P2

Acknowledgements:

   ISC would like to thank Tony Finch of the University of Cambridge
   for his assistance in discovering and analyzing this vulnerability.

Document Revision History:

   1.0 Advance Notification, 09 May 2018
   1.1 BIND 9.12.1-P1 was recalled before public announcement
   due to defect, the advisory language was re-written to be
   clearer about the exploit risk, and the public disclosure
   date was adjusted because of the problem with 9.12.1-P1,
   17 May 2018
   2.0 Public Disclosure, 18 May 2018

Related Documents:

   See our BIND9 Security Vulnerability Matrix at
   https://kb.isc.org/article/AA-00913 for a complete listing of
   Security Vulnerabilities and versions affected.

If you'd like more information on ISC Subscription Support and
Advance Security Notifications, please visit http://www.isc.org/support/.

Do you still have questions?  Questions regarding this advisory
should go to security-offi...@isc.org.  To report a new issue,
please encrypt your message using security-offi...@isc.org's PGP
key which can be found here:
   https://www.isc.org/downloads/software-support-policy/openpgp-key/.
If you are unable to use encrypted email, you may also report new
issues at: https://www.isc.org/community/report-bug/.

Note:

   ISC patches only currently supported versions. When possible we
   indicate EOL versions affected.  (For current information on
   which versions are actively supported, please see
   http://www.isc.org/downloads/).

ISC Security Vulnerability Disclosure Policy:

   Details of our current security advisory policy and practice can
   be found here: https://kb.isc.org/article/AA-00861

This Knowledge Base article https://kb.isc.org/article/AA-01606 is
the complete and official security advisory document.

Legal Disclaimer:

   Internet Systems Consortium (ISC) is providing this notice on
   an "AS IS" basis. No warranty or guarantee of any kind is expressed
   in this notice and none should be implied. ISC expressly excludes
   and disclaims any warranties regarding this notice or materials
   referred to in this notice, including, without limitation, any
   implied warranty of merchantability, fitness for a particular
   purpose, absence of hidden defects, or of non-infringement. Your
   use or reliance on this notice or materials referred to in this
   notice is at your own risk. ISC may change this notice at any
   time.  A stand-alone copy or paraphrase of the text of this
   document that omits the document URL is an uncontrolled copy.
   Uncontrolled copies may lack important information, be out of
   date, or contain factual errors.

(c) 2001-2018 Internet Systems Consortium
___
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

BIND 9.12.1-P2 is now available

[Michael McNally]

A new version of BIND is available to address two vulnerabilities
disclosed today: CVE-2018-5736 and CVE-2018-5737; see the respective
messages on this mailing list or consult the ISC Knowledge Base
https://kb.isc.org/category/74/0/10/Software-Products/BIND9/Security-Advisories/.

Only two releases in the BIND 9.12 branch were affected by these
vulnerabilities and BIND 9.12.1-P2 corrects both issues.  The new
release can be found via our software download page:

   https://www.isc.org/downloads

Finally, a word of apology for the awkward timing of this diclosure.
At ISC we usually try to avoid the very beginning or end of the week
for our vulnerability disclosures because time zone factors can make
those times particularly awkward for operators in other parts of the
world.  In this particular instance we had originally scheduled our
disclosure for Wednesday (16 May) but were forced to delay the
release when a last-minute flaw was found in BIND 9.12.1-P1, leading
to its withdrawal and replacement with BIND 9.12.1-P2.  Unfortunately
the vulnerabilities were partly disclosed at that stage and we
decided that the safest course was to proceed as directly as possible
to public disclosure, rather than risk a leak.  We do regret the
inconvenience that will be incurred by server operators due to the
timing of this announcement.

Michael McNally
ISC Security Officer
___
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