resolved stub resolver doesn't provide RRSIG data in replies when DO/CD queries are sent to it #4621
Comments
|
But besides the bug report... thanks for bringing DNSSEC so close to the end-user! |
|
Well, resolved is not supposed to be a DNS server, it's supposed to be exactly good enough so that libc-like DNS clients can resolve their stuff, and we carry enough info for the AD bit to be set. That's by design really. See the commit msg of b30bf55. If we don't set AD properly for negative replies, that'd be a bug however, indeed. |
poettering
changed the title
|
Op 12-11-16 om 05:37 schreef Lennart Poettering:
Thanks Lennart. I understand systemd-resolved is not a fully fledged ldns and getdns can do this for example. Perhaps this could be a enhancement request then? Also, I have to admit that I cannot find it specified in the RFCs right
|
|
well, if clients want to validate DNSSEC on their own, they should probably not involve resolved then I think... But anyway, I'll turn this into an RFE, but I don't think this is really in focus for us. |
poettering
changed the title
|
Hi, I'm not sure if I'm seeing the same issue, or at least a variant of the same issue. I configured my system (ubuntu 16.10) to use systemd as the dns resolver, and that broke lookups of RRSIG records. If i try to use dig i get this result: and by using systemd-resolve directly i get this result: |
If /etc/resolv.conf points to 127.0.0.53, what choice do they have? |
When we managed to prove non-existance of a name, then we should properly propagate this to clients by setting the AD bit on NXDOMAIN. See: systemd#4621
This bit should be fixed now with #5347. Dropping the v233 milestone hence, as what remains of this issue is mostly RFE. |
When we managed to prove non-existance of a name, then we should properly propagate this to clients by setting the AD bit on NXDOMAIN. See: systemd#4621
|
Please, help! Or in other words, I would like to have an answer to Anders’ question above. My very own app which does DANE, broke on Ubuntu 18.04 LTS. It worked great in Ubuntu 14.04 LTS and Ubuntu 16.04 LTS. This is a software bug for sure. Now, I have to report this somewhere, even if it is to myself. A) Ubuntu B) systemd-resolved
C) Unbound D) Myself
E) End-Users Another example $ dig @127.0.0.1 www.nlnetlabs.nl. A +dnssec $ dig @8.8.8.8 www.nlnetlabs.nl. A +dnssec Yet another example
There must be a totally easy answer, which I do not see. My app does not work on default in Ubuntu 18.04 LTS at all, because the DNS result is even ‘bogus’. Please, help! I cross-posted this on the Unbound mailing-list… |
|
If this is not a DNS server, perhaps we shouldn't use it as the default DNS server? |
|
Has anyone an idea where to report my bug: Is it A, B, C, D, or E? As explained on the Unbound mailing list, I found another workaround for Ubuntu 18.04 LTS: |
|
the work-around is easy, just specify the real dns server on your diag tools. this forces you to check what server resolved is actually using first, which is simple: |
|
@traud I don't know the official answer, but I did (A). https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1782679 |
|
According to the BIND docs, the tool I stumbled over this issue here because I was wondering and debugging why It's because Of course, one can always manually tell |
|
@poettering I think, "resolved is not supposed to be a real DNS server" answer can't be counted as valid in context of DNSSEC support requests. For now, using systemd's "stub" resolver is the only way on linux systems to have link-aware DNS resolver (like, say, MacOS have long time ago). Unfortunately, there is absolutely no way to have this logic out-of-the-box, without tons of magic (like auto-regeneration of dnsmasq/bind configs triggered by network status change), which is definitely not a way to go for typical user. Talking that, for now, almost all of the linux distros moved to systemd-resolved's stub resolver as default system resolver, so, now it is de-facto standard for linux system (whatever it will be: desktop, server or "new generation of embedded" (arm/mips/risc-v powered by ubuntu/debian/fedora). And all of that people, who use that systems, DO need full DNSSEC support in their systems, but not just "stub-resolver will internally validate the answer (and will fail to resolve on MITM), but won't let you get the signatures". And, as already mentioned, current behavior also brakes network diagnostic tools like dig... So, just as all the people above, I signing on the "petition" to SystemD developers to fully implement DNSSEC in stub resolver, starting with |
|
// well, that situation with "broken DNSSEC compatibility everywhere" is one of the reasons why such monsters as DNS-over-HTTP(S) was created and gains their popularity :-/ |
|
Its been four years, any progress? |
This substantially beefs up the local DNS stub feature set in order to allow local clients to do DNSSEC validation through the stub. Previously we'd return NOTIMP if we'd get a DO or DO+CD lookup. With this change we'll instead: 1. If we get DO+CD requests (i.e. DNSSEC with no local checking) we'll proxy DNS queries and response mostly unmodified to/from upstream DNS servers if possible (this is called "bypass" mode). We will patch in new request IDs, (and patch them back out on reply), so that we can sanely keep track of things. We'll also maintain a minimal local cache for such lookups, always keeping the whole DNS packets in it (if we reply from cache we'll patch the TTLs of all included RRs). 2. If we get DO requests without CD (i.e. DNSSEC with local checking) we'll resolve and validate locally. In this mode we will not proxy packets, but generate our own. We will however cache the combination of answer RRs (along with their packet section assignments) we got back in the cache, and use this information to generate reply packets from the DNS stub. In both cases: if we determine a lookup is to be answered from LLMNR or mDNS we'll always revert to non-DNSSEC, non-proxy operation as before. Answers will lack the DO bit then, since the data cannot be validated via DNSSEC by the clients. To make this logic more debuggable, this also adds query flags for turning off RR sources. i.e. cache/network/zone/trust anchor/local synthesis may now be disabled individually for each lookup. The cache is substantially updated to make all this work: in addition to caching simple RRs for lookup RR keys, we'll now cache the whole packets and the whole combination of RRs, so that we can answer DO and DO+CD replies sensibly according to the rules described above. This sounds wasteful, but given that the DnsResourceRecord/DnsResourceKey/DnsAnswer/DnsPacket objects are all ref-counted and we try to merge references the actual additional memory used should be limited (but this might be something to optimize further later on). To implement classic RR key lookups and new-style packet proxy lookups (i.e. the ones necessary for DO+CD packet proxying, as described above) DnsTransaction and DnsQuery objects now always maintain either a DnsResourceKey/DnsQuestion as lookup key or a DnsPacket for "bypass" mode. Fixes: systemd#4621 systemd#17218
This substantially beefs up the local DNS stub feature set in order to allow local clients to do DNSSEC validation through the stub. Previously we'd return NOTIMP if we'd get a DO or DO+CD lookup. With this change we'll instead: 1. If we get DO+CD requests (i.e. DNSSEC with no local checking) we'll proxy DNS queries and response mostly unmodified to/from upstream DNS servers if possible (this is called "bypass" mode). We will patch in new request IDs, (and patch them back out on reply), so that we can sanely keep track of things. We'll also maintain a minimal local cache for such lookups, always keeping the whole DNS packets in it (if we reply from cache we'll patch the TTLs of all included RRs). 2. If we get DO requests without CD (i.e. DNSSEC with local checking) we'll resolve and validate locally. In this mode we will not proxy packets, but generate our own. We will however cache the combination of answer RRs (along with their packet section assignments) we got back in the cache, and use this information to generate reply packets from the DNS stub. In both cases: if we determine a lookup is to be answered from LLMNR or mDNS we'll always revert to non-DNSSEC, non-proxy operation as before. Answers will lack the DO bit then, since the data cannot be validated via DNSSEC by the clients. To make this logic more debuggable, this also adds query flags for turning off RR sources. i.e. cache/network/zone/trust anchor/local synthesis may now be disabled individually for each lookup. The cache is substantially updated to make all this work: in addition to caching simple RRs for lookup RR keys, we'll now cache the whole packets and the whole combination of RRs, so that we can answer DO and DO+CD replies sensibly according to the rules described above. This sounds wasteful, but given that the DnsResourceRecord/DnsResourceKey/DnsAnswer/DnsPacket objects are all ref-counted and we try to merge references the actual additional memory used should be limited (but this might be something to optimize further later on). To implement classic RR key lookups and new-style packet proxy lookups (i.e. the ones necessary for DO+CD packet proxying, as described above) DnsTransaction and DnsQuery objects now always maintain either a DnsResourceKey/DnsQuestion as lookup key or a DnsPacket for "bypass" mode. Fixes: systemd#4621 systemd#17218
This substantially beefs up the local DNS stub feature set in order to allow local clients to do DNSSEC validation through the stub. Previously we'd return NOTIMP if we'd get a DO or DO+CD lookup. With this change we'll instead: 1. If we get DO+CD requests (i.e. DNSSEC with no local checking) we'll proxy DNS queries and response mostly unmodified to/from upstream DNS servers if possible (this is called "bypass" mode). We will patch in new request IDs, (and patch them back out on reply), so that we can sanely keep track of things. We'll also maintain a minimal local cache for such lookups, always keeping the whole DNS packets in it (if we reply from cache we'll patch the TTLs of all included RRs). 2. If we get DO requests without CD (i.e. DNSSEC with local checking) we'll resolve and validate locally. In this mode we will not proxy packets, but generate our own. We will however cache the combination of answer RRs (along with their packet section assignments) we got back in the cache, and use this information to generate reply packets from the DNS stub. In both cases: if we determine a lookup is to be answered from LLMNR or mDNS we'll always revert to non-DNSSEC, non-proxy operation as before. Answers will lack the DO bit then, since the data cannot be validated via DNSSEC by the clients. To make this logic more debuggable, this also adds query flags for turning off RR sources. i.e. cache/network/zone/trust anchor/local synthesis may now be disabled individually for each lookup. The cache is substantially updated to make all this work: in addition to caching simple RRs for lookup RR keys, we'll now cache the whole packets and the whole combination of RRs, so that we can answer DO and DO+CD replies sensibly according to the rules described above. This sounds wasteful, but given that the DnsResourceRecord/DnsResourceKey/DnsAnswer/DnsPacket objects are all ref-counted and we try to merge references the actual additional memory used should be limited (but this might be something to optimize further later on). To implement classic RR key lookups and new-style packet proxy lookups (i.e. the ones necessary for DO+CD packet proxying, as described above) DnsTransaction and DnsQuery objects now always maintain either a DnsResourceKey/DnsQuestion as lookup key or a DnsPacket for "bypass" mode. Fixes: systemd#4621 systemd#17218
This substantially beefs up the local DNS stub feature set in order to allow local clients to do DNSSEC validation through the stub. Previously we'd return NOTIMP if we'd get a DO or DO+CD lookup. With this change we'll instead: 1. If we get DO+CD requests (i.e. DNSSEC with no local checking) we'll proxy DNS queries and response mostly unmodified to/from upstream DNS servers if possible (this is called "bypass" mode). We will patch in new request IDs, (and patch them back out on reply), so that we can sanely keep track of things. We'll also maintain a minimal local cache for such lookups, always keeping the whole DNS packets in it (if we reply from cache we'll patch the TTLs of all included RRs). 2. If we get DO requests without CD (i.e. DNSSEC with local checking) we'll resolve and validate locally. In this mode we will not proxy packets, but generate our own. We will however cache the combination of answer RRs (along with their packet section assignments) we got back in the cache, and use this information to generate reply packets from the DNS stub. In both cases: if we determine a lookup is to be answered from LLMNR or mDNS we'll always revert to non-DNSSEC, non-proxy operation as before. Answers will lack the DO bit then, since the data cannot be validated via DNSSEC by the clients. To make this logic more debuggable, this also adds query flags for turning off RR sources. i.e. cache/network/zone/trust anchor/local synthesis may now be disabled individually for each lookup. The cache is substantially updated to make all this work: in addition to caching simple RRs for lookup RR keys, we'll now cache the whole packets and the whole combination of RRs, so that we can answer DO and DO+CD replies sensibly according to the rules described above. This sounds wasteful, but given that the DnsResourceRecord/DnsResourceKey/DnsAnswer/DnsPacket objects are all ref-counted and we try to merge references the actual additional memory used should be limited (but this might be something to optimize further later on). To implement classic RR key lookups and new-style packet proxy lookups (i.e. the ones necessary for DO+CD packet proxying, as described above) DnsTransaction and DnsQuery objects now always maintain either a DnsResourceKey/DnsQuestion as lookup key or a DnsPacket for "bypass" mode. Fixes: systemd#4621 systemd#17218
This substantially beefs up the local DNS stub feature set in order to allow local clients to do DNSSEC validation through the stub. Previously we'd return NOTIMP if we'd get a DO or DO+CD lookup. With this change we'll instead: 1. If we get DO+CD requests (i.e. DNSSEC with no local checking) we'll proxy DNS queries and response mostly unmodified to/from upstream DNS servers if possible (this is called "bypass" mode). We will patch in new request IDs, (and patch them back out on reply), so that we can sanely keep track of things. We'll also maintain a minimal local cache for such lookups, always keeping the whole DNS packets in it (if we reply from cache we'll patch the TTLs of all included RRs). 2. If we get DO requests without CD (i.e. DNSSEC with local checking) we'll resolve and validate locally. In this mode we will not proxy packets, but generate our own. We will however cache the combination of answer RRs (along with their packet section assignments) we got back in the cache, and use this information to generate reply packets from the DNS stub. In both cases: if we determine a lookup is to be answered from LLMNR or mDNS we'll always revert to non-DNSSEC, non-proxy operation as before. Answers will lack the DO bit then, since the data cannot be validated via DNSSEC by the clients. To make this logic more debuggable, this also adds query flags for turning off RR sources. i.e. cache/network/zone/trust anchor/local synthesis may now be disabled individually for each lookup. The cache is substantially updated to make all this work: in addition to caching simple RRs for lookup RR keys, we'll now cache the whole packets and the whole combination of RRs, so that we can answer DO and DO+CD replies sensibly according to the rules described above. This sounds wasteful, but given that the DnsResourceRecord/DnsResourceKey/DnsAnswer/DnsPacket objects are all ref-counted and we try to merge references the actual additional memory used should be limited (but this might be something to optimize further later on). To implement classic RR key lookups and new-style packet proxy lookups (i.e. the ones necessary for DO+CD packet proxying, as described above) DnsTransaction and DnsQuery objects now always maintain either a DnsResourceKey/DnsQuestion as lookup key or a DnsPacket for "bypass" mode. Fixes: systemd#4621 systemd#17218
This substantially beefs up the local DNS stub feature set in order to allow local clients to do DNSSEC validation through the stub. Previously we'd return NOTIMP if we'd get a DO or DO+CD lookup. With this change we'll instead: 1. If we get DO+CD requests (i.e. DNSSEC with no local checking) we'll proxy DNS queries and response mostly unmodified to/from upstream DNS servers if possible (this is called "bypass" mode). We will patch in new request IDs, (and patch them back out on reply), so that we can sanely keep track of things. We'll also maintain a minimal local cache for such lookups, always keeping the whole DNS packets in it (if we reply from cache we'll patch the TTLs of all included RRs). 2. If we get DO requests without CD (i.e. DNSSEC with local checking) we'll resolve and validate locally. In this mode we will not proxy packets, but generate our own. We will however cache the combination of answer RRs (along with their packet section assignments) we got back in the cache, and use this information to generate reply packets from the DNS stub. In both cases: if we determine a lookup is to be answered from LLMNR or mDNS we'll always revert to non-DNSSEC, non-proxy operation as before. Answers will lack the DO bit then, since the data cannot be validated via DNSSEC by the clients. To make this logic more debuggable, this also adds query flags for turning off RR sources. i.e. cache/network/zone/trust anchor/local synthesis may now be disabled individually for each lookup. The cache is substantially updated to make all this work: in addition to caching simple RRs for lookup RR keys, we'll now cache the whole packets and the whole combination of RRs, so that we can answer DO and DO+CD replies sensibly according to the rules described above. This sounds wasteful, but given that the DnsResourceRecord/DnsResourceKey/DnsAnswer/DnsPacket objects are all ref-counted and we try to merge references the actual additional memory used should be limited (but this might be something to optimize further later on). To implement classic RR key lookups and new-style packet proxy lookups (i.e. the ones necessary for DO+CD packet proxying, as described above) DnsTransaction and DnsQuery objects now always maintain either a DnsResourceKey/DnsQuestion as lookup key or a DnsPacket for "bypass" mode. Fixes: systemd#4621 systemd#17218
This substantially beefs up the local DNS stub feature set in order to allow local clients to do DNSSEC validation through the stub. Previously we'd return NOTIMP if we'd get a DO or DO+CD lookup. With this change we'll instead: 1. If we get DO+CD requests (i.e. DNSSEC with no local checking) we'll proxy DNS queries and response mostly unmodified to/from upstream DNS servers if possible (this is called "bypass" mode). We will patch in new request IDs, (and patch them back out on reply), so that we can sanely keep track of things. We'll also maintain a minimal local cache for such lookups, always keeping the whole DNS packets in it (if we reply from cache we'll patch the TTLs of all included RRs). 2. If we get DO requests without CD (i.e. DNSSEC with local checking) we'll resolve and validate locally. In this mode we will not proxy packets, but generate our own. We will however cache the combination of answer RRs (along with their packet section assignments) we got back in the cache, and use this information to generate reply packets from the DNS stub. In both cases: if we determine a lookup is to be answered from LLMNR or mDNS we'll always revert to non-DNSSEC, non-proxy operation as before. Answers will lack the DO bit then, since the data cannot be validated via DNSSEC by the clients. To make this logic more debuggable, this also adds query flags for turning off RR sources. i.e. cache/network/zone/trust anchor/local synthesis may now be disabled individually for each lookup. The cache is substantially updated to make all this work: in addition to caching simple RRs for lookup RR keys, we'll now cache the whole packets and the whole combination of RRs, so that we can answer DO and DO+CD replies sensibly according to the rules described above. This sounds wasteful, but given that the DnsResourceRecord/DnsResourceKey/DnsAnswer/DnsPacket objects are all ref-counted and we try to merge references the actual additional memory used should be limited (but this might be something to optimize further later on). To implement classic RR key lookups and new-style packet proxy lookups (i.e. the ones necessary for DO+CD packet proxying, as described above) DnsTransaction and DnsQuery objects now always maintain either a DnsResourceKey/DnsQuestion as lookup key or a DnsPacket for "bypass" mode. Fixes: systemd#4621 systemd#17218
This substantially beefs up the local DNS stub feature set in order to allow local clients to do DNSSEC validation through the stub. Previously we'd return NOTIMP if we'd get a DO or DO+CD lookup. With this change we'll instead: 1. If we get DO+CD requests (i.e. DNSSEC with no local checking) we'll proxy DNS queries and response mostly unmodified to/from upstream DNS servers if possible (this is called "bypass" mode). We will patch in new request IDs, (and patch them back out on reply), so that we can sanely keep track of things. We'll also maintain a minimal local cache for such lookups, always keeping the whole DNS packets in it (if we reply from cache we'll patch the TTLs of all included RRs). 2. If we get DO requests without CD (i.e. DNSSEC with local checking) we'll resolve and validate locally. In this mode we will not proxy packets, but generate our own. We will however cache the combination of answer RRs (along with their packet section assignments) we got back in the cache, and use this information to generate reply packets from the DNS stub. In both cases: if we determine a lookup is to be answered from LLMNR or mDNS we'll always revert to non-DNSSEC, non-proxy operation as before. Answers will lack the DO bit then, since the data cannot be validated via DNSSEC by the clients. To make this logic more debuggable, this also adds query flags for turning off RR sources. i.e. cache/network/zone/trust anchor/local synthesis may now be disabled individually for each lookup. The cache is substantially updated to make all this work: in addition to caching simple RRs for lookup RR keys, we'll now cache the whole packets and the whole combination of RRs, so that we can answer DO and DO+CD replies sensibly according to the rules described above. This sounds wasteful, but given that the DnsResourceRecord/DnsResourceKey/DnsAnswer/DnsPacket objects are all ref-counted and we try to merge references the actual additional memory used should be limited (but this might be something to optimize further later on). To implement classic RR key lookups and new-style packet proxy lookups (i.e. the ones necessary for DO+CD packet proxying, as described above) DnsTransaction and DnsQuery objects now always maintain either a DnsResourceKey/DnsQuestion as lookup key or a DnsPacket for "bypass" mode. Fixes: systemd#4621 systemd#17218
This substantially beefs up the local DNS stub feature set in order to allow local clients to do DNSSEC validation through the stub. Previously we'd return NOTIMP if we'd get a DO or DO+CD lookup. With this change we'll instead: 1. If we get DO+CD requests (i.e. DNSSEC with no local checking) we'll proxy DNS queries and response mostly unmodified to/from upstream DNS servers if possible (this is called "bypass" mode). We will patch in new request IDs, (and patch them back out on reply), so that we can sanely keep track of things. We'll also maintain a minimal local cache for such lookups, always keeping the whole DNS packets in it (if we reply from cache we'll patch the TTLs of all included RRs). 2. If we get DO requests without CD (i.e. DNSSEC with local checking) we'll resolve and validate locally. In this mode we will not proxy packets, but generate our own. We will however cache the combination of answer RRs (along with their packet section assignments) we got back in the cache, and use this information to generate reply packets from the DNS stub. In both cases: if we determine a lookup is to be answered from LLMNR or mDNS we'll always revert to non-DNSSEC, non-proxy operation as before. Answers will lack the DO bit then, since the data cannot be validated via DNSSEC by the clients. To make this logic more debuggable, this also adds query flags for turning off RR sources. i.e. cache/network/zone/trust anchor/local synthesis may now be disabled individually for each lookup. The cache is substantially updated to make all this work: in addition to caching simple RRs for lookup RR keys, we'll now cache the whole packets and the whole combination of RRs, so that we can answer DO and DO+CD replies sensibly according to the rules described above. This sounds wasteful, but given that the DnsResourceRecord/DnsResourceKey/DnsAnswer/DnsPacket objects are all ref-counted and we try to merge references the actual additional memory used should be limited (but this might be something to optimize further later on). To implement classic RR key lookups and new-style packet proxy lookups (i.e. the ones necessary for DO+CD packet proxying, as described above) DnsTransaction and DnsQuery objects now always maintain either a DnsResourceKey/DnsQuestion as lookup key or a DnsPacket for "bypass" mode. Fixes: systemd#4621 systemd#17218
This substantially beefs up the local DNS stub feature set in order to allow local clients to do DNSSEC validation through the stub. Previously we'd return NOTIMP if we'd get a DO or DO+CD lookup. With this change we'll instead: 1. If we get DO+CD requests (i.e. DNSSEC with no local checking) we'll proxy DNS queries and response mostly unmodified to/from upstream DNS servers if possible (this is called "bypass" mode). We will patch in new request IDs, (and patch them back out on reply), so that we can sanely keep track of things. We'll also maintain a minimal local cache for such lookups, always keeping the whole DNS packets in it (if we reply from cache we'll patch the TTLs of all included RRs). 2. If we get DO requests without CD (i.e. DNSSEC with local checking) we'll resolve and validate locally. In this mode we will not proxy packets, but generate our own. We will however cache the combination of answer RRs (along with their packet section assignments) we got back in the cache, and use this information to generate reply packets from the DNS stub. In both cases: if we determine a lookup is to be answered from LLMNR or mDNS we'll always revert to non-DNSSEC, non-proxy operation as before. Answers will lack the DO bit then, since the data cannot be validated via DNSSEC by the clients. To make this logic more debuggable, this also adds query flags for turning off RR sources. i.e. cache/network/zone/trust anchor/local synthesis may now be disabled individually for each lookup. The cache is substantially updated to make all this work: in addition to caching simple RRs for lookup RR keys, we'll now cache the whole packets and the whole combination of RRs, so that we can answer DO and DO+CD replies sensibly according to the rules described above. This sounds wasteful, but given that the DnsResourceRecord/DnsResourceKey/DnsAnswer/DnsPacket objects are all ref-counted and we try to merge references the actual additional memory used should be limited (but this might be something to optimize further later on). To implement classic RR key lookups and new-style packet proxy lookups (i.e. the ones necessary for DO+CD packet proxying, as described above) DnsTransaction and DnsQuery objects now always maintain either a DnsResourceKey/DnsQuestion as lookup key or a DnsPacket for "bypass" mode. Fixes: systemd#4621 systemd#17218
because it use systemd-resolved by default, and it cannot do DNSSEC validation systemd/systemd#4621 Commenting out instead of deleting, to remind us that sometimes in future we can return it back. Hopefully.
because it use systemd-resolved by default, and it cannot do DNSSEC validation systemd/systemd#4621 Commenting out instead of deleting, to remind us that sometimes in future we can return it back. Hopefully.
|
Is it supposed to be fixed? I tried to compile commit 372a500, still no validation is possible via 127.0.0.53. It does not seem to be fixed to me. Can you explain, why was it closed? Is ability to validate just +cd queries considered sufficient? |
|
It does not even fulfill original issue message. NSEC record have appeared, but RRSIG records are still missing. My upstream server provides them however. |
|
Is this issue tracked now under different id, @keszybz? Is the issue tested first somehow, before closed? |
Submission type
systemd version the issue has been seen with
Used distribution
In case of bug report: Expected behaviour you didn't see
In case of bug report: Unexpected behaviour you saw
In case of bug report: Steps to reproduce the problem
The text was updated successfully, but these errors were encountered: