[DNSOP] inputs on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment

[JORDI PALET MARTINEZ]

Hi all,

(dnsop copied because DNS64)

I'm working in a new version of this document.

Link to the document:

https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/

It will be great if we can get some new inputs.

Thanks!

Regards,
Jordi
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

[Dick Franks]

On Wed, 20 Feb 2019 at 11:27, Petr Špaček  wrote:
8<

> Yet another code propodsl:
> * answer with stale data
>
>The resolver was unable to resolve answer within its time limits and
>decided to answer with stale data instead of answering with an error.
>This is typically caused by problems on authoritative side, possibly
>as result of an DoS attack. Retrying is likely to cause load and not
>yield a fresh answer, RETRY=0.
>
> Here is a problem that this code point is applicable to NOERROR as well
> as NXDOMAIN answers so I'm not sure how to categorize it. This
> reinforces my unanswered question why the draft proposes to copy RCODE
> into EDE.
>

This seems to be a good argument in favour of a one-dimensional error table..

--Dick
___
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]

> On 21 Feb 2019, at 6:30 am, Tony Finch  wrote:
> 
> Mark Andrews  wrote:
>> 
>> All that is missing is the automated cleanup.  DNS servers are quite
>> capable of doing that once specified how.
> 
> Does it need to be per-record? Why not GC the whole RRset?

Because there are scenarios where you do want to GC as single
record from the RRset. AD has them with SRV.  Each server adds
its own SRV record to the RRset.  When a server goes away without
cleaning up you want the SRV to go but the RRset to remain.

A machine has permanent and time limited addresses.

I’m sure there will be other cases where you want selective deletion
from a RRset.

Mark

> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Fair Isle: Southwesterly 5 or 6, occasionally 7 later in west. Moderate or
> rough, occasionally very rough at first in west. Rain. Good, occasionally
> moderate.

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

Tony Finch wrote on 2019-02-20 11:30:

Mark Andrews  wrote:


All that is missing is the automated cleanup.  DNS servers are quite
capable of doing that once specified how.


Does it need to be per-record? Why not GC the whole RRset?


+1. this is what DEFUPD did.

(https://datatracker.ietf.org/doc/draft-ietf-dnsind-defupd/)

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

[Tony Finch]

Mark Andrews  wrote:
>
> All that is missing is the automated cleanup.  DNS servers are quite
> capable of doing that once specified how.

Does it need to be per-record? Why not GC the whole RRset?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fair Isle: Southwesterly 5 or 6, occasionally 7 later in west. Moderate or
rough, occasionally very rough at first in west. Rain. Good, occasionally
moderate.

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

Joe, look at active directory. The names in the DNS are garbage cleaned by 
undocumented processes that prevent UPDATE being used to manage the “static” 
content. 

You have registering  and PTR records with SLAAC. You don’t want stale 
records to continue to exist in the zones. You will be sent to the wrong 
machine () or the zone will become a garbage dump of stale records (PTR).   
But until the support is there you can’t safely do this. 

Today you can use SIG(0) to register your  records and use TCP to 
authenticate PTR  additions to the DNS zones. All that is missing is the 
automated cleanup.  DNS servers are quite capable of doing that once specified 
how.   DHCP servers mostly do this for IPv4 but even that is problematic.  
Records still get left behind because there was a communication failure at 
lease expiry / release. 

DNS-SD has the same issues. Garbage collection. 

You also need it as standards track so people won’t think it is something that 
is going away and to encourage everyone who implements UPDATE to support it.  
Clients and servers. 
-- 
Mark Andrews

> On 20 Feb 2019, at 23:51, Joe Abley  wrote:
> 
>> On 20 Feb 2019, at 00:35, 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 occurance.
> 
> I agree.
> 
> The crux of the use case seems to be that it is commonplace for names in the 
> DNS to exist for short periods of time and that for some applications a name 
> that overstays its welcome can cause an operational problem.
> 
> While I can understand the philosophical desire to complete the UPDATE 
> specification so that it is possible to engineer around this scenario, I 
> don't see the practical application. The existence of the requirement in the 
> first place seems unproven (at least there are no obvious examples given); 
> the scenario in which the purported operational problem arises seems likely 
> to be rare; workarounds surely exist and, really, the damage in the event 
> that the stars align and a temporary name does persist seems very low.
> 
> If the goal is to try this out and have no impact on existing implementations 
> (e.g. there is some side code that is imagined that will poll a transferred 
> zone for TIMEOUT records and do local UPDATEs in order to remove RRSets that 
> should not be there) then all that is really needed here is a code point for 
> the TIMEOUT RR. The existence of the draft is nice since documentation is 
> good, but I think "experimental" would be a better target than "standards 
> track". It's surely possible that this mechanism will solve some as-yet 
> unnoticed, large-scale problem and will one day be considered essential 
> functionality, but I don't think we're there today. There be camels.
> 
> 
> Joe
> 
> ___
> 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] Two Resurrected WG I-Ds: Don't Switch Resolvers & Auth DNS Mistakes

[Livingood, Jason]

A few years ago I had somehow succeeded in getting WG adoption of 2 documents 
that addressed some pet peeves I had as a recursive DNS operator. Things got 
busy and my attention wandered elsewhere and I did not advance them. Since 
these issues continue to haunt RDNS operators, I have decided to update these 
documents. The first says that DNSSEC errors (and other auth RR issues) are the 
operational responsibility of and must be solved by auth DNS admins. The second 
says that people should not change to non-validating resolvers when a DNSSEC 
failure occurs. Both are likely obvious to us in the WG, but no so much to 
anyone else. ;-)

Just a week or so ago, Windows Update started to fail seemingly due to a bad 
delegation to a CDN from Microsoft and the TTL on the bad RR was long-ish 
(details are scant). So reporters and even Microsoft support started suggesting 
that people change their DNS resolvers. Only later did people figure out the 
problem was on Microsoft’s auth DNS end (see 
https://www.zdnet.com/article/windows-update-problems-fixed-now-but-heres-what-went-wrong-says-microsoft/
 and 1st story at 
https://www.zdnet.com/article/windows-10-updates-are-broken-again-but-this-time-its-not-microsofts-fault/).
 And we also see the issue of “DNSSEC validation failed, so switch to a 
non-validator” on a regular basis.

So I just submitted these again / updated them. I have asked the WG chairs to 
let me know how they’d like me to proceed with them, but haven’t yet heard 
back. In the meantime, I’m happy to continue to once again take input and 
comment from the WG.

https://datatracker.ietf.org/doc/draft-livingood-dnsop-dont-switch-resolvers/
https://datatracker.ietf.org/doc/draft-livingood-dnsop-auth-dnssec-mistakes/

Thanks!
Jason
___
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 Wed, 20 Feb 2019 at 12:36, Tony Finch  wrote:

> Dick Franks  wrote:
> >
> > Unsigned 32 bit RRSIG time is good for travel until 7th February 2106.
>
> No, it lasts indefinitely. It covers +/- 68 years relative to current
> POSIX time using serial number arithmetic.
>

The value is  ( t - Jan1970 ) mod 2**32,  for any integer t,   which is
certainly
not relative to current time, always positive, and I agree lasts
indefinitely.
The point I was trying to make was that the wrapping occurs in 2106,
not 2038 as some have claimed.
RFC1982 serial number arithmetic is mandated for comparison of these values,
not for defining the values themselves.


[RFC4034] 3.1.5.  Signature Expiration and Inception Fields

   The Signature Expiration and Inception fields specify a validity
   period for the signature.  The RRSIG record MUST NOT be used for
   authentication prior to the inception date and MUST NOT be used for
   authentication after the expiration date.

   The Signature Expiration and Inception field values specify a date
   and time in the form of a 32-bit unsigned number of seconds elapsed
   since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
   byte order.  The longest interval that can be expressed by this
   format without wrapping is approximately 136 years.  An RRSIG RR can
   have an Expiration field value that is numerically smaller than the
   Inception field value if the expiration field value is near the
   32-bit wrap-around point or if the signature is long lived.  Because
   of this, all comparisons involving these fields MUST use "Serial
   number arithmetic", as defined in [RFC1982].  As a direct
   consequence, the values contained in these fields cannot refer to
   dates more than 68 years in either the past or the future.
___
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

[Ted Lemon]

On Feb 20, 2019, at 4:51 AM, Joe Abley  wrote:
> The crux of the use case seems to be that it is commonplace for names in the 
> DNS to exist for short periods of time and that for some applications a name 
> that overstays its welcome can cause an operational problem.
> 
> While I can understand the philosophical desire to complete the UPDATE 
> specification so that it is possible to engineer around this scenario, I 
> don't see the practical application. The existence of the requirement in the 
> first place seems unproven (at least there are no obvious examples given); 
> the scenario in which the purported operational problem arises seems likely 
> to be rare; workarounds surely exist and, really, the damage in the event 
> that the stars align and a temporary name does persist seems very low.
> 
> If the goal is to try this out and have no impact on existing implementations 
> (e.g. there is some side code that is imagined that will poll a transferred 
> zone for TIMEOUT records and do local UPDATEs in order to remove RRSets that 
> should not be there) then all that is really needed here is a code point for 
> the TIMEOUT RR. The existence of the draft is nice since documentation is 
> good, but I think "experimental" would be a better target than "standards 
> track". It's surely possible that this mechanism will solve some as-yet 
> unnoticed, large-scale problem and will one day be considered essential 
> functionality, but I don't think we're there today. There be camels.

The goal of this is to automate name publication for situations where this is 
desirable.   You’re probably not going to use this for your public servers.   
See https://tools.ietf.org/html/draft-ietf-dnssd-srp-00 
 (expired, but we’ll be 
submitting an update soon).

I say this not to specfically support this proposal, which I think has 
problems, but simply to point out that there is an itch here to scratch.   I 
don’t think this is something that we need in every different kind of DNS 
server, but something like this could definitely be useful in some operational 
situations.   Of course it can be done out of band, but there’s something to be 
said for keeping all the state in one place.   I don’t have enough operational 
experience with this yet to have formed a preference.

___
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

[Joe Abley]

On 20 Feb 2019, at 00:35, 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 occurance.

I agree.

The crux of the use case seems to be that it is commonplace for names in the 
DNS to exist for short periods of time and that for some applications a name 
that overstays its welcome can cause an operational problem.

While I can understand the philosophical desire to complete the UPDATE 
specification so that it is possible to engineer around this scenario, I don't 
see the practical application. The existence of the requirement in the first 
place seems unproven (at least there are no obvious examples given); the 
scenario in which the purported operational problem arises seems likely to be 
rare; workarounds surely exist and, really, the damage in the event that the 
stars align and a temporary name does persist seems very low.

If the goal is to try this out and have no impact on existing implementations 
(e.g. there is some side code that is imagined that will poll a transferred 
zone for TIMEOUT records and do local UPDATEs in order to remove RRSets that 
should not be there) then all that is really needed here is a code point for 
the TIMEOUT RR. The existence of the draft is nice since documentation is good, 
but I think "experimental" would be a better target than "standards track". 
It's surely possible that this mechanism will solve some as-yet unnoticed, 
large-scale problem and will one day be considered essential functionality, but 
I don't think we're there today. There be camels.


Joe

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

Dick,

> On 20. Feb 2019, at 13:35, Tony Finch  wrote:
> 
> Dick Franks  wrote:
>> 
>> Unsigned 32 bit RRSIG time is good for travel until 7th February 2106.
> 
> No, it lasts indefinitely. It covers +/- 68 years relative to current
> POSIX time using serial number arithmetic.

you might want to give RFC 1982 a read... I got that wrong before, too ;-)

Tim

smime.p7s
Description: S/MIME cryptographic signature
___
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]

Dick Franks  wrote:
>
> Unsigned 32 bit RRSIG time is good for travel until 7th February 2106.

No, it lasts indefinitely. It covers +/- 68 years relative to current
POSIX time using serial number arithmetic.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shannon, Rockall: South 6 to gale 8. Rough or very rough, becoming very rough
or high. Occasional rain or drizzle. Good, occasionally poor.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

[Petr Špaček]

On 07. 02. 19 16:47, Petr Špaček wrote:
> --- New code points ---
> 
> I propose to add couple more codes:

Yet another code propodsl:
* answer with stale data

   The resolver was unable to resolve answer within its time limits and
   decided to answer with stale data instead of answering with an error.
   This is typically caused by problems on authoritative side, possibly
   as result of an DoS attack. Retrying is likely to cause load and not
   yield a fresh answer, RETRY=0.

Here is a problem that this code point is applicable to NOERROR as well
as NXDOMAIN answers so I'm not sure how to categorize it. This
reinforces my unanswered question why the draft proposes to copy RCODE
into EDE.

-- 
Petr Špaček  @  CZ.NIC

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