resolved: "resolvectl query" not working with for some addresses my corporate network #19394
Labels
Comments
|
Please enable debug logging in resolved ( |
poettering
added
needs-reporter-feedback ❓
Full log is here: |
|
hmm, weird. Any chance you can install debug symbols for this, and install gdb and then attach gdb to the running instance and set a breakpoint to It's a bit of a learning curve if you don't know gdb though |
|
when i try to resolve the same hostname here, all works, so this is really strange |
|
It happens only when my VPN link is up. The last working for me systemd-resolve is 247.3-3.fc35 Yes as you can see, some of the requests also did not resolved, but this was more likely was a rare exception. But starting with version 248~rc1-1.fc35 all queries stopping resolving. |
|
This is happening to me with Dallas airport's WiFi. I can't resolve the captive portal's hostname with resolved 248.3: But oddly, resolving only v4 works just fine! There's no AAAA record: There's a single nameserver on the network: Dig also has no issues with this server: Here's the debug log for one query: |
|
I think the needs-reporter-feedback label should be dropped now (logs have been provided as requested). |
mrc0mmand
removed
the
needs-reporter-feedback ❓
|
I'm seeing similar behavior with a Response Policy Zone (RPZ) in BIND. Like above |
|
We have the same problem with |
|
Looks like three different users are all experiencing this issue, any update? Is further information needed? If so, what information? I'm happy to provide any additional information. |
|
Could this be similar to #17384? I seem to have the same behavior via |
|
Sorry for double-posting. On a whim, I tried to add an AAAA record to the RPZ and |
|
@g5pw, from my testing the only way this resolves the above failure is if a AAAA record is created for the RPZ host(s). However, my testing also seems to show that if a AAAA record is created the IPv6 address in the response is preferred over the IPv4 address. In my case this is a problem as the host in question does not actually have an IPv6 address. |
|
Adding a data point, I encountered this issue as well on Fedora 35 and can consistently reproduce it. |
I've had the same symptom with my RPZ (Invalid argument without -4/-6, working with explicit -4). The workaround of adding an AAAA record helped here. |
|
@jluebbe what record would you add for a host that does not have an ipv6 address? |
My host actually has a v6 address (which I just didn't have in my RPZ before). I don't have a good suggestion for your case, sorry. |
|
Hey all, we're still seeing this bug, output from journalctl: version: |
|
Maybe I'm having the same problem? Can't resolve our AWS instance/load-balancer host names: Using Is there a workaround for this? I've been manually touching up my
System details: |
|
I would be more than happy to pair up with anyone interested in resolving this -- I can make myself available whenever. |
|
For bind with RPZ, this appears to work: Instead of this in your rpz.local zone: You do this: Now A/AAAA lookups both return the CNAME. And the CNAME target (for a legit domain) can safely return only an A record. Also, as mentioned above, regular queries work fine. But calls through the bus (resolvectl or libnss-resolve) only exhibit the issue. As for the cause of the issue, I think we're moving through these parts: void dns_transaction_process_reply(DnsTransaction *t, DnsPacket *p, bool encrypted) {
...
/* After the superficial checks, actually parse the message. */
r = dns_packet_extract(p);
if (r < 0) {
...
dns_transaction_complete(t, DNS_TRANSACTION_INVALID_REPLY);
return;
}
dns_transaction_process_dnssec(t);
return;
...static void dns_transaction_process_dnssec(DnsTransaction *t) {
...
dns_transaction_cache_answer(t);
if (t->answer_rcode == DNS_RCODE_SUCCESS)
dns_transaction_complete(t, DNS_TRANSACTION_SUCCESS);
else
dns_transaction_complete(t, DNS_TRANSACTION_RCODE_FAILURE);
return;void dns_transaction_complete(DnsTransaction *t, DnsTransactionState state) {
...
log_debug("%s transaction %" PRIu16 " for <%s> on scope %s on %s/%s now complete with <%s> from %s (%s; %s).",
...We get this log message: And this: But not this, which should be between those two: Because of the last message with static void dns_transaction_cache_answer(DnsTransaction *t) {
...
dns_cache_put(&t->scope->cache,
t->scope->manager->enable_cache,
dns_transaction_key(t),
t->answer_rcode,
t->answer,
DNS_PACKET_CD(t->received) ? t->received : NULL, /* only cache full packets with CD on,
* since our usecase for caching them
* is "bypass" mode which is only
* enabled for CD packets. */
t->answer_query_flags,
t->answer_dnssec_result,
t->answer_nsec_ttl,
t->received->family,
&t->received->sender);int dns_cache_put(
DnsCache *c,
DnsCacheMode cache_mode,
DnsResourceKey *key,
int rcode,
DnsAnswer *answer,
DnsPacket *full_packet,
uint64_t query_flags,
DnssecResult dnssec_result,
uint32_t nsec_ttl,
int owner_family,
const union in_addr_union *owner_address) {
...
/* See https://tools.ietf.org/html/rfc2308, which say that a matching SOA record in the packet is used to
* enable negative caching. We apply one exception though: if we are about to cache a weird rcode we do so
* regardless of a SOA. */
r = dns_answer_find_soa(answer, key, &soa, &flags);
if (r < 0)
goto fail;
if (r == 0 && !weird_rcode)
return 0;
...Probably (And not in the authority section, but in the additional one. See other people's dig output.) But, that was not the problem either. The problem is here: This code is invoked from dns_transaction_complete() With these values: So, because expect->rr->ttl holds 1 and rr->ttl holds 0, we get This TTL of Not sure where the problem is. But this should be sufficient debug info to get to the bottom of this. Cheers, |
|
Fixed by 8ec951e, i.e. merging multiple RRs with different TTLs into one rrset is no longer refused with EINVAL. Closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Distro: Fedora Rawhide
The text was updated successfully, but these errors were encountered: