Re: How to update zone with dnssec-policy (error with nsupdate: RRset exists)
Am 05.07.2023 um 13:13 schrieb Matthias Fechner: So far, nsdiff generates expected output, next step is now to apply the changes in an automated way. If I try now to update some records remotely on the server I see in the log of the server: ==> /var/named/var/log/named.log <== 08-Jul-2023 07:40:22.962 update-security: info: client @0x848ac0760 93.182.104.69#18475/key idefix.fechner.net-beta.fechner.net: signer "idefix.fechner.net-beta.fechner.net" approved 08-Jul-2023 07:40:22.962 update: info: client @0x848ac0760 93.182.104.69#18475/key idefix.fechner.net-beta.fechner.net: updating zone 'fechner.net/IN': update unsuccessful: fechner.net/SOA: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET) What I did is at first execute nsdiff to control if the changes are making sense with: nsdiff -k ../.key fechner.net fechner.net ``` nsdiff: loading zone fechner.net. via AXFR from ns.fechner.net. zone fechner.net/IN: loaded serial 2023070228 (DNSSEC signed) OK nsdiff: loading zone fechner.net. from file fechner.net zone fechner.net/IN: loaded serial 2023070201 OK prereq yxrrset fechner.net. IN SOA ns.fechner.net. hostmaster.fechner.net. 2023070228 43200 7200 1814400 86400 update add fechner.net. 300 IN SOA ns.fechner.net. hostmaster.fechner.net. 2023070229 43200 7200 1814400 86400 update delete fechner.net. IN TXT "v=spf1 a mx a:anny.lostinspace.de mx:freebsd.org a:mx2.freebsd.org ~all" update add fechner.net. 300 IN TXT "v=spf1 a mx a:anny.lostinspace.de a:beta.fechner.net mx:freebsd.org a:mx2.freebsd.org ~all" update delete gitlab.fechner.net. IN TXT "v=spf1 a mx a:anny.lostinspace.de -all" update add gitlab.fechner.net. 300 IN TXT "v=spf1 a mx a:anny.lostinspace.de a:beta.fechner.net -all" update delete ark.fechner.net. IN TXT "v=spf1 a mx a:anny.lostinspace.de -all" update add ark.fechner.net. 300 IN TXT "v=spf1 a mx a:anny.lostinspace.de a:beta.fechner.net -all" update delete news.fechner.net. IN TXT "v=spf1 a mx a:anny.lostinspace.de -all" update add news.fechner.net. 300 IN TXT "v=spf1 a mx a:anny.lostinspace.de a:beta.fechner.net -all" send answer ``` So I tried to chain nsupdate to it with: nsdiff -k ../.key fechner.net fechner.net | nsupdate -k ../.key ``` nsdiff: loading zone fechner.net. via AXFR from ns.fechner.net. zone fechner.net/IN: loaded serial 2023070228 (DNSSEC signed) OK nsdiff: loading zone fechner.net. from file fechner.net zone fechner.net/IN: loaded serial 2023070201 OK update failed: NXRRSET Answer: ;; ->>HEADER<<- opcode: UPDATE, status: NXRRSET, id: 14683 ;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 ;; ZONE SECTION: ;fechner.net. IN SOA ;; TSIG PSEUDOSECTION: idefix.fechner.net-beta.fechner.net. 0 ANY TSIG hmac-sha256. 1688794822 300 32 re/dNrsChdUQSyzMox2O+uAQWJG7+LBWNkS19QmJ48U= 14683 NOERROR 0 ``` anyone an idea what can cause this? Gruß Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
You are wrong if you think the SOA record is only informal. It’s not, see https://www.rfc-editor.org/rfc/rfc2308 for more details. Then > In a similar way, bind should not object to the SOA mail contect being valid, > as a surprising number of zones actually fail to handle mail to that address mixes things that **are** important to DNS (caches) and those that **aren’t** important to the DNS. You used that as a strawman argument and that never helps to have a useful discussion. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 7. 7. 2023, at 12:35, Jakob Bohm via bind-users > wrote: > > On 2023-07-07 12:17, Emmanuel Fusté wrote: >>> Le 07/07/2023 à 11:57, Jakob Bohm via bind-users a écrit : >>> >>> >>> On 2023-06-02 05:02, Jesus Cea wrote: On 2/6/23 4:25, Mark Andrews wrote: > Yep, some people just don’t take care with delegations. Complain to > Huawei. > Complain to the other companies you list in your followup email. > > All it takes to fix this is to change the name of the zone on the child > servers > (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from > “huawei.com” > to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the > zone > if they are fully qualified. If there are other delegations from > huawei.com > for other sub zones to these servers they will also need to be > instantiated. > > It’s maybe 10 minute work for each subdomain to fix. It just requires > someone > to do the work. I sympathize. Expertise and caring for the job is something the world is losing fast and few people care at all. Complaining to business is not going to work, because this misconfiguration works fine for 99.9% of their users, clients of more "lax" DNS resolvers. What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. > When people come to you and say that it works with Google, et al. point > them at > https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error > and say > “Here is a DNS configuration testing site and it reports the zone as > broken, you > need to take it up with the company." "Whatever, Google works and you don't. You sucks!". Few people care about doing the right thing if crap works for them. If only 8.8.8.8 cared and gave back SERVFAIL as it should, everybody would fix her configuration immediately. Postel law [*] was a mistake (be strict when sending and forgiving when receiving). Nice advice, awful consequences we will pay forever. https://en.wikipedia.org/wiki/Robustness_principle >>> >>> The robustness principle isn't the problem here. It is more that parts of >>> the >>> bind code isapparently being strict about receiving out-of-range values in >>> an >>> informational part ofDNS responses, then turning a mostly usable reply from >>> remote servers into a SERVFAIL of binds own making, rather than just >>> filtering >>> out that informational part if bind considers it worth checking at all. >>> >> It is at the core of delegation and trust model of DNS, now possibly >> enforced by DNSSEC. Peer centric resolvers are lax on this checking for all >> but the security of their users. >> So in your opinion it is purely useless, and bad data it better than >> nodata/error. >> > I am saying that the SOA copy in the authority section of responses is purely > informational, unlike the data that provides DNSSEC signatures or even the > data that provides IP addresses for servers in responses to MX queries. > > So from that perspective, if bind code checks that this informal copy of an > SOA record is for the wrong zone, it should simply filter out that SOA > record instead of filtering out the entire response to the actual query. > > In the special case of using that SOA copy to get the negative response TTL, > that special use should only check that the SOA copy was provided in the > same DNS response as the negative response to be cached, not the diagnostic > data about the origin server's zone files. > > In a similar way, bind should not object to the SOA mail contect being valid, > as a surprising number of zones actually fail to handle mail to that address > (I personally had to go through hoops with support people when trying to > coordinate a small change with another zone that I no longer had a business > relationship with, so validating this is useful in a compliance checker, but > not > in a caching resolver). > > Enjoy > > Jakob > -- > Jakob
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 2023-07-07 12:17, Emmanuel Fusté wrote: Le 07/07/2023 à 11:57, Jakob Bohm via bind-users a écrit : On 2023-06-02 05:02, Jesus Cea wrote: On 2/6/23 4:25, Mark Andrews wrote: Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. All it takes to fix this is to change the name of the zone on the child servers (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com” to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone if they are fully qualified. If there are other delegations from huawei.com for other sub zones to these servers they will also need to be instantiated. It’s maybe 10 minute work for each subdomain to fix. It just requires someone to do the work. I sympathize. Expertise and caring for the job is something the world is losing fast and few people care at all. Complaining to business is not going to work, because this misconfiguration works fine for 99.9% of their users, clients of more "lax" DNS resolvers. What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. When people come to you and say that it works with Google, et al. point them at https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say “Here is a DNS configuration testing site and it reports the zone as broken, you need to take it up with the company." "Whatever, Google works and you don't. You sucks!". Few people care about doing the right thing if crap works for them. If only 8.8.8.8 cared and gave back SERVFAIL as it should, everybody would fix her configuration immediately. Postel law [*] was a mistake (be strict when sending and forgiving when receiving). Nice advice, awful consequences we will pay forever. https://en.wikipedia.org/wiki/Robustness_principle The robustness principle isn't the problem here. It is more that parts of the bind code isapparently being strict about receiving out-of-range values in an informational part ofDNS responses, then turning a mostly usable reply from remote servers into a SERVFAIL of binds own making, rather than just filtering out that informational part if bind considers it worth checking at all. It is at the core of delegation and trust model of DNS, now possibly enforced by DNSSEC. Peer centric resolvers are lax on this checking for all but the security of their users. So in your opinion it is purely useless, and bad data it better than nodata/error. I am saying that the SOA copy in the authority section of responses is purely informational, unlike the data that provides DNSSEC signatures or even the data that provides IP addresses for servers in responses to MX queries. So from that perspective, if bind code checks that this informal copy of an SOA record is for the wrong zone, it should simply filter out that SOA record instead of filtering out the entire response to the actual query. In the special case of using that SOA copy to get the negative response TTL, that special use should only check that the SOA copy was provided in the same DNS response as the negative response to be cached, not the diagnostic data about the origin server's zone files. In a similar way, bind should not object to the SOA mail contect being valid, as a surprising number of zones actually fail to handle mail to that address (I personally had to go through hoops with support people when trying to coordinate a small change with another zone that I no longer had a business relationship with, so validating this is useful in a compliance checker, but not in a caching resolver). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
Le 07/07/2023 à 11:57, Jakob Bohm via bind-users a écrit : On 2023-06-02 05:02, Jesus Cea wrote: On 2/6/23 4:25, Mark Andrews wrote: Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. All it takes to fix this is to change the name of the zone on the child servers (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com” to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone if they are fully qualified. If there are other delegations from huawei.com for other sub zones to these servers they will also need to be instantiated. It’s maybe 10 minute work for each subdomain to fix. It just requires someone to do the work. I sympathize. Expertise and caring for the job is something the world is losing fast and few people care at all. Complaining to business is not going to work, because this misconfiguration works fine for 99.9% of their users, clients of more "lax" DNS resolvers. What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. When people come to you and say that it works with Google, et al. point them at https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say “Here is a DNS configuration testing site and it reports the zone as broken, you need to take it up with the company." "Whatever, Google works and you don't. You sucks!". Few people care about doing the right thing if crap works for them. If only 8.8.8.8 cared and gave back SERVFAIL as it should, everybody would fix her configuration immediately. Postel law [*] was a mistake (be strict when sending and forgiving when receiving). Nice advice, awful consequences we will pay forever. https://en.wikipedia.org/wiki/Robustness_principle The robustness principle isn't the problem here. It is more that parts of the bind code isapparently being strict about receiving out-of-range values in an informational part ofDNS responses, then turning a mostly usable reply from remote servers into a SERVFAIL of binds own making, rather than just filtering out that informational part if bind considers it worth checking at all. It is at the core of delegation and trust model of DNS, now possibly enforced by DNSSEC. Peer centric resolvers are lax on this checking for all but the security of their users. So in your opinion it is purely useless, and bad data it better than nodata/error. Emmanuel. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 2023-06-02 05:02, Jesus Cea wrote: On 2/6/23 4:25, Mark Andrews wrote: Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. All it takes to fix this is to change the name of the zone on the child servers (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com” to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone if they are fully qualified. If there are other delegations from huawei.com for other sub zones to these servers they will also need to be instantiated. It’s maybe 10 minute work for each subdomain to fix. It just requires someone to do the work. I sympathize. Expertise and caring for the job is something the world is losing fast and few people care at all. Complaining to business is not going to work, because this misconfiguration works fine for 99.9% of their users, clients of more "lax" DNS resolvers. What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. When people come to you and say that it works with Google, et al. point them at https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say “Here is a DNS configuration testing site and it reports the zone as broken, you need to take it up with the company." "Whatever, Google works and you don't. You sucks!". Few people care about doing the right thing if crap works for them. If only 8.8.8.8 cared and gave back SERVFAIL as it should, everybody would fix her configuration immediately. Postel law [*] was a mistake (be strict when sending and forgiving when receiving). Nice advice, awful consequences we will pay forever. https://en.wikipedia.org/wiki/Robustness_principle The robustness principle isn't the problem here. It is more that parts of the bind code isapparently being strict about receiving out-of-range values in an informational part ofDNS responses, then turning a mostly usable reply from remote servers into a SERVFAIL of binds own making, rather than just filtering out that informational part if bind considers it worth checking at all. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
