<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body text="#000000" bgcolor="#FFFFFF">summary: no worries, this
isn't what i thought it was. details below.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAHw9_i+NP5=qt_3Ev3s6xonp1-nOuU24O48k4W_F=PR7pyGcgg@mail.gmail.com"
type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="warren@kumari.net" photoname="Warren Kumari"
src="cid:part1.07030602.05090000@redbarn.org" name="postbox-contact.jpg"
width="25px" height="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:warren@kumari.net"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Warren Kumari</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Thursday,
November 27, 2014 2:20 PM</span></font></div></div></div>
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><br>This
allows a slave (or anyone else who wants to validate a zone, e.g a
master loading from disk) to know that they have a full and correct
zone. This covers things like accidental zone truncation (which has
bitten some folk),</div>
</blockquote>
<br>
if your master server sends you a final (matching) SOA not having
stuffed its end of the tcp session with all the right records in
between, or if your TCP is allowing end-to-end badness without its CRC32
detecting same at the tcp segment level, then you have bigger worries.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAHw9_i+NP5=qt_3Ev3s6xonp1-nOuU24O48k4W_F=PR7pyGcgg@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"> zone file
corruption, etc. if someone hands me a zone somehow (e.g AXFR) and asks
me to serve it I'd like a way to make sure it hasn't been accidentally
(or intentionally) changed.</div>
</blockquote>
<br>
for a dnssec signed zone the only way to do that is to zone-walk and
validate. belt-and-suspenders isn't a good model for axfr/ixfr, because
complexity, and because the zone signature would have to be
incrementally maleable and so not one-way or crypto-authentic, because
update.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAHw9_i+NP5=qt_3Ev3s6xonp1-nOuU24O48k4W_F=PR7pyGcgg@mail.gmail.com"
type="cite">
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"> I'm assuming I'd want my name
server software to refuse to load the zone and try retransfer, throw an
error, or similar.
<div>The signature could be (and the way I'd envisioned it) DNSSEC,
so up to a TA, or a manually configured key specific to the zone.<br></div>
</div>
</blockquote>
<br>
if this is proposed and adopted, my discussion input will be along the
lines of "no authority server can every be required to query for
anything as part of its operations". just letting you know where "DNSSEC
... signature" leads to.<br>
<br>
importantly, you're envisioning this as a new way to fail, but not a new
criteria for success. that is, this new signature mechanism is to you a
reason to reject an AXFR or IXFR, which would then lead to zone timeout
and SERVFAIL unless corrected. that's not a problem. i was worried that
this would be used in some way to permit/deny zone data to be used by a
mixed-mode server in response to RD=1 queries. that would be a larger
kettle of different fish.<br>
<br>
furthermore:<br>
<br>
> Mark Andrews<br>
> Thursday, November 27, 2014 2:45 PM<br>
><br>
> Just having a cryptographically strong zone self consistancy check<br>
> is a big win with IXFR. If that fails you AXFR the zone and try<br>
> again.<br>
<br>
if you're trying to make a case for public key TSIG, i'd agree with you,
and say, SIG(0) [RFC 2931]. i'd support an rfc 2931-bis effort, as a
reviewer and as a contributor.<br>
<br>
> For the root zone you don't need a iterative validator as you would<br>
> have the root as a trust anchor and in general a authoritative<br>
> server needs a interative resolver for NOTIFY.<br>
<br>
if you're arguing that NOTIFY should support DNSSEC by including
RRSIG(SOA), i'd agree. but right now there is no TA on root zone slaves,
they never query for anything, they never validate anything, they don't
speak RFC 5011. and that's a deliberate design decision, not an
accident or oversight.<br>
<br>
> As to whether you iterate or not also depends on the trust anchors<br>
> installed, whether the keys are RFC 5011 managed or similar. Having<br>
> a managed trust anchor for every zone isn't a be deal.<br>
<br>
adding RFC 5011 support to a non-mixed-mode (authority only) server
would be a very big deal. so, that's an area of strong disagreement if
we discuss it further.<br>
<br>
vixie<br>
</body></html>