Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

[Francis Dupont]

 In your previous mail you wrote:

  On 20/01/2014 17:12, Simon Perreault wrote:
   IIRC, recent versions of Bind open a socket per address on IPv4

= not it is not by choice, just:
 - DNS requires to answer from the address the request was received
 - there is no standard/portable way to do this without the one
  socket per address in IPv4 (if you need an argument, just ask what
  this discussion is about :-)

  this feature was one of the main reasons I stopped using BIND.  It has the
  side effect that you cannot necessarily set it up on a system which shares
  IP addresses using e.g. VRRP, because you cannot be guaranteed that the
  system will have the virtual IP address configured at the time that BIND
  starts.  Frustrating.

= BIND polls from time to time interfaces to bind() to new addresses
(again, there is no standard/portable way to be notified. BTW we (ISC)
know this is a point which can be improved so if you know a generic
simple solution...)

Regards

francis.dup...@fdupont.fr (also fdup...@isc.org)

Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

[Francis Dupont]

 In your previous mail you wrote:

  On 22/01/2014 16:54, Francis Dupont wrote:
- there is no standard/portable way to do this without the one
 socket per address in IPv4 (if you need an argument, just ask what
 this discussion is about :-)
  
  i thought recvfrom() fixed this issue?  Forgive me if I'm wrong here - it's
  been far too long since I've done any socket related stuff.

= recvfrom() returns the peer address, i.e., the source address of
the request, when you need the local address, i.e., the destination
address.

   = BIND polls from time to time interfaces to bind() to new addresses
   (again, there is no standard/portable way to be notified. BTW we (ISC)
   know this is a point which can be improved so if you know a generic
   simple solution...)
  
  server.c:load_configuration() has:
  
  interface_interval = cfg_obj_asuint32(obj) * 60;
  
  which means that the granularity for interface rescanning is per-minute.
  I'm not suggesting that per-second rescan would be a good idea, but
  per-minute is too long for workable failover with vrrp.

= I'd like to say VRRP needs to be fixed but here the reasonable
solution is to be notified...

Regards

francis.dup...@fdupont.fr