filter-aaaa-on-v4 does not filter AAAA if there is no existing A Record with the same FQDN - working as designed?

[addie]

Hi all,

I am not sure if the following behavior is working as designed or not.
I have configured filter-aaaa-on-v4 to yes on my DNS Server.

Regarding this filter option, I have a working and a non working example:

Working example (AAAA was filtered):

# dig www.google.com. AAAA +noall +answer +comments
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.2 <<>> www.google.com. AAAA +noall +answer +comments
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26914
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0


Non working example (AAAA was NOT filtered!):

# dig ipv6.msftconnecttest.com AAAA +noall +answer +comments
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.2 <<>> ipv6.msftconnecttest.com AAAA +noall +answer +comments
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44238
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
ipv6.msftconnecttest.com. 900 IN CNAME v6ncsi.msedge.net.
v6ncsi.msedge.net. 60 IN CNAME ncsi.6-c-0003.c-msedge.net.
ncsi.6-c-0003.c-msedge.net. 60 IN CNAME 6-c-0003.c-msedge.net.
6-c-0003.c-msedge.net. 60 IN AAAA 2a01:111:2003::52


As you can see in the second query the AAAA record was not filtered out of the response!


As a remark of the examples above:
- for www.google.com. there is an existing A-Record.
- for ipv6.msftconnecttest.com there is NO existing A-Record (AAAA only).


There also additional AAAA only Records with the same behavior where the AAAA records will not filtered out as well:
ipv6.google.com
loopsofzen.co.uk
ipv6.cybernode.com
v6.vvv.facebook.com

Question:
is this working as designed or not? if yes, for which reasons?
I expected that this filter will filter every AAAA record. I don't see any reason why this should work partialy.
Our goal is that no DNS Client should receive AAAA records, because there is no IPv6 connectivity from local network to the internet at all.

Any advice would be helpful.

[Tony Finch]

addie <ad...@gmx.ch> wrote:
>
> is this working as designed or not? if yes, for which reasons?

It isn't documented, but there is a comment in the code which says:

/*
* The filter-aaaa-on-v4 option should suppress AAAAs for IPv4
* clients if there is an A; filter-aaaa-on-v6 option does the same
* for IPv6 clients.
*/

https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=bin/named/query.c;hb=HEAD#l8311

The actual logic is considerably more complicated than that so I won't dig
into the details of what it does in particular situations...

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode
Northwest Forties, Cromarty: Southwesterly 5 or 6, backing southerly 5 to 7.
Moderate or rough. Fair. Good.

[addie]

So we can assume that this is working as designed?!
However, it would be very interesting to know why this policy does not filter AAAA Records when there is no A record. From my point of view this policy is useless.
If we want to prevent clients from receiving any AAAA Records for every case, there should not be any exception. Are there any critical side effects that I disregard?

[Mark Andrews]

In message <823d435a-eff7-48eb...@googlegroups.com>, addie write
s:

In reality this shouldn't be needed at all. This is a workaround
for a broken IPv6 stack (network/OS/application). Your network
layer should be telling the applications that IPv6 destinations are
unreachable and they should be moving onto the next address.

If there is no A record then there is no fallback possible so there
is no need for the workaround. What harm is there in returning the
AAAA? All you get is a reminder to fix your network / application
/ OS if a failure takes a long time to be reported.

Mark

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org