... And please don't misunderstand; I'm not asking you to debug my network. 
There are actually two parts here, one is what the clients are/n't doing with 
the AAAA responses they receive, and that's sort of beside the point and came 
up incidentally, They aren't really experiencing any issues or problems just 
from the fact that they get AAAA responses; it was mostly just wishful thinking 
in the sense of "why give them responses they don't need and can't ever use?" 
No machines on this network have IPv6 default routes in their routing tables. 
I'm not trying to argue with you or make a stink about it. Hopefully I didn't 
come across that way.

But setting that aside, on the BIND server itself, IPv6 is not bound on any NIC 
(only the built-in Windows ISATAP adapter which is unsupported to disable), and 
the IPv6 routing table does not contain any routes at all except for ::1/128 
and ff00::/8  -  so that's why it was puzzling to me that it BIND would still 
try to use IPv6 for outbound queries, especially when started with the -4 flag. 
The response you get back from trying to ping any (ipv6) host in an unreachable 
network in this situation (on a Windows kernel) is not an ICMP Unreachable, but 
rather a "Transmit Failed: General Failure" which doesn't show up anywhere in a 
packet trace, even on the loopback adapter. If BIND is looking for the ICMP 
message specifically to decide whether IPv6 is go or no-go, perhaps it's not 
perceiving that General Failure means "don't keep trying this, it will never 
work" so it's still waiting for the timeout. I'm not saying you have to chase 
this down, just pointing out that this seems (to me) to be unexpected behavior 
on a standard-configuration Windows host system in an IPv4-only network.

-Steve


-----Original Message-----
From: Ondrej Sur� 
Sent: Monday, January 20, 2020 9:37 AM
To: Steve Farr 
Cc: bind-users@lists.isc.org
Subject: Re: Slow recursive query performance on Windows x64

The problem is that apparently[*] the machines in your network have default 
IPv6 routes, but you don t have IPv6 connectivity. Fix that and you don t have 
to apply any bandaids. I think we should just remove filter-aaaa in the next 
release cycle of BIND 9, having the feature doesn t do any good for the health 
of the Internet.

* - Normally, the ICMP unreachables are generated by local kernel, and based on 
the evidences you provided (timeouts) it doesn t, so something is misconfigured 
either in your network or on that particular machine. Debugging your network is 
beyond the scope of this mailing list.

Ondrej
--
Ondrej Sur    ISC

> On 20 Jan 2020, at 15:19, Steve Farr via bind-users 
> <bind-users@lists.isc.org> wrote:
> 
> ?Yeah, it's hard to disagree on the "should" part but we all definitely have 
> to administer networks in an imperfect world... To my mind, when there's zero 
> ipv6 connectivity beyond the LAN, it would be handy to not ask the firewall 
> to create 3x more TCP connections that it can never complete, and/or have it 
> send unreachables for all of them, especially on a larger network, so I would 
> suggest that even if it is "wrong," filter-aaaa-on-v4 is probably still 
> "helpful" in some situations, particularly where v6 is not available. The 
> network that I originally posted about is small, but I administer a number of 
> larger ones and this has been very eye-opening, so I do thank you all for 
> your contributions to the conversation. 
> 
> It looks like I'd have to compile the filter plugin separately on Windows 
> since it's not already integrated, and I don't see a dll or exe for it in the 
> bin folder... That's all right though; I'm just glad to have the query times 
> be so much quicker now! 
> 
> In case it's useful for anyone to know, I did just now try running named with 
> the -4 option, taking out the server ::/0 { bogus yes; }; and it still has 
> the same delay problem, so it appears that even with -4 it's still trying to 
> do something on v6 that it shouldn't be doing. So, server ::/0 { bogus yes; 
> }; is still the fix... at least on Windows, anyway. Many thanks again to all 
> of you for the insightful responses. 
> 
> -Steve
> 
> -----Original Message-----
> From: bind-users <bind-users-boun...@lists.isc.org> On Behalf Of Mark 
> Andrews
> Sent: Monday, January 20, 2020 1:45 AM
> To: Lee
> Cc: Ondrej Sury
> Subject: Re: Slow recursive query performance on Windows x64
> 
> Devices should return ICMP unreachables when networks are not reachable.  
> This allows applications to move onto the next address.  Not returning 
> unreachables results in timeouts being the mechanism to move to the next 
> address.
> 
> Additionally applications can make parallel connection attempts.  This works 
> particularly well for TCP and is what Happy Eyeballs does with a slight delay 
> (sub second) between each different address. Once a TCP connection succeeds 
> the other connection attempts are aborted.  Too many developers have coped 
> out on providing fast multi-homing support.  It usually only takes small 
> while to convert a application from serial connection attempts to parallel 
> connection attempts to the addresses returned from getaddrinfo().  What s 
> more work is adding MIF (multiple interface) support which allows you to try 
> different source addresses as well.
> 
> Mark
> 
>> On 20 Jan 2020, at 17:16, Lee <ler...@gmail.com> wrote:
>> 
>>> On 1/20/20, Ondrej Sur  <ond...@isc.org> wrote:
>>> 
>>> Please note that filter-aaaa-on-v4 was always wrong.
>> 
>> how so?
>> 
>>> You should fix your network instead. It s a bandaid, not a fix.
>> 
>> My ISP doesn't offer ipv6, so I'm not sure how to fix my network..
>> unless you mean disable ipv6 on everything?  (which I'm not sure is 
>> even possible)
>> 
>> Lee
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>> 
>> bind-users mailing list
>> bind-users@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
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to