Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

Thanks Paul. Paul Wouters 于2024年1月10日周三 23:01写道： > On Wed, 10 Jan 2024, Lanlan Pan wrote: > > > I have submitted a new draft to discuss the faked answer returned from > the recursive resolver. > > > > Your comments are appreciated. > > As I've said during

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

Thanks Bob, I will revised it. Bob Harold 于2024年1月10日周三 22:23写道： > > On Wed, Jan 10, 2024 at 4:19 AM Lanlan Pan wrote: > >> Hi all, >> >> I have submitted a new draft to discuss the faked answer returned from >> the recursive resolver. &g

[DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

To: Lanlan Pan A new version of Internet-Draft draft-pan-dnsop-explicit-forged-answer-signal-00.txt has been successfully submitted by Lanlan Pan and posted to the IETF repository. Name: draft-pan-dnsop-explicit-forged-answer-signal Revision: 00 Title:Explicit Forged Answer Signal Date

Re: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

Ray Bellis 于2021年4月16日周五 下午4:19写道： > > > On 14/04/2021 10:19, Stephane Bortzmeyer wrote: > > > Regarding dnsop work, the same report suggests to modify RFC 5625 "DNS > > Proxy Implementation Guidelines" to replace the MAY in section 6.3 by > > a MUST. I think that the reason there is currently a

Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient...

Shumon Huque 于2020年5月22日周五 下午11:00写道： > On Fri, May 22, 2020 at 10:52 AM Joe Abley wrote: > >> On 21 May 2020, at 16:07, Warren Kumari wrote: >> >> > What does all of this *mean*? >> > .. >> > .. >> > .. >> > Sorry, I haven't a clue, other than maybe: >> > The DNS is weird. >> >> In your experi

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Erik Nygren 于2020年2月27日周四 上午5:38写道： > On Wed, Feb 26, 2020 at 2:34 PM Lanlan Pan wrote: > >> My option: >> 1) ANAME just configured in zonefile, and anlayzed by authoritative >> server. >> 2) Authoritative server response to recursive (or resolver) on its policy

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

My option: 1) ANAME just configured in zonefile, and anlayzed by authoritative server. 2) Authoritative server response to recursive (or resolver) on its policy as before, such as geo-ip, GSLB, ... 3) No upgrade on recursive and resolver. Tony Finch 于2020年2月27日周四 上午1:25写道： > Vladimír Čunát wro

Re: [DNSOP] Fundamental ANAME problems

Brian Dickson 于2018年11月2日周五 上午9:38写道： > On Thu, Nov 1, 2018 at 5:14 PM John Levine wrote: > >> I can't help but note that people all over the Internet do various >> flavors of ANAME now, and the DNS hasn't fallen over. Let us not make >> the same mistake we did with NAT, and pretend that since w

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Anthony Eden 于2018年6月20日周三 上午12:06写道： > On Tue, Jun 19, 2018 at 4:47 PM, Lanlan Pan wrote: > >> >> >> Petr Špaček 于2018年6月19日周二 下午9:19写道： >> >>> Hello dnsop, >>> >>> beware, material in this e-mail might cause your head to explode :-)

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Petr Špaček 于2018年6月19日周二 下午9:19写道： > Hello dnsop, > > beware, material in this e-mail might cause your head to explode :-) > > This proposal is based on following observations: > - It seems that DNS protocol police lost battle about CNAME at apex, >is is deployed on the Internet. > - Major DN

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Ted Lemon 于2018年2月6日周二 下午1:17写道： > On Feb 5, 2018, at 11:58 PM, Lanlan Pan wrote: > > If we decide to ban localhost.example, > > > Nobody is proposing that we ban localhost.example. > Sorry for my poor english. I mean that in *5.2. 'localhost' labels in subd

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Ted Lemon 于2018年2月6日周二 上午12:52写道： > On Feb 5, 2018, at 1:51 AM, Mark Andrews wrote: > > No it is not! The browser knows where the name came from. > > > Walk me through it. How does the browser know where the name came from? > we can return NXDOMAIN for localhost. , little influence. If we dec

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Mark Andrews 于2018年2月3日周六 上午4:11写道： > The problem is that search lists are being applied when “localhost” is > being entered into name lookup APIs and is being matched against > localhost.example which isn’t expected to to a address on the current > machine and that the search list may be auto co

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

> Recursive DNS servers are required to return "NXDOMAIN" when queried for localhost names Why not just let Root return NXDOMAIN for "localhost. / *.localhost.", but also require this on recursive ? (anyway, recursive's data is from authoritative, in theory) For latency, reduce queries, or ... ?

Re: [DNSOP] CLIENT-SUBNET bis appetite?

Hi Warren, Thank you for the mention, :-) We all know that, because of network topology, client subnet is the *best* indicator for CDN traffic management, expecially for Akamai, Google, ... Totally agree with you: There is no *best* answer for a country, nor a city or even a postal address. My

Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling

Stephane Bortzmeyer 于2017年12月13日周三 下午5:58写道： > On Wed, Dec 13, 2017 at 05:31:06PM +0800, > 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. > > >

Re: [DNSOP] Measuring DNS TTL Violations in the wild

Mukund Sivaraman 于2017年12月2日周六 下午10:39写道： > On Fri, Dec 01, 2017 at 05:16:47PM +, Ólafur Guðmundsson wrote: > > On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane > > wrote: > > > > > > > > > On Dec 1, 2017, at 8:38 AM, Ólafur Guðmundsson < > ola...@cloudflare.com> > > > wrote: > > > > > > > > I

Re: [DNSOP] Resolver behaviour with multiple trust anchors

Brian Dickson 于2017年11月3日周五 上午3:58写道： > (Apologies for neither top- nor bottom- posting, i.e. not quoting any > other emails.) > > There are corner cases which exist, where desired behavior of some > resolvers is not possible to achieve. > > This mostly has to do with constraints where "local poli

Re: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt

Paul Vixie 于2017年9月12日周二 下午11:14写道： > > > Stephane Bortzmeyer wrote: > > On Tue, Sep 12, 2017 at 09:50:37AM +0000, > > Lanlan Pan wrote > > a message of 210 lines which said: > > > >> ATR make Authoritative Servers send normal big response packet &g

Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

no only localhost.example.com : http://seclists.org/bugtraq/2008/Jan/270 if xxx.example.com is NXDOMAIN , there is similar risk cause by the "nxdomain redirect" recursive dns (they return a hijack A RR ). CA SSO (siteminder) may be a solution. localhost. seems a new special-use TLD, like arpa. ,

Re: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt

Hi Davey, ATR make Authoritative Servers send normal big response packet before they try to send TC response for large RRsets ? Davey Song 于2017年9月11日周一 下午12:29写道： > Hi folks, > > I just submit a draft dealing with issue of large DNS response especially > in IPv6. Commnets are welcome. > > If ch

Re: [DNSOP] 答复: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

Davey Song(宋林健) 于2017年9月8日周五 下午5:16写道： > I just notice it asks for "Standards Track" document. If it aims to > introduce a special use of resolver to achieve some features for their > users' benefit, I think informational document may be more appropriate ? I > guess, like what RFC7706 does. > +1,

Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

sh a wildcard marker". Warren Kumari 于2017年8月22日周二 上午2:45写道： > I was really trying to stay out of this thread... > > > On Fri, Aug 18, 2017 at 1:05 PM, Ted Lemon wrote: > > El 18 ag 2017, a les 11:33, Lanlan Pan va escriure: > > > > So, can you talk abou

Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Thanks a lot for your detail analysis, :-) Ralf Weber 于2017年8月17日周四 下午11:16写道： > Moin! > > On 17 Aug 2017, at 0:09, Lanlan Pan wrote: > > Yes, I agree, in fact the *online cache rate* is small (0.12% queries), > LRU > > & TTL works fine. > > SWILD not save many

Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Thanks a lot for your pertinent comments, :-) Ted Lemon 于2017年8月17日周四 下午9:56写道： > El 17 ag 2017, a les 0:09, Lanlan Pan va escriure: > > We can use SWILD to optimize it, not need to detecting, just remove items > which SWILD marked, to save cost. > > > So, can you talk ab

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

can not just simply remove them like some other random label attack. We prefer recursive directly return the IP of subdomain wildcards, and not rise recursive cach, not send repeat query to authoritative. Ted Lemon 于2017年8月16日周三 下午8:54写道： > El 16 ag 2017, a les 0:19, Lanlan Pan va escriure:

Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Ralf Weber 于2017年8月16日周三 下午4:22写道： > Moin! > > On 16 Aug 2017, at 6:19, Lanlan Pan wrote: > > > We analyzed our recursive query log, about 18.6 billion queries from > > 12/01/2015 to 12/07/2015. > > > > We found about 4.7 Million temporary domains occupy the

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Mukund Sivaraman 于2017年8月16日周三 下午1:45写道： > On Fri, Aug 11, 2017 at 10:39:50AM -0400, Matthew Pounsett wrote: > > It sounds like you're assuming that SWILD would be supported by caching > > servers that do not support DNSSEC or NSEC aggressive use. Why do you > > expect implementers would adopt SW

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

(Without commenting about SWILD) Is your RPZ a mixture ? Doesn't RPZ rewrite DNS answer, break DNSSEC validation ? Should we give up , or we shouldn't ? Paul Vixie 于2017年8月16日周三 下午2:30写道： > > > Mukund Sivaraman wrote: > ... > > > > Alexa Top domains and DNSSEC: > > > > 24 / 500 top domains (4

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

The operational problem is, subdomain wildcards waste recursive cache capacity. Existing solution to the problem is not adequate in recursive operating environment at present, because of low DNSSEC deployment. > > On Tue, Aug 15, 2017 at 9:41 AM, Vernon Schryver wrote: > >> ] From: La

Re: [DNSOP] on engineering cost/benefits

The complexity is the real world, No Silver Bullet. It is the fact, there is always more than one way to do it, not only for subdomain wildcard cache, or IPv4/IPv6 migration. Take virtual network tunneling for example, we have VN-Tag, VXLAN, NVGRE, ... Give the choice to operators, time is the be

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Hi Vernon, Thanks for your advice, :-) Vernon Schryver 于2017年8月15日周二 下午2:52写道： > > From: Lanlan Pan > > > Don't judy other's motivation with meaningless skeptics. The endless > > skeptics can also push on your RPZ to DNSSEC. > > A significant difference

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Mark Andrews 于2017年8月15日周二 下午1:14写道： > > In message < > canljsvwyo0nbisjgsqhrh33evbcuflnzcjceahj-l89fa+e...@mail.gmail.com> > , Lanlan Pan writes: > > > > Hi Paul, > > > > Don't judy other's motivation with meaningless skeptics. The endless >

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

, more probability than because of NSEC aggressive wildcards. Paul Vixie 于2017年8月15日周二 上午5:32写道： > WG Chairs: i oppose adoption of this draft. > > Lanlan Pan wrote: > > Hi Paul, > > > > ... > > tl;dr: this message marks the end of this thread from my side. > &

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Hi Matthew, Thanks for your detailed reply, :-) Matthew Pounsett 于2017年8月13日周日 上午12:31写道： > On 12 August 2017 at 04:29, Lanlan Pan wrote: > >> Hi Matthew ＆ Paul, >> >> Good question, :-) >> >> SWILD is a feature just for recusive cache optimization, only de

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

-dsn2014.pdf>. But the rate of "DNSSEC + NSEC + default dns query with DNSSEC” has influnence on subdomain wildcard cache issue if we only accept unique solution depend on it. Paul Vixie 于2017年8月12日周六 下午11:42写道： > On Saturday, August 12, 2017 8:29:45 AM GMT Lanlan Pan wrote: > >

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

eturn NXDOMAIN. Matthew Pounsett 于2017年8月11日周五 下午10:39写道： > On 11 August 2017 at 01:02, Lanlan Pan wrote: > > >>> We can get even better behavior from aggressive NSEC use. Here are >>> advantages of aggressive NSEC use: >>> - does not require changes to exist

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Hi Petr, Thanks for your comments, :-) Petr Špaček 于2017年8月10日周四 下午7:04写道： > Hello, > > On 4.7.2017 05:54, Lanlan Pan wrote: > > Hi Tony, > > > > We try to solve similar wildcard problem. > > > > NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards > &g

Re: [DNSOP] UDP fragmentation vs multiple-responses and multi-qtypes

+1 Avoid UDP fragmentations (big response packet) on protocol level could reduce DDoS defense cost. Similar to the DNS ANY qtype deprecation. Ondřej Surý 于2017年7月21日周五 上午12:41写道： > multi-qtypes Security Considerations says: > >The method documented here does not change any of the security >

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-edns-isp-location-02.txt

Hi Dave, Thanks for your feedback, :-) Dave Lawrence 于2017年7月17日周一 下午5:01写道： > Have you had any feedback from authority server implementers who are > interested in using this? > We plan to contact authoritative server implementers and public recursive implementers, for further realistic using, w

[DNSOP] Fwd: New Version Notification for draft-pan-dnsop-edns-isp-location-02.txt

cation-02.txt has been successfully submitted by Lanlan Pan and posted to the IETF repository. Name: draft-pan-dnsop-edns-isp-location Revision: 02 Title: ISP Location in DNS Queries Document date: 2017-07-17 Group: Individual Submission Pages: 19 URL

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

ault wildcard RR. SWILD: - Directly give "ALL SUBDOMAIN" information, and the default wildcard RR. SWILD is applicable even when Authoritative Nameservers don't give NSEC/NSEC3 RR. SWILD is applicable on non-validating Forwarding Resolvers. Regards, Tony Finch 于2017年7月3日周一 下午8:18写道： &g

[DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

ully submitted by Lanlan Pan and posted to the IETF repository. Name: draft-pan-dnsop-swild-rr-type Revision: 00 Title: SWILD RR Type (Wildcard on Intermediate Nameservers) Document date: 2017-07-03 Group: Individual Submission Pages: 6 URL: h

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

Hi Peter, one question, will authoritative server return multiple ANAME RRs for the same domain at one dns query ? for example, www.example.com ANAME us.www.example.com www.example.com ANAME cn.www.example.com or return only one selected ANAME RR for one domain ? (based on authoritative's

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

satisfied with your statement, because your AUTH make dns decision down to subnet pricise level. Barry Raveendran Greene 于2017年3月24日周五 上午2:06写道： > > > On Mar 21, 2017, at 11:38 PM, Lanlan Pan wrote: > > > > However, if you know about the geolocation , > you can make a bet

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

ency problem is the public recursive service providers couldn't deploy servers in every country and every ISP's network. - *Cache Size*: The cache size of ECS grows up with the number of client subnets. under future IPv6 environment, huge number of subnet, the cache

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

Hi Paul, https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/ Paul Vixie 于2017年3月22日周三 下午4:00写道： > > > Lanlan Pan wrote: > > ... Because ECS is > > also based on the map of "*client subnet -> geolocation*" information. > > wait, what?

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

Hi Ask, Ask Bjørn Hansen 于2017年3月22日周三 下午12:40写道： > > On Mar 21, 2017, at 21:30 , Lanlan Pan wrote: > > See this example of ECS : Which CDNs support edns-client-subnet? > <https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/>, > they *map the EC

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

Hi Ask， Ask Bjørn Hansen 于2017年3月21日周二 下午4:11写道： > > > On Mar 20, 2017, at 0:49, Lanlan Pan wrote: > > > > Everyone has known that physical location and the topology of content > delivery DO NOT MATCH. > > As last mail reply to Warren, my proposal can offer the S

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

Hi, Thanks for Petr and Brian. Brian Hartvigsen 于2017年3月21日周二 上午3:34写道： >> For user privacy concern, we can revise ECS(114.240.0.0/24 >> ) => EIL (CHINA, BEIJING, UNICOM)，give a >> tradeoff between privacy and precise. > > Nice, this sounds like appropriate tradeoff to m

Re: [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

T your house” or move from E-mail exertion threats to phone based threats. Barry > On Mar 17, 2017, at 6:57 PM, Lanlan Pan wrote: > > Hi all, > > In NDSS 2017 DNS Privacy Workshop, I presented a EIL option as an alternative privacy improvement for ECS. > > The paper an

Re: [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

INA, BEIJING, TELECOM at network topology". But not "I want to know what is the nearest ip address for clients from CHINA, BEIJING, TELECOM at physical topology". Thanks Lanlan & Yu. Warren Kumari 于2017年3月18日周六 下午5:08写道： > On Sat, Mar 18, 2017 at 2:57 AM, Lanlan Pan wrote: &g