Subject: [dnsext] RFC3596: A/AAAA records and additional section processing

From: Jehan Pagès <[email-masked]>
Date: Fri, 4 Mar 2011 15:35:27 +0900

Hi all,

I have a small question about the IPv6 resource records extension (RFC3596).
As section 2.3 states:
« A type AAAA query does not trigger additional section processing. ». Fine.

But I noticed that some DNS servers (like the one installed on my
server, a bind 9.7.2) would return the A records in additional section
on a AAAA query and AAAA records in additional on A queries.
And when I thought about this, I realized it was a pretty good logics.
Usually when people will try to contact a server, they will want both
A and AAAA records.
So the question is: why wouldn't this be standard?
Thanks.

Jehan

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 3 Mar 2011 22:50:46 -0800

The good news is that it is standard - section 3 of the same RFC says;

"3. Modifications to existing query types

   All existing query types that perform type A additional section
   processing, i.e., name server (NS), location of services (SRV) and
   mail exchange (MX) query types, must be redefined to perform both
   type A and type AAAA additional section processing.  These
   definitions mean that a name server must add any relevant IPv4
   addresses and any relevant IPv6 addresses available locally to the
   additional section of a response when processing any one of the above
   queries."

(e.g. dig MX example.stdlib.net @ns-191.awsdns-23.com.) .

The section you've quoted is just pointing out that a query for a
q-tuple of type AAAA would not normally by itself trigger any
additional-section processing. As worded, I think it's actually wrong.
A query of type AAAA might trigger additional section processing if
the query arrives at the parent of a delegated zone. For example the
query;

dig AAAA www.google.com @a.root-servers.net.

plainly does trigger additional section processing. (though one might
argue it was the name, not the type, that pulled the trigger).

2011/3/3 Jehan Pagès <[email-masked]>:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

-- 
Colm

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Mar 2011 18:01:41 +1100

In message <AANLkTin_GMbCxTV8XTqMKM5RE=[email-masked]>, =?IS
> argue it was the name, not the type, that pulled the trigger).

No. That is not addition section processing.  That is referral
processing.

Additional section processing would be returning A and AAAA to
NS queries.

> 2011/3/3 Jehan Pag=E8s <[email-masked]>:
> > Hi all,
> >
> > I have a small question about the IPv6 resource records extension (RFC359=
> 6).
> > As section 2.3 states:
> > =AB=A0A type AAAA query does not trigger additional section processing.=
> =A0=BB. Fine.
> >
> -- =
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 4 Mar 2011 16:12:34 +0900

Hi,

> the query arrives at the parent of a delegated zone. For example the

I did read this section you quote but from my understanding this is a
different case. It says that if some query already makes *A additional
section processing*, then it should do both A and AAAA additional
section processing. Hence the examples: NS, SRV, MX which all do A
additional section processing.

This is not what I am talking about. I am talking about *direct* A
query (answer section) and *direct* AAAA query. And I believe the
section I quoted is the one answering how it is currently
standardized: no additional section processing.

> argue it was the name, not the type, that pulled the trigger).

That's what I say. Some servers out there already do this because that
indeed seems so logical. And I agree with this behavior. Simply this
is not the standardized recommended behavior. This is why I ask why,
and maybe we could make it the default standardized behavior unless
someone comes up with good reasons against.

Jehan

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 3 Mar 2011 23:13:09 -0800

and

dig NS www.google.com @a.root-servers.net.

return literally byte-identical responses after the question section.

dig NS com @a.root-servers.net.

too (with EDNS enabled). I find it hard to reason about what the difference is.

-- 
Colm

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Mar 2011 23:03:36 +1100

In message <[email-masked]>, =?IS
O-8859-1?Q?Colm_MacC=E1rthaigh?= writes:
> > No. That is not addition section processing. =A0That is referral
> > processing.
> >
> too (with EDNS enabled). I find it hard to reason about what the difference=
>  is.

They are all referrals.

"dig NS com @a.gtld-servers.net" triggers additional section processing.

Yes address records get added in both cases but only in the second are
they optional.
 
> --=20

---

From: Dave Lawrence <[email-masked]>
Date: Fri, 4 Mar 2011 11:38:58 -0500

Colm MacCárthaigh writes:
> > processing.  Additional section processing would be returning A
> > and AAAA to NS queries.
> 
> I find it hard to reason about what the difference is.

At a delegating parent there is no meaningful difference because the
referral processing will always happen before additional processing
can even be considered.

There's quite a meaningful difference at the actual authority,
however.

dig a www.google.com @ns1.google.com
dig aaaa www.google.com @ns1.google.com
dig ns www.google.com @ns1.google.com

---

From: Dave Lawrence <[email-masked]>
Date: Fri, 4 Mar 2011 11:42:29 -0500

> dig ns www.google.com @ns1.google.com

Or to illustrate the point a bit better by using the actual zone cut,
these all have three distinctly different replies:

dig a google.com @ns1.google.com
dig aaaa google.com @ns1.google.com
dig ns google.com @ns1.google.com

Neither qtype A nor AAAA triggers additional section processing.  NS does.

---

From: Jehan Pagès <[email-masked]>
Date: Sat, 5 Mar 2011 03:48:31 +0900

Hi,

> Neither qtype A nor AAAA triggers additional section processing.  NS does.

Indeed. So what about the idea of proposing an update to this? I think
that it seems a pretty good and logical idea to trigger an A
additional section processing for AAAA and vis-versa.
Don't you think?

Regards,

Jehan