Re: Fwd: New Version Notification for draft-reid-dnsext-aleatoric-00
Stephane Bortzmeyer
Jim Reid <j...@rfc1035.com> wrote
a message of 38 lines which said:
> This idea is probably even uglier than the 0x20 draft. :-)
I like it although I'm not sure it is better than cookies: after all,
a name server software has to be changed in one way or the other. If
we are going to add AL support, why not directly adding cookies? AL
seems interesting only if EDNS support is unrealistic (too complicated
for the name server software or blocked by a stupid firewall). Is it a
sufficient motivation?
Also, you do not address downgrade attacks, apparently? How to know if
a response without AL comes from an old server, not upgraded, or from
an attacker?
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Stephane Bortzmeyer
Paul Vixie <vi...@isc.org> wrote
a message of 8 lines which said:
> 0x20 is a one-side upgrade (RDNS only).
Only if the aDNS preserves case which is currently NOT mandatory.
Florian Weimer
> since the draft allows for this situation and explains what to do about i=
t,
> and since i've implemented it and have run it successfully for six months,
Your setup is probably not representative (is it mail only?) because
it failed to detect initial breakage which other parties have observed
subsequently.
> and since unbound has implemented it and noone has reported trouble there,
<https://lists.dns-oarc.net/pipermail/dns-operations/2008-August/003183.htm=
l>
> i think it's safe to categorize this as "RDNS only".
I suppose that, as far as DNS changes go, 0x20 is relatively
risk-free. But it's still a protocol change that affects responders
as well.
(I would prefer if the authors answered my previous question about
potential BCP 79 disclosures, though.)
--=20
Florian Weimer <fwe...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra=DFe 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
Florian Weimer
>> > since the draft allows for this situation and explains what to do abou=
t it,
>> > and since i've implemented it and have run it successfully for six mon=
ths,
>>=20
>> Your setup is probably not representative (is it mail only?) because
>> it failed to detect initial breakage which other parties have observed
>> subsequently.
>
> it failed because i had a bug in my syslog() library call arguments and i
> literally didn't know that it wasn't universally working. i quickly fixed
> that and found l.google.com and other nameservers,
Ah, okay. Thanks.
>> I suppose that, as far as DNS changes go, 0x20 is relatively risk-free.
>> But it's still a protocol change that affects responders as well.
>
> if it works today and will work whether or not any given ADNS is changed,
I don't think your detection logic handles the
NXDOMAIN-for-upper-case-but-echo-with-correct-echo case, but this one
is violating the RFC and is terminally broken anyway (potential DoS
through client query) and it should not be held against 0x20.
If we can't label 0x20 as a protocol change for procedural reasons,
I'm fine with that.
> i hope this clarifies the BCP 79 status of dns-0x20.
Yes, thank you very much.