Subject: [dnsext] DDNS - multi-packet? + SERIAL autoincrement

From: Lubos Slovak <[email-masked]>
Date: Wed, 17 Oct 2012 09:55:00 +0200

Hello,

we're currently implementing Dynamic Updates into Knot DNS and I still 
wonder about two things:

1) Is it possible that the update is divided into multiple DNS packets, 
similarly as AXFR/IXFR? If so, what is the format? Should there be all 
Prerequisities first (in one or more packets) and all Update RRs 
afterwards (in another one or more packets), or each DNS packet may 
contain both the Prerequisities section and the Update section and the 
server should wait for the last packet before it starts to process it in 
any way? I found no clue about this in the RFC.

2) Section 3.2 of RFC 2136 gives quite a lot of options when to 
autoincrement SERIAL if it was not updated by the operation. However, it 
seems to me, that implementing anything other than option (1) 
(incrementing after each update operation) is too much hassle with 
little effect. Does someone know how it is implemented in other servers?

Thanks a lot,
Lubos

-- 
  Ľuboš Slovák                       Knot DNS
  CZ.NIC Labs          http://www.knot-dns.cz
  -------------------------------------------
  Americká 23, 120 00 Praha 2, Czech Republic

  Email: [email-masked]
  WWW: http://labs.nic.cz   http://www.nic.cz
  -------------------------------------------

  Please consider the environment before printing this email.
  Join the campaign at http://thinkBeforePrinting.org

---

From: Miek Gieben <[email-masked]>
Date: Wed, 17 Oct 2012 10:26:55 +0200

[ Quoting <[email-masked]> in "[dnsext] DDNS - multi-packet? + SER..." ]
> Hello,
> 
> we're currently implementing Dynamic Updates into Knot DNS and I
> still wonder about two things:
> 
> 1) Is it possible that the update is divided into multiple DNS
> packets, similarly as AXFR/IXFR? If so, what is the format? Should

What text in 2136 makes you want to ask this question?

 Regards,

-- 
    Miek Gieben                                                   http://miek.nl

---

From: Lubos Slovak <[email-masked]>
Date: Wed, 17 Oct 2012 10:31:11 +0200

None at all, but there is also none that would forbid such behaviour. 
And the old RFCs are often very unclear on what can or cannot be done.

On 10/17/2012 10:26 AM, Miek Gieben wrote:
> [ Quoting<[email-masked]>  in "[dnsext] DDNS - multi-packet? + SER..." ]
>> Hello,
>>
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

-- 
  L(ubos( Slovák                       Knot DNS

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 17 Oct 2012 11:20:03 -0400

Dude,
             The RFC says "An update transaction may be carried in a UDP 
datagram, if the request fits, or in a TCP connection (at the discretion 
of the requestor). When TCP is used, the message is in the format 
described in [RFC1035 4.2.2].". "A" is singular. So there is no such 
thing as a Dynamic Update in multiple UDP packets. As for TCP, if you 
follow the reference to RFC 1035, you see that a stream of data is 
presented to the server. Once you're dealing with a connection-oriented 
transport, packet boundaries don't matter any more. Or, to put it 
another way, the algorithm reads as much of the input stream as it needs 
to process. If there isn't enough data yet, it waits for more. How this 
is handled at the packet level is not the concern of the Dynamic Update 
processing algorithm. If the algorithm tries to read data from the 
stream, and the end of the stream is reached, then the algorithm detects 
that and processes what it has. If there's an error, it detects that 
too. Reading from a stream socket is not that much different from 
reading from a file. On Unix platforms, at least, the whole "socket" 
concept was and is part of the abstraction of "files".

One of the downsides of incrementing serial for every operation, is that 
if you do thousands of operations a second, you could end up wrapping 
within an EXPIRE interval, which might cause problems for traditional 
master/slave replication (sometimes slaves can't talk to their master 
for an extended periods of time, so EXPIRE is the worst-case scenario 
for serial wrap, not REFRESH).

                                             - Kevin

On 10/17/2012 3:55 AM, Lubos Slovak wrote:
> there be all Prerequisities first (in one or more packets) and all 
> Update RRs afterwards (in another one or more packets), or each DNS 
> packet may contain both the Prerequisities section and the Update 
> section and the server should wait for the last packet before it 
> starts to process it in any way? I found no clue about this in the RFC.
>
> autoincrement SERIAL if it was not updated by the operation. However, 
> it seems to me, that implementing anything other than option (1)

---

From: Lubos Slovak <[email-masked]>
Date: Wed, 17 Oct 2012 17:36:26 +0200

On 17-Oct-12 17:20, Kevin Darcy wrote:
> Dude,
> The RFC says "An update transaction may be carried in a UDP datagram, 
> if the request fits, or in a TCP connection (at the discretion of the 
> requestor). When TCP is used, the message is in the format described 
> in [RFC1035 4.2.2].". "A" is singular. So there is no such thing as a 
> Dynamic Update in multiple UDP packets. 
I thought so, just want to be sure. I did not consider the indefinite 
article a proper indicator.
> As for TCP, if you follow the reference to RFC 1035, you see that a 
> stream of data is presented to the server. Once you're dealing with a 
> connection-oriented transport, packet boundaries don't matter any more.
They do, indeed - the two-byte length field limits the DNS packet to 
64k. That's why large A-/IXFR comes in more DNS packets (though in one 
data stream). The transport protocol does not bother me at all, it's the 
DNS packets that do.
> Or, to put it another way, the algorithm reads as much of the input 
> stream as it needs to process. If there isn't enough data yet, it 
> waits for more. How this is handled at the packet level is not the 
> concern of the Dynamic Update processing algorithm. If the algorithm 
> tries to read data from the stream, and the end of the stream is 
> reached, then the algorithm detects that and processes what it has. If 
> there's an error, it detects that too. Reading from a stream socket is 
> not that much different from reading from a file. On Unix platforms, 
> at least, the whole "socket" concept was and is part of the 
> abstraction of "files".
>
> One of the downsides of incrementing serial for every operation, is 
> that if you do thousands of operations a second, you could end up 
> wrapping within an EXPIRE interval, which might cause problems for 
> traditional master/slave replication (sometimes slaves can't talk to 
> their master for an extended periods of time, so EXPIRE is the 
> worst-case scenario for serial wrap, not REFRESH).
OK, will consider that.

---

From: Tony Finch <[email-masked]>
Date: Wed, 17 Oct 2012 16:46:46 +0100

> data stream). The transport protocol does not bother me at all, it's the

It is best to call them "DNS messages" which makes it more clear that you
are not talking about TCP segments or UDP datagrams or IP fragments.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Lubos Slovak <[email-masked]>
Date: Wed, 17 Oct 2012 17:56:38 +0200

Right, sorry for that! So the question stands:

Is it possible for an UPDATE operation to be larger than 64k and thus 
divided into more DNS messages, when sent over TCP? If so, what's the 
format (see my first post)?

Lubos

On 17-Oct-12 17:46, Tony Finch wrote:
> Lubos Slovak<[email-masked]>  wrote:
>
>

---

From: Tony Finch <[email-masked]>
Date: Wed, 17 Oct 2012 17:19:50 +0100

Lubos Slovak <[email-masked]> wrote:
>
> Is it possible for an UPDATE operation to be larger than 64k and thus divided
> into more DNS messages, when sent over TCP?

No :-)

(The obvious consequence is that you have to do some kind of higher-level
hack to split very large updates into separate operations, and multiple
updates are not atomic in the way that individual ones are.)

Tony.

---

From: Lubos Slovak <[email-masked]>
Date: Wed, 17 Oct 2012 22:45:03 +0200

Very well, thanks for all responses!

Lubos