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

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

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

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

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

> 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

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

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

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

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:

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

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

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

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,

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

> 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 >>

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

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 >>

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

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

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

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

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

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,

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

> 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 >>

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

> 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

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

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

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

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

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

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

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

> > 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 >

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

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,

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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