Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8
> > On 21 Oct 2022, at 12:23, Ondřej Surý wrote: > > > > What you are really saying that we should dance how tech giants whistle, > > and I don’t think succumbing to tech giants is a good strategy long term. > > Not at all and I agree with you. > > But tell your customer that their email message didn’t arrive on time because > the recipient has a misconfigured DNS server and > try to explain to them that, yes, Google resolved it successfully but you are > working for the common good. > > But wasn't it exactly the idea with the 2019 DNS Flag Day campaign? http://www.dnsflagday.net/2019/ I see Google's name there, so I would expect their commitment to refuse to solve incorrect domains. They do a skinny favor to all the Internet by returning to the workarounds, and blaming those who do well (as Bind 9.18) Hugo 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: What action to take first with DS algorithm migration?
On 11:23 14/09, frank picabia wrote: > Hi, > > I'm at the point in DNSSEC algorithm migration > where I have two types of keys involved in signing. > Both algorithm 7 and 8 are in use. > > The top level domain registrar also has DS keys set up for both 7 and 8. > > I need to coordinate pulling out algorithm 7 with the domain registrar so > our domain will be running against only algo 8. > > Should the TLD registrar remove 7 first, or should I remove signing of zone > with the algo 7 keys before they make their change? > > I noticed that when I tried removing signing with the algo 7 keys, and > checked > the DNS state at https://dnsviz.net/d/acadiau.ca/dnssec/ > > I saw errors at the analyzer like this: > > The DS RRset for the zone included algorithm 7 (RSASHA1NSEC3SHA1), but no > RRSIG with algorithm 7 covering the RRset was returned in the response. > > I'm not sure if that would be a crippling error to DNS functionality > if I didn't reverse removal of algo 7 signing, which I've done after seeing > this. > > Can I do removal of algo 7 at one side prior to the > other (Bind signing vs TLD Registrar side), > or do we have to try to coordinate this with the TLD > registrar as closely as possible? If you already have the two DS at your parent, the next step is removing the old DS, then wait, then remove the old KSK (but still have the old ZSK and old signatures), then wait, then remove everything from the old algorithm. For adding a new DS is the other way around. You first add the new ZSK + signatures, then the KSK, then the DS at your parent. Here's an step by step method, in spanish, but hopefully the diagrams are self explanatory: https://hugo.salga.do/post/615501933278642176/c%C3%B3mo-hacer-un-rollover-de-algoritmo-en-dnssec Hugo 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 rookie question
On 16:48 10/01, Danilo Godec via bind-users wrote: > Hello, > > > today I implemented DNSSEC for a domain - by that I mean that the DS records > have been published / added to TLD DNS today, while the zone has been signed > a couple of days ago. > > > So a couple of hours later I went to https://dnsviz.net to see if everything > seems OK and it reports one error and a couple of warnings. The error is: > > > RRSIG sid.si/NSEC3PARAM alg 13, id 48018: The TTL of the RRset (3600) exceeds > the value of the Original TTL field of the RRSIG RR covering it (0). > > > But if I use /dig/ for, I get this: > > ;; ANSWER SECTION: > sid.si. 3600IN NSEC3PARAM 1 0 10 - > sid.si. 3600IN RRSIG NSEC3PARAM 13 2 0 > 20220205091303 20220106091303 48018 sid.si. > WVstsjBLSQNS+PaKbR3LAAALG7tlV+cuzLYUKgWDXKrFnxe+dxx5Tmsa > pYIrabwi/sANBgEBMHtW1Z3NS7hRow== > > > Both records show TTL 3600 - which should be OK, I think? Where does > dnsviz.net get that TTL 0? > That TTL is inside the rdata for the RRSIG. It says "... NSEC3PARAM 13 2 *0* ...". That 0 is the "original TTL" for the record. So currently there's an inconsistency between the 3600 declared in the TTL of the rrset, and the "original TTL" in the RRSIG. Hugo signature.asc Description: PGP signature ___ 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) Re: Change records in DNS slave if master is offline
On 05:12 19/12, Richard Doty wrote:
> Having text files makes editing easier, but you still want to keep the
> slaves the same - making the identical edit multiple times is some work,
> but may not actually happen depending on circumstances (people make
> mistakes)
>
> I like to make all the servers 'masters' - so whoever has the highest
> serial number wins. Then if you update one slave, it is automatically
> synced to the others. This might conflict with however you populate your
> true master.
An architecture that can be useful is that of the "hidden primary",
widely used in certain places.
The idea is to have one (or several) primary servers that are the
origins of the zone and of changes, that are only to serve to the
secondaries, and are not public nor published in NS records; and all
those that are public (those that appear as NS) are secondary to these
primary ones.
That way you separate the functions. You can have the primary ones as
a backup of each other, and synchronize the zone with some mechanism
outside of DNS. And you can protect them to only answer queries and
AXFR from the secondaries (since they are not public). In the secondary
ones you can use "multi-master" (or maybe it is called "multi-primary
now") so that they use any of the hidden ones.
Hugo
>
> On Fri, Dec 17, 2021 at 6:30 AM Roberto Carna
> wrote:
>
> > Warren, thanks a lotwith the masterfile-format clause it works OK.
> >
> > Greetings!!!
> >
> > El jue, 16 dic 2021 a las 15:43, Warren Kumari ()
> > escribió:
> > >
> > >
> > >
> > > On Thu, Dec 16, 2021 at 10:37 AM Roberto Carna
> > wrote:
> > >>
> > >> Dear all, I have one BIND9 server as master and 3 as slaves.
> > >>
> > >> The master and one slave are in a given site #1, and the other two
> > >> slaves are in a geographical different site #2.
> > >>
> > >> In case site #1 goes offline, I need to edit records in both slaves
> > >> from site #2, in order to point some services to other public IP's for
> > >> contingency.
> > >>
> > >> My question is:
> > >>
> > >> What is the recommended way to edit the records from a BIND9 slave?
> > >> Because the zone files are binary files
> > >
> > >
> > > Yup, if you are running (IIRC) > v9.9.x, the default is binary files.
> > > You can convert these beck to text with:
> > > named-compilezone -f raw -F text -o example.com.text example.com
> > example.com.binary
> > >
> > > You can also change the default in named.conf:
> > > options {
> > > // many many options
> > > masterfile-format text;
> > > //
> > > // many other options
> > > //
> > > }
> > >
> > > The raw (binary) zone files are good for large zones, but for small
> > zones, where speed isn't super important, text format works just fine...
> > > W
> > >
> > >
> > >>
> > >> and using the Webmin interface
> > >> is blocked.
> > >>
> > >> The only manner is changing the configuration from slave to master?
> > >>
> > >> Thanks in advance, greetings!!!
> > >> ___
> > >> 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
> > >
> > >
> > >
> > > --
> > > The computing scientist’s main challenge is not to get confused by the
> > > complexities of his own making.
> > > -- E. W. Dijkstra
> > ___
> > 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
> >
> ___
> 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
signature.asc
Description: PGP signature
___
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
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 > signature.asc Description: PGP signature ___ 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: Broken signatures on packages.sury.org
I found just today the same expiration of Ondrej key with some Debian php packages. Was solved downloading the new one: https://www.patreon.com/posts/dpa-new-signing-25451165 Hugo On March 17, 2021 8:20:13 PM GMT-03:00, Mark Andrews wrote: >I’ve pinged Ondrej but he is likely asleep as he is based in Europe. > >> On 18 Mar 2021, at 10:15, Matthew Pounsett wrote: >> >> Beginning today, I'm seeing the following errors on systems that use >> the ISC Debian packages: >> >> Err:5 https://packages.sury.org/bind buster InRelease >> The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 >> DEB.SURY.ORG Automatic Signing Key >> >> I haven't seen any official word from ISC that there are new keys to >> grab, so wanted to check that someone isn't messing about with your >> repository. >> __ > >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > >___ >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 ___ 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: can bind support DOH and DoT (and broken mailing list archive)
On 12:01 02/06, Tony Finch wrote: > ShubhamGoyal wrote: > > > > 1. Can bind support DoH and DoT > > There was more discussion in May but unfortunately the mailing list > archive seems to have got into a muddle so the messages aren't available > https://lists.isc.org/mailman/htdig/bind-users/2020-May Luckily there are copies in marc.info: https://marc.info/?l=bind-users=158812740225333=2 Hugo signature.asc Description: PGP signature ___ 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: Vim Syntax, New Release for ISC Bind named.conf 5.16
Thanks a lot Steve, works like a charm! It's nice to have well formatted SSHFP records at last! :) Regards, Hugo Salgado On 14:32 22/04, Steve Egbert wrote: > Hello, Bind-Users, > > > This is my 2nd post (in 19 years). > > I'm announcing the release of ISC Bind v9.16 named.conf syntax file for Vim > editor. > > Yeah, the last one is the Vim stock 'named.conf' syntax and probably works > marginally today as it was written for Bind 9.4-9.5. > > No auto-installer yet. I'll take pull request for that if you think it's > worth it. > > https://github.com/egberts/vim-syntax-bind-named.git > > Or you can execute: > > git clone https://github.com/egberts/vim-syntax-bind-named.git > > The color scheme is derived from default Vim highlights using your own color > scheme. > > Have it, folks! I hope you enjoyed it as much as I did > > > Cordially, > > S. Egbert > ___ > 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 > signature.asc Description: 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: Should we remove the DLV code?
Last year I was involved in a project to allow the signing of domains in the second level of a country, when the TLD has signed yet. It's a reality in certain regions. I get it that the idea is to put pressure on the TLD, but this institution was the largest ISP in the country and considered that it was better pressure to begin to sign and validate. The best technology was DLV. We started doing some prototypes, but finally (and perhaps because of these conversations) the TLD began its DNSSEC deployment. The project is sleeping, waiting for the TLD finally signing, or to be reactivate if time passes. One important thing is that the "islands of security" concept may be necessary in different places (companies? communities?) and the DLV technique is not limited to the root. For the same reason I consider that Bind's support is vital. On the other hand, could improve things if it were a module that must be activated in compilation, for example? That would reduce the risks in default Bind. And the participants of an eventual DLV would have to consciously compile and activate it. Maybe is it a good compromise? Finally, if the plan is to deprecate DLV as a technique, perhaps a better way is to move 4431 to historical, and then remove it from the code. Hugo On 14:36 21/05, Warren Kumari wrote: > At this point I think DLV is actively dangerous -- I'm not sure if it > "easy" to remove the code without too much risk, but an initial start > would be to make it impossible^whard to enable it (and initially log > an error message for people who already have it configured...). > > W > > On Tue, May 21, 2019 at 2:34 PM Matthijs Mekking wrote: > > > > Hi Grant, > > > > On 5/20/19 11:44 PM, Grant Taylor via bind-users wrote: > > > On 5/20/19 4:34 AM, Matthijs Mekking wrote: > > >> * It will make the code much easier to maintain, which is beneficial > > >> for users too since that will mean in general less bugs, easier to > > >> find bugs, and easier to extend it with new features. > > > > > > Drive by 2¢ comment: > > > > > > Is the existing DLV code causing a problem or otherwise breaking > > > something? > > > > Not actively, but in general it adds more corner cases, which make it > > harder to investigate potential bugs in validation behavior. > > > > > How much easier will removing the DLV code make maintaining the rest of > > > the code base? > > > > Hard to say, but quoting my colleague "about 50%". > > > > > > > Is the existing DLV code preventing doing something else that is desired? > > > > Not preventing, but it is something that we need to take into account > > every time we touch the validation code, and so there is a maintenance cost. > > > > > > > IMHO if the code is sitting there and not actively causing problems, > > > despite being unsightly, then I'd be inclined to leave it. If it's > > > anything more than unsightly, I'd pontificate removing it. > > > > Thanks for your input. > > > > Best regards, > > > > Matthijs > > > > > > > > > > > > > > > > > > > ___ > > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > > > unsubscribe from this list > > > > > > bind-users mailing list > > > bind-users@lists.isc.org > > > https://lists.isc.org/mailman/listinfo/bind-users > > > > > ___ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > > unsubscribe from this list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. >---maf > ___ > 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 signature.asc Description: 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: KSK Rollover
Hi Brent. In out CentOS box, the named.secroots file is written on /var/named/ You should check permissions there too. Hugo On 20:32 06/09, Brent Swingle wrote: > Evan, > > I ran the command and followed the directions to build out rndc as you have > suggested. However, I am not sure that it made much of a difference. I > should have been a little clearer from the beginning. I had worked with rndc > to issue other commands and had received what appeared to be valid responses > as if rndc was functional. I had somewhat assumed that rndc was baked in > behind the scenes and ready to go. Either way I it has a rndc.conf and is > specified in named.conf at this point. > > I have two of these servers that are identical from an SW perspective. As a > test, I issued "rndc secroots" on the server that I have modified to > configure rndc and observed the following lines appear in the > /var/log/messages file. When I issued "rndc secroots" from the non-modified > file I get the same 3 lines. It acts like the process is running but it is > unable to write output to the named.secroots file. > > Sep 6 14:33:13 ns2 named[31189]: received control channel command 'secroots' > Sep 6 14:33:13 ns2 named[31189]: could not open secroots dump file > 'named.secroots': permission denied > Sep 6 14:33:13 ns2 named[31189]: dumpsecroots failed: permission denied > > > As a test, I manually created named.secroots with weakened permissions to see > if that made a difference but it still won't print output to it. > [root@ns3 etc]# ls -lh named.secroots > -rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots > > > > -Original Message- > From: Evan Hunt [mailto:e...@isc.org] > Sent: Thursday, September 06, 2018 1:22 PM > To: Brent Swingle > Cc: bind-users@lists.isc.org > Subject: Re: KSK Rollover > > On Thu, Sep 06, 2018 at 05:34:21PM +, Brent Swingle wrote: > > This is the command that does not work and the output received: > > [root@ns2 ~]# rndc secroots > > rndc: 'secroots' failed: permission denied > > [root@ns2 ~]# > > Have you set up your server to accept rndc commands? > > If not, run "rndc-confgen" and follow the directions. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > > ___ > 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 > signature.asc Description: 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] Why log a failed transfer successfully?
On 04/02/2015 05:01 AM, Anand Buddhdev wrote: I'm parsing BIND logs to extract the XFR size in bytes of a zone, and was just bitten by this sequence: 02-Apr-2015 04:27:10.393 xfer-in: transfer of './IN' from 2001:67c:2e8:5::c100:c6#53: failed to connect: timed out 02-Apr-2015 04:27:10.393 xfer-in: transfer of './IN' from 2001:67c:2e8:5::c100:c6#53: Transfer completed: 0 messages, 0 records, 0 bytes, 62.999 secs (0 bytes/s ec) So BIND wasn't even able to connect to the master, but subsequently logged Transfer completed. Is there any logic to this that I'm missing? I want to support (if that was Anand's original idea) a better log line in this case. We host several thousand zones as secondary service, and provide log access to customers. I estimate a couple of questions per week in our helpdesk about people assuming that the transfers are working, overlooking exactly that line. Thanks, Hugo ___ 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: DNSSEC key rollover problems
On 12/28/2011 10:42 PM, Spain, Dr. Jeffry A. wrote: First of all is it correct that the time stamps shown by dig for RRSIG records are in local time? Otherwise, if the time stamps show UTC, then the RRSIG for jaspain.net SOA for ZSK 42152 was generated at 2011121023, one hour prior to that key’s activation. The timestamps are always in UTC. The hour in advance is called the inception time, and is a good practice to sign a record with an inception time in the past. That way you allow it to be validated even with resolvers with not a perfect clock synchronization. Hugo ___ 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: Spaces in keys
On 11/17/2010 05:01 PM, Thomas Schulz wrote: When I copied the key for root from http://www.isc.org/community/blog/201007/using-root-dnssec-key-bind-9-resolvers I ended up with spaces in the key. I assumed that they should not be there and removed them. I since noticed that the key in /etc/bind.keys supplied with the bind distribution has spaces in it. Should the spaces be there or does it not matter? It doesn't matter. From RFC4034 (Resource Records for the DNS Security Extensions), section 2.2 (The DNSKEY RR Presentation Format): The Public Key field MUST be represented as a Base64 encoding of the Public Key. Whitespace is allowed within the Base64 text. For a definition of Base64 encoding, see [RFC 3548]. Hugo ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: is it possible to dynamically update an RRSIG record?
Jack Tavares wrote: Looking at the code for libbind, specifically res_nmkupdate, there is no case statement for RRSIG records. In this case, I was trying to update the TTL. Is that not allowed intentionally? I think so. The TTL of a RRSIG RR *MUST* match the TTL value of the RRset it covers. Hugo ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
