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

[Paul Vixie]

Tom Pusateri wrote:

I don’t think there is a TTL issue because, as we proposed it, the
record is never returned in a query. The TTL could always be set to 0
for our purposes since it never leaves the authoritative servers.


tom, (tim,) to be clear, the ttl which must decline is that of the 
expiring record (or its rrset, due to atomicity), and not that of the 
TIMEOUT RR itself. you cannot hand out an  or PTR (or in the 
degenerate case, an A RR) with a TTL of 3600 if it is due to expire in 
600 seconds. that RR has to have its TTL adjusted during its final 
authority-TTL interval so that noone has it in cache beyond the time of 
its death by expiry.


in  from 1996, this is 
described as follows:



3.4.1 - Initial TTL Limits

   The TTL of all added or updated RRs in the Update Section will be
   maximized silently to one half of the Expiry time.  This will cause
   downstream caching name servers to purge RRsets containing this RR at
   least once before expiry.

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,
   at which time the TTL will not be automatically reduced further by the
   primary master.  It should be noted that RRs held in a server's memory
   need not be swept for half life processing, as long as the TTL changes
   appear when the RR next becomes externally visible, and as long as the
   ``zone has changed'' processing (see below) is done at the time of the
   half life expiration.

   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]).


--
P Vixie

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

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

[Mark Andrews]

> On 24 Aug 2018, at 5:13 pm, Paul Vixie  wrote:
> 
> 
> 
> Tom Pusateri wrote:
>> I don’t think there is a TTL issue because, as we proposed it, the
>> record is never returned in a query. The TTL could always be set to 0
>> for our purposes since it never leaves the authoritative servers.
> 
> tom, (tim,) to be clear, the ttl which must decline is that of the expiring 
> record (or its rrset, due to atomicity), and not that of the TIMEOUT RR 
> itself. you cannot hand out an  or PTR (or in the degenerate case, an A 
> RR) with a TTL of 3600 if it is due to expire in 600 seconds. that RR has to 
> have its TTL adjusted during its final authority-TTL interval so that noone 
> has it in cache beyond the time of its death by expiry.

That’s one way of doing it.  Given the DNS is loosely coherent I really
would just leave it as the time the record is removed from the zone and
not play TTL games which require every server for the zone to support
the extension.  If you are worried about records being in the cache too
long use a smaller TTL from the start.

-- 
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] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Paul Vixie]

Mark Andrews wrote:



On 24 Aug 2018, at 5:13 pm, Paul Vixie  wrote:



tom, (tim,) to be clear, the ttl which must decline is that of the
expiring record (or its rrset, due to atomicity), and not that of
the TIMEOUT RR itself. you cannot hand out an  or PTR (or in
the degenerate case, an A RR) with a TTL of 3600 if it is due to
expire in 600 seconds. that RR has to have its TTL adjusted during
its final authority-TTL interval so that noone has it in cache
beyond the time of its death by expiry.


That’s one way of doing it.  Given the DNS is loosely coherent I
really would just leave it as the time the record is removed from the
zone and not play TTL games which require every server for the zone
to support the extension.  If you are worried about records being in
the cache too long use a smaller TTL from the start.


that may be nec'y given that this is not a deferred update mechanism, 
which is what led in 1996 to the half-life auto-update for propagation.


however, every authority server MUST support the TIMEOUT RR as proposed 
-- that's why i proposed that the configuration for it be negotiated via 
OPT rather than statically configured as proposed. so, every such server 
can have tickdown logic to avoid the bad choice between too-short TTL 
and too-stale data.


--
P Vixie

___
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-00.txt

[Mark Andrews]

This is unnecessary.  All the rule does is limit the process to class IN zones. 
 UPDATE, IXFR and AXFR are class agnostic.

1.  TIMEOUT resource records are only defined for CLASS IN.

This seems overly restrictive.  I would allow TIMEOUT records that
match added records to be accepted.

5.  TIMEOUT resource records cannot be directly added, modified, or
   deleted through DNS Update.

Secondary servers that are TIMEOUT aware should ignore TIMEOUT records
beyond storing them in case the server get promoted to being the master.

Is the secondary going to be able regenerate the RRset as the records are
removed as well as generate and sign NSEC and NSEC3 records?

Sources of TIMEOUT Expiry Time

Add matching TIMEOUT records added via UPDATE.

-- 
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-00.txt

[Ted Lemon]

On Aug 23, 2018, at 11:44 PM, Tom Pusateri  wrote:
> An RRset isn’t granular enough because the components of the set could come 
> from different clients with different timeout values.
> Therefore, a unique identifier is needed for each record. The hash provides 
> that unique identifier since it is calculated over the entire record 
> including the unique RDATA.

The hash stuff seems like a premature optimization.   I can think of two other 
ways to do this: either just send the contents of the RR, or use an index into 
the RRset and define a sorting order.   Bearing in mind that there's no reason 
for any server to store this data internally as anything other than an 
additional tuple in the RR itself, hashes may be the least efficient way to 
implement this.   Remember that for zone transfers, either you transfer the 
whole zone, or you transfer the differences, and in either case the zone 
contents for any zone serial number should always be the same.

Another question to ask here is, what is the application for this?   If it's 
just for DNSSD Registration, then it might be better to implement it in a less 
general way.  It would be worth scoping this before saying that it has to be 
done this way.   When Stuart and I talked about this, we had a much simpler 
model in mind; your model is certainly more general, but who's the customer?   
I'm not saying your model is wrong, just that we ought to discuss it explicitly.

If a zone is signed, are the TIMEOUT records signed?

___
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-00.txt

[Ted Lemon]

On Aug 23, 2018, at 9:23 PM, Paul Vixie  wrote:
> http://family.redbarn.org/~vixie/defupd.txt 
> 
> 
> the IETF DNSIND WG rejected this draft on the basis of its complexity. the 
> idea of a zone having timers inside it, for self-modification, was just a 
> bridge too far at that time. given what is now called "the camel" i think 
> pendulum has swung _well_ away from that point of view, but is now in the 
> process of swinging back. if i had hope, i would submit DEFUPD again, exactly 
> as it was in 1996, because it still deftly threads the needle posed by 
> UPDATE. your needs may differ.

I think that defupd is the core of a good idea, but it's more complicated than 
it needs to be.   Another way to accomplish the same thing would be to have an 
RR that just contains an update and a time when the update is to be done, 
hanging off of the name to be updated.   This could be included in the DNS 
update that creates the record, or created automatically by the server based on 
the update lease EDNS(0) option.

IOW I don't think there's any need for a new DEFUPD opcode, but the idea 
otherwise ought to be considered alongside Tom's proposal to see which one we 
think is easier to specify and implement.


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

Re: [DNSOP] New draft for helping browsers use the DoH server associated with a resolver

[Vladimír Čunát]

On 08/24/2018 02:01 AM, Paul Hoffman wrote:
> Thoughts?

Well, if the OS resolver is validating, it will SERVFAIL with such a
query.  Furthermore, if it uses aggressive caching, it may even give a
negative reply without asking upstream that would answer positively. 
That is, unless the RFC instructs forwarding resolvers to do otherwise,
but that would seem a nasty special case for little benefit.

I assume the non-validation is a conscious tradeoff, as such resolvers
seem not a common OS default, and they're more likely to support DoT or
DoH anyway, hopefully reducing the need for browsers to roll their own.

I'm not sure I understand the motivation for the stated use case, but
apparently others perceive it as useful...

--Vladimir

___
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-00.txt

[Tom Pusateri]

> On Aug 24, 2018, at 9:11 AM, Ted Lemon  wrote:
> 
> On Aug 23, 2018, at 11:44 PM, Tom Pusateri  wrote:
>> An RRset isn’t granular enough because the components of the set could come 
>> from different clients with different timeout values.
>> Therefore, a unique identifier is needed for each record. The hash provides 
>> that unique identifier since it is calculated over the entire record 
>> including the unique RDATA.
> 
> The hash stuff seems like a premature optimization.   I can think of two 
> other ways to do this: either just send the contents of the RR, or use an 
> index into the RRset and define a sorting order.   Bearing in mind that 
> there's no reason for any server to store this data internally as anything 
> other than an additional tuple in the RR itself, hashes may be the least 
> efficient way to implement this.   Remember that for zone transfers, either 
> you transfer the whole zone, or you transfer the differences, and in either 
> case the zone contents for any zone serial number should always be the same.

We thought about sorting and indexing but that seemed way more error prone and 
not as general. The hash is a general solution that works well for these 
immediate uses and for any future uses that we can’t anticipate. It also 
provides the basis of a unique identifier that could be used for other 
non-related DNS extensions that need a unique identifier, so this code could be 
re-used. With the current libraries available, it’s not particularly 
complicated or onerous. 

> Another question to ask here is, what is the application for this?   If it's 
> just for DNSSD Registration, then it might be better to implement it in a 
> less general way.  It would be worth scoping this before saying that it has 
> to be done this way.   When Stuart and I talked about this, we had a much 
> simpler model in mind; your model is certainly more general, but who's the 
> customer?   I'm not saying your model is wrong, just that we ought to discuss 
> it explicitly.
> 

Yes, it was intended to be more general than for service registration. It’s 
directly applicable to name registration for IP addresses. I can add a section 
on other uses if more motivation is desired. Mark Andrews had some uses as well 
that hopefully, he can share. If others have uses in mind that this solves I 
would love to hear about them.

> If a zone is signed, are the TIMEOUT records signed?
> 

No. The draft says they are skipped.

Thanks,
Tom

___
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-00.txt

[Ted Lemon]

On Aug 24, 2018, at 9:52 AM, Tom Pusateri  wrote:
> Yes, it was intended to be more general than for service registration. It’s 
> directly applicable to name registration for IP addresses. I can add a 
> section on other uses if more motivation is desired. Mark Andrews had some 
> uses as well that hopefully, he can share. If others have uses in mind that 
> this solves I would love to hear about them.

The reason I'm asking is not that I don't think there are theoretical use cases 
for what you are proposing.   I'm asking if there are actual use cases.   How 
would this be used in practice?   What can't someone do right now that they 
need to do and that this new technology enables?

___
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-00.txt

[Joe Abley]

Hi Tom,

> On Aug 24, 2018, at 09:52, Tom Pusateri  wrote:
> 
>> If a zone is signed, are the TIMEOUT records signed?
> 
> No. The draft says they are skipped.

New RRTypes are supposed to be handled by old software that pre-dates them 
because they can be treated as opaque types. That's not the case if new RRTypes 
are encumbered with requirements for special handling at query or signing time 
(as described in your section 2).

This seems like a significant architectural change that in effect updates 1034 
and 1035 as well as 3597. This would be a much more straightforward and 
uncontroversial proposal if it was simply a specification for use of a new 
RRType that made no changes at all to the rest of the protocol.

I have not read your draft in detail but I think you probably would also need 
to spend more time considering the cases of old, non-TIMEOUT authority servers 
that wind up serving zones that contain TIMEOUT RRSets (e.g. third-party 
hosting services). Client handling of rogue RRSIGs, RCODE=NOERROR with ANSWER 
sections containing TIMEOUT RRSets, etc.

This all seems a bit messy, to be honest.


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

Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver

[Paul Hoffman]

On Aug 24, 2018, at 6:43 AM, Vladimír Čunát  wrote:
> 
> On 08/24/2018 02:01 AM, Paul Hoffman wrote:
>> Thoughts?
> 
> Well, if the OS resolver is validating, it will SERVFAIL with such a
> query.  

The protocol requires special handling of those specific queries, so a resolver 
that understands the protocol will give the desired answer. A resolver that 
doesn't understand the answer will give NXDOMAIN even if it is validating 
because that RRtype is not in the root zone.

> Furthermore, if it uses aggressive caching, it may even give a
> negative reply without asking upstream that would answer positively. 

...which is fine for resolvers that do not know the protocol.

> That is, unless the RFC instructs forwarding resolvers to do otherwise,
> but that would seem a nasty special case for little benefit.

Forwarding resolvers do not need special casing, I believe. If the forwarding 
resolver understands the protocol, it will reply. If it doesn't understand the 
protocol, it will forward and give back whatever the upstream resolver tells 
it. 

> I assume the non-validation is a conscious tradeoff, as such resolvers
> seem not a common OS default, and they're more likely to support DoT or
> DoH anyway, hopefully reducing the need for browsers to roll their own.

I admit I had not considered validating stub resolvers. Now that you bring it 
up, a validating stub resolver will get an answer that cannot be validated, and 
thus will mark it Bogus. This feels like a limitation, but one that can't 
really be worked around unless we use a RFC 6761 TLD that is guaranteed to be 
unsigned.

> I'm not sure I understand the motivation for the stated use case, but
> apparently others perceive it as useful...

Restating the motivation: a browser that wants to use DoH might also want to 
let the user say "I trust the DoH server that my configured resolver is 
associated with". That eliminates the need to have DHCP know which DoH servers 
are associated with the Do53 servers that it is announcing, and it also 
eliminates the need for the OS to know about those DHCP updates.

Hopefully this helps. But thank you for bringing up the validating stub issue.

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

Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver

[Vladimír Čunát]

On 08/24/2018 04:25 PM, Paul Hoffman wrote:
> Forwarding resolvers do not need special casing, I believe. If the forwarding 
> resolver understands the protocol, it will reply. If it doesn't understand 
> the protocol, it will forward and give back whatever the upstream resolver 
> tells it. 

Oh, I assumed (perhaps wrongly) that if the OS resolver forwards to some
other resolver that can do DoH, you want the browser to use *that* DoH
instead of the OS resolver, at least in the usual case when there's not
a good channel to the OS resolver itself.  If the OS resolver validates,
I don't see much difference between being a "stub" or forwarding.

Anyway, all the notes I've written are about an edge case that seem a
small fraction in practice - dumb stub without validation and without
secure transport is still the default almost everywhere, I'm afraid.

I believe I understood what you mean by the "motivation" - confirmed by
you restating it.  I still can't really understand why that group of
cases is considered useful, but presumably browser/DoH people know
better what most of their users want.

--Vladimir

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

Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver

[Philip Homburg]

> > Well, if the OS resolver is validating, it will SERVFAIL with such a
> > query.
> 
> The protocol requires special handling of those specific queries,
> so a resolver that understands the protocol will give the desired
> answer. A resolver that doesn't understand the answer will give
> NXDOMAIN even if it is validating because that RRtype is not in
> the root zone.

It seems to go wrong when you have one validating resolver that forwards to a
resolver that supports this mechanism.

It don't really see the point of what you propose. For resolvers obtained by
DHCP it makes more sense to include the URL in the DHCP reply than to have
yet another DNSSEC-violating discovery hack.

For manually configured resolvers, it is likely more convenient for the user
to just enter the URL and let the system figure out the addresses of the
resolvers.

Figuring out what SNI to use using insecure DNS sort of negates any advantage
TLS authentication offers.

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

Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver

[Paul Hoffman]

On Aug 24, 2018, at 7:45 AM, Philip Homburg  wrote:
> 
>>> Well, if the OS resolver is validating, it will SERVFAIL with such a
>>> query.
>> 
>> The protocol requires special handling of those specific queries,
>> so a resolver that understands the protocol will give the desired
>> answer. A resolver that doesn't understand the answer will give
>> NXDOMAIN even if it is validating because that RRtype is not in
>> the root zone.
> 
> It seems to go wrong when you have one validating resolver that forwards to a
> resolver that supports this mechanism.

Agree. This might mean that using an unsigned 6761 special use domain name 
would be better.

> It don't really see the point of what you propose. For resolvers obtained by
> DHCP it makes more sense to include the URL in the DHCP reply than to have
> yet another DNSSEC-violating discovery hack.

Two reasons here (although they might not be convincing):

- This proposal works for browsers even if the OS doesn't understand a new DHCP 
extension for DoH server URI templates

- It relives the DHCP server admin from needing to know which DoH servers are 
associated with a particular Do53 server.

As I hope I made clear in the proposal, it will work even if there is a new 
DHCP extension for the OS. It just doesn't rely on it.

> For manually configured resolvers, it is likely more convenient for the user
> to just enter the URL and let the system figure out the addresses of the
> resolvers.

Again, it is not clear how that information would get to the browsers. They 
have a hard enough time getting good answers to "what is the address being used 
for the resolver".

> Figuring out what SNI to use using insecure DNS sort of negates any advantage
> TLS authentication offers.

I don't understand this at all. The SNI is the host in the URI template.

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

Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver

[Vladimír Čunát]

On 08/24/2018 04:56 PM, Paul Hoffman wrote:
>> Figuring out what SNI to use using insecure DNS sort of negates any advantage
>> TLS authentication offers.
> I don't understand this at all. The SNI is the host in the URI template.

There remains the general problem with bootstrapping a "secure" channel
without using another secure anchor.  DHCP has the same problem - it's
not validable (reportedly, I don't know the protocol well).

You get a name (for SNI) and thus you can verify that you connect to
that name (https/tls), but you can't distinguish whether you got a
spoofed name in the first place, and I can't see a possible workaround
for that.  Both DHCP and this draft are essentially like not validating
identity of the other side but otherwise using a "secure" transport. 
Well, I think many people consider such opportunistic security schemes
to be noticeably better than cleartext.

Still, personally I'd probably prefer to choose someone from a list of
providers, as we might have quite a lot soon, and "I" might trust some
of the names already, and the handshake will then verify that the name
matches.  I assume this draft is meant as yet another fallback when such
user selection isn't suitable.  (Well, I'd most prefer to run a per-SOHO
or per-device validating resolver, in future maybe with TLS-forwarding
somewhere else, but that doesn't belong to this thread, and it isn't
suitable for most people anyway.)

--Vladimir

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

[DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

[Mirja Kühlewind]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dnsop-terminology-bis-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/



--
COMMENT:
--

I'm actually not sure if this doc really updates RFC2308 because the two
definitions (Forwarder and QNAME) only say someting like "it is used
differently today" but seem not really to actually update the existing
definitions. I would recommend to either not use the "update" tag or clarify
these definitions.

Thanks for the clarification added based on the TSV-ART review (and thanks
Allison!).

(Potential) nits:
1) OLD:
A set of resource records with the same label, class and
  type, but with different data.  (Definition from [RFC2181])
MAYBE use quotes here at least for the last part of the sentence:
A set of resource records "with the same label, class and
  type, but with different data."  (Definition from [RFC2181])

2) s/Section 4.3.1 of of [RFC1034] /Section 4.3.1 of [RFC1034]/

3) Probably the first sentence should be removed:
"The idea of a primary master is only used by [RFC2136],
  and is considered archaic in other parts of the DNS.

  The idea of a primary master is only used in [RFC1996] and
  [RFC2136]. "

4) Why is there (a) and (b) for the definition of Origin?


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

Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver

[Shumon Huque]

On Fri, Aug 24, 2018 at 10:26 AM Paul Hoffman 
wrote:

> On Aug 24, 2018, at 6:43 AM, Vladimír Čunát 
> wrote:
> >
> > On 08/24/2018 02:01 AM, Paul Hoffman wrote:
> >> Thoughts?
> >
> > Well, if the OS resolver is validating, it will SERVFAIL with such a
> > query.
>
> The protocol requires special handling of those specific queries, so a
> resolver that understands the protocol will give the desired answer. A
> resolver that doesn't understand the answer will give NXDOMAIN even if it
> is validating because that RRtype is not in the root zone.
>

(Haven't read the draft yet, but a quick comment on this point ..)

Surely you mean NODATA (NOERROR + empty ANSWER section), since the root
domain name exists. If validating, it would additionally provide the signed
NSEC/NSEC3 record at the root disproving the existence of the RRtype.

Shumon
___
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-00.txt

[Tom Pusateri]

> On Aug 24, 2018, at 10:11 AM, Joe Abley  wrote:
> 
> Hi Tom,
> 
>> On Aug 24, 2018, at 09:52, Tom Pusateri  wrote:
>> 
>>> If a zone is signed, are the TIMEOUT records signed?
>> 
>> No. The draft says they are skipped.
> 
> New RRTypes are supposed to be handled by old software that pre-dates them 
> because they can be treated as opaque types. That's not the case if new 
> RRTypes are encumbered with requirements for special handling at query or 
> signing time (as described in your section 2).
> 
> This seems like a significant architectural change that in effect updates 
> 1034 and 1035 as well as 3597. This would be a much more straightforward and 
> uncontroversial proposal if it was simply a specification for use of a new 
> RRType that made no changes at all to the rest of the protocol.
> 
> I have not read your draft in detail but I think you probably would also need 
> to spend more time considering the cases of old, non-TIMEOUT authority 
> servers that wind up serving zones that contain TIMEOUT RRSets (e.g. 
> third-party hosting services). Client handling of rogue RRSIGs, RCODE=NOERROR 
> with ANSWER sections containing TIMEOUT RRSets, etc.

Yes, the draft says the primary has to agree to send them to the secondary and 
the secondary has to agree to accept them (administratively). This prevents old 
authority servers from having to deal with them.

The position of not having them signed is a consequence of not having them 
returned in a query. If you can’t see them in a query, you can’t do 
NSEC/NSEC3/NSEC5 next record semantics so we skip them.

By simply making them returned in a query, we can avoid most of your 
objections. Mark Andrews suggested they not be returned in a query in a hallway 
discussion and I’m happy to change if that’s the preferred approach.

Thanks for the feedback!

Tom

___
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-00.txt

[Tom Pusateri]

> On Aug 24, 2018, at 9:54 AM, Ted Lemon  wrote:
> 
> On Aug 24, 2018, at 9:52 AM, Tom Pusateri  > wrote:
>> Yes, it was intended to be more general than for service registration. It’s 
>> directly applicable to name registration for IP addresses. I can add a 
>> section on other uses if more motivation is desired. Mark Andrews had some 
>> uses as well that hopefully, he can share. If others have uses in mind that 
>> this solves I would love to hear about them.
> 
> The reason I'm asking is not that I don't think there are theoretical use 
> cases for what you are proposing.   I'm asking if there are actual use cases. 
>   How would this be used in practice?   What can't someone do right now that 
> they need to do and that this new technology enables?

Specifically, there are two applications mentioned in the draft.

1. When a DNS server receives a dynamic DNS Update from a client registering 
its name after having received an IP address from an DHCP lease, the length of 
the DHCP lease can be tied to the length that the DNS address/PTR records stay 
in the authoritative server.

2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, & TXT 
records), these records can timeout according to the lease lifetime contained 
in the update lease EDNS(0) option.

These are not theoretical. They solve practical problems that exist today. I 
think there are others associated with existing problems for sleeping devices 
and IoT devices that I need to research to more clearly answer your specific 
question but I think these two already fulfill that requirement.

Tom


___
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-00.txt

[Ted Lemon]

The DHCP case isn't actually a problem today.   DHCP servers automatically
remove these records.   The ISC server has been doing this for 20 years,
and I'm pretty sure all the other servers that compete with it do too.

On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri  wrote:

>
>
> On Aug 24, 2018, at 9:54 AM, Ted Lemon  wrote:
>
> On Aug 24, 2018, at 9:52 AM, Tom Pusateri  wrote:
>
> Yes, it was intended to be more general than for service registration.
> It’s directly applicable to name registration for IP addresses. I can add a
> section on other uses if more motivation is desired. Mark Andrews had some
> uses as well that hopefully, he can share. If others have uses in mind that
> this solves I would love to hear about them.
>
>
> The reason I'm asking is not that I don't think there are theoretical use
> cases for what you are proposing.   I'm asking if there are actual use
> cases.   How would this be used in practice?   What can't someone do right
> now that they need to do and that this new technology enables?
>
>
> Specifically, there are two applications mentioned in the draft.
>
> 1. When a DNS server receives a dynamic DNS Update from a client
> registering its name after having received an IP address from an DHCP
> lease, the length of the DHCP lease can be tied to the length that the DNS
> address/PTR records stay in the authoritative server.
>
> 2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, &
> TXT records), these records can timeout according to the lease lifetime
> contained in the update lease EDNS(0) option.
>
> These are not theoretical. They solve practical problems that exist today..
> I think there are others associated with existing problems for sleeping
> devices and IoT devices that I need to research to more clearly answer your
> specific question but I think these two already fulfill that requirement.
>
> Tom
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

Sure. It’s not the thoughtful, well-behaved implementations that we worry 
about. It’s the ones that aren’t. This is a protection mechanism. (Belt AND 
suspenders..)

Thanks,
Tom


> On Aug 24, 2018, at 1:36 PM, Ted Lemon  wrote:
> 
> The DHCP case isn't actually a problem today.   DHCP servers automatically 
> remove these records.   The ISC server has been doing this for 20 years, and 
> I'm pretty sure all the other servers that compete with it do too.
> 
> On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri  > wrote:
> 
> 
>> On Aug 24, 2018, at 9:54 AM, Ted Lemon > > wrote:
>> 
>> On Aug 24, 2018, at 9:52 AM, Tom Pusateri > > wrote:
>>> Yes, it was intended to be more general than for service registration. It’s 
>>> directly applicable to name registration for IP addresses. I can add a 
>>> section on other uses if more motivation is desired. Mark Andrews had some 
>>> uses as well that hopefully, he can share. If others have uses in mind that 
>>> this solves I would love to hear about them.
>> 
>> The reason I'm asking is not that I don't think there are theoretical use 
>> cases for what you are proposing.   I'm asking if there are actual use 
>> cases.   How would this be used in practice?   What can't someone do right 
>> now that they need to do and that this new technology enables?
> 
> Specifically, there are two applications mentioned in the draft.
> 
> 1. When a DNS server receives a dynamic DNS Update from a client registering 
> its name after having received an IP address from an DHCP lease, the length 
> of the DHCP lease can be tied to the length that the DNS address/PTR records 
> stay in the authoritative server.
> 
> 2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, & TXT 
> records), these records can timeout according to the lease lifetime contained 
> in the update lease EDNS(0) option.
> 
> These are not theoretical. They solve practical problems that exist today. I 
> think there are others associated with existing problems for sleeping devices 
> and IoT devices that I need to research to more clearly answer your specific 
> question but I think these two already fulfill that requirement.
> 
> Tom
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

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

[Ted Lemon]

Can you give us an example?

On Fri, Aug 24, 2018 at 1:56 PM Tom Pusateri  wrote:

> Sure. It’s not the thoughtful, well-behaved implementations that we worry
> about. It’s the ones that aren’t. This is a protection mechanism. (Belt AND
> suspenders..)
>
> Thanks,
> Tom
>
>
> On Aug 24, 2018, at 1:36 PM, Ted Lemon  wrote:
>
> The DHCP case isn't actually a problem today.   DHCP servers automatically
> remove these records.   The ISC server has been doing this for 20 years,
> and I'm pretty sure all the other servers that compete with it do too.
>
> On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri  wrote:
>
>>
>>
>> On Aug 24, 2018, at 9:54 AM, Ted Lemon  wrote:
>>
>> On Aug 24, 2018, at 9:52 AM, Tom Pusateri  wrote:
>>
>> Yes, it was intended to be more general than for service registration.
>> It’s directly applicable to name registration for IP addresses. I can add a
>> section on other uses if more motivation is desired. Mark Andrews had some
>> uses as well that hopefully, he can share. If others have uses in mind that
>> this solves I would love to hear about them.
>>
>>
>> The reason I'm asking is not that I don't think there are theoretical use
>> cases for what you are proposing.   I'm asking if there are actual use
>> cases.   How would this be used in practice?   What can't someone do right
>> now that they need to do and that this new technology enables?
>>
>>
>> Specifically, there are two applications mentioned in the draft.
>>
>> 1. When a DNS server receives a dynamic DNS Update from a client
>> registering its name after having received an IP address from an DHCP
>> lease, the length of the DHCP lease can be tied to the length that the DNS
>> address/PTR records stay in the authoritative server.
>>
>> 2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, &
>> TXT records), these records can timeout according to the lease lifetime
>> contained in the update lease EDNS(0) option.
>>
>> These are not theoretical. They solve practical problems that exist
>> today. I think there are others associated with existing problems for
>> sleeping devices and IoT devices that I need to research to more clearly
>> answer your specific question but I think these two already fulfill that
>> requirement.
>>
>> Tom
>>
>>
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

Sorry, I never surveyed the set of inconsiderate DCHP servers.

Thanks,
Tom

> On Aug 24, 2018, at 2:04 PM, Ted Lemon  wrote:
> 
> Can you give us an example?
> 
>> On Fri, Aug 24, 2018 at 1:56 PM Tom Pusateri  wrote:
>> Sure. It’s not the thoughtful, well-behaved implementations that we worry 
>> about. It’s the ones that aren’t. This is a protection mechanism. (Belt AND 
>> suspenders..)
>> 
>> Thanks,
>> Tom
>> 
>> 
>>> On Aug 24, 2018, at 1:36 PM, Ted Lemon  wrote:
>>> 
>>> The DHCP case isn't actually a problem today.   DHCP servers automatically 
>>> remove these records.   The ISC server has been doing this for 20 years, 
>>> and I'm pretty sure all the other servers that compete with it do too.
>>> 
>>> On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri  wrote:
 
 
> On Aug 24, 2018, at 9:54 AM, Ted Lemon  wrote:
> 
>> On Aug 24, 2018, at 9:52 AM, Tom Pusateri  wrote:
>> Yes, it was intended to be more general than for service registration.. 
>> It’s directly applicable to name registration for IP addresses. I can 
>> add a section on other uses if more motivation is desired. Mark Andrews 
>> had some uses as well that hopefully, he can share. If others have uses 
>> in mind that this solves I would love to hear about them.
> 
> The reason I'm asking is not that I don't think there are theoretical use 
> cases for what you are proposing.   I'm asking if there are actual use 
> cases.   How would this be used in practice?   What can't someone do 
> right now that they need to do and that this new technology enables?
 
 Specifically, there are two applications mentioned in the draft.
 
 1. When a DNS server receives a dynamic DNS Update from a client 
 registering its name after having received an IP address from an DHCP 
 lease, the length of the DHCP lease can be tied to the length that the DNS 
 address/PTR records stay in the authoritative server.
 
 2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, & 
 TXT records), these records can timeout according to the lease lifetime 
 contained in the update lease EDNS(0) option.
 
 These are not theoretical. They solve practical problems that exist today. 
 I think there are others associated with existing problems for sleeping 
 devices and IoT devices that I need to research to more clearly answer 
 your specific question but I think these two already fulfill that 
 requirement.
 
 Tom
 
 
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

It seems odd to take the position that the authoritative server shouldn’t need 
to clean up stale entries because it assumes the client will do it for you. I 
can’t imagine you taking this position under any other scenario.

Thanks,
Tom


> On Aug 24, 2018, at 2:33 PM, Tom Pusateri  wrote:
> 
> Sorry, I never surveyed the set of inconsiderate DCHP servers.
> 
> Thanks,
> Tom
> 
> On Aug 24, 2018, at 2:04 PM, Ted Lemon  > wrote:
> 
>> Can you give us an example?
>> 
>> On Fri, Aug 24, 2018 at 1:56 PM Tom Pusateri > > wrote:
>> Sure. It’s not the thoughtful, well-behaved implementations that we worry 
>> about. It’s the ones that aren’t. This is a protection mechanism. (Belt AND 
>> suspenders..)
>> 
>> Thanks,
>> Tom
>> 
>> 
>>> On Aug 24, 2018, at 1:36 PM, Ted Lemon >> > wrote:
>>> 
>>> The DHCP case isn't actually a problem today.   DHCP servers automatically 
>>> remove these records.   The ISC server has been doing this for 20 years, 
>>> and I'm pretty sure all the other servers that compete with it do too.
>>> 
>>> On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri >> > wrote:
>>> 
>>> 
 On Aug 24, 2018, at 9:54 AM, Ted Lemon >>> > wrote:
 
 On Aug 24, 2018, at 9:52 AM, Tom Pusateri >>> > wrote:
> Yes, it was intended to be more general than for service registration. 
> It’s directly applicable to name registration for IP addresses. I can add 
> a section on other uses if more motivation is desired. Mark Andrews had 
> some uses as well that hopefully, he can share. If others have uses in 
> mind that this solves I would love to hear about them.
 
 The reason I'm asking is not that I don't think there are theoretical use 
 cases for what you are proposing.   I'm asking if there are actual use 
 cases.   How would this be used in practice?   What can't someone do right 
 now that they need to do and that this new technology enables?
>>> 
>>> Specifically, there are two applications mentioned in the draft.
>>> 
>>> 1. When a DNS server receives a dynamic DNS Update from a client 
>>> registering its name after having received an IP address from an DHCP 
>>> lease, the length of the DHCP lease can be tied to the length that the DNS 
>>> address/PTR records stay in the authoritative server.
>>> 
>>> 2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, & TXT 
>>> records), these records can timeout according to the lease lifetime 
>>> contained in the update lease EDNS(0) option.
>>> 
>>> These are not theoretical. They solve practical problems that exist today. 
>>> I think there are others associated with existing problems for sleeping 
>>> devices and IoT devices that I need to research to more clearly answer your 
>>> specific question but I think these two already fulfill that requirement.
>>> 
>>> Tom
>>> 
>>> 
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/dnsop 
>>> 
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org 
>> https://www.ietf.org/mailman/listinfo/dnsop 
>> 

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

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

[Ted Lemon]

On Aug 24, 2018, at 2:43 PM, Tom Pusateri  wrote:
> It seems odd to take the position that the authoritative server shouldn’t 
> need to clean up stale entries because it assumes the client will do it for 
> you. I can’t imagine you taking this position under any other scenario.

The issue here is that this is a pretty major change to the DNS.   If we really 
want something this heavy, we should have a good reason for wanting it.   
That's all.

The idea that some unnamed DHCP server somewhere doesn't do the right thing 
with cleaning up stale entries doesn't seem like a good enough reason, 
particularly given that the DHCID record tags the thing as having been added by 
the DHCP server, and considering that there are several open source 
implementations that do automatically delete records when the lease expires.

I think it might make sense to just wait on this.  I agree that it's an 
interesting idea for completeness, but we don't have enough operational 
experience yet to know whether we have a problem worth solving.   With respect 
to the DHCP use case, I'm certain we don't.

The good news is that if we do need this, you've done a design, and we also 
have Paul's design to look at.   So if operational experience a few years down 
the road shows us that we have a gap here, we can move on it pretty easily. I 
just don't see any reason to rush into it.

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

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

[Tom Pusateri]

> On Aug 24, 2018, at 2:59 PM, Ted Lemon  wrote:
> 
> On Aug 24, 2018, at 2:43 PM, Tom Pusateri  > wrote:
>> It seems odd to take the position that the authoritative server shouldn’t 
>> need to clean up stale entries because it assumes the client will do it for 
>> you. I can’t imagine you taking this position under any other scenario.
> 
> The issue here is that this is a pretty major change to the DNS.   If we 
> really want something this heavy, we should have a good reason for wanting 
> it.   That's all.
> 
> The idea that some unnamed DHCP server somewhere doesn't do the right thing 
> with cleaning up stale entries doesn't seem like a good enough reason, 
> particularly given that the DHCID record tags the thing as having been added 
> by the DHCP server, and considering that there are several open source 
> implementations that do automatically delete records when the lease expires.
> 
> I think it might make sense to just wait on this.  I agree that it's an 
> interesting idea for completeness, but we don't have enough operational 
> experience yet to know whether we have a problem worth solving.   With 
> respect to the DHCP use case, I'm certain we don't.
> 
> The good news is that if we do need this, you've done a design, and we also 
> have Paul's design to look at.   So if operational experience a few years 
> down the road shows us that we have a gap here, we can move on it pretty 
> easily. I just don't see any reason to rush into it.

Ok, great. Hopefully others have some use cases they can share. In the mean 
time, back to learning Rust…

Thanks,
Tom

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

[DNSOP] AD review of draft-ietf-dnsop-isp-ip6rdns

[Warren Kumari]

AD Review of "Reverse DNS in IPv6 for Internet Service Providers"
(draft-ietf-dnsop-isp-ip6rdns-05)


Apologies for how long it has taken to do this review; I had a few,
primarily editorial notes on this document - while they are mainly
editorial / nits, addressing them now will prevent (well, minimize :-))
issues later in the process.

Section: Abstract

   In IPv4, Internet Service Providers (ISPs) commonly provide IN-
   ADDR.ARPA information for their customers by prepopulating the zone
   with one PTR record for every available address.  This practice does
   not scale in IPv6.  This document analyzes different approaches and
   considerations for ISPs in managing the ip6.arpa zone for IPv6
   address space assigned to many customers.


 Q1: It it intentional that IN-ADDR.ARPA is uppercase, and ip6.arpa is
lower?

 Q2: ... "managing the ip6.arpa zone for IPv6 address space assigned to
many customers."
The "assigned to many customers" bit reads oddly to me - does it add
anything? Could it just be "for their IPv6 space" instead? Or just drop the
"many"?

Section 1.1:  Reverse DNS in IPv4

"For instance, if an ISP Example.com aggregated
192.0.2.0/24 at a network hub in Town in the province of AnyWhere,
the reverse zone might look like:

   1.2.0.192.IN-ADDR.ARPA.  IN PTR 1.string.region.example.com."

Q3: Was the Town, AnyWhere bit supposed to be referenced ?  Perhaps:
1.town.anywhere.example.com?

Section 1.2.  Reverse DNS Considerations in IPv6
"Since 2^^80 possible addresses could be configured in an example
2001:db8:f00/48 zone alone, even with automation ..."

Q4: The "in an example 2001:db8:f00/48 zone" is confusing to me - this
makes it sound like the example / prefix is in some what special - this is
true for any /48. Can the prefix bit be dropped? Or this reworded?

Q5: This document uses DNSsec - I believe that the standard capitalization
is DNSSEC.

Thanks,
W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

Registering slaac derived addresses in the DNS.  These are tied to prefix 
lifetimes. 

-- 
Mark Andrews

> On 25 Aug 2018, at 05:02, Tom Pusateri  wrote:
> 
> 
> 
>> On Aug 24, 2018, at 2:59 PM, Ted Lemon  wrote:
>> 
>>> On Aug 24, 2018, at 2:43 PM, Tom Pusateri  wrote:
>>> It seems odd to take the position that the authoritative server shouldn’t 
>>> need to clean up stale entries because it assumes the client will do it for 
>>> you. I can’t imagine you taking this position under any other scenario.
>> 
>> The issue here is that this is a pretty major change to the DNS.   If we 
>> really want something this heavy, we should have a good reason for wanting 
>> it..   That's all.
>> 
>> The idea that some unnamed DHCP server somewhere doesn't do the right thing 
>> with cleaning up stale entries doesn't seem like a good enough reason, 
>> particularly given that the DHCID record tags the thing as having been added 
>> by the DHCP server, and considering that there are several open source 
>> implementations that do automatically delete records when the lease expires.
>> 
>> I think it might make sense to just wait on this.  I agree that it's an 
>> interesting idea for completeness, but we don't have enough operational 
>> experience yet to know whether we have a problem worth solving.   With 
>> respect to the DHCP use case, I'm certain we don't.
>> 
>> The good news is that if we do need this, you've done a design, and we also 
>> have Paul's design to look at.   So if operational experience a few years 
>> down the road shows us that we have a gap here, we can move on it pretty 
>> easily. I just don't see any reason to rush into it.
> 
> Ok, great. Hopefully others have some use cases they can share. In the mean 
> time, back to learning Rust…
> 
> Thanks,
> Tom
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

When would that happen?

On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews  wrote:

> Registering slaac derived addresses in the DNS.  These are tied to prefix
> lifetimes.
>
>
> --
> Mark Andrews
>
> On 25 Aug 2018, at 05:02, Tom Pusateri  wrote:
>
>
>
> On Aug 24, 2018, at 2:59 PM, Ted Lemon  wrote:
>
> On Aug 24, 2018, at 2:43 PM, Tom Pusateri  wrote:
>
> It seems odd to take the position that the authoritative server shouldn’t
> need to clean up stale entries because it assumes the client will do it for
> you. I can’t imagine you taking this position under any other scenario.
>
>
> The issue here is that this is a pretty major change to the DNS.   If we
> really want something this heavy, we should have a good reason for wanting
> it.   That's all.
>
> The idea that some unnamed DHCP server somewhere doesn't do the right
> thing with cleaning up stale entries doesn't seem like a good enough
> reason, particularly given that the DHCID record tags the thing as having
> been added by the DHCP server, and considering that there are several open
> source implementations that do automatically delete records when the lease
> expires.
>
> I think it might make sense to just wait on this.  I agree that it's an
> interesting idea for completeness, but we don't have enough operational
> experience yet to know whether we have a problem worth solving.   With
> respect to the DHCP use case, I'm certain we don't.
>
> The good news is that if we do need this, you've done a design, and we
> also have Paul's design to look at.   So if operational experience a few
> years down the road shows us that we have a gap here, we can move on it
> pretty easily. I just don't see any reason to rush into it.
>
>
> Ok, great. Hopefully others have some use cases they can share. In the
> mean time, back to learning Rust…
>
> Thanks,
> Tom
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

Ted stop being daft. People have been registering addresses of machines in the 
public DNS for decades.   SLAAC. Is just one source of addresses. DHCP is 
another. Come up with a third method and they will do it with it. 

Also DHCP servers from ISPs don’t have authority to update DNS servers for my 
machines. Only those machines have such authority so don’t discount DHCP 
derived addresses. 

-- 
Mark Andrews

> On 25 Aug 2018, at 12:53, Ted Lemon  wrote:
> 
> When would that happen?
> 
>> On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews  wrote:
>> Registering slaac derived addresses in the DNS.  These are tied to prefix 
>> lifetimes. 
>> 
>> 
>> -- 
>> Mark Andrews
>> 
>>> On 25 Aug 2018, at 05:02, Tom Pusateri  wrote:
>>> 
>>> 
>>> 
 On Aug 24, 2018, at 2:59 PM, Ted Lemon  wrote:
 
> On Aug 24, 2018, at 2:43 PM, Tom Pusateri  wrote:
> It seems odd to take the position that the authoritative server shouldn’t 
> need to clean up stale entries because it assumes the client will do it 
> for you. I can’t imagine you taking this position under any other 
> scenario.
 
 The issue here is that this is a pretty major change to the DNS.   If we 
 really want something this heavy, we should have a good reason for wanting 
 it.   That's all.
 
 The idea that some unnamed DHCP server somewhere doesn't do the right 
 thing with cleaning up stale entries doesn't seem like a good enough 
 reason, particularly given that the DHCID record tags the thing as having 
 been added by the DHCP server, and considering that there are several open 
 source implementations that do automatically delete records when the lease 
 expires.
 
 I think it might make sense to just wait on this.  I agree that it's an 
 interesting idea for completeness, but we don't have enough operational 
 experience yet to know whether we have a problem worth solving.   With 
 respect to the DHCP use case, I'm certain we don't.
 
 The good news is that if we do need this, you've done a design, and we 
 also have Paul's design to look at.   So if operational experience a few 
 years down the road shows us that we have a gap here, we can move on it 
 pretty easily. I just don't see any reason to rush into it.
>>> 
>>> Ok, great. Hopefully others have some use cases they can share. In the mean 
>>> time, back to learning Rust…
>>> 
>>> Thanks,
>>> Tom
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

> On Aug 24, 2018, at 3:46 AM, Mark Andrews  wrote:
> 
> This is unnecessary.  All the rule does is limit the process to class IN 
> zones.  UPDATE, IXFR and AXFR are class agnostic.
> 
> 1.  TIMEOUT resource records are only defined for CLASS IN.

Ok, we will make them applicable to all classes.

> 
> This seems overly restrictive.  I would allow TIMEOUT records that
> match added records to be accepted.
> 
> 5.  TIMEOUT resource records cannot be directly added, modified, or
>   deleted through DNS Update.

This restriction is another consequence of not being able to query TIMEOUT 
records. In order to allow UPDATE of TIMEOUT records, the client has to be able 
to retrieve the record and merge changes before UPDATING it. The server can’t 
do the merging or the record would change underneath the client that created it 
when another client added a record with the same owner name.

We haven’t been able to think of any significant downsides to allowing QUERY of 
TIMEOUT records and by doing so, it solves Joe’s issues so unless you can think 
of any, we’ll make that change in the next version and then be able to support 
UPDATE of TIMEOUT records.

> 
> Secondary servers that are TIMEOUT aware should ignore TIMEOUT records
> beyond storing them in case the server get promoted to being the master.
> 
> Is the secondary going to be able regenerate the RRset as the records are
> removed as well as generate and sign NSEC and NSEC3 records?

I would expect a secondary server to treat them the same as it does any other 
record type.

> 
> Sources of TIMEOUT Expiry Time
> 
> Add matching TIMEOUT records added via UPDATE.

Ok.

Thanks!

Tom

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

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

[Tom Pusateri]

Right, prefix delegation over DHCPv6 is a similar case that gets a prefix 
lifetime. I still use the WIDE dhcp6c client for PD and it has no means to 
update DNS. I haven’t found specific documentation from ISC DHCPv6 or KEA that 
describes creating DNS entries (PTR records) from delegated prefixes.

Tom

> On Aug 24, 2018, at 10:53 PM, Ted Lemon  wrote:
> 
> When would that happen?
> 
> On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews  > wrote:
> Registering slaac derived addresses in the DNS.  These are tied to prefix 
> lifetimes. 
> 
> 
> -- 
> Mark Andrews
> 
> On 25 Aug 2018, at 05:02, Tom Pusateri  > wrote:
> 
>> 
>> 
>>> On Aug 24, 2018, at 2:59 PM, Ted Lemon >> > wrote:
>>> 
>>> On Aug 24, 2018, at 2:43 PM, Tom Pusateri >> > wrote:
 It seems odd to take the position that the authoritative server shouldn’t 
 need to clean up stale entries because it assumes the client will do it 
 for you. I can’t imagine you taking this position under any other scenario.
>>> 
>>> The issue here is that this is a pretty major change to the DNS.   If we 
>>> really want something this heavy, we should have a good reason for wanting 
>>> it.   That's all.
>>> 
>>> The idea that some unnamed DHCP server somewhere doesn't do the right thing 
>>> with cleaning up stale entries doesn't seem like a good enough reason, 
>>> particularly given that the DHCID record tags the thing as having been 
>>> added by the DHCP server, and considering that there are several open 
>>> source implementations that do automatically delete records when the lease 
>>> expires.
>>> 
>>> I think it might make sense to just wait on this.  I agree that it's an 
>>> interesting idea for completeness, but we don't have enough operational 
>>> experience yet to know whether we have a problem worth solving.   With 
>>> respect to the DHCP use case, I'm certain we don't.
>>> 
>>> The good news is that if we do need this, you've done a design, and we also 
>>> have Paul's design to look at.   So if operational experience a few years 
>>> down the road shows us that we have a gap here, we can move on it pretty 
>>> easily. I just don't see any reason to rush into it.
>> 
>> Ok, great. Hopefully others have some use cases they can share. In the mean 
>> time, back to learning Rust…
>> 
>> Thanks,
>> Tom
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org 
>> https://www.ietf.org/mailman/listinfo/dnsop 
>> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

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

[Mark Andrews]

Named already has the ability to allow a machine within a /48 to insert/remove a
delegation at the /48 point using TCP to authenticate the update request.
I wrote the code to support this about the same time as Geoff Huston was looking
at setting up 6to4 reverse delegations.  He ended up going the HTTP to do it.
The code to do that works for any /48 for IPv6 connections.

https://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-02 is a fully fleshed
out example of how to do this but I couldn’t get even a request to adopt call 
from the DNSOP chairs when I presented it.  Can we stop leaving this in
limbo and move it forward?

Mark

> On 25 Aug 2018, at 2:18 pm, Tom Pusateri  wrote:
> 
> Right, prefix delegation over DHCPv6 is a similar case that gets a prefix 
> lifetime. I still use the WIDE dhcp6c client for PD and it has no means to 
> update DNS. I haven’t found specific documentation from ISC DHCPv6 or KEA 
> that describes creating DNS entries (PTR records) from delegated prefixes.
> 
> Tom
> 
>> On Aug 24, 2018, at 10:53 PM, Ted Lemon  wrote:
>> 
>> When would that happen?
>> 
>> On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews  wrote:
>> Registering slaac derived addresses in the DNS.  These are tied to prefix 
>> lifetimes. 
>> 
>> 
>> -- 
>> Mark Andrews
>> 
>> On 25 Aug 2018, at 05:02, Tom Pusateri  wrote:
>> 
>>> 
>>> 
 On Aug 24, 2018, at 2:59 PM, Ted Lemon  wrote:
 
 On Aug 24, 2018, at 2:43 PM, Tom Pusateri  wrote:
> It seems odd to take the position that the authoritative server shouldn’t 
> need to clean up stale entries because it assumes the client will do it 
> for you. I can’t imagine you taking this position under any other 
> scenario.
 
 The issue here is that this is a pretty major change to the DNS.   If we 
 really want something this heavy, we should have a good reason for wanting 
 it.   That's all.
 
 The idea that some unnamed DHCP server somewhere doesn't do the right 
 thing with cleaning up stale entries doesn't seem like a good enough 
 reason, particularly given that the DHCID record tags the thing as having 
 been added by the DHCP server, and considering that there are several open 
 source implementations that do automatically delete records when the lease 
 expires.
 
 I think it might make sense to just wait on this.  I agree that it's an 
 interesting idea for completeness, but we don't have enough operational 
 experience yet to know whether we have a problem worth solving.   With 
 respect to the DHCP use case, I'm certain we don't.
 
 The good news is that if we do need this, you've done a design, and we 
 also have Paul's design to look at.   So if operational experience a few 
 years down the road shows us that we have a gap here, we can move on it 
 pretty easily. I just don't see any reason to rush into it.
>>> 
>>> Ok, great. Hopefully others have some use cases they can share. In the mean 
>>> time, back to learning Rust…
>>> 
>>> Thanks,
>>> Tom
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> ___
>> 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