Subject: Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case

From: Dan York <[email-masked]>
Date: Wed, 25 Mar 2015 11:51:17 +0000

Matthijs,

On Jan 15, 2015, at 5:13 AM, Matthijs Mekking <[email-masked]<mailto:[email-masked]>> wrote:

IXFR with DNSSEC is suddenly not so small anymore. Do you recognize
this? Olafur and I have some ideas on keeping those zone transfers
small. Your feedback is appreciated.

 http://www.ietf.org/internet-drafts/draft-mekking-mixfr-01.txt

I support this draft.  Steps that can improve the efficiency of DNS are good in my mind (where reduced packet size is to me being efficient).

In the Security Considerations section you are asking what you should include in there.  I think what you say about using MIXFR over a secure channel and with TSIG is a good recommendation.

The question would really be to me - can an attacker do anything different with MIXFR than with IXFR?  Could an attacker, for instance, use MIXFR to delete RRSIGs so that portions of a zone were then unsigned?   Could multiple MIXFR records be sent at the same time to create confusion?  Could a MIXFR be used for a DoS attack?

And is any of that different from IXFR?  (Or should you then just reference the Security Considerations for IXFR?)

I don’t know the answers… but those are the kinds of things I think would be good to discuss in the Security Considerations area.

Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 25 Mar 2015 22:31:17 +0900

Matthijs Mekking wrote:

> this?

That is a problem of DNSSEC and, worse, even with the proposal,
neither AXFR nor IXFR won't be so small.

So, if the point of the proposal is to make IXFR with DNSSEC
small, the proposal is wrong.

Even if it is not and something should change, it should be done
only after DNSSEC specification stabilizes (e.g. no new NSEC*
proposals any more for considerable amount of time and most
of NSEC* is obsoleted).

> Olafur and I have some ideas on keeping those zone transfers
> small.

Wrong. With DNSSEC, you can't keep them small.

The conventional wisdom widely deployed by many operators is
not to use DNSSEC, which is not very secure.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 25 Mar 2015 22:53:59 +0900

Paul Vixie wrote:

> my proposal at the time IXFR was being worked on back in DNSEXT was to use the
> UPDATE encoding, which allows RRset deletion or replacement without transmitting
> the old RRset. i still think that's a good plan, and if...

As conditions to update a zone supported by UPDATE is limited, my
proposal at that time is:

	1) a client gets the current serial number from the primary
	of the zone.

	2) the client check the current zone content satisfies
	certain conditions for update, including those which
	are not supported by UPDATE (e.g. some RR does not exist)

	the conditions can be arbitrary complex.

	3) the client gets the serial number again, to confirm
	that other clients haven't changed the zone content

	4) the client send IXFR style update and if it fails,
	it should be because of race condition with other clients

	so, try again

which is still a good thing to do.

Then, IXFR syntax may be extended with wildcard styles of UPDATE,
if bandwidth consumed by DNS administration is a so severe problem.

						Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Mar 2015 15:09:36 +0000

This is to document what I said to Matthijs in the hallway after the
presentation.

As a source of data on the problem - look at IXFR traffic supporting a
zone to see what's being deleted that doesn't need to be explicitly stated.

It's obvious that changing any set invalidates the RRSIGs on it.

(Not from the conversation) When refreshing RRSIGs, the incumbent ones
might deserve deleting.  Back in the day we imagined that an RRSET might
include signature good on Monday and a different one on Tuesday, etc., so
the protocol does not limit the set of signatures for owner, type, class,
dnssec-algorithm, footprint to 1.  OTOH, what we imagined in this regard
is not a realistic use, today sets usually sport just one RRSIG at a time.
 Given this - when an RRSIG is added, questionably matching (for some
definition of matching) RRSIGs should be deleted.

It's not to obvious whether the addition of an NSEC3PARAM record implies
the desire to delete NSEC3 records with different salt (or other
parameters).  Adding NSEC3's might mean a new chain is being installed (as
in a salt change), but until the NSEC3PARAM, it isn't the active or
necessarily a complete chain.

Ultimately, if MIXFR can identify all records that should suffer an
implied delete, then this is an improvement over IXFR in terms of saving
message size.  Operators don't often look at IXFR traffic, so I discount
the idea that implicit actions is a problem here - so long as the change
logs show what is deleted due to an implicit MIXFR assumption.

I think examining live IXFR flows found in real operations would be very
helpful in tuning the implicit delete heuristics that can be employed.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 26 Mar 2015 00:26:58 +0900

> helpful in tuning the implicit delete heuristics that can be employed.

If only the primary purpose of IXFR were to reduce traffic.

But, the purpose is to reduce CPU load of nameservers serving huge
zones.

Thus, IXFR over UDP is a good thing to do.

However, implicit deletions may increase CPU load if there is
nothing to delete, though reduction of TCP traffic may reduce
CPU load more.

Depending on database structure, wildcard deletions may also
increase CPU load.

					Masataka Ohta