Subject: [DNSOP] Why would a v4 client send AAAA query?

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 28 Aug 2019 05:53:26 +0530

Dear experts,

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?

Thanks & Regards,
Naveen

---

From: william manning <[email-masked]>
Date: Tue, 27 Aug 2019 17:33:03 -0700

because the DNS systems have no idea what the application(s) will use the
answer for.  remember that data (A & AAAA) is the zone files is NOT the
same as the address(es) with which an interfce may be configured.
"Think before you ask these questions, Mitch."  - Chris Knight

On Tue, Aug 27, 2019 at 5:24 PM Naveen Kottapalli <[email-masked]>
wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Joe Abley <[email-masked]>
Date: Tue, 27 Aug 2019 20:34:28 -0400

Hi Naveen,

On 27 Aug 2019, at 20:23, Naveen Kottapalli <[email-masked]> 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?

Sometimes you can't tell if you can use an address until you find out what it was. You might have some but not all routes for a particular address family, for example.

Sometimes you request DNS resource records on behalf of other devices that have different connectivity from your own.

Sometimes devices make queries for reasons other than sending datagrams across a network.

Sometimes the connectivity a device can have can change, depending on what network it joins or changing conditions on a network it has already joined.

A device might have both v4 and v6 connectivity and still use v4 to send a query with QTYPE=AAAA or v6 to send a query with QTYPE=A. Perhaps the device knows that the v4 address its using tends to respond quicker than the v6 address it has tried in the past, or perhaps it's random selection, or local policy, or something else.

Bill's answer was pithier, though.

Joe

---

From: Rob Sayre <[email-masked]>
Date: Tue, 27 Aug 2019 22:55:40 -0700

>
> >> On Tue, Aug 27, 2019 at 5:33 PM william manning <
> [email-masked]> wrote:
> > because the DNS systems have no idea what the application(s) will use
> the answer for.
> > remember that data (A & AAAA) is the zone files is NOT the same as the
> address(es)
> > with which an interfce may be configured.
> >
> >> On Tue, Aug 27, 2019 at 5:34 PM Joe Abley <[email-masked]> wrote:
> >

Oh. I don't get it. I believe the quote in Bill's message is from the 1985
movie "Real Genius", but I was only a small child when that film premiered.

Could one of you explain the joke, in the interests of understanding?

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Wed, 28 Aug 2019 00:56:21 -0700

Perhaps the saddest thing about all of this is that I have to cc
www-archive.

that sucks,
Rob

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 Aug 2019 10:07:08 -0400

Hi Rob,

On 28 Aug 2019, at 01:55, Rob Sayre <[email-masked]> wrote:

> >> On Tue, Aug 27, 2019 at 5:33 PM william manning <[email-masked]> wrote:
> > because the DNS systems have no idea what the application(s) will use the answer for.
> > remember that data (A & AAAA) is the zone files is NOT the same as the address(es)
> Oh. I don't get it. I believe the quote in Bill's message is from the 1985 movie "Real Genius", but I was only a small child when that film premiered.

I wasn't referring to the movie quote (I am used to not understanding Bill's movie quotes) but rather the simple answer that "DNS systems have no idea what the application(s) will use the answer for".

I have no idea what your subsequent comment means, sorry ("cc www-archive").

Joe

---

From: william manning <[email-masked]>
Date: Wed, 28 Aug 2019 09:35:08 -0700

the movie quote was a reminder to think a little bit about -why- things are
the way they are.  for most of the current list participants, IPv4 & IPv6
co-existence is the only multiple protocol environment they have ever seen.
for some, this is not the first time we have seen multiple protocols active
at the same time.

when you realize that DNS is, basically a query/response system that is
transport agnostic, the original question becomes moot.  I can put X.25,
NSAP, IPv4, IPv6, and a few other addressing formats into the DNS as data
which can be queried.  That in no way reflects the transport used to get to
the data.

(Joe, we should watch more movies together)

/Wm

On Wed, Aug 28, 2019 at 7:07 AM Joe Abley <[email-masked]> wrote:

> > Oh. I don't get it. I believe the quote in Bill's message is from the
> 1985 movie "Real Genius", but I was only a small child when that film
> premiered.
>
> I wasn't referring to the movie quote (I am used to not understanding
> Bill's movie quotes) but rather the simple answer that "DNS systems have no
> idea what the application(s) will use the answer for".
>

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 29 Aug 2019 06:51:12 +0530

Hello Joe,

Thanks for answering my question appropriately. I got the answer am
looking for.

Also, thanks for *not suggesting unsolicitedly. * It shows how matured you
are.

Thanks,
Naveen

On Wed, 28 Aug 2019, 06:04 Joe Abley, <[email-masked]> wrote:

> Sometimes you can't tell if you can use an address until you find out what
> it was. You might have some but not all routes for a particular address
> family, for example.
>
> Sometimes you request DNS resource records on behalf of other devices that
> have different connectivity from your own.
>
> Sometimes the connectivity a device can have can change, depending on what
> network it joins or changing conditions on a network it has already joined.
>
> A device might have both v4 and v6 connectivity and still use v4 to send a
> query with QTYPE=AAAA or v6 to send a query with QTYPE=A. Perhaps the
> device knows that the v4 address its using tends to respond quicker than
> the v6 address it has tried in the past, or perhaps it's random selection,
> or local policy, or something else.
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 29 Aug 2019 02:39:10 -0400

> 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.

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 29 Aug 2019 15:13:45 +0530

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 <[email-masked]>
wrote:

> ....  An efficient implementation of getaddrinfo() can do the A and

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Aug 2019 21:35:40 +1000

Firstly most machines these days have at least one dual stack interface if not many even if the uplink is IPv4 only. Until the address is resolved they don’t know if the AAAA is usable (reachable) or not. 

-- 
Mark Andrews

> On 29 Aug 2019, at 19:43, Naveen Kottapalli <[email-masked]> wrote:
> 
> 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 <[email-masked]> wrote:
>> .....  An efficient implementation of getaddrinfo() can do the A and

---

From: Töma Gavrichenkov <[email-masked]>
Date: Thu, 29 Aug 2019 15:21:45 +0300

Peace,

On Thu, Aug 29, 2019 at 12:44 PM Naveen Kottapalli
<[email-masked]> wrote:
> 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.

In any way, that subscriber almost for sure has got v6 on the loopback
interface, and it is always possible that a domain name resolves to an
address within ::1.

--
Töma

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 29 Aug 2019 18:15:05 +0530

> the v6 addresses of the domain.

As Viktor pointed out, when a process calls getaddrinfo() without hints,
some libc implementations of getaddrinfo() don't consider what address
families the system has configured as it doesn't matter at that library
interface.

For example, here is FreeBSD's getaddrinfo() implementation:

https://github.com/freebsd/freebsd/blob/master/lib/libc/net/getaddrinfo.c#L2301

So, for example, FreeBSD's ping which uses gethostbyname2() with AF_INET
will appear to lookup only the A record of a hostname being pinged,
whereas FreeBSD's telnet which uses getaddrinfo() without hints (which
gets converted internally to AF_UNSPEC) will appear to lookup both A and
AAAA records.

Also what Mark said applies that even if you think a subscriber has no
v6 address/stack, they probably do.

		Mukund

---

From: Erik Nygren <[email-masked]>
Date: Thu, 29 Aug 2019 08:09:24 -0400

The device could also have an IPv6 interface via a tunnel or VPN client.

- Erik

     [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]

---

From: Wes Hardaker <[email-masked]>
Date: Sat, 31 Aug 2019 08:30:24 -0700

Naveen Kottapalli <[email-masked]> writes:

> 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?

As others have pointed out it's very common.

As an example, I looked at all the requests arriving to a root server in
the DITL data for 2019-04-10 and found:

| IPv |                  |            |         |
|-----+------------------+------------+---------|
|   6 | count of all v6: |  328328681 |         |
|   6 | requesting A     |  169375042 | 0.51587 |
|   6 | requesting AAAA  |  121834127 | 0.37107 |
|   4 | count of all v4: | 2997023565 |         |
|   4 | count of A       | 1593723264 | 0.53177 |
|   4 | count of AAAA    |  326232540 | 0.10885 |

So you can see that of all the ipv4 clients, 53% were asking for A
records and 10.8% were asking for AAAA (the other requests were for
other types, eg DNSKEY/SOA/etc).  In the IPV6 space, it's even more
interesting that 51.6% of IPv6 clients were asking about A records, and
only 37% about AAAA!

-- 
Wes Hardaker
USC/ISI

---

From: "Mark Delany" <[email-masked]>
Date: 31 Aug 2019 17:44:45 +0000

> So you can see that of all the ipv4 clients, 53% were asking for A

Ahh. But are you both talking about the same "clients"?

I assume Naveen is asking about clients as in applications on end-point
devices whereas your data is talking about clients as in recursive resolvers
asking on behalf of applications on end-point devices.

Your data is showing which transports the recursive resolvers prefer not which
transports the end-point devices have available to them. Even if there was a
correlation between the two (which I don't believe there is in general) it
still doesn't tell you whether that end-point device has both transports
available or not - it only shows which they prefer.

I think the answer is two-fold. First there is no standardized or easy way for
an application or a stub library to determine which transports are available
without actually trying them. As a consequence programmers, being a naturally
indolent mob, gravitate to the simplest and easiest thing to do which is to
ask for all addresses then iterate over them until they find one that
works. Using 'getaddrinfo' in perl tends to produce that outcome as does
net.Dial("tcp") in Go.

Second, as others have pointed out, almost all systems these days have at
least a loopback ipv6 address so well-written applications really must ask for
both types just in case ::1 comes back as an answer (or the only answer!).

What would be telling from those stats is how many clients are still only
asking for v4 addresses when they presumably have an interface with a v6
address as that probably indicates legacy code using pre-ipv6 APIs (or poorly
written modern code) which specifically asks for v4-only addresses.

Having said all that, there are still a scary number of IoT-type devices that
are v4-only; webcams and VOIP phones come to mind. But code in those things
are so poorly cobbled together that expecting rational DNS behavior is
probably asking too much.

Mark.