Re: [DNSSEC] testing KASP
Only if KSK has DSState: rumoured. If the DSState is hidden it means
that it is not expected to be in the parent (for example because the
DNSKEY has not yet been fully propagated).
> Do you need to withdraw the old key too immediatly ? anything else to do ?
>>> Do you mean withdraw the old DS?
Yes, the old DS should be not yet withdraw because some RRSIG could be
still valid ? or can i withdraw the old DS / KSK immediatly ?
In my logic :
For each file en .state
If is KSK with "DSState: rumoured" or "DSState: hidden"
If not in my registar (dig ds +dnssec +multiline)
Publish on my Registar(api register)
Notify Bind(bind rndc dnssec -checkds -key
published )
Notify Bind(bind rndc dnssec -checkds -key
withdraw )
In my understanding, i shouldn't do "Notify Bind(bind rndc dnssec -checkds
-key withdraw )" and wait until all RRSIG sign (with
the old KSK) expire. In that case, how can i check this ? (some dig command
? or check state file for "DSState: unretentive" ?)
regards,
Adrien
Le ven. 17 mai 2024 à 15:13, Matthijs Mekking a écrit :
> Hi,
>
> On 5/16/24 14:02, adrien sipasseuth wrote:
> > Hello,
> >
> > I try to set up a testing environment in order to create some scripts
> > for automated the roll over KSK.
> >
> > # question 1 #
> > this is my policy :
> >
> > dnssec-policy "test" {
> > keys {
> > ksk lifetime P3D algorithm ecdsa256 2048;
> > zsk lifetime P1D algorithm ecdsa256 2048;
> > };
> >
> > // Key timings
> > purge-keys P4D;
> >
> > // Signature timings
> > signatures-refresh PT50M;
> > signatures-validity PT1H;
> > signatures-validity-dnskey PT1H;
> >
> > // Zone parameters
> > max-zone-ttl PT1H;
> > parent-ds-ttl PT1H;
> >
> > };
> >
> > I would like automaticly update new DS to my registar, to do it this my
> > logic :
> >
> > For each file en .state
> > If is KSK with "DSState: rumoured" or "DSState: hidden"
> > If not in my registar (dig ds +dnssec +multiline)
> > Publish on my Registar(api register)
> > Notify Bind(bind rndc dnssec -checkds -key published
> > )
>
> Only if KSK has DSState: rumoured. If the DSState is hidden it means
> that it is not expected to be in the parent (for example because the
> DNSKEY has not yet been fully propagated).
>
>
> > Do y need to withdraw the old key too immediatly ? anything else to do ?
>
> Do you mean withdraw the old DS?
>
> I would use similar logic but then use "unretentive" instead of
> "rumoured". Following the example above:
>
> For each file en .state
>If is KSK with "DSState: unretentive"
>If in my registar (dig ds +dnssec +multiline)
>Withdraw on my Registar(api register)
>Notify Bind(bind rndc dnssec -checkds -key withdrawn
>
>
> > # question 2 #
> > If i want to unsigned a zone, i change my policy to "insecure" which is
> > default but file like .signed still exist, Bind doesn't remove
> it ?
>
> Correct. If all DNSSEC records have been removed, it is safe to remove
> the "dnssec-policy" configuration from your named.conf and then remove
> the .signed file.
>
> Unsigning your zone also takes time.
>
>
> > # question 3 #
> >
> > In state file, when the remove date issue, can i just remove the key,
> > anything else to do ?
>
> When all states are "hidden" it is safe to remove the key.
>
> Best regards,
>
> Matthijs
>
>
> > Regards,
> > Adrien SIPASSEUTH
> >
> >
> >
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: CNAME and IPv6
On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote: rinetd manages 2 separate connections and should work with PMTUD. On 28.05.24 22:17, Peter wrote: I'm wondering how it would. The connections are TCP, the PMTU works via ICMP6. No, Path MTU discovery works with TCPv4 using ICMPv4 as well. (although it was/is quite common to block ICMP packets which can make it not work properly) So I would assume, the ICMP "packet too big" message reaches the host where rinetd runs, is swallowed by the kernel, and the kernel sets the MTU in it's hostcache. Or something along that line. The TCP traffic however gets forwarded by rinetd to the internal appserver(s) - which never get the message that they should reduce their MTU. The data from one TCP connection are sent through another TCP connection, where both connections are separate with separate MTU and PMTUD. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows 2000: 640 MB ought to be enough for anybody -- 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] testing KASP
On 29. 05. 24 11:31, adrien sipasseuth wrote: Only if KSK has DSState: rumoured. If the DSState is hidden it means that it is not expected to be in the parent (for example because the DNSKEY has not yet been fully propagated). > Do you need to withdraw the old key too immediatly ? anything else to do ? >>> Do you mean withdraw the old DS? Yes, the old DS should be not yet withdraw because some RRSIG could be still valid ? or can i withdraw the old DS / KSK immediatly ? In my logic : For each file en .state If is KSK with "DSState: rumoured" or "DSState: hidden" If not in my registar (dig ds +dnssec +multiline) Publish on my Registar(api register) Notify Bind(bind rndc dnssec -checkds -key published ) Notify Bind(bind rndc dnssec -checkds -key withdraw ) In my understanding, i shouldn't do "Notify Bind(bind rndc dnssec -checkds -key withdraw )" and wait until all RRSIG sign (with the old KSK) expire. In that case, how can i check this ? (some dig command ? or check state file for "DSState: unretentive" ?) I think the best approach is to enable "checkds" feature and leave it up to BIND to decide when it's safe to do next state transition. There should not be a need to do the rndc magic. See https://bind9.readthedocs.io/en/latest/reference.html#automated-ksk-rollovers and also https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-parental-agents I hope it helps. -- Petr Špaček Internet Systems Consortium -- 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
issue with forwarder zones
My bad - I'd mailed this mistakenly to an individual and not the list. --- I am currently running BIND 9.18.18-0ubuntu0.22.04.2-Ubuntu. I am sometimes seeing that I don't have resolution for some FQDN in forwarder zones. Usually it works, sometimes I don't get resolution. Interesting I failed resolution for an FQDN yesterday and while relieved to see that I failed to get resolution on the authoritative server I later was able to resolve on the authoritative server but still failed on the local forwarding server. Wondering what is going on there. Conjecture - caching the failed response for some period of time? If so, disable caching for the problematic forwarder zone? Some other issue? If so what might it be, how can I test for it and how do I resolve/work-around it? Thanks in advance, Brian Brian R Cuttler System and Network Administrator Wadsworth Center, New York State Department of Health Empire State Plaza Corning Tower, Sublevel D-280, Albany NY 12237 518 486-1697 (O) 518 redacted (C) brian.cutt...@health.ny.gov https://www.wadsworth.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: issue with forwarder zones
Hi Brian. We're going to need some details please, like for starters: - What's the domain being queried? - A network diagram showing where your BIND server is and what it's forwarding to. - IP addresses of everything. - A packet capture (binary pcap format, not a snippet or a screenshot) from your BIND server showing both client->server and server->forwarder DNS traffic, crucially capturing the moment this issue occurs. - dig results from your making test queries. It may sound like a lot of detail, but the devil... as they say. Cheers, Greg On Wed, 29 May 2024 at 21:48, Cuttler, Brian R (HEALTH) via bind-users < bind-users@lists.isc.org> wrote: > My bad - I'd mailed this mistakenly to an individual and not the list. > > --- > > I am currently running BIND 9.18.18-0ubuntu0.22.04.2-Ubuntu. > > I am sometimes seeing that I don't have resolution for some FQDN in > forwarder zones. > > Usually it works, sometimes I don't get resolution. Interesting I failed > resolution for an FQDN yesterday and while relieved to see that I failed to > get resolution on the authoritative server I later was able to resolve on > the authoritative server but still failed on the local forwarding server. > > Wondering what is going on there. > > Conjecture - caching the failed response for some period of time? > If so, disable caching for the problematic forwarder zone? > > Some other issue? If so what might it be, how can I test for it and how do > I resolve/work-around it? > > Thanks in advance, > Brian > > > Brian R Cuttler > System and Network Administrator > Wadsworth Center, New York State Department of Health > Empire State Plaza > Corning Tower, Sublevel D-280, Albany NY 12237 > 518 486-1697 (O) > 518 redacted (C) > brian.cutt...@health.ny.gov > https://www.wadsworth.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 > -- 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: CNAME and IPv6
On Wed, May 29, 2024 at 12:20:09PM +0200, Matus UHLAR - fantomas wrote: ! > On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote: ! > > rinetd manages 2 separate connections and should work with PMTUD. ! ! On 28.05.24 22:17, Peter wrote: ! > I'm wondering how it would. The connections are TCP, the PMTU works ! > via ICMP6. ! ! No, Path MTU discovery works with TCPv4 using ICMPv4 as well. ! (although it was/is quite common to block ICMP packets which can make it not ! work properly) That is a different matter, lots of people switch them off and things do still work, because we're in most cases allowed to defragment (firewalls do that) and refragment at any point on the way as needed. Blocking ICMPv4 a practise that is certainly annoying, but what can we do? With v6 things simply won't work. ! > So I would assume, the ICMP "packet too big" message ! > reaches the host where rinetd runs, is swallowed by the kernel, and ! > the kernel sets the MTU in it's hostcache. Or something along that ! > line. ! ! > The TCP traffic however gets forwarded by rinetd to the internal ! > appserver(s) - which never get the message that they should reduce ! > their MTU. ! ! The data from one TCP connection are sent through another TCP connection, ! where both connections are separate with separate MTU and PMTUD. A new quintuple, then. Hm. Not sure why I was unhappy with that... one reason was probably that a webserver would not be able to know the client address. But I think this goes into off-topic here. -- 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: CNAME and IPv6
Am 30.05.2024 um 00:47:56 Uhr schrieb Peter: > On Wed, May 29, 2024 at 12:20:09PM +0200, Matus UHLAR - fantomas > wrote: ! > On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock > wrote: ! > > rinetd manages 2 separate connections and should work > with PMTUD. ! > ! On 28.05.24 22:17, Peter wrote: > ! > I'm wondering how it would. The connections are TCP, the PMTU > works ! > via ICMP6. Please stop using ! as a quoting character, it will break line wrapping when replying and create a mess in the mailing list. > ! No, Path MTU discovery works with TCPv4 using ICMPv4 as well. > ! (although it was/is quite common to block ICMP packets which can > make it not ! work properly) > > That is a different matter, lots of people switch them off > and things do still work, because we're in most cases allowed to > defragment (firewalls do that) and refragment at any point on the > way as needed. That only applies if the router want to fragment it and if the DF bit is NOT set by the sender. > Blocking ICMPv4 a practise that is certainly annoying, but what > can we do? Telling those who do it that is is a really bad idea and don't implement workarounds. > ! > So I would assume, the ICMP "packet too big" message > ! > reaches the host where rinetd runs, is swallowed by the kernel, > and ! > the kernel sets the MTU in it's hostcache. Or something along > that ! > line. > ! > ! > The TCP traffic however gets forwarded by rinetd to the internal > ! > appserver(s) - which never get the message that they should reduce > ! > their MTU. > ! > ! The data from one TCP connection are sent through another TCP > connection, ! where both connections are separate with separate MTU > and PMTUD. > > A new quintuple, then. Hm. Not sure why I was unhappy with that... Didn't you say you never tried rinetd? > one reason was probably that a webserver would not be able to know the > client address. That is indeed the case and logging will be much more complicated, including banning with fail2ban. -- Gruß Marco Send unsolicited bulk mail to 1717022876mu...@cartoonies.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
