Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt
Thanks for pointing out the mistake. I will revise it in next version. The opening paragraph of 4.3 should be removed and how a recursive DNS responds to a DDC request option should be added in 4.2. As recent research has found new attack that by pointing the glue address to public recursive DNS which does not follow standard specification well（like ignore RD bit）, can significantly amplify attack traffic. zuop...@cnnic.cn From: Dick Franks Date: 2024-01-22 02:16 To: zuop...@cnnic.cn CC: dnsop Subject: Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt On Tue, 2 Jan 2024 at 07:34, zuop...@cnnic.cn wrote: >8 > This draft suggests a lightweight and backward-compatible mechanism to > mitigate the risk of these attacks. > > Any comments are welcome! > The proposal contains internal inconsistencies and contradictions which need to be addressed: 4.2. Responding to a request DDC request option should be responded by a DDC-aware authoritative server. For a DDC-not-aware server, the presence of a DDC request option is ignored and the server responds as if no DDC request option had been included in the request. 4.3. Processing Responses If the client(usually a Recursive server) is expecting the response to contain a DDC respond option and it is missing, the response MUST be discarded. The client has no way of knowing in advance if the server is DDC-aware. Considering 4.2, merely sending a DDC request does not create any reliable expectation that there will be a corresponding DDC response. Regarding the processing of the DNS delegation respond option by a recursive server, there are 4 possibilities: (1) The client is expecting the response to contain a DDC respond option and it is missing. In this case, the client processes the response as normal and does not implement DNS delegation confirmation. This contradicts the MUST in the opening paragraph of 4.3 --rwf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt
Thanks for your valuable comment ! negative caching (RFC 2308) and failure caching (RFC 9520) can mitigate NXNSAttack–like attack to some extent, but I don’t think they are sufficient enough, because for a resolver that adopts these 2 RFCs only caches failure answer for a single record at a time, it can't avoid queries for a large number of random NS records. Aggressive NSEC (RFC 8198) is useful against to NXNSAttack –like attack, because it allows a DNSSEC-validating resolver to generate negative answers within a range. But if a NSEC3 RR has an Opt-Out flag, it can’t be used for aggressive negative caching. In addition, DNSSEC adoption rate remains low in some area and this situation may not change significantly over a long period of time for policy reasons. Compared to DNSSEC, the draft is relatively simple, it uses OPT RR option to confirm NS record only when a resolver is requesting address (Glue record) of delegation points. And it is compatible with current DNS protocol. zuop...@cnnic.cn From: Ben Schwartz Date: 2024-01-03 23:49 To: zuop...@cnnic.cn; dnsop Subject: Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt Thanks for this proposal. I note the following text on the motivation in Section 1.3: If a malicious Delegated Zone specifies a large amount of fake NS pointing to victim zones, much more queries from recursive DNS to victim zones will be triggered. This protocol vulnerability can be abused to launch new types of attacks, such as NXNSAttack. Current mitigation measures against such attacks are based on optimizing DNS software implementations, such as limiting the number of outgoing queries for NS glue. I think this is a helpful description of the motivation, but it omits some additional mitigations that already exist, such as negative caching (RFC 2308), failure caching (RFC 9520), and Aggressive NSEC (RFC 8198). I don't see any argument in this draft that the current mitigations are insufficient, or are likely to fail in the future. This draft adds a significant amount of complexity to the DNS protocol. I don't think it makes sense to add complexity if our current mitigations are sufficient. --Ben Schwartz From: DNSOP on behalf of zuop...@cnnic.cn Sent: Tuesday, January 2, 2024 2:35 AM To: dnsop Subject: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt ZjQcmQRYFpfptBannerStart This Message Is From an Untrusted Sender You have not previously corresponded with this sender. ZjQcmQRYFpfptBannerEnd Hi all, We submitted a draft about DNS delegation confirmation. In the current DNS delegation mechanism, a delegated zone/child zone can specify any NS records at the zone apex without requiring confirmation from the zone maintaining Glue records of these NS record. This could be exploited to lunch new types of attacks such as NXNSattack. This draft suggests a lightweight and backward-compatible mechanism to mitigate the risk of these attacks. Any comments are welcome! zuop...@cnnic.cn From: internet-drafts Date: 2024-01-02 14:42 To: Peng Zuo; Zhiwei Yan Subject: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt A new version of Internet-Draft draft-zuo-dnsop-delegation-confirmation-00.txt has been successfully submitted by Zhiwei Yan and posted to the IETF repository. Name: draft-zuo-dnsop-delegation-confirmation Revision: 00 Title:A lightweight DNS delegation confirmation protocol Date: 2024-01-01 Group:Individual Submission Pages:13 URL: https://www.ietf.org/archive/id/draft-zuo-dnsop-delegation-confirmation-00.txt Status: https://datatracker.ietf.org/doc/draft-zuo-dnsop-delegation-confirmation/ HTMLized: https://datatracker.ietf.org/doc/html/draft-zuo-dnsop-delegation-confirmation Abstract: Delegation occurs when an NS record is added in the parent zone for the child origin. In the current DNS delegation mechanism, a delegated zone/child zone (see Section1.1 for definition of delegated zone) can specify any NS records at the zone apex without requiring confirmation from the zone maintaining Glue records of the NS record. Recently, new types of attacks that exploit this flaw have been discovered. This draft suggests a protocol-level solution for DNS delegation confirmation to reduce the risk of these attacks. The IETF Secretariat
[DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt
Hi all, We submitted a draft about DNS delegation confirmation. In the current DNS delegation mechanism, a delegated zone/child zone can specify any NS records at the zone apex without requiring confirmation from the zone maintaining Glue records of these NS record. This could be exploited to lunch new types of attacks such as NXNSattack. This draft suggests a lightweight and backward-compatible mechanism to mitigate the risk of these attacks. Any comments are welcome! zuop...@cnnic.cn From: internet-drafts Date: 2024-01-02 14:42 To: Peng Zuo; Zhiwei Yan Subject: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt A new version of Internet-Draft draft-zuo-dnsop-delegation-confirmation-00.txt has been successfully submitted by Zhiwei Yan and posted to the IETF repository. Name: draft-zuo-dnsop-delegation-confirmation Revision: 00 Title:A lightweight DNS delegation confirmation protocol Date: 2024-01-01 Group:Individual Submission Pages:13 URL: https://www.ietf.org/archive/id/draft-zuo-dnsop-delegation-confirmation-00.txt Status: https://datatracker.ietf.org/doc/draft-zuo-dnsop-delegation-confirmation/ HTMLized: https://datatracker.ietf.org/doc/html/draft-zuo-dnsop-delegation-confirmation Abstract: Delegation occurs when an NS record is added in the parent zone for the child origin. In the current DNS delegation mechanism, a delegated zone/child zone (see Section1.1 for definition of delegated zone) can specify any NS records at the zone apex without requiring confirmation from the zone maintaining Glue records of the NS record. Recently, new types of attacks that exploit this flaw have been discovered. This draft suggests a protocol-level solution for DNS delegation confirmation to reduce the risk of these attacks. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME high-level benefit question
configure several CNAME records to use multi-CDN service is also widely used in industry, though this is not allowed by DNS standards. shall we support this on protocal level? like defining new CNAMEx record which contains "weight" attribute. zuop...@cnnic.cn From: Ondřej Surý Date: 2019-05-12 14:59 To: Brian Dickson; dnsop Subject: Re: [DNSOP] ANAME high-level benefit question Also, I would argue that the ability to run ANAME at your own infrastructure might drive less people to the “managed DNS” land or allow them to migrate away without a significant loss of functionality. One way or another, ANAME-like behaviour became defacto industry standard and we need to have a solution on a protocol level. Ondrej -- Ondřej Surý ond...@isc.org > On 11 May 2019, at 16:34, Ray Bellis wrote: > > > > On 11/05/2019 15:54, Dave Lawrence wrote: > >> I have a related question ... is allowing only targets on their own >> infrastructure currently a limitation most such providers have? > > I don't know about "most", but certainly some. See e.g. the attached > message posted here 2018/06/25. > > Ray > > <[DNSOP] abandoning ANAME and standardizing CNAME at > apex.eml>___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
sorry, because of my english level, i misused the word "protect". i know the difference between channel security and object security. but in my proposal, the premise is the recursive server should completely trust an Authenticated server. i think this is simialr in DNSSEC, because if an DNSSEC_enabled authotative server(no matter it is Alice or Bob) is evil and modifies DNS records, it will succeed because it has private key and can fake anything. zuop...@cnnic.cn From: Stephane Bortzmeyer Date: 2019-02-14 16:33 To: zuop...@cnnic.cn CC: dnsop; Paul Wouters Subject: Re: [DNSOP] extension of DoH to authoritative servers On Thu, Feb 14, 2019 at 02:36:14PM +0800, zuop...@cnnic.cn wrote a message of 86 lines which said: > i think both DNSSEC and DoH(or DoT) can protect DNS data, "Protect" is like "security", a word so vague, which includes so many different (and sometimes contradictory) services that it is not very useful. Writing "both DNSSEC and DoH(or DoT) can protect DNS data" seems to imply that you did not think enough about the difference between channel security and object security. This is really the weakest point in your argumentation. (Yes, djb always make the same mistake but he is a famous cryptographer so people forget and forgive about his mistakes.) > the fundmental point it to establish the trust chain and transit > trust. No. The entire point of DNSSEC is that you do not need to trust the many servers that are between the validator and the origin. > Regarding the case"secondary name servers mnaged by a different > organisation", the servers can publish several TLSAs to distingush > them. I'm afraid you did not understand. Let me explain with concrete examples. Suppose organisation Alice subcontracts a secondary name server to organisation Bob (a very common use case). 1) What is Bob is evil and modify DNS records? 2) What is Bob is sloppy in security and its servers are cracked and the attacker modify DNS records? DNSSEC protects against both. DoT and DoH does not protect against these issues. > This idea is just a sketch model The problem is that there are many sketch models floating around and few serious proposals (and even less implemented and analyzed proposals). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
> for instance a DoH or DoT server that intentionally or accidentally returns > false data. DNSSEC can counter that. I dont understand why. If a server intentionally returns false data , it can fake anything because it owns the private key, DNSSEC does not help either. > Indeed. That’s yet another reason why transiting trust is hard. YES. this proposal also needs support from the root. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
i think both DNSSEC and DoH(or DoT) can protect DNS data, the fundmental point it to establish the trust chain and transit trust. Regarding the case"secondary name servers mnaged by a different organisation", the servers can publish several TLSAs to distingush them. This idea is just a sketch model and provides another option for DNS security and privacy. Transiting trust is hard but may be accomplished in the future. The deployment of DNSSEC also takes a long time and is still in progress. zuop...@cnnic.cn From: Stephane Bortzmeyer Date: 2019-02-13 21:44 To: zuop...@cnnic.cn CC: dnsop; Paul Wouters Subject: Re: [DNSOP] extension of DoH to authoritative servers On Wed, Feb 13, 2019 at 02:03:26PM +0800, zuop...@cnnic.cn wrote a message of 103 lines which said: > that's ture. but in my view, if the trust chain is built, we can > ensure a resolver(or a cache) is always talking to a identified > server and the channel is always secure, then the content could not > be tampered. Several emails already mentioned cases where it is not true (relaying through a forwarder - transitive trust is hard - or secondary name servers mnaged by a different organisation - a common use case). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
i prefer DoH because it can identify a server we are talking to and the content is encrypted. zuop...@cnnic.cn From: Stephane Bortzmeyer Date: 2019-02-12 16:39 To: zuop...@cnnic.cn CC: dnsop Subject: Re: extension of DoH to authoritative servers On Tue, Feb 12, 2019 at 03:56:04PM +0800, zuop...@cnnic.cn wrote a message of 546 lines which said: > I am considering extending the DoH protocal to authoritative > servers. Why DoH and not DoT? DoH is useful because 1) port 853 may be blocked at the edge of the network 2) applications running in a Web browser may need DNS data. But these two reasons do not apply to your use case 1) the resolver is often closer to the core and there is less risk that 853 is blocked 2) there is no Web browser on the resolver. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
that's ture. but in my view, if the trust chain is built, we can ensure a resolver(or a cache) is always talking to a identified server and the channel is always secure, then the content could not be tampered. zuop...@cnnic.cn From: Paul Wouters Date: 2019-02-12 22:07 To: zuop...@cnnic.cn CC: dnsop Subject: Re: [DNSOP] extension of DoH to authoritative servers On Tue, 12 Feb 2019, zuop...@cnnic.cn wrote: >In this way, the whole DNS is built on HTTPS which makes DNS more secure. > DNSSEC is not necessary anymore and many other >problems like fragmentation also will > not exist. This idea is similar to DNScurve. The problem is that channel security does not help when you have an infrastructure of DNS caches, as nothing in the cache can be used to validate the content. djb's solution to this problem was to obsolete the cache, and at the CCC conference he then threw around numbers that "claimed" caching is not working or needed, and was proven wrong by me showing some cache percentages of real DNS servers. DNSSEC provides origin protection, and digital signatures are needed, which TLS does not offer. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] extension of DoH to authoritative servers
HI ALL, RFC8484 《DNS Queries over HTTPS》defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Its primary secnario is between stub resolver and recursive resolver. I am considering extending the DoH protocal to authoritative servers. To build the trust chain, the child zone publishes a TLSA record instead of a DS record in the parent zone [RFC 6698 may need update]. The TLSA record contains the certificate that identifies the child zone. In this way, the whole DNS is built on HTTPS which makes DNS more secure. DNSSEC is not necessary anymore and many other problems like fragmentation also will not exist. The sketch diagram is as followed. Any comments are welcome! zuop...@cnnic.cn ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
From: Lanlan Pan Date: 2017-12-13 18:25 To: Stephane Bortzmeyer CC: zuop...@cnnic.cn; dnsop; bert hubert Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling Stephane Bortzmeyer <bortzme...@nic.fr>于2017年12月13日周三 下午5:58写道： On Wed, Dec 13, 2017 at 05:31:06PM +0800, zuop...@cnnic.cn <zuop...@cnnic.cn> wrote a message of 130 lines which said: > (2) RFC2782 requires browser's support; Client support. This is even worse, there are much more HTTP clients than browsers. > Using this method, a browser has no idea about weighted AX/Xs. > It requires no change of browsers. But it requires change in all resolvers. One may wonder which will be the fastest path. something like ANAME ? ANAME can let resolvers choose IP for clients. ---[zuopeng] it is not like ANAME. But ANAME has similar function with CNAME, adding a weight attribute for ANAME may also make sense. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- 致礼 Best Regards 潘蓝兰 Pan Lanlan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
On Wed, Dec 13, 2017 at 09:18:23AM +0100, Stephane Bortzmeyer wrote:
> > For example, a CDN provider can’t schedule 70% of traffic to node A
> > and 30% of traffic to node B [...] adding a “weight” attribute
>
> First, the obvious question: why reinventing RFC 2782?
Implementing this worthwhile capability can be done in four ways/places:
1) Get browsers to honour RFC 2782
2) Get resolvers and auths to support a weighted A/ record (as proposed
in this thread)
3) Serve up multiple copies of the same A record, and weigh like this:
www IN A 1.2.3.4
www IN A 1.2.3.4
www IN A 10.11.12.13
And hope that record shuffling will deliver the 2:1 ratio
4) Get authoritative servers to serve A/ with weighted frequency and
short TTL
Getting browsers to move is a 5 year project at least. You could get the
resolver/auth landscape moving somewhat more quickly ('we know these
people'), but it will still take a long time and support will be spotty.
The 'multiple IP address listings' thing is done in practice, but some
server remove duplicates, so it doesn't work that well.
And the last possibility is what CDNs are actually doing. It does not quite
spread out traffic perfectly, but it is good enough.
In PowerDNS Authoritative Server 4.1.1 (upcoming in January), this looks
like:
@ IN LUA A "wrandom{{2, '1.2.3.4'}, {1, '10.11.12.13'}}"
Or even:
@ IN LUA A "whashed{{2, '1.2.3.4'}, {1, '10.11.12.13'}}"
Which will keep the same IP address going to the same record.
--> [zuopeng] : so far as i know, many CDNs already use similar
methods as you mentioned in PowerDNS 4.1.1
--> [zuopeng] : but i think only the Authoritative Server
change is not enough, support on the recursive server is also very important .
--> [zuopeng] : because the resolver determines the reponse to
clients.
This is documented in https://powerdns.org/auth-4.1.1-docs/lua-records.html
- which also lists things like @ IN LUA A "closest{'1.2.3.4', '10.11.12.13'}"
which will attempt to serve up the geographically closest address.
Bert
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
thanks for your comments!
According to my understanding, here are 2 main differences between RFC2782 and
this idea :
(1) RFC2782 does not solve the problem of using multi-CDN (multiple CNAME
cannot coexist);
here we can use multipile weighted CNMAEXs (need to coexist with CNAME) to
accomplish this;
besides, weighted CNAMEXs can control traffic ratio among several CDN
providers;
(2) RFC2782 requires browser's support;
Using this method, a browser has no idea about weighted AX/Xs.
It requires no change of browsers.
zuop...@cnnic.cn
From: bert hubert
Date: 2017-12-13 16:43
To: Stephane Bortzmeyer
CC: zuop...@cnnic.cn; dnsop
Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
On Wed, Dec 13, 2017 at 09:18:23AM +0100, Stephane Bortzmeyer wrote:
> > For example, a CDN provider can’t schedule 70% of traffic to node A
> > and 30% of traffic to node B [...] adding a “weight” attribute
>
> First, the obvious question: why reinventing RFC 2782?
Implementing this worthwhile capability can be done in four ways/places:
1) Get browsers to honour RFC 2782
2) Get resolvers and auths to support a weighted A/ record (as proposed
in this thread)
3) Serve up multiple copies of the same A record, and weigh like this:
www IN A 1.2.3.4
www IN A 1.2.3.4
www IN A 10.11.12.13
And hope that record shuffling will deliver the 2:1 ratio
4) Get authoritative servers to serve A/ with weighted frequency and
short TTL
Getting browsers to move is a 5 year project at least. You could get the
resolver/auth landscape moving somewhat more quickly ('we know these
people'), but it will still take a long time and support will be spotty.
The 'multiple IP address listings' thing is done in practice, but some
server remove duplicates, so it doesn't work that well.
And the last possibility is what CDNs are actually doing. It does not quite
spread out traffic perfectly, but it is good enough.
In PowerDNS Authoritative Server 4.1.1 (upcoming in January), this looks
like:
@ IN LUA A "wrandom{{2, '1.2.3.4'}, {1, '10.11.12.13'}}"
Or even:
@ IN LUA A "whashed{{2, '1.2.3.4'}, {1, '10.11.12.13'}}"
Which will keep the same IP address going to the same record.
This is documented in https://powerdns.org/auth-4.1.1-docs/lua-records.html
- which also lists things like @ IN LUA A "closest{'1.2.3.4', '10.11.12.13'}"
which will attempt to serve up the geographically closest address.
Bert
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
Hi everyone, Here’s a problem about CDN traffic scheduling. So far as I know, many business companies use multi-CDN to speed up their websites and the CDN providers have requirements for precise traffic scheduling especially in the rush hour of traffic. As CDN providers usually manage authoritative DNS for their clients, the most common method for real-time traffic scheduling is to change the A records of CDN nodes. It does have some positive effects. But because of the lack of DNS protocol support (especially on the recursive server side), a CDN company can’t schedule traffic very precisely. For example, a CDN provider can’t schedule 70% of traffic to node A and 30% of traffic to node B. Even though it places the addresses of both A and B, it can’t determine recursive server’s response to clients. For example, some recursive server may round-robin the address to clients. For better precise CDN traffic scheduling, I have an idea that defines 3 new records from extending 3 existing DNS resource records: A, and CNAME, by adding a “weight” attribute，as below: [ CNAME ] -> [ CNAMEX ] [ A ] -> [ AX ] [ ] -> [ X ] The reasons for doing this are : (1) By adding “weight” in CNAMEX, a multi-CDN user can manage the traffic ratio among different CDN providers by itself easily. (2) By adding “weight” in A/, a CDN provider can manage the traffic ratio among different nodes by itself easily. For compatibility, an authoritative server should place the CNAMEX/AX/X records in additional section in a DNS response for a “A/” query. A “weight-aware” recursive server should make use of the “CNAMEX/AX/X” in the additional section to manage the answer to clinents according to the weight of each RR. A “weight-not-aware” recursive server can just ignore these RRs and still work normally. Here is an example: If a CDN provider configures AX records for “www.example.com” as below which indicates “1.1.1.1” should account for 80% in response while “2.2.2.2” accounting for 20%. A “weight-aware” recursive server should reply to clients accordingly. Any comment or advice is highly appreciated! Thank you!! zuop...@cnnic.cn ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
