My query was about the behavior we observed on a gateway where a pure v4
subscriber (not dual-stack) has sent both A and AAAA query for the same
domain simultaneously. Just wanted to know why would a pure v4 subscriber
which cannot use the resolved AAAA domain addresses is trying to resolve
the v6 addresses of the domain.
Yours,
Naveen.
On Thu, 29 Aug 2019 at 12:09, Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:
> On Wed, Aug 28, 2019 at 05:53:26AM +0530, Naveen Kottapalli wrote:
>
> > Can one of you tell why would a v4 client send AAAA query or a by client
> > send a A query when the resolved address cannot be used?
>
> One answer I did not see, but seems to me to be the most likely,
> is that the library interface used by the application to learn the
> peer's addresses asks for and returns all the v4 and v6 addresses,
> and then the application tries each address in turn, until one
> succeeds, the library is address-family agnostic.
>
> Often the address resolution is many layers down below the actual
> application code, e.g. in an HTTP request library that uses a
> connection pool, that, as needed, establishes connections in a
> generic way, by using getaddrinfo(3) with AF_UNSPEC as the address
> family. The library code many layers down below the application
> code making an HTTP request, has no prior knowledge that on this
> particular system IPv6 may not be available. It just tries the
> returned addresses in order until one works.
>
> My system has IPv6, but only via a GRE tunnel to Hurricane Electric
> (many thanks to HE for the pretty good free service) and IPv6
> performance is consequently not nearly as good as IPv4. So I've
> configured my (FreeBSD) system to prefer IPv4:
>
> $ cat /etc/ip6addrctl.conf
> # Prefer IPv4
> ::ffff:0.0.0.0/96 100 4
> ...
>
> $ grep -i addrctl /etc/rc.conf
> ip6addrctl_enable="YES"
> ip6addrctl_policy="AUTO"
>
> With that, getaddrinfo(3) returns the IPv4 addresses first, and I
> only use IPv6 when none of the IPv4 addresses work, or the application
> chooses to also use the IPv6 addresses (e.g. the DANE survey code
> checks the validity of the certificate chain at every address of
> each MX host).
>
> For example (python):
>
> from socket import getaddrinfo, SOCK_STREAM
> for ai in getaddrinfo('www.ietf.org', 'https', type=SOCK_STREAM):
> print(ai)
>
> outputs:
>
> (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '',
> ('104.20.1.85', 443))
> (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '',
> ('104.20.0.85', 443))
> (<AddressFamily.AF_INET6: 28>, <SocketKind.SOCK_STREAM: 1>, 6, '',
> ('2606:4700:10::6814:55', 443, 0, 0))
> (<AddressFamily.AF_INET6: 28>, <SocketKind.SOCK_STREAM: 1>, 6, '',
> ('2606:4700:10::6814:155', 443, 0, 0))
>
> If I use python's HTTP client code to fetch content from:
>
> https://www.ietf.org/...
>
> code similar to the above will look up both the IPv4 and IPv6
> addresses, and then, if all goes well, use just the first one to
> make an IPv4 TCP connection to www.ietf.org (port 443), perform a
> TLS handshake, ...
>
> So the AAAA lookup is only used for IPv6-only sites, but that's the
> cost of all the layering and abstraction of address order preference,
> .... An efficient implementation of getaddrinfo() can do the A and
> AAAA lookups concurrently.
>
> --
> Viktor.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
