Re: query failed (SERVFAIL) and query failed (failure)

[Barry Scott]

> On 23 Dec 2024, at 13:49, Bob Harold  wrote:
> 
> I don't think it is your problem.  gandi.net  is having 
> trouble.
> https://dnsviz.net/d/mail.gandi.net/dnssec/
> 

That would explain only gandi.net  problems.
I get errors all over the place.

What I need to test next is if the issue was with IPv6 timeouts,
suggested by a friend of mine,

I have just got IPv6 setup and working on the router and will
try again. But Xmas is delaying experiments :-)

Barry


> -- 
> Bob Harold
> 

-- 
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: SVCB/HTTPS vs. getaddrinfo: how to merge?

[Darren Ankney]

Hi,

It seems to me that the HTTPS/SVCB records describe where and how a
service is available (could be several IPv4 and IPv6 addresses as well
as several ports).  It does nothing to select how a client might
connect to the service other than by providing a hierarchy of
importance for each.   I've not completely read RFC3484 (just the
abstract and introduction) but it seems that this might describe some
selection parameters that a client might consider in addition to other
factors when deciding which of the available service addresses to
connect to.

Thank you,
Darren Ankney

On Wed, Dec 25, 2024 at 8:28 PM Peter 'PMc' Much
 wrote:
>
> Folks,
>
>   recent messages here mentioned some HTTPS and SVCB RRs.
>
> This is completely news to me, so I gave it some read.
> Then I found that these new tools are supposed to provide (IPv4 and
> IPv6) addresses, which seems to me as rather strange from a
> logical viewpoint.
>
> Normally, the addresses to be used are provided by 'getaddrinfo',
> which in turn gets substantial information from /etc/ip6addrctl.conf
> (RFC 3484), which describes the client's physical connectivity
> (e.g. which destinations can be reached from which subnets).
>
> So I am wondering how this is supposed to interact.
>
> cheerio,
> PMc
> --
> 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: SVCB/HTTPS vs. getaddrinfo: how to merge?

[Peter 'PMc' Much]

On Thu, Dec 26, 2024 at 04:53:51AM -0500, Darren Ankney wrote:
! Hi,
! 
! It seems to me that the HTTPS/SVCB records describe where and how a
! service is available (could be several IPv4 and IPv6 addresses as well
! as several ports).  It does nothing to select how a client might
! connect to the service other than by providing a hierarchy of
! importance for each.

Yes, that's how I understand it: HTTPS/SVCB describes physics from the
server side as the server admin perceives them, ip6addrctl and
getaddrinfo describe physics from the client side as the client
admin perceives them.

The most simple use for RFC3484 is to specify whether some system would
prefer ipv4 or v6. But it can do more, it can specify which
client addresses match to which server addresses for arbitrary
subnets, and thereby provide a preference for client AND server
addresses.

So you can now get preferrable server addresses from the client
configuration (based on client side physics), and you can get
preferrable server addresses from HTTPS (based on server side
physics).
More obscurely, you're not the one who decides which of these
are to be used; that would rather be some browser coder.

I've not completely read RFC3484 (just the
! abstract and introduction) but it seems that this might describe some
! selection parameters that a client might consider in addition to other
! factors when deciding which of the available service addresses to
! connect to.

Ideally it would. In practice, on my Berkeley/FreeBSD machines,
getaddrinfo provides the results of that selection. getaddrinfo
may or may not ask DNS in the process, depending on nsswitch.conf.

Then, as far as I understand the HTTPS RR, it is designed to
short-circuit this procedure and have the application client
directly query the HTTPS RR, in order to benefit by faster startup,
and probably ignoring any preference settings from ip6addrctl.
I don't yet know how this will work out in practice, but it seems
to me there is some potential for unexpected behaviour.


cheerio,
PMc
-- 
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