Subject: Re: draft-danisch-dns-rr-smtp-02.txt

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Jun 2003 16:05:08 +0000

> > > It is quite possible to solve the problem of long term abuse in a ...
> >
> > This is nothing other than a blacklist scheme.
> 
> ... The draft appears to be attempting to set out a whitelisting scheme ...

please limit namedroppers@ discussion of this draft to the dns aspects, like
whether special processing ought to be a requirement, or whether compression
should be used.  the application layer aspects of RMX (and RMX vs MAILFROM)
will be discussed elsewhere, and i don't think the namedroppers@ audience
needs to see that debate, whereas others elsewhere who don't read namedroppers@
*do* need to see that debate.  ergo, please don't have it here.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 23 Jun 2003 17:40:16 +0000

[robert campbell]
> What do clients see from tinydns?  Eg, for a record of 'dying.example.com'
> which should expire at T+1500, would it be:
> 
>   Client A requesting 'dying.example.com' at time T receives:
> 	dying.example.com 1500  IN A 192.168.1.2
> 
>   Client B requesting 'dying.example.com' at time T+100 receives:
> 	dying.example.com 1400	IN A 192.168.1.2
> 
> ?
> 
> So, Client A and Client B have _nearly_ the same RR set, just with
> different TTLs.

no.  ttl does not affect rrset identity.  per [rfc2136 1.1.1] et al.

> The end effect is that both Client A and Client B will drop the record
> from their cache at the appropriate time.  This is good, right?

yes.

> So, the next question is, since Client A and Client B received different
> (authoritative) responses, does that mean that there were different
> versions of the zone 'example.com' at time T and T+100 ?

no.  see above.

> If yes, there were different versions of the zone at T and T+100, then
> the SOA serial needs to be updated, with the consequent flurry of AXFR
> requests from the 'example.com' slaves when they noticed the SOA
> having changed.

no.  any authoritative server could clamp its ttl's for local policy reasons
without affecting zone identity.  they can't be made longer but they could
absolutely be made shorter without invalidating the zone soa:content mapping.

> Section 3.4.2 of Vixies 1996 draft (related to implementation of
> time-to-die) has the wording:
> 
>    3.4.2 - TTL Half Life
> 
>    Each time an RR's expiry reaches half of its previous value, that RR's
>    TTL will be reduced to half of its previous value, until the TTL reaches
>    a value less than or equal to sixty (60), i.e., one minute of real time,
> 
>    <snip>
> 
>    Whenever the TTL is automatically reduced by this process, the zone will
>    be considered ``changed'' for the purpose of automatic SOA SERIAL
>    increment (see [UPDATE 3.6]) and real time zone slave notification (see
>    [NOTIFY]).
> 
> You could probably do wording such that the only time an SOA serial change
> occurs (due to TTL/TTD behaviour) is when an SOA request comes in (so the
> version of the zone on your non-time-to-die-internal-magic slave is
> correct), but you've still got the problem of differing clients getting
> differing versions of RRs ...

they aren't differing versions of rr's.  ttl is not considered in rr
comparisons.

> ... in the zone without SOA serial change, which is not a good precedent.

see also [rfc2136 3.6].

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Jun 2003 16:13:10 +0000

> Still, when new records are created, you have to propagate the
> information outwards.  Rsync, AXFR and IXFR are all unsuitable for
> this in a frequently changing environment due to their associated
> overhead. ...

"sez you."  before it was called dnsext, this wg was called dnsind.  that
stood for Incrementalzonetransfer, Notificationofchanges, and Dynamicupdate;
these were the three features that the powers that were decided were needed
in order to support DHCP and IPv6, which were the New things in ~1994.

the architectural paradigm was to use Update to get things into the master,
Notify to make the slaves aware of these new changes without waiting for an
SOA timer to expire, and IXFR to get these changes distributed to the slaves
without having to transfer all the unchanged data as well.

interestingly, ohta-san preferred a different, masterless model, but he still
did IXFR when consensus went in favour of the i-n-d model.  also interesting
was microsoft, who went for a masterless model using non-DNS channels for
synchronization (but they never did implement healing after a partition event.)

now as to performance.  a company who was bundling BIND8 into a dhcp/dns
integration product stress tested the i-n-d model, and found all kinds of
early (pre-Y2K) data corruption bugs in our IXFR implementation.  their goal
was to be able to shoot thousands of DHCP-originated PTR updates per second
through BIND8 and have the slaves remain synchronized -- and it all works
fine.  therefore i dispute ("sez you") your assertion of "unsuitable".

various other commercial entities, mostly non-BIND based, have also reached
these transaction volumes, using the i-n-d model.  you may not think it's
pretty, but noone has yet found a real world workload that the model can't
address if you use the right hardware and software to support the load.