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

From: Benno Overeinder <[email-masked]>
Date: Fri, 18 Jan 2019 18:55:16 +0100

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

---

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 21 Jan 2019 11:22:00 +0100

Hello,

> This call for adoption ends: 1 February 2019

I oppose adoption. Any implementation of this draft will actively hurt the DNS and the Internet, and thus publication as an RFC will actively hurt the DNS and the Internet.

The draft doubles the number of packets involved in a legitimate exchange; it more than doubles the number of packets involved in a spoofed exchange. About half of these packets are ICMP packets. Without the draft, ICMP packets are useful debugging aids, and in big numbers, indications of attacks or operational problems. With the draft, ICMP becomes another useless source of background noise.

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

Please do not adopt.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 21 Jan 2019 11:26:12 +0100

> On 21 Jan 2019, at 11:22, Peter van Dijk <[email-masked]> wrote:
> 
> Signed PGP part
> Hello,
> 

+1 to everything that Peter said.  I’ve been opposing ATR draft from the very beginning.  We can’t be removing EDNS workarounds and at the same time slap another workaround into the DNS.

Ondrej
--
Ondřej Surý
[email-masked]

---

From: Jim Reid <[email-masked]>
Date: Mon, 21 Jan 2019 10:34:33 +0000

> On 21 Jan 2019, at 10:26, Ondřej Surý <[email-masked]> wrote:
> 
> We can’t be removing EDNS workarounds and at the same time slap another workaround into the DNS.

+1

I think the WG should drop this draft.

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 21 Jan 2019 11:41:57 +0100

Moin!

On 21 Jan 2019, at 11:26, Ondřej Surý wrote:
> +1 to everything that Peter said.  I’ve been opposing ATR draft from 
> the very beginning.  We can’t be removing EDNS workarounds and at 
> the same time slap another workaround into the DNS.
Another +1 for not adopting this draft. I wonder if there is a 
coincidence that the end of the adoption call is on the same date as DNS 
Flag day ;-).

If I recall the presentation that lead to this correct it is mostly an 
IPv6 problem and given the nature of DNS it will only occur if all name 
servers are on v6. 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.

So long
-Ralf
—--
Ralf Weber

---

From: Petr Špaček <[email-masked]>
Date: Mon, 21 Jan 2019 11:46:29 +0100

> I think the WG should drop this draft.

+1, I also oppose adoption of this draft.

Solving rare operational problem with a huge and ugly hack is no-go
territory for Knot Resolver project.

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

-- 
Petr Špaček  @  CZ.NIC

---

From: "John Dickinson" <[email-masked]>
Date: Mon, 21 Jan 2019 10:46:42 +0000

+1. I we should not adopt this draft for all the reasons all ready presented in the thread and also the draft text regarding "moving all DNS over TCP”.

regards
John

On 21 Jan 2019, at 10:41, Ralf Weber wrote:

> Another +1 for not adopting this draft. I wonder if there is a coincidence that the end of the adoption call is on the same date as DNS Flag day ;-).
>
> If I recall the presentation that lead to this correct it is mostly an IPv6 problem and given the nature of DNS it will only occur if all name servers are on v6. 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.
>
> So long
> -Ralf
> —--
> Ralf Weber
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

John Dickinson

https://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.

---

From: Ralph Dolmans <[email-masked]>
Date: Mon, 21 Jan 2019 12:11:36 +0100

> I oppose adoption. Any implementation of this draft will actively hurt the DNS and the Internet, and thus publication as an RFC will actively hurt the DNS and the Internet.

I agree with Peter. This workaround does more harm than good and should
not be adopted.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Jan 2019 13:49:58 +0100

Peter van Dijk wrote on 2019-01-21 11:22:
>> ...
>> This starts a Call for Adoption for: draft-song-atr-large-resp
> 
> I oppose adoption. ...
likewise. we should not avoid fragmentation in this particular way. that 
is, we can use persistent TCP, or we can avoid sending large messages by 
shaping their contents better (smaller signatures, less additional data).

in fact i would prefer to embrace fragmentation and fix it. so, in 
addition to my reasoning above, i am also biased against the goal 
itself. (i say this not to persuade, but for full disclosure.)

in ~1998, the IETF DNSIND WG persuaded me to remove the MD bit from 
EDNS0, and the reasons given then (see the archives) are all still valid 
today, especially given that IPv6 made fragmentation worse not better 
than it was in V4, and it was pretty broken in V4, the absolute value of 
this negative bar was rather high.

-- 
P Vixie

---

From: Davey Song(宋林健) <[email-masked]>
Date: Tue, 22 Jan 2019 16:50:18 +0800

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.

> 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 AAAA 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, <http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf>.
[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--eckvdtc9d.	1852
xn--gckr3f0f.	1849
xn--1ck2e1b.	1846
xn--cck2b3b.	1846
xn--fct429k.	1846
xn--g2xx48c.	1846
xn--gk3at1e.	1846
xn--jvr189m.	1846
xn--rovu88b.	1846
accountant.	1843
baseball.	1837
download.	1837
grainger.	1837
pharmacy.	1837
audible.	1834
cricket.	1834
science.	1834
wanggou.	1834
whoswho.	1834
yamaxun.	1834
author.	1831
circle.	1831
coupon.	1831
dealer.	1831
health.	1831
hotels.	1831
kindle.	1831
racing.	1831
review.	1831
safety.	1831
secure.	1831
stream.	1831
taipei.	1831
vuelos.	1831
webcam.	1831
zappos.	1831
bible.	1828
earth.	1828
faith.	1828
osaka.	1828
party.	1828
prime.	1828
smile.	1828
trade.	1828
tunes.	1828
tushu.	1828
able.	1825
baby.	1825
book.	1825
buzz.	1825
call.	1825
date.	1825
deal.	1825
fast.	1825
fire.	1825
free.	1825
imdb.	1825
like.	1825
loan.	1825
qpon.	1825
read.	1825
room.	1825
safe.	1825
save.	1825
silk.	1825
song.	1825
spot.	1825
talk.	1825
tube.	1825
zero.	1825
aws.	1822
bid.	1822
bot.	1822
got.	1822
hot.	1822
jot.	1822
joy.	1822
moe.	1822
moi.	1822
now.	1822
nyc.	1822
pay.	1822
pin.	1822
uno.	1822
win.	1822
wow.	1822
you.	1822
ma.	1769
blackfriday.	1762
christmas.	1756
property.	1753
flowers.	1750
guitars.	1750
hosting.	1750
hiphop.	1747
juegos.	1747
tattoo.	1747
audio.	1744
click.	1744
photo.	1744
auto.	1741
cars.	1741
diet.	1741
game.	1741
gift.	1741
help.	1741
link.	1741
pics.	1741
sexy.	1741
car.	1738
lol.	1738
mom.	1738
ky.	1735
xn--mgbai9azgqp6j.	1720
firmdale.	1693
travelersinsurance.	1685
xn--mgbt3dhd.	1681
xn--fzys8d69uvgm.	1677
xn--i1b6b1a6a2e.	1673
xn--nqv7fs00ema.	1673
nowruz.	1669
xn--b4w605ferd.	1669
xn--jlq61u9w7b.	1669
pars.	1665
shia.	1665
wolterskluwer.	1665
tci.	1663
scholarships.	1661
creditunion.	1657
lamborghini.	1657
motorcycles.	1657
progressive.	1657
redumbrella.	1657
xn--6frz82g.	1657
xn--9krt00a.	1657
xn--estv75g.	1657
bnpparibas.	1653
boehringer.	1653
extraspace.	1653
schaeffler.	1653
volkswagen.	1653
xn--4gbrim.	1653
xn--5tzm5g.	1653
xn--kput3i.	1653
homedepot.	1649
richardli.	1649
statebank.	1649
stockholm.	1649
travelers.	1649
xn--c1avg.	1649
xn--nqv7f.	1649
cipriani.	1645
clinique.	1645
goodyear.	1645
hdfcbank.	1645
helsinki.	1645
istanbul.	1645
marriott.	1645
redstone.	1645
agakhan.	1641
alibaba.	1641
avianca.	1641
bugatti.	1641
ismaili.	1641
lasalle.	1641
metlife.	1641
organic.	1641
origins.	1641
shiksha.	1641
shriram.	1641
temasek.	1641
abbott.	1637
abbvie.	1637
active.	1637
alipay.	1637
dunlop.	1637
emerck.	1637
gallup.	1637
global.	1637
hermes.	1637
imamat.	1637
kosher.	1637
locker.	1637
mormon.	1637
natura.	1637
viking.	1637
yachts.	1637
adult.	1633
autos.	1633
black.	1633
boats.	1633
dabur.	1633
delta.	1633
edeka.	1633
green.	1633
homes.	1633
lamer.	1633
lotto.	1633
nokia.	1633
nowtv.	1633
poker.	1633
promo.	1633
stada.	1633
vegas.	1633
weibo.	1633
akdn.	1629
ally.	1629
asia.	1629
audi.	1629
blue.	1629
cern.	1629
cyou.	1629
fage.	1629
icbc.	1629
info.	1629
lgbt.	1629
ltda.	1629
ollo.	1629
pccw.	1629
pink.	1629
porn.	1629
post.	1629
rich.	1629
shaw.	1629
sina.	1629
star.	1629
vote.	1629
voto.	1629
zara.	1629
aco.	1625
bcg.	1625
bet.	1625
bnl.	1625
ceb.	1625
dot.	1625
dtv.	1625
gea.	1625
hkt.	1625
ist.	1625
itv.	1625
jcp.	1625
jll.	1625
kim.	1625
lds.	1625
ngo.	1625
nra.	1625
ong.	1625
onl.	1625
org.	1625
ott.	1625
pet.	1625
pwc.	1625
red.	1625
sbi.	1625
sew.	1625
sex.	1625
srl.	1625
thd.	1625
trv.	1625
tvs.	1625
ups.	1625
vig.	1625
xin.	1625
xxx.	1625
ag.	1621
bz.	1621
gi.	1621
lc.	1621
me.	1621
mn.	1621
sc.	1621
cancerresearch.	1585
barclaycard.	1573
barclays.	1561
luxury.	1553
monash.	1553
physio.	1553
build.	1549
tel.	1546
doha.	1545
menu.	1545
ibm.	1541
men.	1541
mtn.	1541
one.	1541
wtc.	1541
au.	1537
xn--fiqs8s.	1505
xn--fiqz9s.	1505
icu.	1479
capetown.	1477
hyundai.	1474
cn.	1473
durban.	1473
joburg.	1473
sharp.	1468
kiwi.	1465
kia.	1462

Best regards,
Davey

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 22 Jan 2019 11:23:02 +0100

Moin!

On 22 Jan 2019, at 9:50, Davey Song wrote:
> 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.
You see on that listing that the more you go to an actual real world 
scenario the lower the impact gets. As soon as you add an IPv4 server 
the problem is gone. Now IMHO we should work on getting these rates 
where fragments are dropped down and not implement yet another 
workaround.

>> Ralf Weber: Having one v6 name server that will respond correct with 
>> fragments also solves the problem. I think the problem space is to 
> 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.
Replying with large packets itself is not the problem. The problem is 
something in between mostly probably to either edge is dropping re 
assembling of fragmented packets. For some of the resolvers I run and my 
client network I just did a spot check and all v6 fragments get re 
assembled and I could used UDP with a large bufsize to get the DNSKEY 
for org. I event tried some of the more crazy ones with ~3k key set 
size. Again no problem. So it is possible to run IPv6 DNS server with 
large packet sizes over UDP.

So long
-Ralf
—--
Ralf Weber

Sample digs

; <<>> DiG 9.12.3-P1 <<>> DNSKEY +dnssec +bufsize=4096 org. +notcp 
@2001:500:48::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36371
;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;org.				IN	DNSKEY

;; ANSWER SECTION:
org.			900	IN	DNSKEY	256 3 7 
AwEAAcyu1vNojLO1vy6FYAqt3Jne4EGKO5io4MKuTuVYC6POTafpympF 
aRtFfaG3WNmU89psInAyLLy9cpZrf6Zv7H1jxkFHib899GEEIbd8XgW8 
oyHNgH5FrtB2LEGCaVXrPW8p2dASIgQ4EpDTZ8AxX0KWQYCyUtYYoMXD MOTKKKwZ
org.			900	IN	DNSKEY	256 3 7 
AwEAAc5srBkat5T3kAMjJUFqZsmkySlr1UF1sdxTTQ2F6R5zhmbJqYg7 
Y+SekXVi3Y7KgYD8sa14PGHMS0kHGcPTLlYwA7AzMY9U4BuabDYb90ys 
d+8n1PpDtf+BcYe4DuL1pCcOZPSeqko3yWUeu2fNzccBUtE0YazAypCf Sbztq+zT
org.			900	IN	DNSKEY	257 3 7 
AwEAAZTjbIO5kIpxWUtyXc8avsKyHIIZ+LjC2Dv8naO+Tz6X2fqzDC1b 
dq7HlZwtkaqTkMVVJ+8gE9FIreGJ4c8G1GdbjQgbP1OyYIG7OHTc4hv5 
T2NlyWr6k6QFz98Q4zwFIGTFVvwBhmrMDYsOTtXakK6QwHovA1+83BsU 
ACxlidpwB0hQacbD6x+I2RCDzYuTzj64Jv0/9XsX6AYV3ebcgn4hL1jI 
R2eJYyXlrAoWxdzxcW//5yeL5RVWuhRxejmnSVnCuxkfS4AQ485KH2tp 
dbWcCopLJZs6tw8q3jWcpTGzdh/v3xdYfNpQNcPImFlxAun3BtORPA2r 8ti6MNoJEHU=
org.			900	IN	DNSKEY	257 3 7 
AwEAAcMnWBKLuvG/LwnPVykcmpvnntwxfshHlHRhlY0F3oz8AMcuF8gw 
9McCw+BoC2YxWaiTpNPuxjSNhUlBtcJmcdkz3/r7PIn0oDf14ept1Y9p 
dPh8SbIBIWx50ZPfVRlj8oQXv2Y6yKiQik7bi3MT37zMRU2kw2oy3cgr 
sGAzGN4s/C6SFYon5N1Q2O4hGDbeOq538kATOy0GFELjuauV9guX/431 
msYu4Rgb5lLuQ3Mx5FSIxXpI/RaAn2mhM4nEZ/5IeRPKZVGydcuLBS8G 
ZlxW4qbb8MgRZ8bwMg0pqWRHmhirGmJIt3UuzvN1pSFBfX7ysI9PPhSn wXCNDXk0kk0=
org.			900	IN	RRSIG	DNSKEY 7 1 900 20190207152537 20190117142537 45404 
org. mme7P7ZpocftnBBra2q00nXAwKMQLg0UwY0eD9a9GMMbP0gw5K3D9/S4 
xluORkBZqSDBmd6FjuRKERT/TmLdET3A3R1hOTEtWLkuTlM92d3Ts4ds 
a31XVsyDGw1qiH1YMTaK2AbA0pOWHUj0GTzCnCdY3viDhquEsB2msDSA Ss8=
org.			900	IN	RRSIG	DNSKEY 7 1 900 20190207152537 20190117142537 9795 
org. NOfHL8wXeetoNN91jjOiET8lu4X/mxrRR4MeDA03oaQIRgNXGgB9Riz/ 
gcHm8hGivuxpaSGxbx4FTm5LO7hYFUuViC6oo06mdjhikmFeUfCqpdhs 
6TZfntaX0GpYGN4JpJBDIeMFlF0LFdDYqtt6r26Cc6zhebFVMUChgG2o 
6Ofvs/UeUppExO1UEeNULRAFqU7AEvxfsHyEhBbo5fKqBDBwz10UZ5bJ 
KSfXOgxI8wQyIR255AbQEwHxWGjTWnKico/Mrs0KnCp6EOCt5UahNKh9 
MxIWiAjjP6IljqHUOHN+XGWsf3Lq1AcGGAH+4GNK+3P6+wJwtVsHt69l rEOeNA==
org.			900	IN	RRSIG	DNSKEY 7 1 900 20190207152537 20190117142537 17883 
org. lYnkcCCWL7cJmtpifhwF7uhL3Aocj/L8Xp8jpqRcv4OBw1V5JcL0v9Lv 
wnWTc53fJzl+/yBTueC2/LMcQ4IbAXlK6+Aq9cePWopeawiTUjYK8LCE 
VK9xsfeYOUomKhTx27/ddIWhazmbfirWwGoC/uC44oirUrX59XCcyjB5 
lcqsilwmSLBjmgVaXY2Y7oWRC/UcDLXwd/uS5Nrnpux45ogtyz+vcBZy 
1UlmiwkDcrXyBxtrskmQwa7hj8nN+oq05qS8tffA+TZR4uss/biii6nS 
GcdILJkg/enXpEQpUKysyC89MekpisUtdwD3jVAhcdp4DHnR0/PxmxoZ CuDRKw==

;; Query time: 19 msec
;; SERVER: 2001:500:48::1#53(2001:500:48::1)
;; WHEN: Tue Jan 22 11:17:33 CET 2019
;; MSG SIZE  rcvd: 1625

; <<>> DiG 9.12.3-P1 <<>> bg. DNSKEY +dnssec +notcp 
@2a02:6a80::192:92:129:99
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33260
;; flags: qr aa rd; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bg.				IN	DNSKEY

;; ANSWER SECTION:
bg.			3600	IN	DNSKEY	256 3 8 
AwEAAbXpGD+h+TW6apP80SyHGOBV31FC/Lp42tdfC/iHJwOa+ZP7tmPz 
e2kyG1GMIum6jLPlbc0b1GCKE8sToxVKnRbCAQhWMPCCKrkdLTBy2bRa 
kH83v1ppYYceJ3krKgo0fTQyf2kQM5nl/K50wVD11oRzVnnCEBDLKFkk khxucPPj
bg.			3600	IN	DNSKEY	256 3 8 
AwEAAc6p7Y3Ifw/8yPRGKYczPSyE4cqY+UNdHmt4Cn8YwOiCCGg/0Y9v 
KsyTJAMes8O2tB+7vSpV/5taL5EuifQr10lS5B8S5BlDUthUTq+9CECl 
LwFsBYOoZo49VsoiREbIgaesq21yG02JTt4s/QpClOlHWxu3Y3RhNPWP qH2lB8Wv
bg.			3600	IN	DNSKEY	257 3 8 
AwEAAbxtdZBrxUDnwczEYSDmiI7lMDDxsNB+OWGxldJYiVB5D/zQRqPb 
Og2qKGTYMqJ6jI1Dx2q1EWGSG3axrY/Sne9ja24p1FoKh6BTGz/QvbTn 
Q+DGnhamgBb26QN5zs89siGS9uft/8E/+2uK/5NcMBJFCtY1YbdoWBPg 
2TM2OLVDuY4kjIJHj/EUi9NsAYHaYQO1SKHcRVT4hsJ+sDypA3KnLRIp 
yHooo6rygpb1RmegRAM5cF1l4RwUwK1MTP4VemK5btsUZrRa2pOuhO24 
xHKvly7j08vx7MuW0kBEQwJDHZzwa+Z8+GN6DwxWdeAzdP3WdbCBMf6k 
Jsur+9+U+9PcbmTELOsRszDzEQhsTClnTRpoafdNDrTCBjEwhdcEKwM1 
fRXR1ig8GdCSCPevz0i9WYklN/bLte7uifPI+5yV7O+1B7Af7EUnDj7F 
ammyzA6joD6iy0FbKIkILae6FeqglS0SqYl6AX0tomUXQS8zwMFqd3b6 
OOLpbD1rfvGhBNNO/sRs0l+mgCx9xAvdHgRaUq/eijGiT0kJ4oaX6jgP 
ChoVrLMMhk2kyQ21pdYI9JXjjldjVqXxQWp2BpNyntWCKo8p6Qhb4kPq 
hndO3nBVj2bAtPFEx5vCXMYowUiPJ4G/0OUl7S3DTGBOXEoCRK8g8nSE 
a0pTIz17DUn376Kj
bg.			3600	IN	DNSKEY	257 3 5 
AwEAAblV90SQjp4rI9ZLQs3pwcvkmlEt0OogfuI5cm4l+b3fHGA3YtVU 
Tz8j6SzpMQR/psx5KzFzqIJc8YRdLJSFhiBaLxDYPltcjFSie71Ln2U0 
+PPn5NHqUzCYTysLtRG0sl8FHmFGEY4OmkevpDZCX9sscDdt0MfiVwoN 
23Ni3nHuSrGewgr0RI4nBrcrBWII7oAfhyZ9XKWmlZpRM8aNHA6hijix 
ZsSzTNYAfr9r+s/lpiDG2ybiju1H6sKhL/jY02UdMTFiLFdRZ6yuOzxw 
FXWQE/d7cSe5dSCYMU5EmD2Qy0nbGG0YSD9e0iehw01Fr70HfIV9uNXM 
zqHrrTyajMtlft/z9aUug5qIVxFSczNSRCyJedcJU+9OZUMj90yXQLeG 
2soa6QOfAUyYZLs9OgOIKoE0c7hQRIicPM5bK0ycUM3NTcIYUzDV8zZZ 
Fo0xaM1QEIMdXz4kCfFS6V4lUleufTCDTI0CkTq9g14ia464HFXb4WKD 
6eHl0hvnXAviPAqrma0K1iX9efjxiDumyAIJlm/plBL39CMuX/ENyER8 
XXqv9aXAAcdlN2EYsbejGJ262SjvGIMzEVoUKd9UqrnSe44w/2+lzL6a 
WYqFz6njejH6rbzcof2MoEt1QC47G80gZzFk/tn1mMIKKMbQyvMy7+6K 
HaTKSHnJCXr27klR
bg.			3600	IN	DNSKEY	256 3 5 
AwEAAatvnBmra+7zeBm9l13suknlkqymM+dxrFdopER/atXEXpeKon1l 
B9rWXtPTizfXo3UIXugeIF7sL0oLNeaNHmBe4pgvEIZCpokDOQ45Eqk+ 
VgAdskXSlF0X8QhxE1c24wX4lhyIm3hvd5KgOGtKT8OcX3kzol+iBjC4 JGFXWDqD
bg.			3600	IN	DNSKEY	256 3 5 
AwEAAepb8tfII3+xijlGEESRLxW9hDpBHjtqaO0dKLowX6Iz17s1Yrby 
d0EZc8NjuF251KDvixkm54F7mKI8rA5PBo9JCsvXQh9rbekEV3EDhOU8 
Eg/hIrVVCtHR5qWLVe1JEfBvicyUUQSZapQWVPP7MYXb2aZzB+jRIVsr ngGHmzD9
bg.			3600	IN	RRSIG	DNSKEY 5 1 3600 20190221090009 20190122090009 40422 
bg. hwC0VCeV6KQGyefOO1RBeurhXZX182lhA+bVfK62RCMiIXkABSJbMM5v 
qfX3RpaCb/WYW9d4g6eVVaH+oZ2swDpXSY1DVc7fH7vQ7zNsW8yDh2Bt 
dN+5F6H+pFFYhxwsa1NjnlwhKVfK/ips0ogoh5OA0zjzbjztQYzagS4R 3ik=
bg.			3600	IN	RRSIG	DNSKEY 5 1 3600 20190221090009 20190122090009 46846 
bg. UfaFw11jtqaajb9VkVpS1VyAXxKCGec74D2qI0ulCa8EdeT5I0+A7JoI 
FhbigNmUGNER9iC91Var+CygqmYRfjIsi82jRTVYzuVVd1hWPM4VJiQX 
BWjZ5tneeNo9qOQlow1MSqgB7USYMta3XVe6Qyxp6XEna1cGxZjB8h/V 
NQWsiTnnLYdVfCTJEd8nStLqeo4fibsHB9NgOkK+bpD8LApLVUFun1sE 
+ykdTJrf/FZjPtEJn4qVo1EVrJa2NjKnFOMza4bYENYYI4w0LK3zCgQY 
TqbXYKJqbL0EIr8r7OkDG8wzI3Mx2iZ3sl1JaYRDpM/LYHqGbKaDnOkv 
scxh1i7GBu2oCUlL0l++klMQJxUG4jMeaQF5w9MYOJB2xDfPxw3Kq5sF 
YQKyMGIE5IaeT1hjTwqQk/DTXoqxC/ZLSLFVw+Bd9CzkcPEfERupzCn9 
mtAZOaAZwj0E7rM1NdcKHXplkvYTijpGmHKpPMdjUBU+d0DCzHvvyKRZ 
Zo+r59+rfQPcki2RRtphPKIxIgShlZeWJA6cfp2bf75rpybRWQKlT72h 
gWDd57s+ba4+Nj9/9vnDkhDuf6tucpaNlkaLAAudQGsf+zsWWufneWGR 
Y6vlEYSH8a3mUZ0ygk6Xp1Jh3JBclL4lyb0E284afAfF+mIQrXggoBIV 1/Kk0gkH88E=
bg.			3600	IN	RRSIG	DNSKEY 8 1 3600 20190221090009 20190122090009 15660 
bg. W8+IsXooVBp4ZL91L70Uz+nhWGl1UfK6cNj7BXWak7Esc+60Vx7xRqg9 
C06O+CKu7CDBdYD39tn/hScsmA850y76aI0CukEAjRqSEO7ptUl3D7Xf 
UvDoygRycFQNqZYrJuC8JwaUP/FX6DPpezSEIyjojHpRw3ld6TeKEZea Ftk=
bg.			3600	IN	RRSIG	DNSKEY 8 1 3600 20190221090009 20190122090009 58606 
bg. KnSPMb/6HNJsJXpfb0gftGV5e4FFSSGHaf2Zeb4b0g7+bFgmDqYNv0Em 
9oI1T38aem49Cg8VU97KdZdcf4hbB3ugprMjaa00A2k128uvMSRud/zI 
MPPL/8FUfMuC8BkaMoJTt2aSaq+D2uuWlhJOOCD2+uDh3czFBq4zCBGV 
R1uAtvVt5iP4xRXNAsyctJmGrK0Xks4LL0CdytUdoKWTtj6y+8j6KNvy 
Yn27+9Q08/lmQmWFgHtfKWCAFdFclXzNn0BjTNekP3WinIF0iHlWUeQl 
OTg0gErsguzzEU48JaWazhz7nrKN8U+OsPwH+KTuqx9VmElazssDfIp/ 
h3QoOHMfKX4/t8Na3UAWmNPbq6V4eQkBbGuYgX5bVaiAV3DvRQfvRGAU 
URBF2xWwrqG8Vfd9oghXyRt7qyRLQXlM4irdNb3kbv1mLuRQZxNd2bJs 
AZV6aNEizUwXftf8aWxYj62tnMMsgPu426kXpXA2YHaIn1NyE9kFOZCr 
VNfUv5MzIGDB4cXkyJld86pqo7HgpovWBGrXqptwbvU5vTqdsb14R4nG 
M6gOf648w4qKOBqeoLsCCTL+EoBa+n0d23cNtSfMk5WuzNdPDslNkPhz 
W9TAGOpvGZ+Vm4CyA2o++/G6VDT3/jBPlXlKu3OnI8mwQ5UFFXRmoQdW 9t5Msp47WYY=

;; Query time: 54 msec
;; SERVER: 2a02:6a80::192:92:129:99#53(2a02:6a80::192:92:129:99)
;; WHEN: Tue Jan 22 11:20:04 CET 2019
;; MSG SIZE  rcvd: 3103

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Jan 2019 15:19:44 +0000

Paul Vixie <[email-masked]> wrote:

> likewise. we should not avoid fragmentation in this particular way. that is,
> we can use persistent TCP, or we can avoid sending large messages by shaping
> their contents better (smaller signatures, less additional data).

Like this?

https://mailarchive.ietf.org/arch/msg/dnsop/xnJjuOFRE4IiT7uqEFyqhYKKT7c

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet, Irish Sea: Northwest 5 to 7. Slight or moderate in Irish Sea,
otherwise moderate or rough, occasionally very rough, but high at first in
west Fastnet. Rain or showers. Good, occasionally moderate.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 24 Jan 2019 11:43:39 -0800

At Fri, 18 Jan 2019 18:55:16 +0100,
Benno Overeinder <[email-masked]> wrote:

> 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.
> 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.

I've read draft-song-atr-large-resp-02.  I support the adoption of
this doc, or at least of *some work* related to the "large response
drop" problem, by DNSOP.  If adopted I'm willing to review subsequent
versions.

I don't have empirical measurement results of my own on this topic,
but my general understanding of the discussion in the IETF is that the
concern (i.e., the bad effects of dropping fragmented large packets)
is seriously taken.  One of the latest efforts in this sense is
draft-ietf-intarea-frag-fragile, which is currently in an intarea WGLC
and talks about DNS implications (btw, those who dismiss
atr-large-resp because the concern is FUD may want to comment on
intarea-frag-fragile too).  The research result cited in
draft-song-atr-large-resp
(https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns)
may still be anecdotal and artificial, but it also looks solid and
sufficiently broad to draw attention.  So I don't agree on dismissing
the work "because the problem doesn't exist".

I also don't agree on dismissing the work "because it's specific to
IPv6" (I don't know if it really is, but even if so), given the
commitment by the IETF to IPv6 deployment and related problems.

I see it's still debatable whether the particular proposal of "ATR" is
a good solution to the problem, however.  I admit that's a hack with
some obvious adverse effects such as increasing response traffic, so
if there's a better, cleaner solution, I'm happy to support that one
instead of ATR.  One aspect I like about ATR, however, is that it can
be deployed without changing resolvers.  In that sense I see it as
more promising compared to some other proposed DNS hacks, e.g., (the
ultimate form of) ANAME.

--
JINMEI, Tatuya

---

From: Brian Dickson <[email-masked]>
Date: Thu, 24 Jan 2019 12:27:49 -0800

(Top-reply, apologies for those offended by this practice.)

I also oppose adoption (at least of the draft in its current form).

Very quick questions:
(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.
(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.)

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).

Please experiment a bit and let us know the results.

Brian

On Tue, Jan 22, 2019 at 12:50 AM Davey Song(宋林健) <[email-masked]> wrote:

> 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.
>
> > 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.
>
> 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.
>
> 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 AAAA
> 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, <
> http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf
> >.
> [3] APNIC measurement study,
> https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/
> [5] IP Fragmentation Considered Fragile,
> https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-04

---

From: Davey Song(宋林健) <[email-masked]>
Date: Sat, 26 Jan 2019 11:10:46 +0800

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

---

From: Brian Dickson <[email-masked]>
Date: Sun, 27 Jan 2019 23:08:41 -0800

On Fri, Jan 25, 2019 at 7:10 PM Davey Song(宋林健) <[email-masked]> wrote:

> >(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.

Right, that's what I'm getting at.

If the EDNS0 bufsize is configured (on the resolver specifically, to be
clear) as MTU*, then no fragmentation on UDP packets will occur.

(*MTU minus fixed IP and UDP headers.)

This is what I suggest you test against the scenarios. Set the EDNS0
bufsize to various values, and observe the results (including whether or
not TC gets set).

If it is possible to fix the fragmentation problem simply by changing
EDNS0, that would be much better to write up as an ID rather than this ATR
thing.

My strong suspicion is (modulo the individual operator's localized,
observed "internet MTU") setting the EDNS0 bufsize will prevent
fragmentation without degrading/breaking DNS resolution.
(E.g. if only some of the Additional section fits, it may be necessary for
the resolver to request individual records, and/or do DNSSEC validation for
missing RRSIGs).

> 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.
>

Yes, technically that is correct. However, the authority servers will have
a configured maximum DNS message size.

The actual maximum DNS message size for a given resolver<->authority pair
will be MIN(EDNS0 bufsize, authority configuration).

The actual maximum UDP packet size will be that value, plus some fixed
stuff (IP and UDP headers).

The actual maximum layer 2 frame size will be the UDP packet size plus
whatever layer 2 stuff gets added.

You can generally work backwards from the functional limits (at which no
fragmentation happens) to determine the maximum EDNS0 bufsize to configure,
assuming a given destination.

A particular operator would probably need to be cognizant of the set of
such values across observed authority server paths, and pick the lowest
common denominator (i.e. that will fit in the vast majority of paths with
no fragmentation).

>
> >(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.
>

No, they won't. There are some authorities that have configured their own
max DNS message size low enough to not fragment, but that is not
necessarily in response to observed fragmentation.
And in particular, this is the operator doing this, not the DNS software.
It conflates the issue to say "server". It is better to say either
"operator" or "software", as it will only be one or the other, and knowing
which is which, along with how and why, is important in figuring out what
the problem is and what solutions are feasible.

And yes, I am aware that it requires resolvers make the change. My point is
they can, and if that fixes the problem for them, that should be the
recommendation (which might be something the software folks look at, either
adaptively or by changing their default value for EDNS0 bufsize.)

>    truncating the response when the response size is large than a

No, you are mischaracterizing what is happening.

It is ALWAYS the case (and required by the RFCs), that the answering server
send a DNS message no larger than the EDNS0 bufsize requested. It may be
the case that the authority server has a lower value than the supplied
EDNS0 bufsize, but that is not the same as "ignoring" the bufsize. It is
doing "MIN(server_config, EDNS0 bufsize)" to determine max DNS message
size. If the actual DNS message is smaller than that, it is irrelevant, of
course. If the DNS message would be larger, the smaller of the two values
is used, always, and it isn't "some" servers "ignoring" the supplied value,
at all.

If the EDNS0 bufsize is smaller than the configured server limit, the EDNS0
bufsize will be used, and specifically NOT ignored.

The only time an EDNS0 bufsize is ignored, is when it is below the minimum
allowed value (512), again, per RFCs.

>
> 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:
>
> 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
> 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.
>

Resolvers do not require any software updates, to make changes to their
EDNS0 bufsize. All resolver software that does EDNS0 supports configurable
(user-supplied) bufsize values, at least as far as I'm aware.

Communicating experimental results with recommendations for changes to
operational parameters is something that various folks can help with.
Getting those experimental results is the first step, IMHO.
Not doing those experiments first, and continuing to push ATR, without any
evidence showing that this specific suggestion (lower the EDSN0 bufsize)
WON'T work, would be premature (and/or irresponsible). If there is an easy
solution that will work, that is something that should be agreeable as
being the path that should be at least investigated.
(All the folks involved in the KSK roll are eager to learn any observed
issues, and to communicate recommendations to the larger DNS community,
including resolver operators.)

Would you be willing to redo your tests with EDNS0 bufsize set to some
smaller values, like 1500, 1472, 1452?

Brian

>
> 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
>
>
>
>

---

From: Tony Finch <[email-masked]>
Date: Mon, 28 Jan 2019 11:32:03 +0000

Davey Song(宋林健) <[email-masked]> wrote:
> >happens when you do that?
>

Or for authoritative servers to set their maximum UDP response size
small enough.

Fragmentation in the DNS can be reduced by either the initiator or the
responder without co-operation from the other end. There's a good chance
we can reduce the problem substantially just by changing the defaults and
waiting for people to upgrade, even if there are lots of unmaintained
servers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
defend the right to speak, write, worship, associate, and vote freely