Re: Problema chroot sid

[Griera]

Hola, Alex:

Gràcies per l'ajuda!

Al final vaig veure que al fer:

$ sudo debootstrap sid /srv/chroot/sid

Tot anava bé fins arribar a un determinat fitxer:

I: Extracting libuuid1...
I: Extracting libuuid1t64...
E: Tried to extract package, but file already exists. Exit...

I al debootstrap.log hi ha:

2024-03-04 08:20:28 
URL:http://deb.debian.org/debian/pool/main/z/zlib/zlib1g_1.3.dfsg-3.1_amd64.deb 
[87580/87580] -> 
"/srv/chroot/sid//var/cache/apt/archives/partial/zlib1g_1%3a1.3.dfsg-3.1_amd64.deb"
 [1]
tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0: Cannot open: File exists
tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1: Cannot create symlink to 
'libuuid.so.1.3.0': File exists
tar: Exiting with failure status due to previous errors

Els primers cops no me'n vaig adonar d'aquest error. Total que he enviat un bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065343

Tanmateix a continuació comento entre línies el que dius.

On Sun, 3 Mar 2024 23:52:24 +0100
Alex Muntada  wrote:

> Hola,
> 
> tingues en compte que he trobat el teu correu a la carpeta d'spam
> (per això no l'havia vist abans).

Deu ser per ser un yandex. . .

 
> > Sempre havia anat perfecte, però ara dona error:
> >   $ xhost +local: && sudo schroot -c sid  && xhost - 
> >non-network local connections being added to access control list 
> >E: Failed to execute “/bin/bash”: No such file or directory
> 
> Jo he fet un nou schroot seguint les teves passes (aproximadament)
> i sembla que funciona bé. Les diferències són les següents:
> 
> - Utilitzo el debootstrap de Debian 12

Vols dir que no utilitzes el debootstrap de bookworm-backports? No ho entenc, 
perquè si utilitzo el debootstrap de bookworm en lloc del de bookworm-backports 
a mi me surt el mateix error de "Cannot open: File exists".


> - Munto per defecte alguns directoris del sistema principal. Per
>   exemple, per estalviar-me executar xhost, tinc això al fitxer
>   /etc/schroot/default/fstab:
> 
>   ```
>   /run/user/1000 /run/user/1000 none rw,bind 0 0
>   ```

Gràcies per aquest suggeriment! Jo abans també ho feia, però no se perquè ho 
vaig deixar de fer.


> > I /bin/bash existeix i és executable:
> > 
> >   $ dir -l /srv/chroot/sid/bin/bash
> > -rwxr-xr-x 1 root root 1277936 26 de nov.  09:09 
> > /srv/chroot/sid/bin/bash
> 
> Té tota la pinta de ser un problema degut a la conversió cap a
> usrmerge. Pots mirar si /src/schroot/sid/bin és un directori o
> un symlink? 

És un directori:

$ dir -l /srv/chroot/sid/
total 64
drwxr-xr-x  2 root root 4096  4 de març  08:20 bin
...


> I si fas un ldd al bash des de la Debian 12 dóna
> algun error? Jo el puc executar des de fora del chroot i va bé.

No hi se veure cap error:

$ ldd /srv/chroot/sid/bin/bash
linux-vdso.so.1 (0x7ffd091f6000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f3bcecc)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3bceadf000)
/lib64/ld-linux-x86-64.so.2 (0x7f3bcee5a000)


> La cosa curiosa és que amb el debootstrap de la 12 no fa la
> conversió a usrmerge, o sigui que podria ser una solució a
> considerar si no tens una necessitat especial d'executar la
> versió dels backports.

No hi entenc tant com per comentar això, però, com he dit, si no faig
servir la versió de backports, me passa el mateix. Ni idea com és que a
tu et funciona i a mi no, malgrat que abans de provar-ho amb la versió
no backports he intentat esborrar-ho tot després de verificar que no
tenia cap sessió de schroot amb 

schroot --list --all-sessions

En concret he fet.

sudo apt --purge remove schroot debootstrap  && sudo apt autoremove
sudo rm -r /srv/chroot/sid
sudo rm -r /etc/schroot

Però poder queda alguna cosa que fa que l'error persisteixi.

Moltes gràcies per l'ajuda i aquest comentaris tant detallats.

Salut!

> 
> Salut,
> Alex
> 
> --
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
>   ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
>   ⠈⠳⣄
> 

Re: systemd-resolved resolving fails sometimes on Debian12

[Marco Moock]

Am 02.03.2024 um 15:06:01 Uhr schrieb Victor Sudakov:

> In my case the problem seems related to IPv6. That is, when I disable
> IPv6 via "sysctl net.ipv6.conf.all.disable_ipv6=1" the problem
> disappears.

Please run 
resolvectl

that shows the resolvers available.

Check each of them with
dig example.org @

If that doesn't work for one of them, this must be fixed and is not a
problem of IPv6 nor of systemd-resolve.

-- 
Gruß
Marco

Send spam to 1709388361mu...@cartoonies.org

Re: systemd-resolved resolving fails sometimes on Debian12

[jeremy ardley]

On 3/3/24 22:39, Victor Sudakov wrote:

jeremy ardley wrote:

On 3/3/24 12:43, Victor Sudakov wrote:

Not that I would use bind9 as a caching resolver but still, how
do you pass the dynamically obtained AWS DNS server address from
systemd-networkd to bind9 ?


The AWS DNS resolver IPs are static and are widely published.

Do you mean 169.254.169.253?



That IP address is a non-routable AWS internal address for internal DNS 
services. It is not the public IP address


There is some convention that address 2 in non routable address ranges 
allocatted to customers is also a DNS server address. So 10.0.0.2 is a 
DNS server.


The actual public source addresses used by AWS DNS servers are not well 
defined and may vary by region



It is permissible to not use AWS resolvers for upstream.

If you want to use AWS resolvers you may run into the problem that some RBL
services reject queries from 'well known' free DNS servers; that may include
AWS resolver addresses.

systemd-networkd without systemd-resolved maintains a list of DNS servers in
/etc/resolv.conf that can be used by local services.

Do you just disable the systemd-resolved service or do you remove the
systemd-resolved package completely?


I completely removed system-resolved as when it is installed it changes 
the DNS configuration to be non-standard





If you disable it, you are also supposed to remove the "resolve"
service from nsswitch.conf, right?


I am not sure what you mean by resolve service. The current user manual 
manual for  nsswitch has


hosts:  dns [!UNAVAIL=return] files

which seems to be some new spin. It has always been the practice to use 
files and then dns if nothing found


hosts: files dns

in neither case is systemd-resolved required. The resolution uses the 
contents of /etc/resolv.conf to choose a resolver.






You can override dynamic setting of the dns resolvers in the
systemd-networkd configuration to use a local caching resolver such as
bind9, usually listening at 127.0.0.1:53

What would this be for? Sorry, I did not understand this step.


I was in error stating that. You need to manually edit /etc/resolv.conf 
to contain a line


nameserver 127.0.0.1

and configure bind9 to listen to that

options {
    listen-on { 127.0.0.1; };
    // other options like directory, allow-query, etc.
    recursion yes;
    // Additional configuration to ensure it acts as a caching server
};



You can then configure bind 9 as a caching only DNS resolver and set
appropriate upstream (forwarder) sites, or none at all defaulting to the
root servers.


Thank you for the ideas, I may use them but first I would like to do
something about the obvious bug in systemd-resolved.

Re: compartir mediante samba

[Julián Daich]

El 29/2/24 a las 15:54, Elena DP escribió:

¡hola Julian!
El problema es que no lo has configurado bien .


Hola,

Gracias. El problema estaba en que la ruta al archivo de configuración 
no era correcta.


Puedes ver el hilo completo en la lista con la solución y el titulo 
corregido.


Saludos,

Julián

Por parte de samba hay 
un usuario llamado guest que te permite no usar password, úsalo para lo 
que creo pretendes: compartir sin seguridad. En map to guest ... revisa 
eso. Tambien revisa el owner y user de las carpetas /home/julian/videos 
, etc para que samba pueda permitir o hacer efectivo lo que deseas.


¡saludos!

El vie, 9 feb 2024, 22:00, Julian Daich > escribió:


Compartir archivos con Samba
Hola,

Estoy tratando de compartir dos carpetas por Samba y no me funciona.
En el servidor tengo Samba instalado. Hice

sudo smbpasswd -a julian, también use las opciones e y n para que no
pregunte contraseña

En /etc/samba.smb.conf

[global]
workgroup = workgroup
security = user
map to guest = Bad User
null passwords = yes

[Música]
path = /home/julian/Música
browsable = yes
writable = yes
read only = no
force create mode = 0666
force directory mode = 0777

[Vídeos]
path = /home/julian/Vídeos
browsable = yes
writable = yes
read only = no
force create mode = 0666
force directory mode = 0777

En el cliente hago smb://nombre_del_equipo

Me pide la contrseña, la haya anulado o no, y da mensaje de error·
parámetros incorrectos"

El servidor es Debian y el cliente Ubuintu Studio. En los dos uso el
mismo usuario. Veo que esto de compartir archivos sigue siendo igual
de complicado como 20 años atrás.

Saludos,

Julián
-- 
Julian




--
Julian Daich 

Re: bash parameter expansion "doesn't like" dots?

[John Crawley]

On 04/03/2024 10:07, David Wright wrote:

On Sun 03 Mar 2024 at 17:58:53 (-0600), Albretch Mueller wrote:

  bash doesn't seem to like dots too close to brackets:

  echo "${_VAR//[^0-9a-zA-Z.,_-]/}"

  works fine.

On 3/3/24, Albretch Mueller  wrote:

_VAR="admissions.piedmont.edu_files?trackid=wnm:1980=what-is-the-second-fundamental-theorem-of-calculus(1).pdf"

echo "${_VAR//[^a-zA-Z0-9_-]/}"

echo "${_VAR//[^a-zA-Z0-9_-.]/}"

  ↑↑↑

That's a range, except that it isn't because it's written backwards.
Check for yourself by testing with 9-0 instead of 0-9.

Cheers,
David.


So the problem isn't about dots, but the handling of the - which has to go last 
if it isn't to be treated as a range marker.

https://www.gnu.org/software/grep/manual/html_node/Character-Classes-and-Bracket-Expressions.html
says:

‘-’
represents the range if it’s not first or last in a list or the ending 
point of a range. To make the ‘-’ a list item, it is best to put it last.

--
John

Re: [ *** ] Job anacron.service/stop running (15min 49s / no limit)

[David Wright]

On Sun 03 Mar 2024 at 13:27:50 (+0100), Eduard Bloch wrote:
> * David Wright [Sun, Feb 11 2024, 10:20:16PM]:
> > On Sun 11 Feb 2024 at 20:41:51 (+), Darac Marjal wrote:
> > > On 11/02/2024 11:21, Rainer Dorsch wrote:
> >
> > > > - How do I set a timeout/limit for anacron, that it cannot block forever
> > > > during a reboot?
> > >
> > > It may be germane to point out that anacron.service already explicitly
> > > sets "TimeoutStopSec=Infinity". So, in the opinion of the developers,
> > > the service shouldn't be prematurely killed. Of course you, as the
> > > system administrator, always have the right to countermand that sort
> > > of decision, but it would be curious to find out why the developers
> > > thought they needed to override the systemd default in the first
> > > place?
> >
> > Bug #915379 explains all: long-running cron jobs, like backups, can
> > get killed, and there was also an issue with exim.
> 
> Yes, and?

If you don't like it, then

  # systemctl edit --full anacron.service

and remove or decrease the timeout, which means (for removal)
you'll be reverting to how things are in bullseye.

> The opposite is: you have some stupid (and UNKNOWN) task which
> hangs forever because of some programming bug. And then your whole system
> locks up, unable to reboot, and no way to recover it because the reboot
> is stuck because of this. I am observing this on my old hacking laptop
> right now, the system took many minutes (5? 7?) to continue, but even
> that was pure luck.

I would probably have force-powered-down by then.

> Sorry, no, that cannot be the proper way. I am reopening 915379 now, the
> maintainer should maybe come up with some sane solution.

#915379 has been archived, which AIUI means you need to open a new one.

Cheers,
David.

Re: bash parameter expansion "doesn't like" dots?

[David Wright]

On Sun 03 Mar 2024 at 17:58:53 (-0600), Albretch Mueller wrote:
>  bash doesn't seem to like dots too close to brackets:
> 
>  echo "${_VAR//[^0-9a-zA-Z.,_-]/}"
> 
>  works fine.
> 
> On 3/3/24, Albretch Mueller  wrote:
> > _VAR="admissions.piedmont.edu_files?trackid=wnm:1980=what-is-the-second-fundamental-theorem-of-calculus(1).pdf"
> >
> > echo "${_VAR//[^a-zA-Z0-9_-]/}"
> >
> > echo "${_VAR//[^a-zA-Z0-9_-.]/}"
 ↑↑↑

That's a range, except that it isn't because it's written backwards.
Check for yourself by testing with 9-0 instead of 0-9.

Cheers,
David.

Re: bash parameter expansion "doesn't like" dots?

[Albretch Mueller]

 bash doesn't seem to like dots too close to brackets:

 echo "${_VAR//[^0-9a-zA-Z.,_-]/}"

 works fine.

 lbrtchx

On 3/3/24, Albretch Mueller  wrote:
> _VAR="admissions.piedmont.edu_files?trackid=wnm:1980=what-is-the-second-fundamental-theorem-of-calculus(1).pdf"
>
> echo "${_VAR//[^a-zA-Z0-9_-]/}"
>
> echo "${_VAR//[^a-zA-Z0-9_-.]/}"
>

Re: Problema chroot sid

[Alex Muntada]

Hola,

tingues en compte que he trobat el teu correu a la carpeta d'spam
(per això no l'havia vist abans).

> Sempre havia anat perfecte, però ara dona error:
>   $ xhost +local: && sudo schroot -c sid  && xhost - 
>non-network local connections being added to access control list 
>E: Failed to execute “/bin/bash”: No such file or directory

Jo he fet un nou schroot seguint les teves passes (aproximadament)
i sembla que funciona bé. Les diferències són les següents:

- Utilitzo el debootstrap de Debian 12
- Munto per defecte alguns directoris del sistema principal. Per
  exemple, per estalviar-me executar xhost, tinc això al fitxer
  /etc/schroot/default/fstab:

  ```
  /run/user/1000 /run/user/1000 none rw,bind 0 0
  ```

> I /bin/bash existeix i és executable:
> 
>   $ dir -l /srv/chroot/sid/bin/bash
> -rwxr-xr-x 1 root root 1277936 26 de nov.  09:09 /srv/chroot/sid/bin/bash

Té tota la pinta de ser un problema degut a la conversió cap a
usrmerge. Pots mirar si /src/schroot/sid/bin és un directori o
un symlink? I si fas un ldd al bash des de la Debian 12 dóna
algun error? Jo el puc executar des de fora del chroot i va bé.

La cosa curiosa és que amb el debootstrap de la 12 no fa la
conversió a usrmerge, o sigui que podria ser una solució a
considerar si no tens una necessitat especial d'executar la
versió dels backports.

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: indi Debian Astro

[Stefan Monnier]

> I'm using debiain on a rock64 for astrophotography and noticed all the indi
> packages except indi-eqmod are from 2022. 
> I was hoping for some updates to the drivers and some new drivers added like
> the svbony drivers and zwo am5 driver.
> How does one go about moving this forward?

I suggest you start by looking at https://tracker.debian.org/pkg/indi
and asking the maintainers mentioned there.


Stefan

Re: “Secure Connection Failed” Error in Firefox

[Jeffrey Walton]

On Sun, Mar 3, 2024 at 2:02 PM Jeffrey Walton  wrote:
>
> On Sun, Mar 3, 2024 at 1:47 PM Marcelo Laia  wrote:
> >
> > Hello Debian users!
> >
> > When accessing the website https://gontijoonibus.gontijo.com.br/ on Firefox 
> > Android (on my smartphone), the site is accessed normally. However, when 
> > attempting to access this site on the desktop, Debian Firefox-ESR version 
> > 115.8.0esr (64-bit), the following error occurs:
> >
> > Secure Connection Failed
> > An error occurred during a connection to gontijoonibus.gontijo.com.br.
> > The page you are trying to view cannot be displayed because the 
> > authenticity of the received data could not be verified.
> > Please contact the website owners to inform them of this problem.
>
> According to OpenSSL and the default CA list on Ubuntu 22.04, the
> connection looks Ok. The problem appears to be more than a simple
> problem connecting.
>
> If I had to hazard a guess, I would start with the wildcard in the
> Common Name (CN) shown below. I know the CA/Browser Baseline
> Requirements changed recently, and CN is now a SHOULD NOT. Wildcards
> have been frowned upon but not forbidden. Maybe the browsers are
> moving against wildcards in the CN now.
>
> Note: tooling, like cURL, OpenSSL and Wget follow the IETF's Internet
> PKI (PKIX). Browsers follow the CA/Browsers Baseline Requirements (Web
> PKI). They mostly overlap, but they have a fair amount of differences
> once you accumulate some knowledge about them.
>
> And the IETF lawyers wrote a nasty letter to the W3C a couple of years
> ago because the W3C was publishing incompatible standards. See
> .
> And from my observations, the CA/Browser Forums have been doing the
> same thing. So I would not be surprised if there's an incompatible
> change between PKIX and Web PKI.
>
> 
> $ echo -e 'GET / HTTP/1.1\r\n\r\n' | openssl s_client -connect
> gontijoonibus.gontijo.com.br:443 -servername
> gontijoonibus.gontijo.com.br
> CONNECTED(0003)
> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
> Global Root G2
> verify return:1
> depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte
> TLS RSA CA G1
> verify return:1
> depth=0 CN = *.gontijo.com.br
> verify return:1
> ---
> Certificate chain
>  0 s:CN = *.gontijo.com.br
>i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte TLS RSA CA 
> G1
>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>v:NotBefore: May  9 00:00:00 2023 GMT; NotAfter: May  8 23:59:59 2024 GMT
>  1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte TLS RSA CA 
> G1
>i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
> Global Root G2
>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>v:NotBefore: Nov  2 12:24:25 2017 GMT; NotAfter: Nov  2 12:24:25 2027 GMT
>  2 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
> Global Root G2
>i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
> Global Root G2
>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>v:NotBefore: Aug  1 12:00:00 2013 GMT; NotAfter: Jan 15 12:00:00 2038 GMT
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIGITCCBQmgAwIBAgIQB7Bs73IlM/884Dqb8/YZoTANBgkqhkiG9w0BAQsFADBe
> MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
> d3cuZGlnaWNlcnQuY29tMR0wGwYDVQQDExRUaGF3dGUgVExTIFJTQSBDQSBHMTAe
> Fw0yMzA1MDkwMDAwMDBaFw0yNDA1MDgyMzU5NTlaMBsxGTAXBgNVBAMMECouZ29u
> dGlqby5jb20uYnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDNoYUM
> EjKsU7gHu5iZpkwZkwJGyMe1l5d1+YVUJLkB23vxGXxSRoYVOqhPR/sbvyue0FFA
> OwbKriu+XjXA/dCOC6hEX9UbvHK9i5YFaPbJIDkwZKuA3SltFSyJsuRNP7dpYEkY
> uxZ4pcLBtEAh9+im1g5l4ubrFDrxdr5Wvjne6viDyZ+40Alc+i1pirlymsD7k6tH
> 4bLaR+qopr6YqufzOkWlcodNbCnQ3TF1ZOVppwJDYvWaROQ8WcUC5c3v4TDYcXrq
> YasWMtN2GL+UwQL4Gc/q9slkpG1ML8lX50CwxhGAngjz8PdNq9ql+kHa9XfTx+5G
> DYrshriHimk9POppAgMBAAGjggMcMIIDGDAfBgNVHSMEGDAWgBSljP4yzOsPLNQZ
> xgi4ACSIXcPFtzAdBgNVHQ4EFgQUOgqjT5nVOc1VYZ8vm/Y80TI7UIEwKwYDVR0R
> BCQwIoIQKi5nb250aWpvLmNvbS5icoIOZ29udGlqby5jb20uYnIwDgYDVR0PAQH/
> BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjA7BgNVHR8ENDAy
> MDCgLqAshipodHRwOi8vY2RwLnRoYXd0ZS5jb20vVGhhd3RlVExTUlNBQ0FHMS5j
> cmwwPgYDVR0gBDcwNTAzBgZngQwBAgEwKTAnBggrBgEFBQcCARYbaHR0cDovL3d3
> dy5kaWdpY2VydC5jb20vQ1BTMHAGCCsGAQUFBwEBBGQwYjAkBggrBgEFBQcwAYYY
> aHR0cDovL3N0YXR1cy50aGF3dGUuY29tMDoGCCsGAQUFBzAChi5odHRwOi8vY2Fj
> ZXJ0cy50aGF3dGUuY29tL1RoYXd0ZVRMU1JTQUNBRzEuY3J0MAkGA1UdEwQCMAAw
> ggF+BgorBgEEAdZ5AgQCBIIBbgSCAWoBaAB2AO7N0GTV2xrOxVy3nbTNE6Iyh0Z8
> vOzew1FIWUZxH7WbAAABiABkUyYAAAQDAEcwRQIgfzcKflXhHpmu5GHg8S048cs8
> vpP1gxpdWDsSoIW7iBICIQDMDeAMb6rf8XcdLAxVXeScb4DE6WI73WrxLuhijv7O
> +gB2AEiw42vapkc0D+VqAvqdMOscUgHLVt0sgdm7v6s52IRzAAABiABkUyUAAAQD
> AEcwRQIgP46qqZOnzi6Zp+F30GBTHY5LpCR9uL55MFTS+XnRsv0CIQDTC52xy9Gl
> xzzDqltvAGVq10MgnLY9rIvZMccRsEVgEAB2ANq2v2s/tbYin5vCu1xr6HCRcWy7
> 

Re: “Secure Connection Failed” Error in Firefox

[Jeffrey Walton]

On Sun, Mar 3, 2024 at 1:47 PM Marcelo Laia  wrote:
>
> Hello Debian users!
>
> When accessing the website https://gontijoonibus.gontijo.com.br/ on Firefox 
> Android (on my smartphone), the site is accessed normally. However, when 
> attempting to access this site on the desktop, Debian Firefox-ESR version 
> 115.8.0esr (64-bit), the following error occurs:
>
> Secure Connection Failed
> An error occurred during a connection to gontijoonibus.gontijo.com.br.
> The page you are trying to view cannot be displayed because the authenticity 
> of the received data could not be verified.
> Please contact the website owners to inform them of this problem.

According to OpenSSL and the default CA list on Ubuntu 22.04, the
connection looks Ok. The problem appears to be more than a simple
problem connecting.

If I had to hazard a guess, I would start with the wildcard in the
Common Name (CN) shown below. I know the CA/Browser Baseline
Requirements changed recently, and CN is now a SHOULD NOT. Wildcards
have been frowned upon but not forbidden. Maybe the browsers are
moving against wildcards in the CN now.

Note: tooling, like cURL, OpenSSL and Wget follow the IETF's Internet
PKI (PKIX). Browsers follow the CA/Browsers Baseline Requirements (Web
PKI). They mostly overlap, but they have a fair amount of differences
once you accumulate some knowledge about them.

And the IETF lawyers wrote a nasty letter to the W3C a couple of years
ago because the W3C was publishing incompatible standards. See
.
And from my observations, the CA/Browser Forums have been doing the
same thing. So I would not be surprised if there's an incompatible
change between PKIX and Web PKI.


$ echo -e 'GET / HTTP/1.1\r\n\r\n' | openssl s_client -connect
gontijoonibus.gontijo.com.br:443 -servername
gontijoonibus.gontijo.com.br
CONNECTED(0003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
Global Root G2
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte
TLS RSA CA G1
verify return:1
depth=0 CN = *.gontijo.com.br
verify return:1
---
Certificate chain
 0 s:CN = *.gontijo.com.br
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte TLS RSA CA G1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May  9 00:00:00 2023 GMT; NotAfter: May  8 23:59:59 2024 GMT
 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte TLS RSA CA G1
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
Global Root G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Nov  2 12:24:25 2017 GMT; NotAfter: Nov  2 12:24:25 2027 GMT
 2 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
Global Root G2
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
Global Root G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug  1 12:00:00 2013 GMT; NotAfter: Jan 15 12:00:00 2038 GMT
---
Server certificate
-BEGIN CERTIFICATE-
MIIGITCCBQmgAwIBAgIQB7Bs73IlM/884Dqb8/YZoTANBgkqhkiG9w0BAQsFADBe
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMR0wGwYDVQQDExRUaGF3dGUgVExTIFJTQSBDQSBHMTAe
Fw0yMzA1MDkwMDAwMDBaFw0yNDA1MDgyMzU5NTlaMBsxGTAXBgNVBAMMECouZ29u
dGlqby5jb20uYnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDNoYUM
EjKsU7gHu5iZpkwZkwJGyMe1l5d1+YVUJLkB23vxGXxSRoYVOqhPR/sbvyue0FFA
OwbKriu+XjXA/dCOC6hEX9UbvHK9i5YFaPbJIDkwZKuA3SltFSyJsuRNP7dpYEkY
uxZ4pcLBtEAh9+im1g5l4ubrFDrxdr5Wvjne6viDyZ+40Alc+i1pirlymsD7k6tH
4bLaR+qopr6YqufzOkWlcodNbCnQ3TF1ZOVppwJDYvWaROQ8WcUC5c3v4TDYcXrq
YasWMtN2GL+UwQL4Gc/q9slkpG1ML8lX50CwxhGAngjz8PdNq9ql+kHa9XfTx+5G
DYrshriHimk9POppAgMBAAGjggMcMIIDGDAfBgNVHSMEGDAWgBSljP4yzOsPLNQZ
xgi4ACSIXcPFtzAdBgNVHQ4EFgQUOgqjT5nVOc1VYZ8vm/Y80TI7UIEwKwYDVR0R
BCQwIoIQKi5nb250aWpvLmNvbS5icoIOZ29udGlqby5jb20uYnIwDgYDVR0PAQH/
BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjA7BgNVHR8ENDAy
MDCgLqAshipodHRwOi8vY2RwLnRoYXd0ZS5jb20vVGhhd3RlVExTUlNBQ0FHMS5j
cmwwPgYDVR0gBDcwNTAzBgZngQwBAgEwKTAnBggrBgEFBQcCARYbaHR0cDovL3d3
dy5kaWdpY2VydC5jb20vQ1BTMHAGCCsGAQUFBwEBBGQwYjAkBggrBgEFBQcwAYYY
aHR0cDovL3N0YXR1cy50aGF3dGUuY29tMDoGCCsGAQUFBzAChi5odHRwOi8vY2Fj
ZXJ0cy50aGF3dGUuY29tL1RoYXd0ZVRMU1JTQUNBRzEuY3J0MAkGA1UdEwQCMAAw
ggF+BgorBgEEAdZ5AgQCBIIBbgSCAWoBaAB2AO7N0GTV2xrOxVy3nbTNE6Iyh0Z8
vOzew1FIWUZxH7WbAAABiABkUyYAAAQDAEcwRQIgfzcKflXhHpmu5GHg8S048cs8
vpP1gxpdWDsSoIW7iBICIQDMDeAMb6rf8XcdLAxVXeScb4DE6WI73WrxLuhijv7O
+gB2AEiw42vapkc0D+VqAvqdMOscUgHLVt0sgdm7v6s52IRzAAABiABkUyUAAAQD
AEcwRQIgP46qqZOnzi6Zp+F30GBTHY5LpCR9uL55MFTS+XnRsv0CIQDTC52xy9Gl
xzzDqltvAGVq10MgnLY9rIvZMccRsEVgEAB2ANq2v2s/tbYin5vCu1xr6HCRcWy7
UYSFNL2kPTBI1/urAAABiABkUvIAAAQDAEcwRQIgAtm8xShzPd6lmxA4dGyZzQKa
U6fmBbCDIkyqNnKgOtoCIQCx5g1X5GBvuqkBlQHIYeWQ4UB1tNEtYYN/z3D293Lf
LTANBgkqhkiG9w0BAQsFAAOCAQEARpS7/BX4uVMvOMGfTo92uZNMozhWJzE+5o+k
ARsyf8FPmTNjHs+Z6A+DWTQ/4AAJ+cRv9LJzHpXw4X/o3u6VF5+rma20q7eLupxg

indi Debian Astro

[Joe]

hi,
I'm using debiain on a rock64 for astrophotography and noticed all the indi 
packages except indi-eqmod are from 2022. 
I was hoping for some updates to the drivers and some new drivers added like 
the svbony drivers and zwo am5 driver.
How does one go about moving this forward?
Astro Berry is no longer maintained, but indi drivers are. 
thanksJoe

Re: “Secure Connection Failed” Error in Firefox

[Dan Ritter]

Marcelo Laia wrote: 
> Hello Debian users!
> 
> When accessing the website https://gontijoonibus.gontijo.com.br/ on Firefox 
> Android (on my smartphone), the site is accessed normally. However, when 
> attempting to access this site on the desktop, Debian Firefox-ESR version 
> 115.8.0esr (64-bit), the following error occurs:
>

https://www.ssllabs.com/ssltest/analyze.html?d=gontijoonibus.gontijo.com.br

shows that there are several IP addresses that could be serving
this, but only 206.41.74.19 seems to be responsive.

And then it doesn't serve any content.

I would say that there are deep problems going on, which have
nothing to do with the client and everything to do with the
server.

-dsr-

Re: “Secure Connection Failed” Error in Firefox

[Brad Rogers]

On Sun, 3 Mar 2024 12:26:20 -0300
Marcelo Laia  wrote:

Hello Marcelo,

>website https://gontijoonibus.gontijo.com.br/ on 

I get the same results as Greg - in several browsers.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
I hope I live to relive the days gone by
Old Before I Die - Robbie Williams


pgpuwr_glqCXn.pgp
Description: OpenPGP digital signature

Re: “Secure Connection Failed” Error in Firefox

[Greg Wooledge]

On Sun, Mar 03, 2024 at 12:26:20PM -0300, Marcelo Laia wrote:
> When accessing the website https://gontijoonibus.gontijo.com.br/ on Firefox 
> Android (on my smartphone), the site is accessed normally. However, when 
> attempting to access this site on the desktop, Debian Firefox-ESR version 
> 115.8.0esr (64-bit), the following error occurs:
> 
> 
> Secure Connection Failed
> An error occurred during a connection to gontijoonibus.gontijo.com.br.
> The page you are trying to view cannot be displayed because the authenticity 
> of the received data could not be verified.
> Please contact the website owners to inform them of this problem.
> 
> Learn more…

For the record, Google Chrome gives:

This site can’t be reached

The webpage at https://gontijoonibus.gontijo.com.br/ might be temporarily
down or it may have moved permanently to a new web address.

ERR_HTTP2_PROTOCOL_ERROR

“Secure Connection Failed” Error in Firefox

[Marcelo Laia]

Hello Debian users!

When accessing the website https://gontijoonibus.gontijo.com.br/ on Firefox 
Android (on my smartphone), the site is accessed normally. However, when 
attempting to access this site on the desktop, Debian Firefox-ESR version 
115.8.0esr (64-bit), the following error occurs:


Secure Connection Failed
An error occurred during a connection to gontijoonibus.gontijo.com.br.
The page you are trying to view cannot be displayed because the authenticity of 
the received data could not be verified.
Please contact the website owners to inform them of this problem.

Learn more…


I have already changed the minimum accepted TLS protocol value from 3 to 1 in 
about:config, but this did not resolve the issue.

I have also deleted the ~/.mozilla folder and it was recreated, but without 
success.

How can I solve this problem?

Thank you so much!

--
Marcelo

Re: systemd-resolved resolving fails sometimes on Debian12

[Victor Sudakov]

jeremy ardley wrote:
> 
> On 3/3/24 12:43, Victor Sudakov wrote:
> > Not that I would use bind9 as a caching resolver but still, how
> > do you pass the dynamically obtained AWS DNS server address from
> > systemd-networkd to bind9 ?
> 
> 
> The AWS DNS resolver IPs are static and are widely published.

Do you mean 169.254.169.253?
> 
> It is permissible to not use AWS resolvers for upstream.
> 
> If you want to use AWS resolvers you may run into the problem that some RBL
> services reject queries from 'well known' free DNS servers; that may include
> AWS resolver addresses.
> 
> systemd-networkd without systemd-resolved maintains a list of DNS servers in
> /etc/resolv.conf that can be used by local services.

Do you just disable the systemd-resolved service or do you remove the
systemd-resolved package completely?

If you disable it, you are also supposed to remove the "resolve"
service from nsswitch.conf, right?

> You can override dynamic setting of the dns resolvers in the
> systemd-networkd configuration to use a local caching resolver such as
> bind9, usually listening at 127.0.0.1:53

What would this be for? Sorry, I did not understand this step.
> 
> You can then configure bind 9 as a caching only DNS resolver and set
> appropriate upstream (forwarder) sites, or none at all defaulting to the
> root servers.
> 

Thank you for the ideas, I may use them but first I would like to do
something about the obvious bug in systemd-resolved.

-- 
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet


signature.asc
Description: PGP signature

Re: DNSSEC status of deb.debian.org

[Andre Rodier]

On 03/03/2024 14:06, Andy Smith wrote:

Hi,

On Sun, Mar 03, 2024 at 09:39:42AM +, Andre Rodier wrote:

I was checking the Debian domain, and noticed that it is DNSSEC compliant.

However, when I check "deb.debian.org", the DNS validation fails.


Things in the debian.org domain are responding correctly with DNSSEC
but deb.debian.org is a CNAME to debian.map.fastlydns.net, and
*that* domain doesn't (yet?) use DNSSEC.

$ delv deb.debian.org
; fully validated
deb.debian.org. 3600IN  CNAME   debian.map.fastlydns.net.
deb.debian.org. 3600IN  RRSIG   CNAME 8 3 3600 20240405180549 
20240225172415 59788 debian.org. 
YnRgyoBEdwn9PHKTN9pIHNp+VyY+J0hripSOOV7feEsJmgfJwwslnsTR 
pC0QTkKZQlNflC2sPGqAc5/sKSHHGkHdKYemVCH7IcDTKOZ6wilVUlvT 
zumWhTZDk+ntLoptwmDblI6emnj8z8wimiFuyGv3+bU16RbdzdFvMdQI 
Ys9Ldyz6eQSMMyD58OwpiwDxFWjns92iUb05VB+yLeVeFwQ9uvJW1lZa 
oASmDhoyNijntU9UjA6h/Bzx6ZJvLHlE

; unsigned answer
debian.map.fastlydns.net. 30IN  A   146.75.74.132


After checking the status using Verisign
(https://dnssec-debugger.verisignlabs.com/deb.debian.org), I understand
Debian is using a CDN (Content Delivery Network).

Is there a stable domain we can use that doesn't rely on a CDN, please ?


I am left to wonder what problem(s) you are trying to avoid by "not
relying on a CDN", but you can just use a different mirror.

But note that Debian mirrors are operated by many diverse
organisations and individuals, most of which probably aren't Debian
developers. Debian itself has no legal entity; SPI, inc only deals
with some financial matters, so trying to form a notion of any kind
of legislative or administrative control structure is difficult.

Or to put it another way, if it bothers you that responsibility for
operation of a mirror passes outside of the people who control the
debian.org zone, I have bad news for you.

For example, if you chose ftp.uk.debian.org…

$ delv ftp.uk.debian.org
; fully validated
ftp.uk.debian.org.  300 IN  CNAME   debian.hands.com.
ftp.uk.debian.org.  300 IN  RRSIG   CNAME 8 4 300 20240401002934 
20240220235036 59788 debian.org. 
Pu+9FflqjMDfCjNxUoQy32dA5X3atU92LH3hozdZcDk3ZZwtyqcAoA6x 
IZSLZEzJvXa6+gTd3P0pOib+rIoypUYz47OulgYTWqQdLILtV3cRMVxU 
hf+z5xOYmOzzwSKAuI7iho4PNCmChccyfFdc3p4nKtciQmyWYbUeNJRu 
s83Ki0YEdvgMP+74HCwH6BNUEFhCuYFeDc+XWTzwg55EDSAmyMdXU9rl 
BRfpyCg4VU0NeJMFGci5sxKooAwbstvs

; unsigned answer
debian.hands.com.   14030   IN  A   78.129.164.123

…you again end up at something that doesn't use DNSSEC. It isn't a
CDN though, so maybe you like it more (?).

I haven't gone through all of the mirrors to see if there are any
ones that use DNSSEC. I wouldn't be surprised if there were some,
but again, I don't know what your threat model is so I'm not
suggesting this matters.

Thanks,
Andy




Thanks for the answer, Andy.

This make sense.

Kind regards,
André Rodier

Re: DNSSEC status of deb.debian.org

[Andre Rodier]

On 03/03/2024 14:03, Max Nikulin wrote:

On 03/03/2024 16:39, Andre Rodier wrote:


Is there a stable domain we can use that doesn't rely on a CDN, please ?


https://www.debian.org/mirror/list

APT relies on GPG signed metadata, so DNSSEC is not necessary for 
repositories.




Thanks, this make sense.

Kind regards,
André Rodier

Re: Encrypted home and pam_mount

[Max Nikulin]

On 03/03/2024 02:46, Andrey Dogadkin wrote:

Automounting works fine, but I'm having trouble with auto-unmounting
when I log out. The partition stays mounted and I can see "target is
busy" errors from umount in the journal.


It is an issue with ecryptfs and fscrypt as well.

https://github.com/systemd/systemd/issues/8598#issuecomment-376845082
"systemd-user doesn't properly close its PAM session"

systemd-logind default settings have UserStopDelaySec=10 so some 
processes are still running after the session is finished.


Depending on desktop environment or window manager you may try

 systemctl --user start exit.target

during logout if the user has no other sessions (SSH, VT, etc.)

I have not tried systemd-homed
https://systemd.io/HOME_DIRECTORY/

Re: DNSSEC status of deb.debian.org

[Greg Wooledge]

On Sun, Mar 03, 2024 at 02:06:00PM +, Andy Smith wrote:
> On Sun, Mar 03, 2024 at 09:39:42AM +, Andre Rodier wrote:
> > I was checking the Debian domain, and noticed that it is DNSSEC compliant.
> > 
> > However, when I check "deb.debian.org", the DNS validation fails.
> 
> Things in the debian.org domain are responding correctly with DNSSEC
> but deb.debian.org is a CNAME to debian.map.fastlydns.net, and
> *that* domain doesn't (yet?) use DNSSEC.
> 
> $ delv deb.debian.org
> ; fully validated
> deb.debian.org. 3600IN  CNAME   debian.map.fastlydns.net.
> deb.debian.org. 3600IN  RRSIG   CNAME 8 3 3600 20240405180549 
> 20240225172415 59788 debian.org. 
> YnRgyoBEdwn9PHKTN9pIHNp+VyY+J0hripSOOV7feEsJmgfJwwslnsTR 
> pC0QTkKZQlNflC2sPGqAc5/sKSHHGkHdKYemVCH7IcDTKOZ6wilVUlvT 
> zumWhTZDk+ntLoptwmDblI6emnj8z8wimiFuyGv3+bU16RbdzdFvMdQI 
> Ys9Ldyz6eQSMMyD58OwpiwDxFWjns92iUb05VB+yLeVeFwQ9uvJW1lZa 
> oASmDhoyNijntU9UjA6h/Bzx6ZJvLHlE
> 
> ; unsigned answer
> debian.map.fastlydns.net. 30IN  A   146.75.74.132

In addition to all of that, please note that deb.debian.org uses SRV
records instead of regular A or  records.  This is explained
(not fully) on http://deb.debian.org/ if you care to read it.

Re: DNSSEC status of deb.debian.org

[Andy Smith]

Hi,

On Sun, Mar 03, 2024 at 09:39:42AM +, Andre Rodier wrote:
> I was checking the Debian domain, and noticed that it is DNSSEC compliant.
> 
> However, when I check "deb.debian.org", the DNS validation fails.

Things in the debian.org domain are responding correctly with DNSSEC
but deb.debian.org is a CNAME to debian.map.fastlydns.net, and
*that* domain doesn't (yet?) use DNSSEC.

$ delv deb.debian.org
; fully validated
deb.debian.org. 3600IN  CNAME   debian.map.fastlydns.net.
deb.debian.org. 3600IN  RRSIG   CNAME 8 3 3600 20240405180549 
20240225172415 59788 debian.org. 
YnRgyoBEdwn9PHKTN9pIHNp+VyY+J0hripSOOV7feEsJmgfJwwslnsTR 
pC0QTkKZQlNflC2sPGqAc5/sKSHHGkHdKYemVCH7IcDTKOZ6wilVUlvT 
zumWhTZDk+ntLoptwmDblI6emnj8z8wimiFuyGv3+bU16RbdzdFvMdQI 
Ys9Ldyz6eQSMMyD58OwpiwDxFWjns92iUb05VB+yLeVeFwQ9uvJW1lZa 
oASmDhoyNijntU9UjA6h/Bzx6ZJvLHlE

; unsigned answer
debian.map.fastlydns.net. 30IN  A   146.75.74.132

> After checking the status using Verisign
> (https://dnssec-debugger.verisignlabs.com/deb.debian.org), I understand
> Debian is using a CDN (Content Delivery Network).
> 
> Is there a stable domain we can use that doesn't rely on a CDN, please ?

I am left to wonder what problem(s) you are trying to avoid by "not
relying on a CDN", but you can just use a different mirror.

But note that Debian mirrors are operated by many diverse
organisations and individuals, most of which probably aren't Debian
developers. Debian itself has no legal entity; SPI, inc only deals
with some financial matters, so trying to form a notion of any kind
of legislative or administrative control structure is difficult.

Or to put it another way, if it bothers you that responsibility for
operation of a mirror passes outside of the people who control the
debian.org zone, I have bad news for you.

For example, if you chose ftp.uk.debian.org…

$ delv ftp.uk.debian.org
; fully validated
ftp.uk.debian.org.  300 IN  CNAME   debian.hands.com.
ftp.uk.debian.org.  300 IN  RRSIG   CNAME 8 4 300 20240401002934 
20240220235036 59788 debian.org. 
Pu+9FflqjMDfCjNxUoQy32dA5X3atU92LH3hozdZcDk3ZZwtyqcAoA6x 
IZSLZEzJvXa6+gTd3P0pOib+rIoypUYz47OulgYTWqQdLILtV3cRMVxU 
hf+z5xOYmOzzwSKAuI7iho4PNCmChccyfFdc3p4nKtciQmyWYbUeNJRu 
s83Ki0YEdvgMP+74HCwH6BNUEFhCuYFeDc+XWTzwg55EDSAmyMdXU9rl 
BRfpyCg4VU0NeJMFGci5sxKooAwbstvs

; unsigned answer
debian.hands.com.   14030   IN  A   78.129.164.123

…you again end up at something that doesn't use DNSSEC. It isn't a
CDN though, so maybe you like it more (?).

I haven't gone through all of the mirrors to see if there are any
ones that use DNSSEC. I wouldn't be surprised if there were some,
but again, I don't know what your threat model is so I'm not
suggesting this matters.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: DNSSEC status of deb.debian.org

[Max Nikulin]

On 03/03/2024 16:39, Andre Rodier wrote:


Is there a stable domain we can use that doesn't rely on a CDN, please ?


https://www.debian.org/mirror/list

APT relies on GPG signed metadata, so DNSSEC is not necessary for 
repositories.

Re: [ *** ] Job anacron.service/stop running (15min 49s / no limit)

[Eduard Bloch]

reopen 915379
thanks

Hallo,
* David Wright [Sun, Feb 11 2024, 10:20:16PM]:
> On Sun 11 Feb 2024 at 20:41:51 (+), Darac Marjal wrote:
> > On 11/02/2024 11:21, Rainer Dorsch wrote:
>
> > > - How do I set a timeout/limit for anacron, that it cannot block forever
> > > during a reboot?
> >
> > It may be germane to point out that anacron.service already explicitly
> > sets "TimeoutStopSec=Infinity". So, in the opinion of the developers,
> > the service shouldn't be prematurely killed. Of course you, as the
> > system administrator, always have the right to countermand that sort
> > of decision, but it would be curious to find out why the developers
> > thought they needed to override the systemd default in the first
> > place?
>
> Bug #915379 explains all: long-running cron jobs, like backups, can
> get killed, and there was also an issue with exim.

Yes, and? The opposite is: you have some stupid (and UNKNOWN) task which
hangs forever because of some programming bug. And then your whole system
locks up, unable to reboot, and no way to recover it because the reboot
is stuck because of this. I am observing this on my old hacking laptop
right now, the system took many minutes (5? 7?) to continue, but even
that was pure luck.

Sorry, no, that cannot be the proper way. I am reopening 915379 now, the
maintainer should maybe come up with some sane solution.

Best regards,
Eduard.

DNSSEC status of deb.debian.org

[Andre Rodier]

Hello,

I was checking the Debian domain, and noticed that it is DNSSEC compliant.

However, when I check "deb.debian.org", the DNS validation fails.

After checking the status using Verisign 
(https://dnssec-debugger.verisignlabs.com/deb.debian.org), I understand 
Debian is using a CDN (Content Delivery Network).


Is there a stable domain we can use that doesn't rely on a CDN, please ?

Thanks,
André Rodier.

PS: Sorry to send an empty subject before.

Re: systemd-resolved resolving fails sometimes on Debian12

[jeremy ardley]

On 3/3/24 12:43, Victor Sudakov wrote:

Not that I would use bind9 as a caching resolver but still, how
do you pass the dynamically obtained AWS DNS server address from
systemd-networkd to bind9 ?



The AWS DNS resolver IPs are static and are widely published.

It is permissible to not use AWS resolvers for upstream.

If you want to use AWS resolvers you may run into the problem that some 
RBL services reject queries from 'well known' free DNS servers; that may 
include AWS resolver addresses.


systemd-networkd without systemd-resolved maintains a list of DNS 
servers in /etc/resolv.conf that can be used by local services.


You can override dynamic setting of the dns resolvers in the 
systemd-networkd configuration to use a local caching resolver such as 
bind9, usually listening at 127.0.0.1:53


You can then configure bind 9 as a caching only DNS resolver and set 
appropriate upstream (forwarder) sites, or none at all defaulting to the 
root servers.

[no subject]

[Andre Rodier]

Hello,

I was checking the Debian domain, and noticed that it is DNSSEC compliant.

However, when I check "deb.debian.org", the DNS validation fails.

Is there any reason behind this, please ?

Thanks,
André Rodier.