Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Mark Andrews]

> On 20 Feb 2019, at 4:35 pm, Paul Wouters  wrote:
> 
> On Wed, 20 Feb 2019, Mark Andrews wrote:
> 
>> Think disaster recovery and promoting a slave to master.  You have to
>> transfer state between servers.  You can transfer it in band or out of
>> band.  If you transfer it out of band you need to invent / specify
>> yet-another-protocol to do it on top of specifying when records need to
>> be removed.
> 
> That is not very convincing to me. disaster recovery scenarios seem to
> be solvable by proper admin and by the daemon properly writing state to
> disk which can be saved off-site. It also seems a rather rare occurrence.

So you write it to disk then transfer it off site which breaks atomicity
of the zone’s meta state or do it in band with TIMEOUT.

> If the primary does DNSSEC, you also have to transfer private keys and
> that isn't happening in-band either. So I'm not convinced by the
> promotion of secondary to master either.

You can pass the keys before you start to use them.  They are essentially
static information.

> It also seems these two use cases are mostly solved if you keep your
> dynamic update clients within their own zone, which I think is pretty
> normal for DHCP based nodes that can make up their own hostname anyway
> and shouldn't be able to muck with real static records or apex records.

Policy about who can update what is unrelated to making sure content gets
cleaned up.  There isn’t always a DHCP server to do the garbage collection.
This is especially true with IPv6 and SLAAC.

> Paul
> 
>>> On 20 Feb 2019, at 9:26 am, Paul Wouters  wrote:
>>> 
>>> 
>>> I have read the document.
>>> 
>>> I have a question about:
>>> 
>>>  A zone administrator may
>>>  want to enforce a default lifetime for dynamic updates (such as the
>>>  DHCP lease lifetime) or the DNS Update may contain a lifetime using
>>>  an EDNS(0) Update Lease option [I-D.sekar-dns-ul].
>>> 
>>> This seems a local policy and local implementation issue only.
>>> 
>>> However, this
>>> lease lifetime is not communicated to secondary servers and will not
>>> endure through server software restarts.
>>> 
>>> Why does the secondary server need to know the lease lifetime? Only the
>>> primary needs to know this because it will need to purge the records and
>>> update the appropriate DNSSEC entries, something the secondary cannot do
>>> anyway? In fact, Section 8 agrees with me:
>>> 
>>>  A secondary server MUST NOT expire the records in a zone it maintains
>>>  covered by the TIMEOUT resource record and it MUST NOT expire the
>>>  TIMEOUT resource record itself when the last record it covers has
>>>  expired.  The secondary server MUST always wait for the records to be
>>>  removed or updated by the primary server.
>>> 
>>> So why is the TIMEOUT record needed? If the secondary argument is
>>> gone, the only argument left from the Introduction is server software
>>> restart. Which seems to me to be an application issue and not a protocol
>>> issue?
>>> 
>>> As others pointed out, introducing SHA3 into the DNS right now is not
>>> appropriate.
>>> 
>>> I see a use for clients telling the dns update server what the maximum
>>> possibly lifetime can be, so it can go and perform a delete request on
>>> behalf of vanished clients. But again I don't see this as a protocol
>>> issue needing a TIMEOUT RRTYPE ?
>>> 
>>> Did I miss anything?
>>> 
>>> Paul
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Paul Wouters]

On Wed, 20 Feb 2019, Mark Andrews wrote:


Think disaster recovery and promoting a slave to master.  You have to
transfer state between servers.  You can transfer it in band or out of
band.  If you transfer it out of band you need to invent / specify
yet-another-protocol to do it on top of specifying when records need to
be removed.


That is not very convincing to me. disaster recovery scenarios seem to
be solvable by proper admin and by the daemon properly writing state to
disk which can be saved off-site. It also seems a rather rare occurance.

If the primary does DNSSEC, you also have to transfer private keys and
that isn't happening in-band either. So I'm not convinced by the
promotion of secondary to master either.

It also seems these two use cases are mostly solved if you keep your
dynamic update clients within their own zone, which I think is pretty
normal for DHCP based nodes that can make up their own hostname anyway
and shouldn't be able to muck with real static records or apex records.

Paul


On 20 Feb 2019, at 9:26 am, Paul Wouters  wrote:


I have read the document.

I have a question about:

  A zone administrator may
  want to enforce a default lifetime for dynamic updates (such as the
  DHCP lease lifetime) or the DNS Update may contain a lifetime using
  an EDNS(0) Update Lease option [I-D.sekar-dns-ul].

This seems a local policy and local implementation issue only.

 However, this
 lease lifetime is not communicated to secondary servers and will not
 endure through server software restarts.

Why does the secondary server need to know the lease lifetime? Only the
primary needs to know this because it will need to purge the records and
update the appropriate DNSSEC entries, something the secondary cannot do
anyway? In fact, Section 8 agrees with me:

  A secondary server MUST NOT expire the records in a zone it maintains
  covered by the TIMEOUT resource record and it MUST NOT expire the
  TIMEOUT resource record itself when the last record it covers has
  expired.  The secondary server MUST always wait for the records to be
  removed or updated by the primary server.

So why is the TIMEOUT record needed? If the secondary argument is
gone, the only argument left from the Introduction is server software
restart. Which seems to me to be an application issue and not a protocol
issue?

As others pointed out, introducing SHA3 into the DNS right now is not
appropriate.

I see a use for clients telling the dns update server what the maximum
possibly lifetime can be, so it can go and perform a delete request on
behalf of vanished clients. But again I don't see this as a protocol
issue needing a TIMEOUT RRTYPE ?

Did I miss anything?

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Dick Franks]

On Tue, 19 Feb 2019 at 21:27, Tim Wattenberg  wrote:

> 8<

> RRSIG, SIG, TKEY (32 bits with serial number arithmetic relative to now)
> >
> > TSIG (48 bits)
>
> thanks for bringing up this point again. I was aware of the way RRSIG
> presents time but thanks for pointing us to TSIG – I hadn’t considered this
> earlier.
>

TSIG is an aberration. Using a timescale of 8.9 million years to specify a
window of a few minutes around the current time was a monumental blunder.



> Given these possible representations, is there a preference over one of
> the two?
>

Unsigned 32 bit RRSIG time is good for travel until 7th February 2106.
The fact that 2100 will not be a leap year is likely to be a bigger issue
than wrap-around.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Mark Andrews]

Think disaster recovery and promoting a slave to master.  You have to
transfer state between servers.  You can transfer it in band or out of
band.  If you transfer it out of band you need to invent / specify
yet-another-protocol to do it on top of specifying when records need to
be removed.

Mark

> On 20 Feb 2019, at 9:26 am, Paul Wouters  wrote:
> 
> 
> I have read the document.
> 
> I have a question about:
> 
>   A zone administrator may
>   want to enforce a default lifetime for dynamic updates (such as the
>   DHCP lease lifetime) or the DNS Update may contain a lifetime using
>   an EDNS(0) Update Lease option [I-D.sekar-dns-ul].
> 
> This seems a local policy and local implementation issue only.
> 
>  However, this
>  lease lifetime is not communicated to secondary servers and will not
>  endure through server software restarts.
> 
> Why does the secondary server need to know the lease lifetime? Only the
> primary needs to know this because it will need to purge the records and
> update the appropriate DNSSEC entries, something the secondary cannot do
> anyway? In fact, Section 8 agrees with me:
> 
>   A secondary server MUST NOT expire the records in a zone it maintains
>   covered by the TIMEOUT resource record and it MUST NOT expire the
>   TIMEOUT resource record itself when the last record it covers has
>   expired.  The secondary server MUST always wait for the records to be
>   removed or updated by the primary server.
> 
> So why is the TIMEOUT record needed? If the secondary argument is
> gone, the only argument left from the Introduction is server software
> restart. Which seems to me to be an application issue and not a protocol
> issue?
> 
> As others pointed out, introducing SHA3 into the DNS right now is not
> appropriate.
> 
> I see a use for clients telling the dns update server what the maximum
> possibly lifetime can be, so it can go and perform a delete request on
> behalf of vanished clients. But again I don't see this as a protocol
> issue needing a TIMEOUT RRTYPE ?
> 
> Did I miss anything?
> 
> Paul
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Paul Wouters]

I have read the document.

I have a question about:

   A zone administrator may
   want to enforce a default lifetime for dynamic updates (such as the
   DHCP lease lifetime) or the DNS Update may contain a lifetime using
   an EDNS(0) Update Lease option [I-D.sekar-dns-ul].

This seems a local policy and local implementation issue only.

  However, this
  lease lifetime is not communicated to secondary servers and will not
  endure through server software restarts.

Why does the secondary server need to know the lease lifetime? Only the
primary needs to know this because it will need to purge the records and
update the appropriate DNSSEC entries, something the secondary cannot do
anyway? In fact, Section 8 agrees with me:

   A secondary server MUST NOT expire the records in a zone it maintains
   covered by the TIMEOUT resource record and it MUST NOT expire the
   TIMEOUT resource record itself when the last record it covers has
   expired.  The secondary server MUST always wait for the records to be
   removed or updated by the primary server.

So why is the TIMEOUT record needed? If the secondary argument is
gone, the only argument left from the Introduction is server software
restart. Which seems to me to be an application issue and not a protocol
issue?

As others pointed out, introducing SHA3 into the DNS right now is not
appropriate.

I see a use for clients telling the dns update server what the maximum
possibly lifetime can be, so it can go and perform a delete request on
behalf of vanished clients. But again I don't see this as a protocol
issue needing a TIMEOUT RRTYPE ?

Did I miss anything?

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Tim Wattenberg]

Tony,

> Am 19.02.2019 um 13:27 schrieb Tony Finch :
> 
> The DNS currently has a couple of representations of absolute (POSIX
> flavoured) time:
> 
> RRSIG, SIG, TKEY (32 bits with serial number arithmetic relative to now)
> 
> TSIG (48 bits)

thanks for bringing up this point again. I was aware of the way RRSIG presents 
time but thanks for pointing us to TSIG – I hadn’t considered this earlier.

Given these possible representations, is there a preference over one of the two?

Tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Robert Story]

On Tue 2019-02-19 12:28:08+1100 Mark wrote:
> Where is the need to use SHA-3?  This is introducing a new algorithm
> for the sake of introducing a new algorithm.  Just because TLS 1.3
> uses SHAKE128 is not a reason for DNS to use SHAKE128.  There are
> plenty of platforms that don’t need to use TLS at all.  They don’t
> have web interfaces.  Transaction security is provided by something
> other than TLS.
> 
> There are also lots of old server platforms that just won’t ever
> upgrade their OpenSSL package.  Adding SHA-3 creates yet another
> dependancy / impediment-to upgrading the DNS server.

I agree with Mark. Even the draft says:

5.  Cryptographic Hash Requirements

   The cryptographic hash algorithm used SHOULD provide the following
   properties:

   1.  Well known algorithm with implementations easily available

I have no objections to SHAKE128 being one of the supported algorithms,
but one of the SHA-2 algorithms should be selected for MUST implement.

-- 
Robert Story 
USC Information Sciences Institute 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Tony Finch]

Tom Pusateri  wrote:
>
> I think we have addressed all of the comments except for the Date format
> concern from Mark. That is still an outstanding issue.

The DNS currently has a couple of representations of absolute (POSIX
flavoured) time:

RRSIG, SIG, TKEY (32 bits with serial number arithmetic relative to now)

TSIG (48 bits)

It seems silly to invent a third one and prevent servers from re-using
code.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
the widest possible distribution of wealth

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adding more example configurations to draft-ietf-dnsop-7706bis

[Michał Kępień]

Hi Paul,

Apologies for being late to the party.

> I have seen messages in the past few months about some vendors adding 7706, 
> or 7706-like, support to recent versions of their resolvers. It would be 
> grand if those of you who have shipping implementations of this could send 
> the configuration steps to the list so we can add them to the appendix.

BIND 9.14, i.e. the upcoming stable BIND release, will ship with a
feature called mirror zones which facilitates setting up a local,
DNSSEC-validated copy of the root zone.

As of the currently available BIND 9.13.6 development release, a default
list of primary servers for the IANA root zone is built into named and
thus its mirroring can be enabled using the following configuration
snippet:

zone "." {
type mirror;
};

(The above snippet is intended to be used instead of the example BIND
configuration provided in Appendix B to RFC 7706, not in addition to
it.)

Chapter 5 of the BIND 9 ARM discusses how mirror zones work in more
detail:

https://bind.isc.org/doc/arm/9.13/Bv9ARM.ch05.html#zone_types

Please let me know if anything above is unclear.

-- 
Best regards,
Michał Kępień

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop