Re: procedure for re-signing zones on nsec3param change, when using dnssec-policy full automation?

2022-10-20 Thread Petr Špaček 

On 19. 10. 22 19:48, Mark Andrews wrote:

Just reload the server.



On 20 Oct 2022, at 01:45, PGNet Dev  wrote:



with the does the DS record need to be touched? i.e., will the changed to 
nsec3param change the zone's KSK?


Let me add that no, DS record is not affected at all by NSEC or NSEC3.

--
Petr Špaček

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

FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-20 Thread Andreas S. Kerber 
I've just finished upgrading our last resolver from 9.16 to 9.18.8 a few days 
ago.
As it turn out a number of zones are no longer resolveable with 9.18. Some 
nameservers out there don't seem to support EDNS0 and the number of FORMERR 
responses in our resolver logs went up quite a bit.  Here's an example:


zone bemacom.se when querying a 9.18.8 resolver (status: SERVFAIL):

# dig bemacom.se @213.182.0.X

; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25874


zone bemacom.se when querying a 9.16.34 resolver:

# dig bemacom.se @213.182.0.X

; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5496



The NS for bemacom.se seem to be dnsX.elbrev.com and I'm seeing FORMERR 
messages in the BIND 9.18.8 logs:

Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53


According to dnscheck.ripe.net the zones NS don't support EDNS0: 
https://dnscheck.ripe.net/result/93ee1d56756536dd

I could manually fix this by adding those IP adresses with a server statement 
to named.conf like this: "server x.x.x.x { edns no; };"
Since this is only one a example of about 10 so far, I chose to downgrade one 
of my resolvers back to 9.16.X, to catch those faulty zones.

Of course I would prefer to upgrade back to 9.18.X, but I guess I won't be able 
to find all EDNS0 incompatible servers and loosing customers to 8.8.8.8 - which 
is able to resolve these names..



-- 
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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-20 Thread Ondřej Surý 
Hi,

did you try writing to elbrev.com  operators to fix their 
servers to stop breaking DNS protocol? It often helps. (I'm ccing the contact 
in their SOA records, so let's see if anything happens.)

It's not lack of EDNS0 support, but they fail to properly process unknown EDNS0 
options - DNS Cookie in this specific example:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 57723
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ec9c994f850fe500 (echoed)

vs

ondrej@howl:~/Projects/bind9 (v9_18 $%=)$ bin/dig/dig +norec +noall +comments 
+nocookie bemacom.se @dns1.elbrev.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16277
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000

Their servers are clearly violating existing DNS standards: 
https://ednscomp.isc.org/ednscomp/11fd9e2e46 


> Of course I would prefer to upgrade back to 9.18.X, but I guess I won't be 
> able to find all EDNS0 incompatible servers and loosing customers to 8.8.8.8 
> - which is able to resolve these names..


This is kind of moot argument - the DNS needs to evolve, and it can't evolve if 
we keep supporting broken stuff. This needs to be fixed on the authoritative 
operator side, not in BIND 9.

Cheers,
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

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

> On 20. 10. 2022, at 13:09, Andreas S. Kerber  wrote:
> 
> I've just finished upgrading our last resolver from 9.16 to 9.18.8 a few days 
> ago.
> As it turn out a number of zones are no longer resolveable with 9.18. Some 
> nameservers out there don't seem to support EDNS0 and the number of FORMERR 
> responses in our resolver logs went up quite a bit.  Here's an example:
> 
> 
> zone bemacom.se when querying a 9.18.8 resolver (status: SERVFAIL):
> 
> # dig bemacom.se @213.182.0.X
> 
> ; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25874
> 
> 
> zone bemacom.se when querying a 9.16.34 resolver:
> 
> # dig bemacom.se @213.182.0.X
> 
> ; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5496
> 
> 
> 
> The NS for bemacom.se seem to be dnsX.elbrev.com and I'm seeing FORMERR 
> messages in the BIND 9.18.8 logs:
> 
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:55 fro

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-20 Thread Andreas S. Kerber 
Am Thu, Oct 20, 2022 at 01:23:47PM +0200 schrieb Ondřej Surý:
> did you try writing to elbrev.com  operators to fix their 
> servers to stop breaking DNS protocol? It often helps. (I'm ccing the contact 
> in their SOA records, so let's see if anything happens.)
>
> It's not lack of EDNS0 support, but they fail to properly process unknown 
> EDNS0 options - DNS Cookie in this specific example:

Hi Ondřej,

thanks for your quick reply and analysis regarding DNS cookies.
Is there maybe an option to configure 9.18 to act as if it was 9.16 in this 
regard?
Honestly I haven't contacted the elbrev.com people (see below).


> > Of course I would prefer to upgrade back to 9.18.X, but I guess I won't be 
> > able to find all EDNS0 incompatible servers and loosing customers to 
> > 8.8.8.8 - which is able to resolve these names..
> This is kind of moot argument - the DNS needs to evolve, and it can't evolve 
> if we keep supporting broken stuff. This needs to be fixed on the 
> authoritative operator side, not in BIND 9.

You're absolutely right. I guess I've just kind of given up on convincing other 
people the fix their stuff (dayjob trauma). Sorry about that.
-- 
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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-20 Thread Ondřej Surý 
https://bind9.readthedocs.io/en/v9_18_8/chapter9.html?highlight=cookie

--
Ondřej Surý (He/Him)
ond...@isc.org

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

> On 20. 10. 2022, at 13:49, Andreas S. Kerber  wrote:
> 
> Am Thu, Oct 20, 2022 at 01:23:47PM +0200 schrieb Ondřej Surý:
>> did you try writing to elbrev.com  operators to fix 
>> their servers to stop breaking DNS protocol? It often helps. (I'm ccing the 
>> contact in their SOA records, so let's see if anything happens.)
>> 
>> It's not lack of EDNS0 support, but they fail to properly process unknown 
>> EDNS0 options - DNS Cookie in this specific example:
> 
> Hi Ondřej,
> 
> thanks for your quick reply and analysis regarding DNS cookies.
> Is there maybe an option to configure 9.18 to act as if it was 9.16 in this 
> regard?
> Honestly I haven't contacted the elbrev.com people (see below).
> 
> 
>>> Of course I would prefer to upgrade back to 9.18.X, but I guess I won't be 
>>> able to find all EDNS0 incompatible servers and loosing customers to 
>>> 8.8.8.8 - which is able to resolve these names..
>> This is kind of moot argument - the DNS needs to evolve, and it can't evolve 
>> if we keep supporting broken stuff. This needs to be fixed on the 
>> authoritative operator side, not in BIND 9.
> 
> You're absolutely right. I guess I've just kind of given up on convincing 
> other people the fix their stuff (dayjob trauma). Sorry about that.

-- 
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: procedure for re-signing zones on nsec3param change, when using dnssec-policy full automation?

2022-10-20 Thread PGNet Dev 

On 19. 10. 22 19:48, Mark Andrews wrote:

Just reload the server.


+1


with the does the DS record need to be touched? i.e., will the changed to 
nsec3param change the zone's KSK?


Let me add that no, DS record is not affected at all by NSEC or NSEC3.


dnssec-policy management is doing a nice job of making this easy! even if not 
always clear to me in the docs

after the config edit, and reload,

dig example.com nsec3param
...
;; ANSWER SECTION:
exmaple.com.  5   IN  NSEC3PARAM 1 0 0 -
...

and, NO upstream DS RECORD update, all my functional checks seem, so far, to be 
passing.

thx!


--
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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-20 Thread Mark Andrews 


> On 20 Oct 2022, at 22:49, Andreas S. Kerber  wrote:
> 
> Am Thu, Oct 20, 2022 at 01:23:47PM +0200 schrieb Ondřej Surý:
>> did you try writing to elbrev.com  operators to fix 
>> their servers to stop breaking DNS protocol? It often helps. (I'm ccing the 
>> contact in their SOA records, so let's see if anything happens.)
>> 
>> It's not lack of EDNS0 support, but they fail to properly process unknown 
>> EDNS0 options - DNS Cookie in this specific example:
> 
> Hi Ondřej,
> 
> thanks for your quick reply and analysis regarding DNS cookies.
> Is there maybe an option to configure 9.18 to act as if it was 9.16 in this 
> regard?
> Honestly I haven't contacted the elbrev.com people (see below).
> 
> 
>>> Of course I would prefer to upgrade back to 9.18.X, but I guess I won't be 
>>> able to find all EDNS0 incompatible servers and loosing customers to 
>>> 8.8.8.8 - which is able to resolve these names..
>> This is kind of moot argument - the DNS needs to evolve, and it can't evolve 
>> if we keep supporting broken stuff. This needs to be fixed on the 
>> authoritative operator side, not in BIND 9.
> 
> You're absolutely right. I guess I've just kind of given up on convincing 
> other people the fix their stuff (dayjob trauma). Sorry about that.

It’s also a very small percentage of servers that are broken.  If you look at 
the time series
on https://ednscomp.isc.org/ you can drill done and see the values.  For 
example there are a
little over 10 servers for all zones in .GOV that exhibit this broken 
behaviour.  It’s gone
from ~11% in 2014 to 0.26% currently.  We are at the mop up stage.  For some 
other populations
we are at 0%.

The EDNS specification was updated in April 2013 to specify some unspecified 
behaviour.  In
particular this was added.

   Any OPTION-CODE values not understood by a responder or requestor
   MUST be ignored.  Specifications of such options might wish to
   include some kind of signaled acknowledgement.  For example, an
   option specification might say that if a responder sees and supports
   option XYZ, it MUST include option XYZ in its response.


Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

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


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