Re: ntpd tries to connect via ipv6
On 31 May 2016, Lyndon Nerenberg wrote: > > On May 31, 2016, at 3:58 PM, Ted Unangst > > wrote: > > > > If we're talking about timeframes long enough for network > > connectivity to come and go, that's long enough for IP addresses to > > come and go as well. > > This is an interesting problem, in general. > > In my MTA development days, we would cache the targets of the MX > record(s) we found in queued message's metadata. For each host > target, we included the absolute time the data would expire, based on > the original MX lookup. Expired records were ignored, and when we ran > out of hosts we would re-run the MX lookup and update the meta-data. > This worked quite well, considering the underlying DNS data didn't > change all that often. But SMTP sessions are not long-lived, so this > just worked. > > These days I wish I had similar functionality in pf. And not for > mobile hosts. E.g., at work we need to open up access to things like > Paypal payment API hosts. For those rules we can either hardwire IP > addresses, or use their hostnames. But they inevitably move their API > hosts around. In the first case, our list of hardwired IP addresses > gets stale. In the second, the addresses returned by the A(AAA) > record lookup gets stale. I would really like to be able to say > "build the rule from this hostname, but refresh the A(AAA) record > results as the underlying data's TTL expires." > > pf isn't special - this is the same problem as the ntpd example. I've > puzzled over how to deal with this, but I can't see a solution that > doesn't involve some sort of proxy that isolates the process from the > network changes. And even then, you're dealing with at least a TCP > connection reset if an existing address vanishes. For some things, > that's not an issue. For others, ... ? For pf there's an easy solution: put the IP in a persistent table, and have a cron job resolve the name and update the table when the IP changes. Obviously this only works with rules that can take tables to begin with, but that's good enough in many situations. Regards, Liviu Daia
Re: ntpd tries to connect via ipv6
> On May 31, 2016, at 3:58 PM, Ted Unangst wrote: > > If we're talking about timeframes long enough for network connectivity to come > and go, that's long enough for IP addresses to come and go as well. This is an interesting problem, in general. In my MTA development days, we would cache the targets of the MX record(s) we found in queued message's metadata. For each host target, we included the absolute time the data would expire, based on the original MX lookup. Expired records were ignored, and when we ran out of hosts we would re-run the MX lookup and update the meta-data. This worked quite well, considering the underlying DNS data didn't change all that often. But SMTP sessions are not long-lived, so this just worked. These days I wish I had similar functionality in pf. And not for mobile hosts. E.g., at work we need to open up access to things like Paypal payment API hosts. For those rules we can either hardwire IP addresses, or use their hostnames. But they inevitably move their API hosts around. In the first case, our list of hardwired IP addresses gets stale. In the second, the addresses returned by the A(AAA) record lookup gets stale. I would really like to be able to say "build the rule from this hostname, but refresh the A(AAA) record results as the underlying data's TTL expires." pf isn't special - this is the same problem as the ntpd example. I've puzzled over how to deal with this, but I can't see a solution that doesn't involve some sort of proxy that isolates the process from the network changes. And even then, you're dealing with at least a TCP connection reset if an existing address vanishes. For some things, that's not an issue. For others, ... ?
Re: ntpd tries to connect via ipv6
Carlin Bingham wrote: > On Tue, May 31, 2016 at 01:45:23PM -0400, Ted Unangst wrote: > > Jeremie Courreges-Anglas wrote: > > > ntpd(8) doesn't use getaddrinfo+AI_ADDRCONFIG, which is supposed to skip > > > DNS requests for IPv6 if the machine doesn't have IPv6 addresses > > > configured. > > > > reyk added a comment to that effect, but I don't know why. > > > > /* ntpd MUST NOT use AI_ADDRCONFIG here */ > > error = getaddrinfo(s, NULL, &hints, &res0); > > > > ipv6 might become available after startup: > https://marc.info/?l=openbsd-tech&m=142370671523470&w=2 >> the availability of IPv6 at startup does not necessarily mean that it will not be available later. ntpd is a long-running process that is also used on laptops etc. that move between networks but ntpd keeps on running. This of course leads to a second question. What if, while that long running ntpd is running, the hostname to IP mapping changes? Does it continue probing the wrong IP? If we're talking about timeframes long enough for network connectivity to come and go, that's long enough for IP addresses to come and go as well.
Re: ntpd tries to connect via ipv6
On Tue, May 31, 2016 at 01:45:23PM -0400, Ted Unangst wrote: > Jeremie Courreges-Anglas wrote: > > ntpd(8) doesn't use getaddrinfo+AI_ADDRCONFIG, which is supposed to skip > > DNS requests for IPv6 if the machine doesn't have IPv6 addresses > > configured. > > reyk added a comment to that effect, but I don't know why. > > /* ntpd MUST NOT use AI_ADDRCONFIG here */ > error = getaddrinfo(s, NULL, &hints, &res0); > ipv6 might become available after startup: https://marc.info/?l=openbsd-tech&m=142370671523470&w=2 -- Carlin
Re: ntpd tries to connect via ipv6
On Tue, May 31, 2016 at 1:04 PM, Stefan Wollny wrote: > I asked this just last week. Indeed! Sorry I missed it. Thanks all!
Re: ntpd tries to connect via ipv6
Sonic, I can confirm same issue on -current when ntpd tries to use record to resolve constraints IP address. Can you check and confirm if you don't have IPv6 address :) I guess you should have at least link-local and loopback IPv6 addresses :) ifconfig | grep inet6 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 # cat /etc/ntpd.conf # $OpenBSD: ntpd.conf,v 1.14 2015/07/15 20:28:37 ajacoutot Exp $ # # See ntpd.conf(5) and /etc/examples/ntpd.conf #servers pool.ntp.org #sensor * constraints from "https://www.google.com"; # ntpd -d -s -v ntp engine ready set local clock to Tue May 31 20:51:36 EEST 2016 (offset 0.00s) tls connect failed: 2a00:1450:401b:801::2004 (www.google.com): connect: No route to host no constraint reply from 2a00:1450:401b:801::2004 received in time, next query 900s constraint reply from 173.194.113.211: offset -0.803262 On Tue, May 31, 2016 at 6:36 PM, Sonic wrote: > Getting many such log entries: > === > May 31 08:53:34 stargate ntpd[5702]: tls connect failed: > 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host > May 31 09:08:35 stargate ntpd[15803]: tls connect failed: > 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host > May 31 09:23:36 stargate ntpd[92515]: tls connect failed: > 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host > === > > ntpd.conf has the line: constraints from "https://www.google.com"; > > System has no ipv6 addresses. Unbound is resolving DNS server with "do-ip6: > no". > > resolv.conf uses "nameserver 127.0.0.1" (Unbound serving on this address) > > normal lookups (dig) only return the ipv4 address for www.google.com > > Why does ntpd attempt to connect on an ipv6 address? > > Thanks, > > Chris > -- -- With regards, Eugene Sudyr
Re: ntpd tries to connect via ipv6
Jeremie Courreges-Anglas wrote: > ntpd(8) doesn't use getaddrinfo+AI_ADDRCONFIG, which is supposed to skip > DNS requests for IPv6 if the machine doesn't have IPv6 addresses > configured. reyk added a comment to that effect, but I don't know why. /* ntpd MUST NOT use AI_ADDRCONFIG here */ error = getaddrinfo(s, NULL, &hints, &res0);
Re: ntpd tries to connect via ipv6
Am 05/31/16 um 18:36 schrieb Sonic: > Getting many such log entries: > === > May 31 08:53:34 stargate ntpd[5702]: tls connect failed: > 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host > May 31 09:08:35 stargate ntpd[15803]: tls connect failed: > 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host > May 31 09:23:36 stargate ntpd[92515]: tls connect failed: > 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host > === > > ntpd.conf has the line: constraints from "https://www.google.com"; > > System has no ipv6 addresses. Unbound is resolving DNS server with "do-ip6: > no". > > resolv.conf uses "nameserver 127.0.0.1" (Unbound serving on this address) > > normal lookups (dig) only return the ipv4 address for www.google.com > > Why does ntpd attempt to connect on an ipv6 address? > > Thanks, > > Chris > I asked this just last week. Carlin Bingham's answer solved the issue for me (http://article.gmane.org/gmane.os.openbsd.misc/231185): In /etc/resolv.conf, add: family inet4 (Well: I actually added it in /etc/resolv.conf.tail ...) Best, STEFAN
Re: ntpd tries to connect via ipv6
http://marc.info/?l=openbsd-misc&m=146401377026646&w=2
ntpd tries to connect via ipv6
Getting many such log entries: === May 31 08:53:34 stargate ntpd[5702]: tls connect failed: 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host May 31 09:08:35 stargate ntpd[15803]: tls connect failed: 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host May 31 09:23:36 stargate ntpd[92515]: tls connect failed: 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host === ntpd.conf has the line: constraints from "https://www.google.com"; System has no ipv6 addresses. Unbound is resolving DNS server with "do-ip6: no". resolv.conf uses "nameserver 127.0.0.1" (Unbound serving on this address) normal lookups (dig) only return the ipv4 address for www.google.com Why does ntpd attempt to connect on an ipv6 address? Thanks, Chris
Re: ntpd tries to connect via ipv6
Sonic writes: > Getting many such log entries: > === > May 31 08:53:34 stargate ntpd[5702]: tls connect failed: > 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host > May 31 09:08:35 stargate ntpd[15803]: tls connect failed: > 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host > May 31 09:23:36 stargate ntpd[92515]: tls connect failed: > 2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host > === > > ntpd.conf has the line: constraints from "https://www.google.com"; > > System has no ipv6 addresses. Unbound is resolving DNS server with "do-ip6: > no". > > resolv.conf uses "nameserver 127.0.0.1" (Unbound serving on this address) > > normal lookups (dig) only return the ipv4 address for www.google.com > > Why does ntpd attempt to connect on an ipv6 address? ntpd(8) doesn't use getaddrinfo+AI_ADDRCONFIG, which is supposed to skip DNS requests for IPv6 if the machine doesn't have IPv6 addresses configured. An IPv4 connectivity problem may lead ntpd to fall back to trying IPv6. See the resolv.conf(5) "family" keyword for a way to disable IPv6 DNS requests. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
