[DNSOP] 答复: Call for Adoption: draft-song-atr-large-resp

[宋林健]

Thanks Benno. Thanks all reviewers for your time reviewing ATR draft. I'm
sorry it is not adopted in WG but I still think the draft and the peer
reviews help us to understand the problems better.

Davey
> -邮件原件-
> 发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Benno Overeinder
> 发送时间: 2019年2月14日 23:58
> 收件人: dnsop@ietf.org
> 主题: Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp
> 
> The call for acceptance for draft-song-atr-large-resp is closed, and it is
clear
> that there is insufficient support to adopt the concept as a DNSOP WG
> document.
> 
> There was some concern about the increased number of packages involved in
a
> legitimate exchange (half of them being ICMP messages, introducing other
> concerns) and that the problem space is too narrow to burden all
resolvers.
> 
> We would like to thank the authors and WG participants who responded to
the
> call for adoption on the mailing list.
> 
> Best regards,
> 
> -- Benno
> DNSOP co-chair
> 
> 
> On 18/01/2019 18:55, Benno Overeinder wrote:
> > Dear DNSOP WG,
> >
> > We discussed this work (draft -01) in Montreal, and different opinions
wrt.
> adoption were expressed.  In the past months, the authors pushed a draft
> version -02 that addressed and resolved some of these comments.
> >
> > This starts a Call for Adoption for:
> > draft-song-atr-large-resp
> >
> > The draft is available here:
> > https://datatracker.ietf.org/doc/draft-song-atr-large-resp/
> >
> > Please review this draft to see if you think it is suitable for adoption
by DNSOP,
> and comments to the list, clearly stating your view.
> >
> > Please also indicate if you are willing to contribute text, review, etc.
The
> WG accepts the document or not, but the WG chairs also expect a commitment
> from the WG participants who support the document to contribute to the
draft,
> review, etc.
> >
> > The intended status of the draft is Experimental, but we want to ask
> developers/vendors if they plan to implement it.
> >
> > This call for adoption ends: 1 February 2019
> >
> > Thanks,
> >
> > Benno Overeinder
> > DNSOP co-chair
> >
> >
> >
> > ___
> > 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

[DNSOP] 答复: 答复: Call for Adoption: draft-song-atr-large-resp

[宋林健]

Hi Brian, 

Thanks for your questions. Reply inline

>(1) Has your testing revealed *where* the IPv6 fragmentation is occurring? 
>IIRC, IPv6 requires the originating host to do so. And originating UDP packet 
>size will be the smaller of the authority servers' configs and the EDNS 
>bufsize on the request.

IPv6 fragmentation is done by the end host which is specified in in RFC8200. 
The difference of IPv4 and IPv6 fragmentation is comprehensively introduced in 
draft-ietf-intarea-frag-fragile-05.  EDNS0 bufsize initialized to 4096 octets 
has no meaning for large UDP DNS response. Because if a IPv6 packets size 
larger than 1500 will be fragmented by the Ethernet interface. AFAIK, I''m not 
sure there is a configuration on authority severs on the size of UDP packets 
size. I think you refer to the the size of the DNS message.

>(2) Have you experimented with setting EDNS0 UDP bufsize to the *actual max 
>size* that IPv6 allows *without fragmenting* (or MTU?), and what happens when 
>you do that? (Actual MTU may vary topologically, YMMV, etc.)

It require resolvers' change to set EDNS0 bufsize below a certain number. 
Usually the authority server will work around it  as stated in the ATR draft.

" To avoid that issue, some  authoritative servers may adopt a policy 
   ignoring the UDP payload size in EDNS0 extension and always 
   truncating the response when the response size is large than a 
   expected one."

It is introduced that some root operator did this during KSK rollover. 
(https://blog.apnic.net/2016/11/15/scoring-dns-root-server-system ) 

Because some end users may be behind a resolvers which is not TCP-capable(17% 
according to APNIC measurement). That is one background that ATR is proposed:

 "ATR will helpful for resolver without TCP capacity, because the resolver
   still has a fair chance to receive the large response. "

I noticed there is a typo in above sentence in 02-version in which the txt is 
""ATR will helpful for resolver with TCP capacity" .

>My suspicion is that the better approach for resolvers might actually be to do 
>their IPv6 stuff "better", for some value of "better", in a way that does not 
>require DNS protocol changes (or changes to transport specs like UDP or IPv6).
Or maybe we could add a new edns0 ip6-bufsize option in future so v4 vs v6 
limits can be separated (and thus standardize (and kind of simplify) resolver 
and auth server configs).

It is a choice to ask resolver or server to  adopt that change which  is in the 
solution category  of Tony Finch.  I think both work and both with incentive to 
change. The difference is resolver's change take long time (installed base).   
And the server's change will efficient in a timely manner.

However, ATR actually did not necessary require DNS protocol to change  or more 
specifically the change to the running authoritative server. Akira KATO once 
suggested me that ATR can be implemented as a on-path fix independent of DNS 
server. For example, use a hack in iptable or a separated device monitoring the 
DNS response size on the path and generate an additional truncated response if 
the size beyond a certain number.

Davey

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] 答复: Call for Adoption: draft-song-atr-large-resp

[宋林健]

Thanks for all commenter's, I appreciate your frankness and vote based on your 
technical sense. I understand your push back especially considering the DNS 
camel stuff. I try to reply some of comments here.

Some people argues on the problem statement of this draft.

> Peter: Meanwhile, we have no indication that the draft solves any existing 
> real world problem in a useful way.

> Petr Špaček : Solving rare operational problem with a huge and ugly hack is 
> no-go territory for Knot Resolver project.

It is not rare. It is just under the water. You cannot run a ship unaware of 
it, especially towards IPv6-only future. Here are some pointer and number are 
given:

[1] presents a 28.26% ~ 55.23% packets drop rate for IPv6 fragements. [2] 
reports 10% of the paths between the vantage points and the experimental setup 
filter IP fragments. [3] reports 37.45% of endpoints used IPv6-capable DNS 
resolvers that were incapable of receiving a fragmented IPv6 response. [4] Yeti 
testbed also observed over 7% failure rate for queries against IPv6-only server 
during KSK rollover using 100 probes. [5] is a IETF workgroup document of this 
problem. It is **not** a rare operational problem.

> Ralf Weber: Having one v6 name server that will respond correct with 
> fragments also solves the problem. I think the problem space is to narrow to 
> burden this problem on all resolvers.

Now 389 of v6 tld server including .org reply with large packets, please check 
[Appendix]. I'm not sure how they can respond correct currently when they need 
to add more content in answer section. I'm told that a few large DNS operator 
using certain DNSSEC tool generating a large DNSKEY RRset and RRSIG RRset.

> [Most importantly we need to get an explanation why Geoff's experiments
> show problems but clients can in practice resolve org. DNSKEY just fine.]

Network operation issues are hidden from the sense of application layer. The 
impact introduced by IPv6 fragments dropping is hidden by different layer of 
redundancy. From users perspective, dualstack applications run Happy eyeballs 
willl hide IPv6 networking issues from themselves and network operator. From 
DNS perspective, resolvers can retry, mostly likely fallback to TCP , without 
TCP they finally fallback to IPv4 to deliver  record ! If we leave this 
issue along, I bet the dual-stack period will last much longer than expect.

There is a separate thread in ORAC mailing list on " How .org name server 
handle large DNS response?". I'm looking forward to the response from org. DNS 
people. I expect some data and analysis not only emotion. I'm wondering there 
is difference in the query pattern (in terms of UDP/TCP ratio, IPv4/IPv6 ratio 
etc. ) between small response and large response .

[1] RFC7872, Observations on the Dropping of Packets with IPv6 Extension 
Headers in the Real World, https://tools.ietf.org/html/rfc7872
[2] De Boer, M. and J. Bosma, "Discovering Path MTU black holes on the Internet 
using RIPE Atlas", July 2012, 
.
[3] APNIC measurement study, 
https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/ 
[4] RFC8483 Yeti DNS testbed https://tools.ietf.org/html/rfc8483 
[5] IP Fragmentation Considered Fragile, 
https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-04 
[Appendix] 389 TLD's response for dnsky with RRSIG larger than 1500 (msg size + 
48)


#389 TLD's response packet for dnsky with RRSIG are larger than 1500 (msg 
size + 48) 
sl. 3319
bg. 3103
mm. 3063
si. 2739
xn--mgbx4cd0ab. 2511
za. 2455
best.   2053
kred.   2053
ceo.2051
americanexpress.2006
bananarepublic. 2003
weatherchannel. 2003
hiv.1994
inc.1994
xn--kpu716f.1994
xn--pbt977c.1994
swiftcover. 1991
analytics.  1988
homegoods.  1988
homesense.  1988
honeywell.  1988
marshalls.  1988
statefarm.  1988
country.1987
discover.   1985
jpmorgan.   1985
athleta.1982
banamex.1982
booking.1982
cartier.1982
chintai.1982
citadel.1982
farmers.1982
ferrero.1982
lincoln.1982
oldnavy.1982
watches.1982
weather.1982
winners.1982
dupont. 1979
flickr. 1979
intuit. 1979
kinder. 1979
mutual. 1979
office. 1979
piaget. 1979
rocher. 1979
tjmaxx. 1979
tkmaxx. 1979
yandex. 1979
chase.  1976
cisco.  1976
gucci.  1976
hyatt.  1976
intel.  1976
lilly.  1976
praxi.  1976
skype.  1976
yahoo.  1976
zippo.  1976
amex.   1973
citi.   1973
dell.   1973
duns.   1973
ford.   1973
hsbc.   1973
ieee.   1973
kpmg.   1973
mint.   1973
open.   1973
ping.   1973
teva.   1973
vivo.   1973
aaa.1970
cbn.1970
fox.1970
ftr.1970
gap.1970
jmp.1970
jnj.1970
mlb.1970
nfl.1970
qvc.1970
sas.1970
tdk.1970
tjx.1970
gdn.1954
ar. 1951
uy. 1951
buy.1916
xn--bck1b9a5dre4c.  1864
xn

[DNSOP] 答复: DNSSEC threshold signatures idea

[宋林健]

I also ask the same question and look for solutions. I do find a statement from 
a paper (The Honey Badger of BFT Protocols@ CCS 2016) that " if an trusted 
party is unavailable, then a distributed key generation protocol could be used 
instead (c.f., Boldyreva [11])."

[11] A. Boldyreva. Threshold signatures, multisignatures and blind
signatures based on the gap-diffie-hellman-group signature
scheme. In Public key cryptographyâA˘TPKC 2003 ˇ , pages
31–46. Springer, 2002

I have no experience on Boldyreva protocol though, but it seems possible 
without a central service if all participants follow a certain common rule or 
algorithm.

Davey
> -邮件原件-
> 发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Hugo Salgado-Herná
> ndez
> 发送时间: 2018年9月7日 3:22
> 收件人: Steve Crocker
> 抄送: dnsop; Mukund Sivaraman; dns-operati...@dns-oarc.net
> 主题: Re: [DNSOP] DNSSEC threshold signatures idea
> 
> On 15:08 06/09, Steve Crocker wrote:
> > How do you prevent compromise of the central service?
> >
> 
> For the initial setup a physical ceremony is necessary, to check there's no 
> extra
> subkeys and for secure transmision of them. But afterwards there's no need.
> Each node can check the final signature validates with the public key (just 
> like a
> normal signature), and the plain data should be public (DNSKEY rrset).
> 
> In this same first ceremony you can also share simmetric keys for the secure
> transmission of data and signature pieces.
> 
> The system is fault-tolerant as a subset of nodes can fail and the signing
> process can be completed, and you can detect faked sub-signatures.
> 
> Hugo
> 
> > Steve
> >
> >
> > On Thu, Sep 6, 2018 at 3:02 PM, Hugo Salgado-Hernández
> > 
> > wrote:
> >
> > > On 23:19 06/09, Mukund Sivaraman wrote:
> > > > On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández
> wrote:
> > > > > Hi Mukund.
> > > > > I talked about this to Davey in Montreal. There's an
> > > > > implementation in github[1] and presentations in OARC[2] and
> ICANN[3].
> > > >
> > > > Aha so you're the original source :)
> > > >
> > > > > I'm not sure if its being used right now in a live zone, but
> > > > > certainly in labs and testing. There's been some interests with
> > > > > academic institutions, but don't think they're ready yet.
> > > > >
> > > > > We've been trying to focus this technology as a "poor-man" HSM,
> > > > > as having similar security features without buying an expensive HW.
> > > > > But I think the root and similar high-value zones will benefit
> > > > > for having an split of the private key AND the fact of not
> > > > > needing a "root key ceremony" to sign, because you can sign
> > > > > remotely with each piece of the private key, and transmit the 
> > > > > "signature
> pieces"
> > > > > to a central place.
> > > > >
> > > > > Hugo
> > > > >
> > > > > [1] https://github.com/niclabs/docker/tree/master/tchsm
> > > > > [2]  > > 22&sessionId=3&resId=1&materialId=slides&confId=20>
> > > > > [3]  > > presentation-dnssec-cryptographic-20nov13-en>
> > > >
> > > > So this's implemented as a PKCS 11 provider.. interesting. In my
> > > > mind I was thinking along the lines of updates to dnssec-keygen +
> > > > dnssec-signzone + intermediate RRSIG representation using new RR
> > > > type + zone transfers to share intermediate effects.
> > >
> > > In our implementation you'll need a central "orchestrator" who
> > > creates the first key and split the private pieces to each signing
> > > node. This same orchestrator later send signature requests to each
> > > node, collect the signature pieces and defines the "consensus" of
> > > M/N. Finally, there's an PKCS11 interface between this orchestrator
> > > and the zone signing policy machinery (OpenDNSSEC in our setup).
> > >
> > > Hugo
> > >
> > >
> > > ___
> > > 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

[DNSOP] 答复: DNSSEC threshold signatures idea

[宋林健]

Hi Mukund，

Thank you for proposing here for comments and discussion. I would like to
share more background on this if people are interested. 

Actually I was inspired by several sources. One is the Multisignature
(https://en.bitcoin.it/wiki/Multisignature ) concept from Bitcoin which help
to reduce the risk of wallet keys be stolen.

One is from Yeti work we are doing where Hugo gave me some ideas. In Yeti
testbed, we try to implement the concept of "Share Zone Control" proposed by
PVM in ICANN ITI report. We firstly constructed the root system with 3
signers (3ZSK and 1 KSK) . We would like improve this system with more
fault-tolerant property and less dependency on a central entity. There is a
post I put in Yeti blog (https://goo.gl/7i4NxB ). 

When I survey on this, I learnt some concept of threshold signature
algorithms in the crypto academic field, like BLS , Boldyreva and PBC
(Pairing based crypto). But I'm not a crypto guys . I'm just looking for
mature and reliable crypto tool to fit my case, then we can test and try it
in existing testbed. Maybe people on this mailing list can help.

Best regares,
Davey

> -邮件原件-
> 发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Mukund Sivaraman
> 发送时间: 2018年9月7日 0:13
> 收件人: dnsop@ietf.org; dns-operati...@dns-oarc.net
> 主题: [DNSOP] DNSSEC threshold signatures idea
> 
> During a coversation about the Yeti project, Davey Song brought up an idea
> about using threshold signatures within DNSSEC. While he talked about it
> primarily for the root zone within the context of having multiple signers
for it,
> I'm curious to know what operators think about the concept for other
zones,
> and if there's any interest in having a working implementation.
> 
> DNSKEY RRs contain public keys. Corresponding secret keys are managed by
> signing entities in various ways:
> 
> * It may be for a low-risk zone and a human may leave the key on the
>   nameserver itself
> 
> * The key may be held by some number of trustworthy staff offline and
>   when signing is required, one of them signs the zone and returns the
>   signed zone
> 
> * It may be managed by an automated system under the control of one or
>   more people
> 
> * It may be held in a locked computer system which may be accessed when
>   multiple trustworthy "keepers" are present
> 
> * There may be schemes like this:
>   https://www.icann.org/news/blog/the-problem-with-the-seven-keys
> 
> In many of these cases, it may be possible for one rogue person to sign
records
> against the wish of the rest of the trustworthy group appointed by a zone
> owner. Even though it's unlikely, it's possible to do so because the
control over
> secret key material may be available to one person, even if it is wrapped
in
> multiple layers.
> 
> The concept of threshold crypto is that there is a public DNSKEY, for
which the
> secret key is not available in a single form where it can be
reconstructed.
> Instead, N members of a group have some key material each respectively,
and
> any M (< N) members of the group may work together to prepare RRSIGs by
> using their respective key materials individually, and collaborating to
generate
> the signatures.
> 
> It may be possible for such a scheme to be compatible with existing DNSSEC
> algorithms. Is there any operator interest in this?
> 
>   Mukund
> 
> ___
> 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] 答复: Call for Adoption: draft-bortzmeyer-rfc7816bis

[宋林健]

+1

 

DNS privacy is an important issue. I support this adoption. And I’m willing to 
review it. 

 

Davey

发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Tim Wicinski
发送时间: 2018年7月25日 0:33
收件人: dnsop
主题: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis

 

 

We discussed this and there appears to be support to adopt this, with

the caveat of adding more content to the section on Operational Considerations.

 

 

This starts a Call for Adoption for draft-bortzmeyer-rfc7816bis

 

The draft is available here: 
https://datatracker.ietf.org/doc/draft-bortzmeyer-rfc7816bis/

 

Please review this draft to see if you think it is suitable for adoption

by DNSOP, and comments to the list, clearly stating your view.

 

Please also indicate if you are willing to contribute text, review, etc.

 

This call for adoption ends: 9 August 2018

 

Thanks,

tim wicinski

DNSOP co-chair

 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] 答复: a fragmented and uncooperative Internet

[宋林健]

OK. I finally understand the context of the word " Darwinism " in many IETF 
discussion and slides. Haha~

Davey
> -邮件原件-
> 发件人: Jim Reid [mailto:j...@rfc1035.com]
> 发送时间: 2017年9月21日 15:22
> 收件人: "Davey Song(宋林健)"
> 抄送: Paul Vixie; dnsop WG
> 主题: a fragmented and uncooperative Internet
> 
> 
> > On 21 Sep 2017, at 08:08, Davey Song(宋林健)  wrote:
> >
> > In another word, we are facing the fragmented and uncooperative Internet.
> What should we do ?
> 
> Switch it off? Hand it over to ITU control? :-)
> 
> The Internet was designed from the outset to work around breakage. Packet
> fragmentation issues will always be with us unfortunately. The networks which
> have these problems will fix them: Darwinism will take care of that 
> eventually.
> Until then everyone else just has to work around them or ignore their
> brokenness. 'coz that's how it works.
> 
> We (for some definition of we) might come up with some tools to help identify
> the problem or do some outreach and education to help mend these broken
> networks. However I am sceptical those sort of things will be successful. 
> After
> all we still have nets, servers and middleboxes that can't/won't handle EDNS
> correctly or assume that DNS packets only ever go over UDP and are always <
> 512 bytes.



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[宋林健]

Hi Paul, 

I know you suggest expose the problem and let the trouble maker feeling the 
pain themselves. But return to the specific issue, from APNIC's measurement the 
ASes in the path are dropping the fragments, rather than end ASes. From these 
ASes' view , it's your pain not theirs. 

In another word, we are facing the fragmented and uncooperative Internet. What 
should we do ? It is very hard to coordinate all parts and networks. DNS is a 
field with lots of tussle.

Davey

> -邮件原件-
> 发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Paul Vixie
> 发送时间: 2017年9月21日 12:50
> 收件人: "Davey Song(宋林健)"
> 抄送: 'Davey Song'; 'dnsop'; 'william manning'
> 主题: Re: [DNSOP] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt
> 
> 
> 
> Davey Song(宋林健) wrote:
> > Thank you.
> >
> > The large DNS response in IPv6 is a real problem. ATR is one option to
> > adopted in authoritative  server alone. If someone or party have more
> > influence on both resolver and authoritative side (cloud and app
> > provider who can choose their own DNS resolution path),  Mukund’s
> > proposal to fragment the DNS message is a good
> > solution.https://tools.ietf.org/html/draft-muks-dns-message-fragments-
> > 00
> 
> both ideas are wrong. what we have to do is arrange to fragment, using the
> ipv6 extension header, all ipv6 udp, for a period of not less than five years.
> noone who blocks ipv6 extension headers should be able to get reliable ipv6 
> udp
> services. we have to make this problem felt where it is made. we must NOT
> work around it to insulate the makers of the problem from the costs of their
> actions.
> 
> > So I do recommend ATR and DNS message fragments should be both
> > considered  in a tool box for large DNS response issues.
> 
> can a freebsd kernel hacker please contact me? i need some patches, but i'm
> traveling extensively, and i can't do the investigation and software 
> engineering
> myself.
> 
> --
> P Vixie
> 
> ___
> 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] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt

[宋林健]

Thank you. 

 

The large DNS response in IPv6 is a real problem. ATR is one option to adopted 
in authoritative  server alone. If someone or party have more influence on both 
resolver and authoritative side (cloud and app provider who can choose their 
own DNS resolution path),  Mukund’s proposal to fragment the DNS message is a 
good solution.   
https://tools.ietf.org/html/draft-muks-dns-message-fragments-00 

 

So I do recommend ATR and DNS message fragments should be both considered  in a 
tool box for large DNS response issues. 

 

Davey  

 

发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 william manning
发送时间: 2017年9月21日 1:30
收件人: Davey Song
抄送: dnsop
主题: Re: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt

 

i think this is a worthy document for consideration.  

 

/Wm

 

On Sun, Sep 10, 2017 at 9:29 PM, Davey Song  wrote:

Hi folks, 

 

I just submit a draft dealing with issue of large DNS response especially in 
IPv6. Commnets are welcome. 

 

If chairs think it is in the scope of dnsop wg and encourage us to discuss it 
in this mailing list, I can submit it as a draft listed in dnsop wg.

 

Davey

  

 

-- Forwarded message --
From: 
Date: 11 September 2017 at 10:13
Subject: I-D Action: draft-song-atr-large-resp-00.txt
To: i-d-annou...@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : ATR: Additional Truncated Response for Large DNS 
Response
Author  : Linjian Song
Filename: draft-song-atr-large-resp-00.txt
Pages   : 8
Date: 2017-09-10

Abstract:
   As the increasing use of DNSSEC and IPv6, there are more public
   evidence and concerns on IPv6 fragmentation issues due to larger DNS
   payloads over IPv6.  This memo introduces an simple improvement on
   authoritative server by replying additional truncated response just
   after the normal large response.

   REMOVE BEFORE PUBLICATION: The source of the document with test
   script is currently placed at GitHub [ATR-Github].  Comments and pull
   request are welcome.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-song-atr-large-resp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-song-atr-large-resp-00
https://datatracker.ietf.org/doc/html/draft-song-atr-large-resp-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce 
 
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 


___
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] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt

[宋林健]

Sorry, You are right.

> -邮件原件-
> 发件人: Davey Song(宋林健) [mailto:ljs...@biigroup.cn]
> 发送时间: 2017年9月13日 17:56
> 收件人: 'Lanlan Pan'; 'Davey Song'
> 抄送: 'dnsop'
> 主题: 答复: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt
> 
> 
> > ATR make Authoritative Servers send normal big response packet before they
> try to send TC response for large RRsets ?
> 
> No. big response packet first, then TC response.
> 
> Davey

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[宋林健]

> ATR make Authoritative Servers send normal big response packet before they 
> try to send TC response for large RRsets ? 

No. big response packet first, then TC response.

Davey

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[宋林健]

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. 

Davey

> -邮件原件-
> 发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Stephane Bortzmeyer
> 发送时间: 2017年9月7日 23:43
> 收件人: tjw ietf
> 抄送: dnsop
> 主题: Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
> 
> On Tue, Sep 05, 2017 at 03:25:39PM -0400,  tjw ietf 
> wrote  a message of 77 lines which said:
> 
> > This starts a formal Call for Adoption for
> > draft-tale-dnsop-serve-stale
> >
> > The draft is available here:
> > https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/
> 
> I'm not enthousiastic. We should focus on making the DNS infrastructure
more
> reliable, not on adding something to a pile of already fragile protocols.
> 
> There is also an opportunity that it masks failures and prevents people
from
> properly assigning blame: "example.com works if I use Something Public DNS
> but not if I use my ISP's resolver, therefore my ISP is broken".
> 
> Also, the current draft does not make crystal-clear that stale data MUST
NOT
> be served unless no authoritative name server replies.
> 
> If it is adopted, I think that requesting some way to convey the fact it
is stale to
> the client (Davey Song's message) is necessary.
> 
> Regarding the draft, I'm surprised by the paragraph starting with "Paul
Vixie
> has suggested", paragraph which seems to completely ignore RFC 8020.
> 
> ___
> 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] 答复: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

[宋林健]

Just quickly go through the draft. 

 

One question: Is it worthwhile to let sub-resolver to know that the answer is 
stale. It is true that “stale bread is better than no bread” on the recursive 
server’s point of view. But it may be not true for sub-resolver or measurement 
probes .

 

The user may want to be more informative. They may have alterative recursive 
servers or other resolution path ( some apps have their own resolution path) . 
I have this thought analogous to buying a sushi in 7&11 shop. I pay attention 
to the   
expiration time. I think I need to know it. 

 

Davey

 

发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 tjw ietf
发送时间: 2017年9月6日 3:26
收件人: dnsop
主题: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

 

August is over and my self-imposed holiday is over, so it's time to get busy 
again. We have this document marked as a candidate for adoption.  

 

This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale

 

The draft is available here:

https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/

 

Please review this draft to see if you think it is suitable for adoption by 
DNSOP, and comments to the list, clearly stating your view.

 

Please also indicate if you are willing to contribute text, review, etc.

 

*If You have already stated your position for or against adoption, we are 
counting those so you do not need to repeat yourself. *

 

This call for adoption ends: 19 September 2017

 

Thanks,

tim wicinski

DNSOP co-chair

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] 答复: Call for Adoption: draft-song-dns-wireformat-http

[宋林健]

Hi Tim, 

Thanks for the chair's work. If there is any editing suggestion from HTTPbis
WG, please let the us know.

Davey
-邮件原件-
发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Tim Wicinski
发送时间: 2016年8月3日 16:39
收件人: dnsop
主题: Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http


Hi

This adoption period ended a week ago, and between the comments made when
the document was placed in the 'Candidate' phase and the actual call, it has
enough consensus to pass adoption.

One thing of Note:  I'm going to begin some conversations with the HTTPbis
working group on this draft. In some initial discussions, they have some
concerns mostly about decisions made being documented more clearly.

thanks
tim


On 7/11/16 6:33 PM, Tim Wicinski wrote:
> This starts an official Call for Adoption for
>  draft-song-dns-wireformat-http
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
>
> Please review this draft to see if you think it is suitable for 
> adoption by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> We wanted this Call to coincide with the Berlin meeting so if there is 
> opinions that needed to be voiced, they can do so.
>
> This call for adoption ends: 25 July 2016
>
> Thanks,
> tim wicinski
> DNSOP co-chair

___
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] JavaScript implementation of DNS over HTTP wire format draft

[Davey(宋林健)]

+1 for the potential usage

It allows website operator setup their own RDNS proxy to work around the 
ad-injection hijack risk which is getting popular.  DNS resolution inside some 
app also will not rely on the users’ DNS path in their ISP’s networks.

Davey

> 在 2016年7月18日，14:13，Shane Kerr  写道：
> 
> Hello,
> 
> tl;dr DNS over HTTP in JavaScript implementation done. Demo here:
>  http://blij.tk:/
> 
> I decided to see how much trouble it would be to use the DNS over HTTP
> protocol from JavaScript. I did this over the IETF 96 Hackathon, with
> some extra time this morning.
> 
> While at first I thought that it made no sense - in fact it seemed
> crazy - on reflection there are several good reasons for this.
> 
> First, unlike a higher-level API, doing the packet munging yourself
> means never having to wait for an API to support the newest, craziest
> DNS features.
> 
> Second, you have access to the full contents of the DNS packets. That
> means getting TTL, seeing full CNAME chains, and so on.
> 
> Third, you can do DNSSEC validation if that's what you want.
> 
> The demo page explains the details, but I will cover them here for
> posterity. (Also I'm not sure how long I will keep the demo up. I have
> no plans to turn it off, but it's running on an aging VPS which will
> probably need to be revamped at some point.)
> 
> 
> 
> On the browser side, a JavaScript program builds a DNS wire-format
> packet, and then submits it to the server side via a HTTP POST. The
> program uses the native-dns-packet JavaScript library combined with the
> code using the Browserify tool:
> 
>   $ npm install native-dns-packet
>   $ npm install buffercursor
>   $ browserify test.js -o dnsoverhttpjsdemo.js
> 
> The test.js code works with the HTML form and the native-dns-packet
> stuff to do the actual work.
> 
> On the server side, the DNS over HTTP server proxy written in Go is
> run, with a couple of modifications:
> 
> * It was modified to act as an HTTP server when
>  the /.well-known/dns-wireformat URL is not used.   This allows it to
>  serve HTML documents, which is necessary since JavaScript requires
>  that all communication is with the same server that the script itself
>  comes from. 
> 
> * The type specifying the DNS transport requested was changed to
>  X-Proxy-DNS-Transport since the browser will not add unknown header
>  fields when sending a POST command. 
> 
> Source for the server proxy can be found at:
> 
>https://github.com/shane-kerr/DNSoverHTTPinGO/tree/ietf96hackathon. 
> 
> It will be merged into the main DNS over HTTP in Go repository soon.
> 
> See you at the dnsop session soon! :)
> 
> --
> Shane
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

---
Davey Song(宋林健)
BII Lab
ljs...@biigroup.cn



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] 答复: Call for Adoption: draft-song-dns-wireformat-http

[宋林健]

+1, there is enough room for us to improve. 

When I first drafted some idea, I was told that the IETF work is driven by
the community. It's good. As one of the co-authors, I'm fairly open for
suggestions. But for experimental draft, I'm not sure whether we should
stick to the scope of original experiment we have done (hiding the DNS
traffic in web traffic ), or expand it for potential usage. I will ask and
handle it to the WG people if it is adopted by the WG.

As to the question of performance, we once had done some simple test
(http://www.dnsv6lab.net ) . It is not so scary and almost equal to DNS/TCP.
I'm glad to see more comprehensive test result if some guys are interested
on that. 

Davey

-邮件原件-
发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Paul Hoffman
发送时间: 2016年7月13日 3:22
收件人: dnsop
主题: Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

Folks, this is a call for WG adoption, not a design exercise. If the WG
adopts the document, we will have plenty of opportunity to fine-tune or make
major changes. Such as:


On 12 Jul 2016, at 11:51, Shane Kerr wrote:

> I recognize that HTTP/2 is definitely a better option because of 
> out-of-order replies, but I worry about requiring it. It's still quite 
> new and language support may be spotty. But I guess given it's 
> popularity this shouldn't be a huge problem, so maybe that is a 
> reasonable recommendation.

If this WG adopts the document and then says "but we want to use an older
version of the HTTP protocol", we should expect a fair amount of push-back
during IETF Last Call.

--Paul Hoffman

___
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] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

[宋林健]

When I first looked into DNS, I was recommended with a complex figure of DNS
protocol family describing the dependency and activeness of many RFC
documents. I'm wondering if it is possible to attach versions to DNS
protocol similar like IPv4 and IPv6, http/1.1 and HTTP/2 which can give
clear path of DNS evolution and help to keep protocol conformance. 

Davey
-邮件原件-
发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Shane Kerr
发送时间: 2016年7月8日 22:39
收件人: dnsop@ietf.org
主题: [DNSOP] Fw: New Version Notification for draft-shane-dns-manifesto-00.
txt

Hello,

I've put together some high-level thoughts I had about DNS.  I started
thinking about this a year or so ago, and typed up an earlier version 9
months ago, but wasn't sure what to do with it. I've been struggling to
figure out how to actually make the types of changes that I am thinking of -
in the end I guess that the IETF is the best place for this work, if it is
possible. So I finally turned them into a draft.

My main goal is to try to make the DNS a more agile protocol. Until this is
done, working in DNS will always be an exercise in pushing boulders uphill.

GitHub page here for pull requests:

https://github.com/shane-kerr/DNSManifesto

I'm not really sure what the next steps are, if any. One fear I have is that
nobody is looking at the overall architecture of the DNS, and so we'll end
up muddling along one patch at a time, forever. Hopefully not!

Please let me know what you think. Also, I'll be in Berlin for the IETF and
happy to discuss things there, with or without beer. ;)

Cheers,

--
Shane

p.s. I did this using Miek Gieben's awesome mmark tool. Writing a
 Internet Draft in Markdown instead of XML is awesome. AWE-SOME.
 https://github.com/miekg/mmark



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] 答复: Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt

[宋林健]

I think the major benefit from this proposal is to make the upper layer(http 
layer) unaware the DNS data inside. So we do not need to consider the 
checksum-like mechanism , special authentication for DNS stub, and do keep 
truncation logic.  I accept your idea that a new head filed Proxy-DNS-Transport 
may break that transparency.

 

-Davey

 

发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Adrien de Croy
发送时间: 2016年5月3日 13:15
收件人: Davey Song; dnsop@ietf.org
主题: Re: [DNSOP] Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

 

 

Hi Davey

 

Some general comments:

 

I don't think you can claim that https provides data integrity or privacy any 
more, since MitM proxies are abundant.

 

I think some thought should be given to how a DNS stub might deal with a 
captive portal or http proxy authentication.

 

I think also that any HTTP server that receives such a request probably ought 
to be validating the encapsulated binary data before forwarding it to any DNS 
server.

 

I wonder why you'd want to keep truncation, as the request should be able to 
benefit from the fact that fundamentally it's made over TCP to the HTTP agent.

 

I would also suggest looking into how such requests might be best blocked by an 
http proxy, because this will be a requirement of proxy operators, and it would 
be good to consider user experience for when this happens, so that a consistent 
approach can be taken (rather than every different proxy blocking it some other 
way so that the user experience becomes awful).

 

Cheers

Adrien

 

 

 

 

-- Original Message --

From: "Davey Song" 

To: "dnsop@ietf.org" 

Sent: 27/04/2016 8:43:09 p.m.

Subject: [DNSOP] Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

 

Hi Colleagues, 

 

We have update the dns-wireformat draft according to the advice we gained from 
last IETF meeting, changing the well-known URI from dns-over-http to 
dns-wireformat according to Paul Hoffman's suggestion. Any further comments ? I 
would like to ask for WG to adopt it this time.

 

Best regards,

Davey

 

-- Forwarded message --
From: 
Date: 27 April 2016 at 16:03
Subject: New Version Notification for draft-song-dns-wireformat-http-03.txt
To: "Paul A. Vixie" , Shane Kerr , Runxia 
Wan , Linjian Song 



A new version of I-D, draft-song-dns-wireformat-http-03.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:   draft-song-dns-wireformat-http
Revision:   03
Title:  DNS wire-format over HTTP
Document date:  2016-04-27
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-song-dns-wireformat-http-03.txt
Status: https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
Htmlized:   https://tools.ietf.org/html/draft-song-dns-wireformat-http-03
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-song-dns-wireformat-http-03

Abstract:
   This memo introduces a way to tunnel DNS data over HTTP.  This may be
   useful in any situation where DNS is not working properly, such as
   when there is middlebox misbehavior.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org 
 .

The IETF Secretariat

 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] 答复: Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt

[宋林健]

It’s interesting idea. We have not discuss that before. I’m not sure the impact 
of bad HTTP proxies to this protocol.  Anyway it is not free to register a new 
head filed. I will discuss with co-author about delivering the TCP/UDP massage 
via other meta format. Thanks for your interest and comments.

 

Davey

发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Adrien de Croy
发送时间: 2016年5月3日 13:25
收件人: Adrien de Croy; Davey Song; dnsop@ietf.org
主题: Re: [DNSOP] Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

 

 

One other thing... there are plenty of http proxies that will rightly or 
wrongly strip or reject unknown header fields.

 

Since you're proposing the use of POST to send the query, why not also include 
the Proxy-DNS-Transport value as POST data also.

 

either inside the application/dns-wireformat definition, or some other new meta 
format, or just base64 encode the message, and include both parts as form data 
(application/x-www-form-encoded).

 

The same applies to unknown response headers (may be stripped or blocked)

 

Regards


Adrien

 

-- Original Message --

From: "Adrien de Croy" 

To: "Davey Song" ; "dnsop@ietf.org" 

Sent: 3/05/2016 5:14:31 p.m.

Subject: Re: [DNSOP] Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

 

 

Hi Davey

 

Some general comments:

 

I don't think you can claim that https provides data integrity or privacy any 
more, since MitM proxies are abundant.

 

I think some thought should be given to how a DNS stub might deal with a 
captive portal or http proxy authentication.

 

I think also that any HTTP server that receives such a request probably ought 
to be validating the encapsulated binary data before forwarding it to any DNS 
server.

 

I wonder why you'd want to keep truncation, as the request should be able to 
benefit from the fact that fundamentally it's made over TCP to the HTTP agent.

 

I would also suggest looking into how such requests might be best blocked by an 
http proxy, because this will be a requirement of proxy operators, and it would 
be good to consider user experience for when this happens, so that a consistent 
approach can be taken (rather than every different proxy blocking it some other 
way so that the user experience becomes awful).

 

Cheers

Adrien

 

 

 

 

-- Original Message --

From: "Davey Song" 

To: "dnsop@ietf.org" 

Sent: 27/04/2016 8:43:09 p.m.

Subject: [DNSOP] Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

 

Hi Colleagues, 

 

We have update the dns-wireformat draft according to the advice we gained from 
last IETF meeting, changing the well-known URI from dns-over-http to 
dns-wireformat according to Paul Hoffman's suggestion. Any further comments ? I 
would like to ask for WG to adopt it this time.

 

Best regards,

Davey

 

-- Forwarded message --
From: 
Date: 27 April 2016 at 16:03
Subject: New Version Notification for draft-song-dns-wireformat-http-03.txt
To: "Paul A. Vixie" , Shane Kerr , Runxia 
Wan , Linjian Song 



A new version of I-D, draft-song-dns-wireformat-http-03.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:   draft-song-dns-wireformat-http
Revision:   03
Title:  DNS wire-format over HTTP
Document date:  2016-04-27
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-song-dns-wireformat-http-03.txt
Status: https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
Htmlized:   https://tools.ietf.org/html/draft-song-dns-wireformat-http-03
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-song-dns-wireformat-http-03

Abstract:
   This memo introduces a way to tunnel DNS data over HTTP.  This may be
   useful in any situation where DNS is not working properly, such as
   when there is middlebox misbehavior.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org 
 .

The IETF Secretariat

 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] 答复: New Agenda Uploaded

[宋林健]

Note that the **Session 2** is in Friday (10:00-12:00) not 
Wednesday(10:00-12:00). It is wrong in the attached file 
dnsop-ietf95-agenda.txt.

-邮件原件-
发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Tim Wicinski
发送时间: 2016年4月3日 5:28
收件人: dnsop
主题: [DNSOP] New Agenda Uploaded


All,

After some discussion with my co-chair and some authors I've worked out a new 
agenda and uploaded it (and include it here)

tl;dr

Wednesday Afternoon One Hour Session:

This will be "Current Bussiness" and will cover all drafts which have
*already* been adopted by the working group. We'll cover some updates and there 
are a few (nxdomain-cut) which have some vocal opponents.

Friday Morning Two Hour Session:

This will be three different things:

- Possibly New Working Group Business:  Drafts which have some good discussion 
and may end up coming up for adoption.

- Not New Working Group Work:  There are two drafts which have asked for some 
discussion time, but are probably "scraping the ceiling" of the DNSOP charter.  
That's fine - the chairs have always felt we can host and shepherd these sort 
of discussions, and if so, spin them into a new 
working group (see: DPRIVE).   Consider this section of the meeting 
'dns-dispatch' if it helps you sleep better at night.

- 6761 Design Team discussion

Thanks for your patience.

*Presenters* - Send us slides.

thanks
Tim/Suzanne



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS message fragments

[Davey(宋林健)]

FYI

There is a implementation of DNS fragments which is placed in the GitHub.

https://github.com/BII-Lab/DNS-layer-Fragmentation 
<https://github.com/BII-Lab/DNS-layer-Fragmentation>

any suggestion and feedback is welcome.

Davey
> 在 2015年7月22日，19:24，Shane Kerr  写道：
> 
> Dear dnsop working group participants,
> 
> We put together a draft with more details about an idea that Mukund
> Sivaraman proposed back in December 2014. There are still a number of
> wrinkles to be ironed out, but we wanted to get it out for discussion.
> 
> Cheers,
> 
> --
> Shane
> 
> 
> Begin forwarded message:
> 
> Date: Mon, 20 Jul 2015 06:41:00 -0700
> From: internet-dra...@ietf.org
> To: "Linjian Song" , "Shane Kerr"
> ,  "Mukund Sivaraman" , "Shane Kerr"
> , "Davey Song" , "Mukund
> Sivaraman"  Subject: New Version Notification for
> draft-muks-dns-message-fragments-00.txt
> 
> 
> 
> A new version of I-D, draft-muks-dns-message-fragments-00.txt
> has been successfully submitted by Shane Kerr and posted to the
> IETF repository.
> 
> Name: draft-muks-dns-message-fragments
> Revision: 00
> Title:DNS message fragments
> Document date:2015-07-20
> Group:Individual Submission
> Pages:13
> URL:
> https://www.ietf.org/internet-drafts/draft-muks-dns-message-fragments-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/
> Htmlized:
> https://tools.ietf.org/html/draft-muks-dns-message-fragments-00
> 
> 
> Abstract:
>   This document describes a method to transmit DNS messages over
>   multiple UDP datagrams by fragmenting them at the application layer.
>   The objective is to allow authoriative servers to successfully reply
>   to DNS queries via UDP using multiple smaller datagrams, where larger
>   datagrams may not pass through the network successfully.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

---
Davey Song(宋林健)
BII Lab
ljs...@biigroup.cn



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

[宋林健]

Hi Warren

It's good idea that the authority DNS be smart enough to predict or
configured to package all the information for a URL as a whole object (like
a webpage). It will reduce the latency for user. 

As to the draft itself, there are two questions:

First, for a same transaction, the cost from using TCP may be more than the
gain from the queries you save, which may ultimately let the performance
become even worse. Do you have any consideration on this?

Second, the purpose of using TCP is to mitigate amplify attack as you
describe in the draft. I notice that there is a draft using DNS cookie to
counter that problem. But it lacks incentive to deploy. For my concern, you
can consider to combine the two ideas to achieve better result.

Glad to see more discussion on application and innovation of large packet
which will lead us to break through the limitation of 512B :-)

Davey

-邮件原件-
发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Warren Kumari
发送时间: 2015年1月12日 4:52
收件人: dnsop
主题: [DNSOP] Fwd: New Version Notification for
draft-wkumari-dnsop-multiple-responses-00.txt

Hi all,

This document may contain much that makes folk grumpy.

It proposes allowing an authoritative nameserver to return additional
information (surprisingly, in the Additional section), and have recursives
trust it (because it is DNSSEC signed). This makes responses larger, and so
we propose an, um, interesting mitigation to the DDoS concern... you'll have
to read it to find out what :-P

W


-- Forwarded message --
From:  
Date: Sun, Jan 11, 2015 at 3:47 PM
Subject: New Version Notification for
draft-wkumari-dnsop-multiple-responses-00.txt
To: Wesley Hardaker , Warren Kumari ,
Zhiwei Yan 



A new version of I-D, draft-wkumari-dnsop-multiple-responses-00.txt
has been successfully submitted by Warren Kumari and posted to the IETF
repository.

Name:   draft-wkumari-dnsop-multiple-responses
Revision:   00
Title:  Returning multiple answers in a DNS response.
Document date:  2015-01-11
Group:  Individual Submission
Pages:  8
URL:
http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-multiple-responses-0
0.txt
Status:
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
Htmlized:
http://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-00


Abstract:
   This document (re)introduces the ability to provide multiple answers
   in a DNS response.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

___
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