[dns-operations] Recommended zone serial number format for over 100 changes / day

[Matthew Ghali]

I think we're agreeing here- my point was that evaluating records during a transfer seems like extra complexity that's bound to add fragility. Accept the axfr/ixfr then inspect after it succeeds. I would be surprised to see an transfer fail based on such a content policy for a legally-formatted rrtype/rdata tuple. Is there even an rcode appropriate for that failure mode?

Matt

> On Apr 2, 2016, at 6:32 AM, Mark Andrews <marka at isc.org> wrote:
> 
> In message <BF8042CC-96E5-4F51-90B8-2AA94CAEAE17 at snark.net>, Matthew Ghali writes:
>> 
>> Why would you want a nameserver to try parsing/evaluating zone records as
>> its transferring? That seems remarkably more fragile than simply
>> performing the transfer, then parsing the data as the zone is
>> subsequently loaded. What happens to your partially-loaded data if the
>> transfer eventually fails?
> 
> You don't commit the delta / new zone.  If you are serving a
> partial (partially updated - you can commit at the end of a delta
> in a ixfr stream) zone you are not RFC compliant.
> 
>>> On Apr 1, 2016, at 3:56 PM, Colm MacCárthaigh <colm at stdlib.net> wrote:
>>> 
>>> It's a really bad idea to accept unknown RRTYPEs. RRTYPEs have been
>> defined in backwards incompatible ways in the past - such as DNAME having
>> a side-effect of occluding below the DNAME cut.
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6100 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160402/19eeb2d1/attachment.bin>