Re: [Pdns-users] Rcode 3 NXDOMAIN for existing CNAME
Hi Peter Thomassen, Since this is the background of the DNS query I find your suggestion a valid solution for the problem that lego could implement. I agree! Thanks for clearing this up, I was on the wrong track about what the goal of that query was. I looked at the pcap again - the one you also have - and it turns out that lego already asks for a CNAME - not TXT - record and the answer is NXDOMAIN.. - Domain Name System (response) Transaction ID: 0xc277 Flags: 0x8183 Standard query response, No such name Questions: 1 Answer RRs: 1 Authority RRs: 1 Additional RRs: 1 Queries _acme-challenge.bender-doh.applied-privacy.net: type CNAME, class IN Name: _acme-challenge.bender-doh.applied-privacy.net [Name Length: 46] [Label Count: 4] Type: CNAME (Canonical NAME for an alias) (5) Class: IN (0x0001) Answers _acme-challenge.bender-doh.applied-privacy.net: type CNAME, class IN, cname bender-doh.acme-dns-challenge.applied-privacy.net Name: _acme-challenge.bender-doh.applied-privacy.net Type: CNAME (Canonical NAME for an alias) (5) Class: IN (0x0001) Time to live: 86400 (1 day) Data length: 32 CNAME: bender-doh.acme-dns-challenge.applied-privacy.net Authoritative nameservers Additional records - so now I suspect the recursive resolver (not pdns) does something unexpected but I have to analyze all recursive resolver DNS traffic before making further conclusions. thanks! Christoph ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Rcode 3 NXDOMAIN for existing CNAME
On 3/25/23 14:04, Christoph wrote: My understanding is that ACME is about whether there is a TXT RRset with the challenge record; if it is not there, it's irrelevant whether the outcome is NXDOMAIN or NODATA/NOERROR. OK, now I understand where the misunderstanding comes from. Thanks for elaborating. The DNS query we are talking about is not about validating the ACME challenge, it is a DNS query that lego triggers to learn which DNS record it has to create/update via the DNS provider's DNS API to place the challenge in the DNS record in the next step. If there is no CNAME it will create the record at the fixed place _acme-challenge. if _acme-challenge. is a CNAME it will follow it recursively to find out which record it should actually update/create. Since this is the background of the DNS query I find your suggestion a valid solution for the problem that lego could implement. I agree! Thanks for clearing this up, I was on the wrong track about what the goal of that query was. Cheers, Peter -- https://desec.io/ ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Rcode 3 NXDOMAIN for existing CNAME
>> However, I doubt this is a reasonable approach for your ACME >> client. Sounds like a simple enough solution to me, can you elaborate why you doubt it is reasonable? My understanding is that ACME is about whether there is a TXT RRset with the challenge record; if it is not there, it's irrelevant whether the outcome is NXDOMAIN or NODATA/NOERROR. OK, now I understand where the misunderstanding comes from. Thanks for elaborating. The DNS query we are talking about is not about validating the ACME challenge, it is a DNS query that lego triggers to learn which DNS record it has to create/update via the DNS provider's DNS API to place the challenge in the DNS record in the next step. If there is no CNAME it will create the record at the fixed place _acme-challenge.SAN> if _acme-challenge. is a CNAME it will follow it recursively to find out which record it should actually update/create. Since this is the background of the DNS query I find your suggestion a valid solution for the problem that lego could implement. We will see how the lego developer sees it. lego had experimental CNAME opt-in support for a while and it is now enabled by default. If the software's behavior depends on that detail, it doesn't seem like it is doing a reasonable thing. It should not need to know / care about the specific circumstances of the challenge record's absence. It would be a weird workaround, when the better approach is to make the ACME client just understand rcodes correctly :) My understanding was that simply looking at the rcode only without Peter Thomassen's workaround is not enough because both cases (existing and not existing) both result in an NXDOMAIN rcode? That's right, but I don't see why the ACME client should investigate whether there is a CNAME present. Can you name a reason why it should? I hope my text above answers your question, if it does not please let me know. best regards, Christoph ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Rcode 3 NXDOMAIN for existing CNAME
On 3/25/23 11:44, Christoph wrote: >> However, I doubt this is a reasonable approach for your ACME >> client. Sounds like a simple enough solution to me, can you elaborate why you doubt it is reasonable? My understanding is that ACME is about whether there is a TXT RRset with the challenge record; if it is not there, it's irrelevant whether the outcome is NXDOMAIN or NODATA/NOERROR. If the software's behavior depends on that detail, it doesn't seem like it is doing a reasonable thing. It should not need to know / care about the specific circumstances of the challenge record's absence. It would be a weird workaround, when the better approach is to make the ACME client just understand rcodes correctly :) My understanding was that simply looking at the rcode only without Peter Thomassen's workaround is not enough because both cases (existing and not existing) both result in an NXDOMAIN rcode? That's right, but I don't see why the ACME client should investigate whether there is a CNAME present. Can you name a reason why it should? Thanks, Peter -- https://desec.io/ ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Rcode 3 NXDOMAIN for existing CNAME
On Tue, 2023-03-21 at 16:57 +0100, Peter Thomassen via Pdns-users wrote: > Well, if you ask for the xNAME (e.g. CNAME) record, then you'll get that > (with a NOERROR code). So by issuing an xNAME query in addition to the record > type you're interested in, you can learn whether the NXDOMAIN is due to the > queried name not existing, or due to the CNAME chain target not existing. > > However, I doubt this is a reasonable approach for your ACME client. It would be a weird workaround, when the better approach is to make the ACME client just understand rcodes correctly :) Cheers, Peter ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Rcode 3 NXDOMAIN for existing CNAME
On 3/13/23 11:41, Chris Hofstaedtler | Deduktiva via Pdns-users wrote: * Christoph [230312 19:52]: When there is an xNAME chain, the RCODE field is set as follows: When an xNAME chain is followed, all but the last query cycle necessarily had no error. The RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that response. If the xNAME chain was terminated by an error, it will be that error code. Is it possible to construct a query that asks the server to not follow the chain? From what I can tell, there is no way of not getting NXDOMAIN here. Well, if you ask for the xNAME (e.g. CNAME) record, then you'll get that (with a NOERROR code). So by issuing an xNAME query in addition to the record type you're interested in, you can learn whether the NXDOMAIN is due to the queried name not existing, or due to the CNAME chain target not existing. However, I doubt this is a reasonable approach for your ACME client. Cheers, Peter -- https://desec.io/ ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Rcode 3 NXDOMAIN for existing CNAME
* Christoph [230312 19:52]: > >When there is an xNAME chain, the RCODE field is set as follows: > > > > When an xNAME chain is followed, all but the last query cycle > > necessarily had no error. The RCODE in the ultimate DNS response > > MUST BE set based on the final query cycle leading to that > > response. If the xNAME chain was terminated by an error, it will > > be that error code. > > Is it possible to construct a query that asks the server > to not follow the chain? >From what I can tell, there is no way of not getting NXDOMAIN here. TTBOMK, clients talking directly to an authoritative server must be prepared for this scenario. They need to implement all of DNS, not just the wire protocol for a single query. -- Chris Hofstaedtler / Deduktiva GmbH (FN 418592 b, HG Wien) www.deduktiva.com / +43 1 353 1707 ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Rcode 3 NXDOMAIN for existing CNAME
* Christoph via Pdns-users [230309 18:42]: > Hi, > [cname chain where target name does not exist] > > Does this behavior meet RFC standards? (so lego is wrong?) > Can the behavior be changed by a configuration setting? RFC 6604 spells out the behaviour quite explicitly: https://www.rfc-editor.org/rfc/rfc6604#section-3 Thanks to Peter van Dijk for the RFC pointer. Hope this helps, -- Chris Hofstaedtler / Deduktiva GmbH (FN 418592 b, HG Wien) www.deduktiva.com / +43 1 353 1707 ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
