(In reply to Pavel Šimerda (pavlix) from comment #3) > Looks like we have another interesting use case for precise unbound > configuration here. When a connection is IPv4 only and provides any forward > zones, we might (or might not) want to somehow filter out the IPv6 data as > those may not be available through a different channel. That's up to a > deeper analysis. > > Normally this would be handled by dualstack DNS resolution *and* connection > which is something I'm addressing with my `netresolve` library. If the > attempts to connect over IPv6 are REJECTed and ICMP/TCP error arrives, any > decent resolver fallbacks to IPv4. But if those are filtered out, a > variation of happy eyeballs (as implemented in `netresolve` comes in handy. > It's not possible to hide this behind the `getaddrinfo` call though. This sound more like the application (wget) issue. Wget could/should try the IPv4 address after failing to connect using IPv6. Maybe some unbound-control option for forward zones like 'filter-aaaa-on-v4' in BIND would be handy in this situation. That way we could filter out AAAA responses if for example the connection that provided the domain had only IPv4 connectivity. However I'm not sure if it is a good idea.
(In reply to Tomas Hozza from comment #6) > (In reply to Pavel Šimerda (pavlix) from comment #3) > > Looks like we have another interesting use case for precise unbound > > configuration here. When a connection is IPv4 only and provides any forward > > zones, we might (or might not) want to somehow filter out the IPv6 data as > > those may not be available through a different channel. That's up to a > > deeper analysis. > > > > Normally this would be handled by dualstack DNS resolution *and* connection > > which is something I'm addressing with my `netresolve` library. If the > > attempts to connect over IPv6 are REJECTed and ICMP/TCP error arrives, any > > decent resolver fallbacks to IPv4. But if those are filtered out, a > > variation of happy eyeballs (as implemented in `netresolve` comes in handy. > > It's not possible to hide this behind the `getaddrinfo` call though. > > This sound more like the application (wget) issue. Wget could/should try the > IPv4 address after failing to connect using IPv6. Trying the IPv4 address *after* a timeout is a bit late. As I already stated, I have a library solution in netresolve already but not many resolver libraries do that. > Maybe some unbound-control option for forward zones like 'filter-aaaa-on-v4' > in BIND would be handy in this situation. Just please note that BIND doesn't implement anything like that even though the names of the options may make that impression. > That way we could filter out AAAA > responses if for example the connection that provided the domain had only > IPv4 connectivity. However I'm not sure if it is a good idea. I'm not sure either but that's IMO the only solution for applications that don't perform A/AAAA queries in parallel. It also might be the only solution when you insist on using the correct view of a multiview domain, e.g. because they differ in authentication method.
Note that any data mangling will likely break DNSSEC (for applications doing validation on their own) ...
(In reply to Pavel Šimerda (pavlix) from comment #7) > (In reply to Tomas Hozza from comment #6) > > Maybe some unbound-control option for forward zones like 'filter-aaaa-on-v4' > > in BIND would be handy in this situation. > > Just please note that BIND doesn't implement anything like that even though > the names of the options may make that impression. I meant that something alike he option would be handy. The option does what the name express. If the client asks for DNS records using IPv4, and is specified in a special list (which includes ANY client by default), and the response does not include DNSSEC signatures, then the server will delete all AAAA records from the response. (In reply to Petr Spacek from comment #8) > Note that any data mangling will likely break DNSSEC (for applications doing > validation on their own) ... That's why I'm not sure it is a good idea. We should not do this by default, but rather make it a configuration option just for a particular forward zone.
(In reply to Petr Spacek from comment #8) > Note that any data mangling will likely break DNSSEC (for applications doing > validation on their own) ... I'm aware of the fact that modifications to the DNS view can theoretically cause problems like that. We would yet have to see whether for example dropping AAAA records while keeping A records would lead into any negative validation in applications. Would they try to verify the *absence* of AAAA records at all? (In reply to Tomas Hozza from comment #9) > > Just please note that BIND doesn't implement anything like that even though > > the names of the options may make that impression. > > I meant that something alike he option would be handy. Just wanted to make sure it's known. > That's why I'm not sure it is a good idea. We should not do this by default, > but rather make it a configuration option just for a particular forward zone. Yes, at least until we know whether it causes any problems or not.
(In reply to Pavel Šimerda (pavlix) from comment #10) > (In reply to Petr Spacek from comment #8) > > Note that any data mangling will likely break DNSSEC (for applications doing > > validation on their own) ... > > I'm aware of the fact that modifications to the DNS view can theoretically > cause problems like that. We would yet have to see whether for example > dropping AAAA records while keeping A records would lead into any negative > validation in applications. Would they try to verify the *absence* of AAAA > records at all? Yes, DNSSEC has authenticated proof-of-nonexistence. You can't "mask" a record without being caught by validating resolver.
(In reply to Petr Spacek from comment #11) > (In reply to Pavel Šimerda (pavlix) from comment #10) > > (In reply to Petr Spacek from comment #8) > > > Note that any data mangling will likely break DNSSEC (for applications doing > > > validation on their own) ... > > > > I'm aware of the fact that modifications to the DNS view can theoretically > > cause problems like that. We would yet have to see whether for example > > dropping AAAA records while keeping A records would lead into any negative > > validation in applications. Would they try to verify the *absence* of AAAA > > records at all? > > Yes, DNSSEC has authenticated proof-of-nonexistence. You can't "mask" a > record without being caught by validating resolver. It's true but it's not an answer to the question above. I'm aware that it's possible to verify non-existence of AAAA but IMO the question is whether applications will invalidate the result of the A query based on either empty or no AAAA response that doesn't validate. Actually it's two questions in one. Whether they typically do it. And whether they *should* do it, which will also be important for 'netresolve'. An example situation follows: TLSA -> validates properly A -> validates properly a) AAAA -> server error b) AAAA -> invalid empty answer
(In reply to Pavel Šimerda (pavlix) from comment #12) > a) AAAA -> server error Application will get SERVFAIL (or API-equivalent) if it tries to do AAAA query and somebody will strip AAAA records. It depends on the application if validation failure is reason to terminate connection attempt or if the application falls back to A record.
(In reply to Petr Spacek from comment #13) > (In reply to Pavel Šimerda (pavlix) from comment #12) > > a) AAAA -> server error > Application will get SERVFAIL (or API-equivalent) if it tries to do AAAA > query and somebody will strip AAAA records. OK, so server error and invalid result are basically on the same level. > It depends on the application if validation failure is reason to terminate > connection attempt or if the application falls back to A record. Then applications that are expected to cope with broken IPv6 name resolution should probably succeed in this case.
Getting back to it. So the VPN name server gives correct information on IPv4 and IPv6 address of which only IPv4 is actually accessible via the VPN. If we know it's a VPN resource thanks to the list of search domains, we might consider reducing the result to only include replies accessible through the VPN, otherwise we attempt to connect to likely inaccessible sites. If we don't know that (i.e. we use the VPN for all resources and we have no search domains list or the hostname doesn't match any of the domains), we're stuck anyway. So what happens when we do nothing on the client side? Then you typically try to connect to unreachable hosts. If your tool attempts to connect sequentialy (which is the most common way) then it depends on the infrastructure whether you get ICMP unreachable or you wait for a timeout. Of course the former is the correct way to handle it in the infrastructure. If your tool attempts to connect in parallel (netresolve/netconnect does that for example) but still prefers IPv6, then you may encounter a very short timeout for the IPv6 preference and then simply work over IPv4. No timeout would also imply virtually no preference, i.e. the two protocols would race and the first answered would be used. I don't think we're going to handle this any soon, setting low priority but keeping open for comments. Also this is probably not at all specific to the nm+dnssec-trigger+unbound setup, dnssec-trigger just happens to be flexible enough to provide a partial workaround.
I am not sure why there is needinfo against me.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Seems to work for me "as expected" ? root@thinkpad:/home/paul/libreswan (master *)# wget download.eng.brq.redhat.com/test.txt --2015-11-04 09:09:16-- http://download.eng.brq.redhat.com/test.txt Resolving download.eng.brq.redhat.com (download.eng.brq.redhat.com)... 2620:52:0:2230::a22:30f1, 10.34.48.241 Connecting to download.eng.brq.redhat.com (download.eng.brq.redhat.com)|2620:52:0:2230::a22:30f1|:80... failed: Permission denied. Connecting to download.eng.brq.redhat.com (download.eng.brq.redhat.com)|10.34.48.241|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2015-11-04 09:09:17 ERROR 404: Not Found.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.