Open pekniada opened 2 months ago
Probably related, but we experience a heavy increase in errors with stack-trace like this: Caused by: network.oxalis.vefa.peppol.lookup.api.LookupException: Unable to fetch 'http://B-2efe7b8d2c600a6193b3c25008552844.iso6523-actorid-upis.edelivery.tech.ec.europa.eu/iso6523-actorid-upis%3A%3A0192%3A984661185/services/busdox-docid-qns%3A%3Aurn%3Afdc%3Adigdir.no%3A2020%3Ainnbyggerpost%3Axsd%3A%3Ainnbyggerpost%23%23urn%3Afdc%3Adigdir.no%3A2020%3Ainnbyggerpost%3Aschema%3Adigital%3A%3A1.0' at network.oxalis.vefa.peppol.lookup.fetcher.ApacheFetcher.fetchResponseFromValidUri(ApacheFetcher.java:114) at network.oxalis.vefa.peppol.lookup.fetcher.ApacheFetcher.fetch(ApacheFetcher.java:67) ... 166 common frames omitted Caused by: java.net.UnknownHostException: B-2efe7b8d2c600a6193b3c25008552844.iso6523-actorid-upis.edelivery.tech.ec.europa.eu: Temporary failure in name resolution
This increase happened after bumping to oxalis 6.7.0, which includes vefa 3.7.0.
Probably related, but we experience a heavy increase in errors with stack-trace like this: Caused by: network.oxalis.vefa.peppol.lookup.api.LookupException: Unable to fetch 'http://B-2efe7b8d2c600a6193b3c25008552844.iso6523-actorid-upis.edelivery.tech.ec.europa.eu/iso6523-actorid-upis%3A%3A0192%3A984661185/services/busdox-docid-qns%3A%3Aurn%3Afdc%3Adigdir.no%3A2020%3Ainnbyggerpost%3Axsd%3A%3Ainnbyggerpost%23%23urn%3Afdc%3Adigdir.no%3A2020%3Ainnbyggerpost%3Aschema%3Adigital%3A%3A1.0' at network.oxalis.vefa.peppol.lookup.fetcher.ApacheFetcher.fetchResponseFromValidUri(ApacheFetcher.java:114) at network.oxalis.vefa.peppol.lookup.fetcher.ApacheFetcher.fetch(ApacheFetcher.java:67) ... 166 common frames omitted Caused by: java.net.UnknownHostException: B-2efe7b8d2c600a6193b3c25008552844.iso6523-actorid-upis.edelivery.tech.ec.europa.eu: Temporary failure in name resolution
This increase happened after bumping to oxalis 6.7.0, which includes vefa 3.7.0.
We've seen this as well, but this was actually just a correct result of the actual fix, where resolution errors are now correctly seen as LookupException instead of False NotFoundException and continue in Resolving based on configuration. These ('Unable to fetch ...') Errors were resolved on our side by tuning DNS configuration on client. Likely culprit is a bigger configuration issue with DNS Sec auth chain for edelivery.tech.ec.europa.eu domain, already reported to European Commission in April 2024 by us causing a lot of SERVFAIL responses from NS resolving domain.
Fixed as part of 96de5d0ca6ad4a752634619f2e77b73676c911d4
After deployment of Oxalis 6.7.0 using vefa-peppol 3.7.0 we have noticed initial lookups are enforcing public DNS from GOOGLE and CLOUDFLARE due to this commit: https://github.com/OxalisCommunity/vefa-peppol/commit/d6a1c0fe14f866989347a1156e8e12e2d79199e0 Public DNS is not really allowed in all enterprise environments and due to resolver logic sequentially using these servers before using system one, this is causing a performance drop and other related issues.
Can any DNS hardcoding be avoided or at least made configurable?