Re: 'managed-keys' is deprecated ??
On Tue, 2021-06-15 at 14:27 +1000, Mark Andrews wrote: > https://downloads.isc.org/isc/bind9/9.16.16/doc/arm/Bv9ARM.pdf The modern-day RTFM :-) -Jim P. ___ 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: Using RNDC to control remote access to my BIND server
On Thu, 2021-04-22 at 10:59 +0100, Greg Donohoe wrote: > Hello, > I have created a CI/CD pipeline in order to amend zone files using > nsupdate based on a front end user request. This portion of the > pipeline is working as expected so now I want to be able to connect > from my pipeline runner to my remote BIND staging server and update > the zone files on there with my newly updated zone file. > I initially thought about using ssh from the runner to the remote BIND > server but this may not be the most secure way of connecting. > So my question is: Is it possible to use RNDC to manage my connection > from host to remote server and if so, how can I ensure complete > security? My suggestion is to install a runner on the staging server and register that runner in your gitlab/github/git/bitbucket/etc. You'd still have to setup the trust bits so that the runner docker/js/etc environment can talk to the staging named. There's 10,000 ways to do things in CI/CD, the 1 way that doesn't exist is the only one you will recall in the middle of a weekend while you are on vacation. :) -Jim P. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: FW: Preventing a particular type of nameserver abuse
On Wed, 2021-04-14 at 08:07 +, Richard T.A. Neal wrote: > > Just out of interest, because I run some services on OVH, I know what > that term means. When you rent a dedicated server from OVH you are > assigned a single IPv4 address. Let's assume that you then want to use > VMware or Hyper-V on that dedicated server to run some VMs - for many > of those VMs you'll obviously want a distinct public IPv4 address. So > OVH assign you what they term a "failover" block of IPv4 addresses. I > don't know why they use that term, I just know that they do! So really > it's just confirmation that it's an OVH customer (running a VM on a > dedicated server) that is either the source IP or the spoofed target. Additional IP address are one thing, Failover IPs are something else. In OVH land they unfortunately lease additional IPs using the same french-to-english translated text form. OVH "Failover IPs" are probably used more for adding an additional IP to a leased server (VPS/Cloud/Physical), but the true purpose and benefit of OVH (and other provider's) Failover IP is that the customer can have one or more reserved IPs and quickly transfer them from server to server using the OVH API. This is great for database resiliency/failover, etc. -Jim P. ___ 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: Testing KASP, CDS, and .ch
On Sat, 2021-04-10 at 13:18 +0200, Oli Schacher wrote: > Hi Jim > let me give you a bit more info > > > On April 9, 2021 8:23:48 PM UTC, Hugo Salgado wrote: > > > Switch has a website to test the CDS processing for .ch: > > > https://www.nic.ch/security/cds/ > > > > > > for domainmail.ch it says "The CDS configuration of the domain name > > > domainmail.ch will not be processed. > > > [ ... ] > > > The DNS query returned: "Server failed to complete the DNS request". > > > " > > It looks like until last night (when the last check ran), the domain was > BOGUS ( https://dnsviz.net/d/domainmail.ch/YHDacA/dnssec/ ) - so we > couldn't even fetch the CDS RRSET. RFC 8078 / 7344 can not be used to > fix a bogus domain, this needs to be fixed by updating the DS through > the registrar (which it seems you have done by now) To be clear, although this is the first time I've reached out to this list, I have had the DNSSEC correct on and off since it was registered on 2021-Jan-04. > The error message on our website in this case is indeed not very clear. > Eventually I hope to improve this once our resolvers support RFC8914 > extended dns errors which we could pass on to the frontend. +1 Thanks!! > On 4/9/21 9:11 PM, Jim Popovitch via bind-users wrote: > > > > What I can't figure out is how/when does .ch query the CDS/CDNSKEY data. > > > > > This process happens in two stages, once every 24 hours. > > In stage 1 (during the night), we scan all .CH and .LI domains for their > CDS RRSETS. > Domains which already have DS in parent are scanned through a validating > resolver. This is where domainmail.ch failed up until last night. > Domains which are currently insecure (=no DS in parent) are scanned over > TCP from multiple locations on every IP address of all nameservers > registered at the registry. > > In stage 2 (during the day) we process the domains with CDS records > found in stage1 and perform additional checks. If all checks pass, we > apply the requested change, i.e. the DS RRSET is changed to match the > published CDS RRSET. > Some restrictions are different if the domain already has a valid DS in > parent. For example, INSECURE domains need to provide a consistent CDS > RRSET on all their nameserver IPs for at least three consecutive days > before the DS RRSET is activated. Key Rollovers or going unsigned > happens immediately if the current CDS RRSET validates ok. The 3 day > delay initially also applied to Rollovers and Deletes, but we have > meanwhile lifted this restriction as it did not provide a security > benefit and caused operational issues(for example, changing Nameserver > operators) > Some other restrictions however apply in all cases, for example, the CDS > RRSET will not be processed if the resulting DS RRSET would break the > chain of trust. Thank you for that info. Something that most certainly contributed to my problems is that when I did my first rounds of testing, months ago, I had a dnssec-policy of 24 hours. At that time I didn't know about the 3-day rule, so I have definitely learned something, Thank you. -Jim P. ___ 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: Testing KASP, CDS, and .ch
On April 9, 2021 8:21:33 PM UTC, "John W. Blue via bind-users" wrote: >Sorry .. clicked send too soon. > >Found this via google: > >https://docs.gandi.net/en/domain_names/advanced_users/dnssec.html > >"You can not add DS keys as we compute it for you with the KSK or ZSK, then we >send it to the registry." > >So it looks like the owner of domainmail.ch must get the DS from Gandi??? I >wouldn't know how that would work exactly but clearly a conversation is needed >with Gandi. > >Good hunting. Thanks for trying but i think you're missing the point of this thread. I'm not asking about how to configure DNSSEC the traditional way. Btw, one *can* manually setup a DS RR at Gandi, but they take and decode the actual key data not the DS. -Jim P ___ 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: Testing KASP, CDS, and .ch
On April 9, 2021 8:23:48 PM UTC, Hugo Salgado wrote: >Switch has a website to test the CDS processing for .ch: > https://www.nic.ch/security/cds/ > >for domainmail.ch it says "The CDS configuration of the domain name >domainmail.ch will not be processed. >[ ... ] >The DNS query returned: "Server failed to complete the DNS request". >" > >You should check the requirements. You'd need to answer for three >consecutive days, be consistent in all NS IP addresses, etc. > >Hugo > >On 15:11 09/04, Jim Popovitch via bind-users wrote: >> On Fri, 2021-04-09 at 19:05 +, John W. Blue via bind-users wrote: >> > So the issue here is that the DS record that sit in .ch has an ID of 22048 >> > but the domainmail.ch servers are telling the world that the correct ID is >> > 17870. >> > >> > Thus the DNSSEC breakage. >> >> Of course, however there is no 22048 id in Gandi (the Registrar), yet it >> appears in .ch, and 17870 is still Active (as of this moment in time). >> >> What I can't figure out is how/when does .ch query the CDS/CDNSKEY data. >> >> I know that I can make the domain validate by manually putting a >> keyid+data in Gandi, but the whole purpose of CDS/CDNSKEY is to not have >> to do that, no? >> >> -Jim P. >> >> >> >> ___ >> 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 >> Thanks Hugo! That helps. -Jim P. ___ 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: Testing KASP, CDS, and .ch
On Fri, 2021-04-09 at 19:05 +, John W. Blue via bind-users wrote: > So the issue here is that the DS record that sit in .ch has an ID of 22048 > but the domainmail.ch servers are telling the world that the correct ID is > 17870. > > Thus the DNSSEC breakage. Of course, however there is no 22048 id in Gandi (the Registrar), yet it appears in .ch, and 17870 is still Active (as of this moment in time). What I can't figure out is how/when does .ch query the CDS/CDNSKEY data. I know that I can make the domain validate by manually putting a keyid+data in Gandi, but the whole purpose of CDS/CDNSKEY is to not have to do that, no? -Jim P. ___ 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
Testing KASP, CDS, and .ch
Hello!
I've read the "Schacher 20200622 Support for and adoption of CDS in .ch
and .li", and studied
https://kb.isc.org/docs/dnssec-key-and-signing-policy, however I've hita brick
wall:
https://dnsviz.net/d/domainmail.ch/dnssec/
What am I missing?
I'm using the following policy and zone config:
dnssec-policy "test" {
keys { csk lifetime P30D algorithm ECDSAP256SHA256; };
};
zone "domainmail.ch" {
type master;
file "/etc/bind/zone/domainmail.ch";
dnssec-policy "test";
};
Here are the info of the active keys:
/etc/bind/keys/Kdomainmail.ch.+013+22048.key
; This is a key-signing key, keyid 22048, for domainmail.ch.
; Created: 20210208192710 (Mon Feb 8 19:27:10 2021)
; Publish: 20210208192710 (Mon Feb 8 19:27:10 2021)
; Activate: 20210208222710 (Mon Feb 8 22:27:10 2021)
; Inactive: 20210310222710 (Wed Mar 10 22:27:10 2021)
; Delete: 20210320233210 (Sat Mar 20 23:32:10 2021)
; SyncPublish: 20210208222710 (Mon Feb 8 22:27:10 2021)
/etc/bind/keys/Kdomainmail.ch.+013+17870.key
; This is a key-signing key, keyid 17870, for domainmail.ch.
; Created: 20210310202210 (Wed Mar 10 20:22:10 2021)
; Publish: 20210310202210 (Wed Mar 10 20:22:10 2021)
; Activate: 20210310222710 (Wed Mar 10 22:27:10 2021)
; Inactive: 20210409222710 (Fri Apr 9 22:27:10 2021)
; Delete: 20210419233210 (Mon Apr 19 23:32:10 2021)
; SyncPublish: 20210310222710 (Wed Mar 10 22:27:10 2021)
/etc/bind/keys/Kdomainmail.ch.+013+04319.key
; This is a key-signing key, keyid 4319, for domainmail.ch.
; Created: 20210220012755 (Sat Feb 20 01:27:55 2021)
; Publish: 20210220012755 (Sat Feb 20 01:27:55 2021)
; Activate: 20210220012755 (Sat Feb 20 01:27:55 2021)
; Inactive: 20210221040633 (Sun Feb 21 04:06:33 2021)
; Delete: 20210303051133 (Wed Mar 3 05:11:33 2021)
; SyncPublish: 20210221023255 (Sun Feb 21 02:32:55 2021)
-Jim P.
___
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: Two copies of recent posts
On Tue, 2020-11-24 at 22:22 -0500, Paul Kosinski wrote: > My reading of the headers (below) does *not* suggest "Reply All". > > Rather, they show that mx.pao1.isc.org sent/forwarded the email once, > and it was received by lists.isc.org once with ESMTP ID 026B967ED73. > But then lists.isc.org resent/forwarded it more than once, as it was > received a few seconds later by lists.isc.org (again!) with two > *different* ESMTP IDs: B380C67F367 and E414B67F36E. > > This suggests to me that lists.isc.org is being a bit too diligent in > delivering its email. > I just received 2 copies of your post, with 2 different ESMTP IDs... because you sent it to 2 different recipients. That same thing would happen if you sent it to bind-users@lists.isc.org and bind-users@lists.isc.org. -Jim P. ___ 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: Two copies of recent posts
On Mon, 2020-11-23 at 08:13 +0100, Reindl Harald wrote: > > Am 23.11.20 um 04:58 schrieb Jim Popovitch via bind-users: > > On Sun, 2020-11-22 at 21:56 -0500, Paul Kosinski via bind-users wrote: > > > I've been getting two identical copies of recent posts to this list... > > > > Me too, but it's because of people hitting reply-all thinking that they > > are replying to the list and the poster. > > why don't you just read what you respond to when "Upon examination of > the headers of the two copies, it looks like ISC's list-servers are > doing the duplication" including the headers where part of the original > post? > > typically that happens when a connection was interruptred (no matter > smtp or local lmtp) in the moment it would have said "OK got it" from > the destination hop and so the client tries again > > below the headers of the OP > > P.S.: this is a reply-all by intention because it takes ages on this > list when you are moderated because you answered to a personmal attack > instead suck it :) Either you need a better *-to-english translation tool, or you should take a class in Comedic Timing. Let me know if you need assistance in deciding! -Jim P. ___ 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: Two copies of recent posts
On Sun, 2020-11-22 at 21:56 -0500, Paul Kosinski via bind-users wrote: > I've been getting two identical copies of recent posts to this list... Me too, but it's because of people hitting reply-all thinking that they are replying to the list and the poster. People really need to verify who they are replying to, it's easy to see from the "Servfail on Bind -9.16.1" thread where the problem(s) exist. Note Paul, I only received one copy of your post, and you should be only receiving one copy of my reply. -Jim P. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: getting a later-version of BIND on various linux OS's
On November 9, 2020 7:18:03 AM UTC, Rob McEwen wrote: >Several weeks ago, Mark Andrews gave me an excellent suggestion about a >particular BIND feature, but it is a somewhat recent feature that >started to exist on a version of BIND that isn't yet distributed in the >default/main BIND distributions for many of the most common linux-based >operating systems. I think the particular feature that was mentioned - >came into existence around BIND 9.13? Unfortunately, many of the major >linux operating systems haven't reached 9.13 yet. So, for example, I'm >currently trying to upgrade a Debian server to a more recent version of >BIND - 9.16 - and I saw the following pages: > >https://packages.debian.org/sid/bind9 > >https://www.isc.org/blogs/bind-9-packages/ > >But I can't seem to find any simple way to do this - or maybe I missed >something on that page? - from what I've seen, for Debian, it requires >that the BIND source code (and various dependencies) be downloaded, and >then BIND has to be compiled. Or so it seems. I tried that, but kept >running into errors - something about "Libressl not found" - even >though I really did already have the SSL package installed that it said >it needed. It was a downward-spiral mess I couldn't seem to resolve. > >So here is the question - is there an */easier/simpler/* way to get the >most common linux operating systems (Debian, Ubuntu, CentOs, etc) - to a >later version of BIND - beyond what auto-installs when you issue a >command like "apt-get install bind9" - but /without/ having to download >and compile the source code? > >-- >Rob McEwen, invaluement > > What you are looking for is Debian Backports: https://backports.debian.org/ Stable (Buster) Backports has v9.16.6 https://packages.debian.org/buster-backports/bind9 It's built and maininted by: https://tracker.debian.org/pkg/bind9 -Jim P.___ 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: rbldnsd and DNSSEC compatibility issues - any suggestions?
On Thu, 2020-09-10 at 13:50 -0400, Jim Popovitch via bind-users wrote:
> On Thu, 2020-09-10 at 11:56 -0400, Rob McEwen wrote:
> > I manage an anti-spam DNSBL and I've been running into an issue in recent
> > years - that I'm FINALLY getting around to asking about. I just joined this
> > list to ask this question. Also, I checked the archives, but couldn't find
> > an answer - at least, not one I understood.
> > So basically, while most of our users do direct queries and don't have this
> > issue - some of our larger subscribers RSYNC the rbldsnd-formatted files,
> > and then they typically run rbldnsd on the same server as their BIND server
> > that is answering their DNSBL queries. Then, their invaluement zone names
> > will all end with "invaluement.local". Typically, their RBLDNSD server is
> > set up to listen on 127.0.0.2 - and then they use BIND for answering their
> > DNSBL queries, and so they tell BIND to get its answers for THOSE
> > invaluement dnsbl queries by doing a DNS forwarder, telling bind to get the
> > answers for THOSE zones from 127.0.0.2 - as shown below:
> > zone "invaluement.local" in {
> > type forward;
> > forward only;
> > forwarders { 127.0.0.2; };
> > };
> >
> > This works perfectly - so long as DNSSEC is turned off. And since most of
> > our subscribers are running a dedicated instance of BIND that is ONLY used
> > for DNSBL queries, they don't mind turning DNSSEC off.
> > But, occasionally, we have a customer who cannot turn DNSSEC off. So I was
> > hoping that THIS command would work:
> > dnssec-must-be-secure "invaluement.local" no;
> > But it doesn't seem to be helping at all. Is that command suppose to
> > disable DNSSEC checking for a particular zone? If yes, what did I do wrong?
> > If not, what does "dnssec-must-be-secure" set to "no" do?
> > I've heard that there is NOT a way to get this to work - and that such
> > subscribers much use DNS Delegation, instead. But I really wish this could
> > be done by simply turning off DNSSEC for a particular zone. That could be
> > useful for MANY various types of internal zones that need this. But if this
> > is that case, how would that DNS Delegation look, to get the above
> > forwarding example to work using delegation instead?
> > Thanks in advance for your help!
>
> Just a thought, but ARM says:
>
> dnssec-must-be-secure
>Specify hierarchies which must be or may not be secure (signed and
> validated). If yes,
>then named will only accept answers if they are secure. If no, then normal
> DNSSEC
>validation applies allowing for insecure answers to be accepted. The
> specified domain
>must be defined as a trust anchor, for instance in a trust-anchors
> statement, or dnssec-
>validation auto must be active.
>
>
> You might want to try adding "dnssec-validation auto" to the zone stanza.
>
> zone "invaluement.local" in {
>type forward;
>forward only;
>forwarders { 127.0.0.2; };
>dnssec-validation auto;
> };
In retrospect that won't work. dnssec-validation can only be used in
options or views. Maybe try using a view?
-Jim P.
___
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: rbldnsd and DNSSEC compatibility issues - any suggestions?
On Thu, 2020-09-10 at 11:56 -0400, Rob McEwen wrote:
> I manage an anti-spam DNSBL and I've been running into an issue in recent
> years - that I'm FINALLY getting around to asking about. I just joined this
> list to ask this question. Also, I checked the archives, but couldn't find an
> answer - at least, not one I understood.
> So basically, while most of our users do direct queries and don't have this
> issue - some of our larger subscribers RSYNC the rbldsnd-formatted files, and
> then they typically run rbldnsd on the same server as their BIND server that
> is answering their DNSBL queries. Then, their invaluement zone names will all
> end with "invaluement.local". Typically, their RBLDNSD server is set up to
> listen on 127.0.0.2 - and then they use BIND for answering their DNSBL
> queries, and so they tell BIND to get its answers for THOSE invaluement dnsbl
> queries by doing a DNS forwarder, telling bind to get the answers for THOSE
> zones from 127.0.0.2 - as shown below:
> zone "invaluement.local" in {
> type forward;
> forward only;
> forwarders { 127.0.0.2; };
> };
>
> This works perfectly - so long as DNSSEC is turned off. And since most of our
> subscribers are running a dedicated instance of BIND that is ONLY used for
> DNSBL queries, they don't mind turning DNSSEC off.
> But, occasionally, we have a customer who cannot turn DNSSEC off. So I was
> hoping that THIS command would work:
> dnssec-must-be-secure "invaluement.local" no;
> But it doesn't seem to be helping at all. Is that command suppose to disable
> DNSSEC checking for a particular zone? If yes, what did I do wrong? If not,
> what does "dnssec-must-be-secure" set to "no" do?
> I've heard that there is NOT a way to get this to work - and that such
> subscribers much use DNS Delegation, instead. But I really wish this could be
> done by simply turning off DNSSEC for a particular zone. That could be useful
> for MANY various types of internal zones that need this. But if this is that
> case, how would that DNS Delegation look, to get the above forwarding example
> to work using delegation instead?
> Thanks in advance for your help!
Just a thought, but ARM says:
dnssec-must-be-secure
Specify hierarchies which must be or may not be secure (signed and
validated). If yes,
then named will only accept answers if they are secure. If no, then normal
DNSSEC
validation applies allowing for insecure answers to be accepted. The
specified domain
must be defined as a trust anchor, for instance in a trust-anchors
statement, or dnssec-
validation auto must be active.
You might want to try adding "dnssec-validation auto" to the zone stanza.
zone "invaluement.local" in {
type forward;
forward only;
forwarders { 127.0.0.2; };
dnssec-validation auto;
};
-Jim P.
___
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?
On Wed, 2020-04-15 at 14:21 +0200, Reindl Harald wrote: > > Am 15.04.20 um 14:17 schrieb Jim Popovitch via bind-users: > > On Wed, 2020-04-15 at 10:35 +0200, Klaus Darilion wrote: > > > Thanks for answer! > > > > > > So actually it is just a cosmetic change not addressing a real problem. > > > > > > I will miss the bind9 service :-( > > > > Wait until you find out about Predicatable Network Interface Names and > > iptables rules. :) > > "net.ifnames=0 biosdevname=0" is your friend :-) s! Didn't you know that is suppose to be difficult for people to figure out? :) -Jim P. ___ 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: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On Wed, 2020-04-15 at 10:35 +0200, Klaus Darilion wrote: > Thanks for answer! > > So actually it is just a cosmetic change not addressing a real problem. > > I will miss the bind9 service :-( Wait until you find out about Predicatable Network Interface Names and iptables rules. :) -Jim P. ___ 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: update-policy wildcard grant
On Thu, 2020-04-02 at 09:27 +1100, Mark Andrews wrote:
> > On 2 Apr 2020, at 06:53, Jim Popovitch via bind-users <
> > bind-users@lists.isc.org> wrote:
> >
> > Hello!
> >
> > I started on #bind, moved on to the ARM, and now I am here.
> >
> > Here is what I want:
> >
> > update-policy {grant webserver-tsig-key wildcard _acme-challenge.*
> > TXT;};
> >
> > This is what I get:
> >
> > ~$ named-checkconf
> > /etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
> >
> > What am I doing wrong?
>
> Presumably the webserver is locked done enough that you can just let
> the TSIG update TXT anywhere.
Do you mean like kb.isc.org ? :-)
Honestly, no webserver, worth it's salt in 2020, is ever locked down
well enough, imho.
> If you really need to apply tighter rules then use ‘external’ and
> implement the check outside of named.
Thanks for that, it looks exactly like what I need/want.
-Jim P.
___
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
update-policy wildcard grant
Hello!
I started on #bind, moved on to the ARM, and now I am here.
Here is what I want:
update-policy {grant webserver-tsig-key wildcard _acme-challenge.* TXT;};
This is what I get:
~$ named-checkconf
/etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
What am I doing wrong?
tia!
-Jim P.
___
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
OT: Reminder: DNSSEC series starts in 1 day
First, I love it that ISC does these informative sessions. However, why send out iCal/Calendar instructions AND then send me emails 1 day and 1 hour before each session? I don't want to cancel my registration, but I do want to cancel the constant email reminders. Help! -Jim P. Forwarded Message From: Vicky Risk Reply-To: no-re...@zoom.us To: Jim Popovitch Subject: Reminder: DNSSEC series starts in 1 day Date: Tue, 11 Feb 2020 18:14:12 + Hi Jim Popovitch, This is a reminder that "DNSSEC series" will begin in 1 day on: Date Time: Feb 12, 2020 10:00 AM Pacific Time (US and Canada) Join from a PC, Mac, iPad, iPhone or Android device: Click Here to Join Note: This link should not be shared with others; it is unique to you. Add to Calendar Add to Google Calendar Add to Yahoo Calendar You can cancel your registration at any time. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: The signed domain file rewritten
On 11/12/19 4:42 AM, Alessandro Vesely wrote:
Hi,
I have a signed domain, with inline-signing yes and auto-dnssec maintain.
Although the domain is static, the .signed and .signed.jnl files are being
rewritten without apparent reason. They are about a month newer than the
corresponding .jbk and base files.
I notice that because of tripwire complaints. I guess I have to tweak that
config, unless there's a way to prevent or foresee those rewritings.
I use this in twpol.txt:
{
/etc-> $(SEC_BIN) (recurse=true) ;
!/etc/bind/zone ;
Why does bind rewrite that file?
Because someone forgot to put dynamic files in /var ? :P
https://en.wikipedia.org/wiki/Unix_filesystem
-Jim P.
___
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: Would/Could/Should
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2019-10-10 at 10:39 -0400, Jim Popovitch via bind-users wrote: > Hello! > > Is this a language/translation issue, or is named telling me that it > would but didn't limit? > > > Oct 10 00:57:21 ns2 named[623]: would limit REFUSED error responses to > 2404:6800:4003:c00::/56 > Oct 10 00:58:35 ns2 named[623]: would stop limiting error responses to > 2404:6800:4003:c00::/56 Thanks to an off-line message from Dave, I now realize I overlooked the "log-only" stanza in my configs. Time for more coffee. - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAl2fS70ACgkQPcxbabkK GJ9AvhAAsDfl0N0Acz4PrA+qAomIPitsBcM4f2EN4XdHOtPyaj1cqEPxYqmvagUc SPUdCQExahMn4mAIif9XPyt6SOEKu8vgl/6izb41gdquB+v3e9sMKuZzTLUH0XH4 4S0Zy69zANOsmKsF9ipjtovaDOzSS+Y2/h016JGlQBURQBLjOaWTsC3AEy+Lt6OX qxk+EL82QCvpj2DGwiwIrgvpW+TdHEC4Nl06HY20uo9ifarEvQhVNqELZInAncqj 3k2KY5X/R3xdBaxW56WUc3WVqZhQZnz2nnBmUg2O87lEe6zbihYnxmlKTWFdGrzK pTJkJVExNXNOHbGTemfYzxnghXj4+eTOj25ID2Wth7ECQUjEnJVrDArnOIcv8BzG XcoTOcGTt2n1v9NAOY3Nlr2+3frlApZxbRjO1ackkCvYxZSbwmHXiNWxSPl/72gd JJYeJAtidb3dnv9qMtyVS6OjfcxRro1fvpkwrRrlV0P/7TYLwR88J/J1m+yktUNr 44T7zMxlBNsx+4hRwNeQphu5GFXVnvQgFLhdGjoteoYXzRo/OoEvdAdylFpoyy2i L20ctqS5C52NWZsY33JExfy9yTwZ5dSceCosk2uyd1zMLHvxC8jhS4I6/eWG3e3+ TaX8lEx7pDyK1uaSOMNqHYfk4xoFVWxdvIeydagla+YOgoEJsPo= =Y/ez -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Would/Could/Should
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello! Is this a language/translation issue, or is named telling me that it would but didn't limit? Oct 10 00:57:21 ns2 named[623]: would limit REFUSED error responses to 2404:6800:4003:c00::/56 Oct 10 00:58:35 ns2 named[623]: would stop limiting error responses to 2404:6800:4003:c00::/56 - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAl2fQp8ACgkQPcxbabkK GJ+E/hAAt8LBEUukrfFTCY1BT4dUq4NVnT3uM2Z4TwXOgT9BzTHO1J6G/BaT7HrR KGnUm055Fa0GtwKQnCMCXjmMRdPNUno9Mr9DXbHq4EmIp9Cpgi1GrTC+fqD4G0s2 DG1VwlP228LapVAoqu3CLxfQ1ppTX1jqzahDkJ7tASWhbDDLjfUR1K//cO0W3iio TDgXKhWhceACJymDHkb3RHHMC+MgZG/HR0kvI3ewUID0HO8ZKyrvLRoCxF69dsJ1 MQTPT2Iqu4CApIJESlEM7yLnqrVF6aKj8NhT8E8eOwGFjfR3ElBld+i9auIFW8wE 0VEHwzqt0ZKDqf5qZEpdj/CIiwq8/pFxPyDqcvlBMp18k0S1lPg9DFxkfVONw7ec CD4tFBLVf8RbTzt8sfxRqnA0Ea9cxeb2I0DBJQ+rSwpYx4hmk8A614dYqrAbYsy9 BUmqTGh9i/OjjTfnd7F9wrxOqlWXESBvGNJcot0+ot82oQ6aqt6DzNDg7vnAs8lI sYmN40Vgt2vBAPzQZHQ0I2ldjSJooKWoDlfCFjiAIfI//EXne65YbdJ+l/DsQL2K qvQCbhln4Cn0KBgkSJsI8lhZeS0qk0WnvK97uKNUm6SG8bq4fpLphn0H8vn8Oii5 OiNv1TBX1HRnqZ+tyTyK6nP11aK5PczV/GVf0295yEffoHtcO5c= =ARdD -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Auth server reports: resolver priming query complete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2019-07-28 at 02:14 +1000, Mark Andrews wrote: > > On 28 Jul 2019, at 2:03 am, Jim Popovitch via bind-users > > wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On Sun, 2019-07-28 at 01:36 +1000, Mark Andrews wrote: > > > Authoritative servers lookup addresses of nameservers to send notify > > > messages. > > > If the names are not in the authoritative data it will iterate to find > > > the address. > > > > Thanks Mark. BTW, this is with v9.14.4. Follow-up question: > > > > I only see ns1 (master) logging the priming, ns2 doesn't. ns2 is a > > slave to ns1, but also a master to a 3rd party (e.g. also-notify, > > notify-explict). Shouldn't ns2 also be priming addresses of the non- > > auth 3rd party? > > If you have "notify explicit;” and also-notify then named will only > send notify messages to the addresses listed in the also-notify clause > so there is not need to iterate. Priming only occurs when named actually > iterates. Should ns1 (master) be priming if it also has notify-explict and also- notify statements. The domain in question is the domain sending this email. - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAl08esIACgkQPcxbabkK GJ85/hAAt3QPtbto6SraqIa24pmYDf0gG/D2YBzjaEI7JkqpIJHabtDSt4FjueGs gQpjgJ40ivs4sicd8KeX5OGMZcr3zerMXJrtVWg/XqlT1hi55ZwMEkEssikHiL2P HYSmNCDRUuZpUuRyQEW2kGoaeTXU/21p0SJo5Q8UCG0D/ww8dTa9ACIJGMBkGCTk KkNduOX+uG3qwSa22WEsewhyU9I7rAUd7W/PrF3nsMEshCuuom5O5zUfq2F5COyJ ad0BJJSBBHfjgEj4ym1oxqRtUoh6M9eJU12GHp9gqhI6uRsTwxtYnwdThXfwvMqp myIwnx4IdG+6gisfns1nPlsdrg6lXAKIZ3AzBKGiTSj5wMVRB3EVnDTs6C4B02pk 75i+/YOUFL5kmRJUUgIVKOqv4f3ePTM3KsglkCLRRRK+Zw/2JGui2vuekS/EO0la DQ8xcFCf75CW3v84TMtiCK0O8yMwsxFJVfW0pyQwOWhU3jjniPEVZDIMs1Wgzryk zjHq6Zi2U25ZXSHKHmYnQB97cMxSAPOikFeWuuZcKfaBhmaSOXKN7RJZdHxCxyu0 gh5k3qt0XaQj351sOm3kHLN1ZtHT2w+W+RZS+EcMu6nIUKPUDE9WNtk5P3Al/OkP FELyyEzDwc1QkaGuqzlz6kXR7BGjR50dRcqwdSJfuFUcdTneVPs= =pPMe -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Auth server reports: resolver priming query complete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2019-07-28 at 01:36 +1000, Mark Andrews wrote: > Authoritative servers lookup addresses of nameservers to send notify messages. > If the names are not in the authoritative data it will iterate to find the > address. Thanks Mark. BTW, this is with v9.14.4. Follow-up question: I only see ns1 (master) logging the priming, ns2 doesn't. ns2 is a slave to ns1, but also a master to a 3rd party (e.g. also-notify, notify-explict). Shouldn't ns2 also be priming addresses of the non- auth 3rd party? - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAl08ddUACgkQPcxbabkK GJ+ogxAAj4x2Cq+MtPe4mmgSN+fiOfyx5lg/TJ/TLBtBZj6TzYVd67urTF1tqzQU gEB2fOM55XVd1ogoVSlXAT6JW3npqfb0Wi6hFGXlHJwvC7AGSwpxEKCqBvUCZIVr 3V9zgFGbEbbmR0VvNAupAxrqUIlu0TvbhIuBSEktRObLk+9W/go+SUCxQFB0VMwe 6UTfGkpjzTE7SWqdoSEUom57LsYm0tOu+zk+f6v7wCc3BmZPWLUpWmlyEwZFpxAy +BZzUBSDA4lmGIqfDyY+FDqu0MIQ5T8JbN6idcvGH03nsNOhMr4gT2m9Sk80C1ro PX0rHIS4gcMPtxnfurmRbpiaGt3psUriPCft8PyazUx47KebERvL0MQOFNH4ayuI jHDLPVc6ZTF5kHY6AipEnzkXRO46cOKWoaasYcVjycMGXVulxqbe/Y4wMir/8Bwu FMVgboDgDmpxSCmsgWfZv5OM/dU9QEv4nSemBBaacXbGbNXoI0ZW5375KkuMQ19d mQM0e9HBDDJ3zj2w+ahJGeM3J/XaN87kdQQLUujdc5RUZKWvuWElYamNLahjC+l/ 4Uez5w2ADGuCvEeid9YKypKMz1m9r2CaGEwysztNpaKNb9YEsNewNY/WQYT0XZzW xAX/t6Q6d+LfejRZSVqk0JyL61IKax0uiQwPLLBiLc7+n4kJ1lo= =aKXt -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Auth server reports: resolver priming query complete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2019-07-27 at 11:04 -0400, Jim Popovitch via bind-users wrote: > Hello! > > Why would an auto-only server (in this case the master) report this: > > Jul 27 13:07:58 ns1 named[624]: resolver priming query complete > "auth-only" - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAl08aHMACgkQPcxbabkK GJ8tuRAAjlNlCEcG9cXb/pgaWGfbbmOB8oFGUr7KXVTJ6hNBnBV9bpDSlOKs8HaZ AvgcMYljXTyCD3E+INHMUmRAZqgDlpK2AsEMGZRqBHBX1/TFTzHas4+CuUS8PmVb nxDw791GOkIe1YQlZoobPCskHPlsBgkLCPYXIi2s2IG+DGmS9MSVJC9hz2Q7XHMm gq/urkj2PN+sf6+fIC7bZ9DXGeM7AzvLNCUJADljwdTPiak8CowOLhckOY3yhkZa UFoH9bY3U+OUosdKnm8fDn1/EbMZ70lsTeFZVMieX73W7nkQtudhovHmVQ6UdfrO Sv5D2hH5C+0Le60n5vyVe6cPWtgVb7CVSGnx6pK6XmHyspJpEiA9EQZ4MOW7QeLe DY3u2i3zHhFKNOlJ1fkD8Hki2GJtN8LhdG+huS+2eWso/d89FOsjmYbJyevp5IV7 oOJZ4jNAEkRr/jz+MyRdYjT99Yd9gy/sM8lsjHbCI+6vcKlJQgrEWdzfUs1qnGh0 GCe0iF9gTq9LHOk1+ACDMDWzPS1Gt9Bsa81+rk+jB4Y0tCaR1E2ODz/2HAg6Jqq7 gMOMgw5jkifvIgUN5phiEdfSlmRLcXJp1jJpZ3UCjbRHwkeINKUdegDt0B9njRiG w77j027FeXMZW8fMvYMOEFNacyRjRYQVFbnUfy5Zah6l4TLTamU= =Dyhy -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Auth server reports: resolver priming query complete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello! Why would an auto-only server (in this case the master) report this: Jul 27 13:07:58 ns1 named[624]: resolver priming query complete tia, - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAl08aBwACgkQPcxbabkK GJ+d+A//dmDuJq06I4BAriAYowLpGTzbtPDQLp+girpskBOFyoXJCTqm0LR0sfcW /f19cuIdSQ4P/VVusyjP02lw66prO33/593Rzi4vdHBGD35/MMj5GPlVMB0nobbW BR3PtBVL2pVVGVPV8bmZzoZOugUV9EsITkPhg41Jy1Aw4LUc53pYrC8D66i+QAl4 J/qazX84SJh64WXpPBgfuksU1l6W5GMBtYS+DzfDNATLjKYknaDTojeObEUJiWhd +9dhStwRpGHdc5wWRmWJFaATvpwuYnQqZDV2aTmb2fEdbI3cwf3DN6PdygTNhU/+ bLljLuconR69GxXkKvpMLkMdmmijR0sAmQWOBvC7UnwpN/y8tZtPtZ2Mk42xE3h/ yA/Bq5lzfIT18PNAMkX6lEpZPhUsRygQ/jwa7MixMiO4OWGkuIKBZeNnapXT14G5 NbQUrXuiEzu9/Nxw4WO8nF/uIdBU0LnJoui1EQjudKZxdU9gU3rwq+EjcLiY3wPc Mbm/6Po4ib9a0jv5ep8ZjfDv63ax0TKLA2JC4bZAAWPvKSoTK7oQMYEFUVV9lk6t zFxovJo3yH/9/OyOUQeNVYQx9WPKMqurISap+5tBhoyT7ZRnoYQmKnmC7uWLa6y2 rR4BK93CDLAPr1KyAIE2f+fZiRYF5juYNe1sSDySp71iFn4g+gw= =epDS -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DMARC test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2019-07-14 at 18:30 -0400, Paul Kosinski via bind-users wrote: > Testing how lists.isc.org handles DMARC "Quarantine" (and "Reject") > policy. The enterpr...@mozilla.org mailing list forwards such email in a > way that some recipients choke on it (i.e., can't validate it). This list applies the Mailman DMARC handler which, in the case of this list's configuration, munges the From address. In your specific case, subscribers see the email as From: Paul Kosinski via bind-users Reply-to: Paul Kosinski You can read more about how Mailman handles DMARC here: https://wiki.list.org/DEV/DMARC hth, - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAl0rw7cACgkQPcxbabkK GJ9JChAAhNPPmoLbUR0UGsPjEfYSSPe1fSoO5q+larj9mXaO9rCOuVpSucf5FqOb zex2JSqyX7Xh8PUTgUnaNLocKFOXxh2Csdx/a/vagSGBfalFk9cShX92dyn5eySj Ah+wQjqh+1uA9esJcDpW+/HtPYUCb1+ixlzxCwneF/kNPNX8yxtenqOMBM1l2Pi+ vlt8JYM/OxSs5mOz1AWRh9OLGL+E7eUg3dljrkRhhSDqDYMlswNNT4ffgRX1EvpR Z6BWgV8gPdmbJPzW+6ZlU53QLauhmGpL8BN6/Ur4739cKgZfxpjyV2DSSau3BGzp cy3o8g/9Lrvvlnfiv1YZfESnQl2mfeseEj+CZespDbHu4CEVT3DqXWdQQDHAqidv GRJ8FJtuqU2UjM+W4mNMEAwwKn5lQRbVnct4btExEYWvr7hdTGiaybNYlr9+jGDj DlnmM9XZE8vIPvOF0mrFA8qWdLkMp5ecOlLn35++XDb2BSLDgZd+n8WqVJ3G+7Df ZgixhaPQQADisfzk3nujKPu1JVBeIwEKyr8YW4LUvjcORLvp13UTxF00p9EVoLF6 yovKLpYvPXN0Vw6h58YAemWnEr46txzrUnHsW8/6JhT8t1AMew/9nyFu+7maOjX+ wHgFNS+YEkCbG0RbFaAkVH8fGgIwPUMUsx3SpKvkuKZpz/SqTHk= =blPk -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fwd: SSHFP observation
On Thu, 2019-01-31 at 21:12 +0530, Mukund Sivaraman wrote: > On Thu, Jan 31, 2019 at 10:30:30AM -0500, Jim Popovitch via bind- > users wrote: > > On Thu, 2019-01-31 at 19:14 +0530, rams wrote: > > > Hi, > > > I have setup sshfp records as follows in bind zone file: > > > > > > test1.ramesh-sshfp.com. 86400 IN SSHFP 1 1 aa > > > test2.ramesh-sshfp.com. 86400 IN SSHFP 1 1 00 > > > > > > Successfully started bind but when queried for domain test1 and > > > test2 > > > , returning malformed error and no answer. If fingerprint value > > > wrong > > > then bind should validate and should not start. Is it expected > > > behavior? Kindly confirm. > > > > Bind will restart cleanly unless you muck up something in the > > config file(s). In this case you have something wrong in a zone > > file, and we can't see what it is because the domain you specified > > is invalid. So, until you show us some data my best guess is that > > you have a formatting error in a zone file(s). > > > > Help us help you by specifying the actual domain. > > The original poster is right. Something is broken in SSHFP > processing. He's configured a zone with the above records, and > querying against that zone is causing dig to print that the reply is > malformed. > BIND should never return a malformed message, so there is a bug > somewhere. The malformed messages are from dig (v9.8.2rc1-RedHat-9.8.2- 0.30.rc1.el6_6.3) Warning: Message parser reports malformed message packet. WARNING: Messages has 55 extra bytes at end We know nothing yet about the BIND setup/version/zone/etc/ For all we know the zone is fat fingered. -Jim P. ___ 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: Fwd: SSHFP observation
On Thu, 2019-01-31 at 19:14 +0530, rams wrote: > Hi, > I have setup sshfp records as follows in bind zone file: > > test1.ramesh-sshfp.com. 86400 IN SSHFP 1 1 aa > test2.ramesh-sshfp.com. 86400 IN SSHFP 1 1 00 > > Successfully started bind but when queried for domain test1 and test2 > , returning malformed error and no answer. If fingerprint value wrong > then bind should validate and should not start. Is it expected > behavior? Kindly confirm. Bind will restart cleanly unless you muck up something in the config file(s). In this case you have something wrong in a zone file, and we can't see what it is because the domain you specified is invalid. So, until you show us some data my best guess is that you have a formatting error in a zone file(s). Help us help you by specifying the actual domain. -Jim P. ___ 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
Definitive guide for purging old DNSSEC key files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 What is the definitive steps for purging (rm -f) old DNSSEC key files that expired months ago? tia, - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAlvHefsACgkQJxVetMRa JwX3HxAAhze9yaypBQdqkz9r0qOUeB6OmU/LTFAq5jzfjMk2ltjiykzko+zF44pL 5HoGCPqmRympcGNO6ksdi5UX8nPLGlwtJ6M/IxIJ485FsBz51CY7hsFG5Cl8eFMz 10ufEG8lTCoueCqKEA5pBot5diLOmUKD9H2vSTv+9bodGb9iq4vUmlddiOk5++0U 9s30H/09GC2Pcwtyo197fsIO19b51QjGWXfd+u4NEBq8FAcGsAuKFFiZG/preHFc IILUVz0Ht1wpDyMcFzO2uE/bLeD2WA1oiSKEkhNUxj0kNX+kyv+6Ahwfuv4LNHR2 vPAb2tcZYr0dzIPMK/3QOLghuvYuEeFCl08S/meLflhTTBg3fajc1HD+TScL2Ga3 1qFrbzie3TgUni8XfLv9JFGlKb5uouFnBrdq1SCeJp4bsjv0bza6mEFt6aJP6AKD 1Zs1ocIvPkPmza6k6yjZVjRejnuS0AfdwQuJD8blLmYQmjuWTmKHKrNsrqQhkve2 9IyT/uCZE+O2c8GkwjxM29tY9Jtmt0lkZvlmCBNe/XGA1hAWS3Xi96Z8eRoQW0FZ jdZuV3R6kHgJ+Yw281VMjjN0oo2PD2u2P7jJ/pbuYjp+m8I937pkx2xx1Rxg+pXx V/t07Bx5bOfDXP/m0BE700MyeKW/9lUaSdMUZI9q6mloQdiUZbc= =yKfm -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [BIND] Re: Is it possible to...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2018-08-10 at 09:47 +1000, Mark Andrews wrote: > > On 10 Aug 2018, at 5:46 am, Jim Popovitch via bind-users > s...@lists.isc.org> wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Is it possible to... > > > > 1) use text only zone files, and > > > > 2) keep serials identical between those zone files and what is > > published in DNS, and > > That’s not even possible with manually edited files. There will > always with every system be times when what is on disk does not > match what is being published. The world doesn’t allow for perfect > synchronisation. There will always be “edit, read” or “update, > write”. > > > 3) automatically handle signatures when adding new RRs, and > > > > 4) not have any journal files. > > Named is not designed to update zones without running the updates > through a journal. Flat files are really bad performance wise so > we use a structured file (the journal) to record changes then write > out the master file later when things are less time critical. > > Even setting the delay between processing a update and starting to > write the new master file to zero seconds will not achieve what you > want. > > UPDATE requires name servers to behave like a database. Databases > can’t behave like you are requesting. You don’t go reading SQL > database > stores directly. > > > Is all of that possible with a(ny)? recent version of Bind9? > > No. > Ok, and thank you for details. - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAlttDdUACgkQJxVetMRa JwUB/RAAjtJloOz51BI+MhbWcL763RHW9+ZXjb4XW3elHUTNCjharS+HAB+eWfEn wV2DphvcKRZTvcOgrPWP6TUDMK+4t3wNKXC9q/AEhZbc4yp+U7jrLfozuxS2Tgrq 6FDpdLAoOBySQOzQYmo8Owc+yIpXYtqVp02NTx2eZvsQX5eLCW3IAIZW+fv3EQZ0 wnbhPzjdJE/qKFETrAbLGfYUDYfmPtsDA6yNaL+Oymwdq7BhmL2SeeTIGy0wLfbD giripm6qSkRunpXBUNpLbiGijsRFYaxbgXXh/1JEaTc55Jmju5PBEYAwE1a9jHjG 33DxcEyaiM3WAzdkSyXgZ2T2R7wCmLGrg2tPXw9KSfuqIevRMa67yNC8oTyv9JZB odFUVpE01xDVTnKQncezy9yL9wG9fdQMmbQOxexvzgTso5TFHvML/3CfpETlzA2t wkt9Ku6GZDvs0kOqavPgiOshB2aEMbnp+eVuR+CdfwlSbPxvrwINM/FFK+WoyZ3J kJWVsvpxaAyG0EgHw35P71tzgw3D+tc7ADnNNnpeErbxIOubBGgqBwzyoMbaBaX1 GfKu+0oVHuSEmt+E+r1WcMFhvNB/bLYYe4QJ8GtAXYQfJG9puo68z64aTZJK1Am0 V3cRZkXOakwYoHlIH+EDcBPtJ5TCZiE4fAG3IazW+ZNMV24Ek5g= =q9os -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Is it possible to...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Is it possible to... 1) use text only zone files, and 2) keep serials identical between those zone files and what is published in DNS, and 3) automatically handle signatures when adding new RRs, and 4) not have any journal files. Is all of that possible with a(ny)? recent version of Bind9? tia, - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAltsmgYACgkQJxVetMRa JwUWaw/9FU02HPacQQtH6AVhp3IFDlbvCcMgodcxzeYvIrFLiJU0pGUlkg31XqBd T4UZkZViaydmDBpZY2igPvBInF8ZzwrgWdLlpJIFNurdLe67nvptF0qcll+2ExHy 1O4tCK0wG76tOFeiDuB+NQN65227zvTLExGuRTDtYkDo/okqrhfWvmth1soBnuYm dnOXdxfINT8NQpDcpCTXm4pvZzyLbOveRUz6SdWRImLqeQloGhkVBCuLPgJED96J trwvs9HsRnC3YWzGIgbiUDjwovwQU8JWm/73aqcWSX8HDBh/8NBqIozXt4stxDtw nrJuuue3mZx6jD1uGOss84Q5zWNuT0swUebVlXlA4HsfqymBrkr9w6S2lI87m020 X5Ve0fUX7PD+7d0GC5tav6+Jdxccb4m5RMuxZGkSsUssnufyddfSHI9KWf5o7kg0 lPW4Jxk5Wa3NPJI4cKDiuHSoXw60ElkLq5yBNepB1KwlJm2DEsYP0NUmKBrPAdQ4 H7JFD8JFtE6EDEBVOIAHm/LNX5e82FOTsJ7wSoOTwVswtad8q8YM3W0e+LFo8LqC LouN+bNCvAszLY0qeP2iVSCH4GpumyFMbOuXV8EdcRySEMDLvRaSSKF4OviDgvs+ q0zVq1s5CMiXxXZj2RPx3iNiuEGCYq/p0+zV4nyjCuYa8VMZ5qM= =0y5L -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: v9.12.1-P2 changed files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2018-05-19 at 01:03 +, Evan Hunt wrote: > On Fri, May 18, 2018 at 04:28:24PM -0400, Jim Popovitch via bind- > users wrote: > > Honest question Why are there so many sourcecode > > modifications/additions/deletions between v9.12.1 and v9.12.1- > > P2? Some > > files should obviously change between minor versions, but ~1300 ? > > Are you sure you're comparing against 9.12.1? I think you might be > looking at a 9.11 release. The list in your pastebin link mentioned > files in lib/lwres having been removed, but those files weren't in > 9.12.1, they were removed in 9.12.0. Ahhh, Doh! I failed to sync (bzr push) my v9.12.1 build tree to my launchpad archive, so when I branch'ed it to my new dev system I was starting with the v9.11.3 release. The launchpad change log clearly shows this. sigh. rev-26. By Jim Popovitch 10 hours ago Upstream v9.12.1-P2 release rev-25. By Jim Popovitch on 2018-04-28 Upstream v9.11.3 release rev-24. By Jim Popovitch on 2018-01-30 Bind9 v9.11.2-P1 ISC Release > According to the git repo, the only source files that were modified > between 9.12.1 and 9.12.1-P2 are: > > lib/dns/rbtdb.c > lib/dns/zone.c > lib/ns/include/ns/query.h > lib/ns/query.c > > And all other differences are from rebuilding the documentation with > the new version number. I really need to switch my dev env to pull the changes from git. Thanks Evan! - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAlr/wVoACgkQJxVetMRa JwVa+BAAlRx7kR7T5M7NK8lz1DDuA1hcsYSg2MJcslZmdqxudx4BFiegy6pg8HOx RdbiyowO+t4OTCWsndzEt7yiEtyM2vR0ZAbeZAjhhFveWFZROAnQFBnJxePTnVJh kOEb9p1comsdRy2IhqSIVmyZGwFCpU1cB0XkzmAj+yWqA2IAPrWG0/veUv0X+YXi QcT1PVDkgFMSGMXC8oCoT3udqjXrb6zSfHU5L5bU7caRkhpxkYvb9HGwmu9shPe/ XH54wtsTssNZaZX2H+b9NylqsLQRhqzzskYlvZmzu/JYvQToSBUcmOUjnyuJJzOW US1B5gfU8S19EnXT/UxbMz0bal9lAuuzCWtODXiFo8CNgt5mf75lup5g6Y+/XEZr Hd7dsavLgA83VzwkAwuR2JCGMKCOcCF4jL7pxuy+NuIsN31OjTyGJgv/L4aH0leM hj1D28IrJBSGNh4BAAqy1+RIuJyeXfaElI6ZsVYTZvUpsUZp2RjZNETYs1RgwEbR DPDofD8Niiw9ub727xILz1VBdoD02WW6oZcTIHXuerExO+GZ0c6vVMwJV3dxhGF/ jgc8xDCZoXEuwvmMMm6bH+AD77YvYPyL2+vY1C+cPGZ3JWAI7oW09kOLLDyEZ9tl uQFfBSCJBr8QWtvF+zNPpsgr9ZPaPdX96+PSQJZ0LSqFAu88N5c= =LqAT -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
v9.12.1-P2 changed files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Honest question Why are there so many sourcecode modifications/additions/deletions between v9.12.1 and v9.12.1-P2? Some files should obviously change between minor versions, but ~1300 ? Bin9 v9.12.1-P2 changed files: http://paste.debian.net/plainh/470058dd - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAlr/N2gACgkQJxVetMRa JwU02w//bWw5TAoVjmTsMlUJndA7Yd3DM14fsWBMTBGGxKYZjG9JskBOOoGYFrbZ gR+ljJAGEOTRBGYStG6f+M7ocPK9brXVpFiqhGB/cG0ntM9vgczKWC0HjWHvQuZf 3vdqu6hs77fQyxy82mkOeVB/dRCJdbAQWt7I7ezstWhvlYqs+HVJRONimnK/dnID swBa9A4Mn+ln606eW8pBVOAML1jj/Eo+Euo+PMAoT7UfNXIz267uf53heOtMe+hZ NSf71wisYEbG04qbUxeJRgSTGBhb3b4TRYIWLKYm1d0wg75gUApdAsTvPDf9DUpD pmxckTy5feuQt2wXRlrq1yanuXLTHlesfQfTj/Kq4QnAlcC2HxdzVkrc55ogVmmM aVa4NDbwL0Q0FKHVzRjRc3d0xFGy6cHWVDiE02zsEqN0syRCGc9Frhck+P6BpD3O gIwC2WmPDwBkBCGNk91BiGD+yDtz9YR7L4tkHouvbNvkeJ6fYVTnTTSqH9oPfSSF 2q1ENTUrtZT2rrkzlUIFsdFGskOTHyr6KPxyC0ZlRsS+/lOr+SI3fZqyeo8JfZ05 Mmfu2m0YlKRKk4yXcjA1TwPRXCmUN+TfFPRK87aDGaCWTGupbTbFvhpmPWtjYvJi crOw9F7AzPdqzJaPKdu1lZUBPxlwXDk+9OZK1IHVONShhPiluys= =hod6 -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Roadmap for DNSSEC signing/automation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, Is there a roadmap for DNSSEC signing capabilities? I'm specifically wondering if any features are planned to fully automate signing, such as being able to specify simple zone options like "dnssec-cycle=90d;" and having bind9 fully manage this, perpetually. Thx, - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAlqn/MAACgkQJxVetMRa JwUIRhAAmB7SewSVkChuKRMqnZdPAvjA30vXOqQFUUiMD91waGhhzlWIesuL5PfH uU9UrBLp6O2V+tZTAPvnogJeIBa7zm1QB9LXK4wWqhyU+ywu4ADS6Fzt6OFgWL08 y5xXuZK+NxcxjgV7UIj+l8gj4d1zF/i6Cv921FmWshPAQ+TL4Ad+9Ygs3s0ak7AH TnsxsoY9KisHLSdiJRwCxctk2gT3JAg9Lz9bbAdQyolghpc3t+roKznwdq+Le04J Z7yrmzp+GTZ8FyTqxrV4pi0sIa3lXnKvzasbBLal9sLtrxPyiH//q9Qfn4v/KzQI CImw5nnIhGI8lPi2o8nyYLqmjKKdFGfNli6JDRq6sCT/QM+6XVgWMtdbuUllT7hX Ku0ksEYHHZQ9z0VqearNukVaDwGV0KWVKWFHScyRMbQIplLiDAQprvsoIOz+SXsL bhV5ZmspBCkIytGGMvn3L7Y/SXReoi5J4nSnNSH3OtpETu702JvG5Phw+cnu+PLH x+7HEj8iQY+vH6SUgbyUObfHlsTUqNCS0VIvJMEPZ/+KX5G0P1bD8CEgJLirPQjQ raZ7vEu4nG/CdEiAFp2BO0QP5qEikdeIErKF1m2WQX3SbsdETtrgJIIhKvBunmYY RqmGyKlIXBnniMVwYQNTYGMQWU1ZC1B3Y6XB4wAYrKfE3HUAG1A= =QdWK -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: minimal-any on master
On Mon, Sep 05, 2016 at 05:12:47PM +0100, Tony Finch wrote:
> Jim Popovitch via bind-users wrote:
> >
> > Thanks. Now I'm seeing something slighly different. I have 3 NS
> > servers, ns{1-3}.domainmail.org.
> >
> > When I first asked 3 days ago I was seeing long ANY repsonses on the
> > master (ns1). Today I am seeing long ANY responses on ns3 (but not
> > ns1). O.o
> >
> > for ns in ns1 ns2 ns3; do dig ANY domainmail.org @$ns.domainmail.org|wc -c;
> > done
> > 591
> > 610
> > 13280
>
> OK, this is SUBTLE.
>
> minimal-any is a bit stupid: it just hands out the first RRset it gets
> out of the guts of BIND without any attempt to choose the smallest or
> otherwise choose an RRset consistently. This means you will get different
> answers from different servers depending on how the zone has changed
> recently - especially if there is churn due to DNSSEC re-signing.
>
> So it is expected that you will get answers of varying sizes. But why such
> a huge variation in this case?
>
> Well, minimal-any doesn't apply to queries over TCP - you get the full
> unexpurgated ANY response over TCP. So, if you use `dig +tcp` you will get
> the huge answer from all your servers. If you use `dig +ignore` (i.e.
> ignore truncation) you will prevent dig from switching from UDP to TCP, so
> you should get a more reliable indication that minimal-any is actually
> working.
>
> Now why are you getting a truncated response?
>
> If I look at the RRsets at the apex of your zone, most of them are pretty
> small, but the DNSKEY RRset is huge. (See script below.) So if your server
> happens to choose the DNSKEY RRset as its response to ANY, that might lead
> to TC and retry over TCP.
Thank you for detailing that Tony, I now have a better understanding.
>
> Your DNSKEY RRset is huge because you have four keys (two KSKs and two
> ZSKs) and four RRSIGs (one for each key).
I call that "full mesh"! :-)
> You can reduce this a bit by setting dnssec-dnskey-kskonly in named.conf.
> This tells BIND to only use KSKs to sign the DNSKEY RRset, which would
> reduce you from 4 signatures to 2.
Done. Thank you for suggesting that.
> You can also be careful when setting up your key rollovers so that only
> one key is active at a time, which would reduce you to 1 signature.
Hmmm, this is counter to what I've believed all along. I thought it was
prudent to have key overlap during rollovers. Or are saying only do ZSK
rollovers well after the KSK rollover has settled?
> And you can avoid rolling ZSK and KSK at the same time, so you only have 2
> or 3 DNSKEY records.
>
Yes, the current situation is due to unfortunate timing.
-Jim P.
signature.asc
Description: Digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: minimal-any on master
On Mon, Sep 05, 2016 at 09:51:25AM +0100, Tony Finch wrote:
> Jim Popovitch via bind-users wrote:
> >
> > Should minimal-all (v9.11.0-rc1) work on a master? My testing shows
> > that it only works on the slave DNS servers.
>
> Works for me :-) minimal-any is implemented at the point the records are
> being assembled into an answer - it still does all the usual ANY
> processing, but just omits all but the first RRset. So it isn't even aware
> of whether the records are from the cache or authoritative, let alone what
> type of authoritative zone they might be from.
>
Hmmm.
Thanks. Now I'm seeing something slighly different. I have 3 NS servers,
ns{1-3}.domainmail.org.
When I first asked 3 days ago I was seeing long ANY repsonses on the master
(ns1). Today I am seeing long ANY responses on ns3 (but not ns1). O.o
for ns in ns1 ns2 ns3; do dig ANY domainmail.org @$ns.domainmail.org|wc -c; done
591
610
13280
-Jim P.
signature.asc
Description: Digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: minimal-all on master
On Fri, Sep 02, 2016 at 06:59:35PM +, Jim Popovitch via bind-users wrote: > Hello, > > Should minimal-all (v9.11.0-rc1) work on a master? My testing shows that it > only works on the slave DNS servers. > And by minimal-all I mean minimal-any (i keep typo'ing that for some reason today) :-) -Jim P. signature.asc Description: Digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
minimal-all on master
Hello, Should minimal-all (v9.11.0-rc1) work on a master? My testing shows that it only works on the slave DNS servers. relevant named.conf: http://paste.debian.net/plainh/62ee2440 -Jim P. signature.asc Description: Digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
