[DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-23.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : A Common Operational Problem in DNS Servers - Failure 
To Communicate
Authors : M. Andrews
  Ray Bellis
Filename: draft-ietf-dnsop-no-response-issue-23.txt
Pages   : 26
Date: 2020-04-16

Abstract:
   The DNS is a query / response protocol.  Failing to respond to
   queries, or responding incorrectly, causes both immediate operational
   problems and long term problems with protocol development.

   This document identifies a number of common kinds of queries to which
   some servers either fail to respond or else respond incorrectly.
   This document also suggests procedures for zone operators to apply to
   identify and remediate the problem.

   The document does not look at the DNS data itself, just the structure
   of the responses.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-23
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-no-response-issue-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-23


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [DNSOP] Doodle poll for DNSOP WG interim 23 April 2020

[Benno Overeinder]

Gentle reminder.  Poll closes today.

https://doodle.com/poll/zk9f4ur7fycz3kra

Thank you,

Suzanne, Tim and Benno


On 14/04/2020 18:26, Benno Overeinder wrote:
> Dear DNSOP WG,
> 
> Thank you for your time and participation in the DNSOP WG meeting today.
> 
> The next DNSOP WG interim meeting is scheduled for April 23 and will be
> a one hour virtual meeting.  To select a timeslot, we again created a
> doodle poll:
> 
> https://doodle.com/poll/zk9f4ur7fycz3kra
> 
> Please fill in the doodle before the end of Thursday (April 16).
> 
> 
> Thank you,
> 
> Suzanne, Tim and Benno
> 
> ___
> 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] Fwd: [EXT] New Version Notification for draft-toorop-dnsop-dns-catalog-zones-01.txt

[Bob Harold]

On Wed, Apr 15, 2020 at 5:27 AM Willem Toorop  wrote:

> Dear all,
>
> This is the new catalog zones draft as presented yesterday at the DNSOP WG
> Interim meeting. The idea of catalog zones is to establish automatic zone
> provisioning along existing primary/secondary relationships.
> This is an earlier idea which was previously worked on by ISC authors. The
> editor's pen has been picked up by authors from different DNS Software
> implementations with the aim to create a cross-implementation compatible
> version of catalog zones.
> Most prominent modifications to earlier versions are:
>
>1. There are descriptions nor definitions of zone properties anymore
>2. A zone is required to reset state when its unique label changes
>3. The version TXT RR now can be a RRset to allow for versions that
>are backwards compatible with earlier versions.
>
> Willem
>
>  Doorgestuurd bericht 
> Onderwerp: [EXT] New Version Notification for
> draft-toorop-dnsop-dns-catalog-zones-01.txt
> Datum: Tue, 14 Apr 2020 04:02:23 -0700
> Van: internet-dra...@ietf.org
> Aan: Ondrej Sury  , Libor Peltan
>  , Peter van Dijk
>  , Willem
> Toorop  , Leo Vandewoestijne
>  
>
> A new version of I-D, draft-toorop-dnsop-dns-catalog-zones-01.txt
> has been successfully submitted by Willem Toorop and posted to the
> IETF repository.
>
> Name: draft-toorop-dnsop-dns-catalog-zones
> Revision: 01
> Title: DNS Catalog Zones
> Document date: 2020-04-14
> Group: Individual Submission
> Pages: 11
> URL:
> https://www.ietf.org/internet-drafts/draft-toorop-dnsop-dns-catalog-zones-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
> Htmlized:
> https://tools.ietf.org/html/draft-toorop-dnsop-dns-catalog-zones-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-toorop-dnsop-dns-catalog-zones
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-toorop-dnsop-dns-catalog-zones-01
>
> Abstract:
> This document describes a method for automatic DNS zone provisioning
> among DNS primary and secondary nameservers by storing and
> transferring the catalog of zones to be provisioned as one or more
> regular DNS zones.
>
>
5.1.  General Requirements

If there is a clash between an existing member zone's name and an
   incoming member zone's name (via transfer or update), the new
   instance of the zone MUST be ignored and an error SHOULD be logged.

-- I do not understand.  Can you give an example?

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

Re: [DNSOP] On Powerbind

[Vittorio Bertola]

> Il 15/04/2020 02:24 Paul Wouters  ha scritto:
> 
> And we might disagree about the value of enforcment. But as I tried
> to explain during the meeting, the value added is not for our little
> community of engineers that trust each other. It is for people at large
> to not need to trust some cabal and who do not trust ICANN, Verisign
> or the USG. 

Personally, I do not have a strong opinion on this draft - if some people want 
it, why not. However I am a bit perplexed by this kind of motivation, as it 
seems misinformed on the current state of governance arrangements around the 
DNS. For example, the USG has been out of the loop for a while, though the .org 
quarrel has shown interesting ways in which the General Attorney of California 
can get back into it as long as ICANN is still incorporated there.

Also, I don't completely get why anyone would want to use a domain name in a 
TLD whose operator they distrust so much that they think that the operator 
could attack the zones it delegated. I see better value in the proposal as a 
way to counter potential attacks to delegated zones that could happen if the 
operator were ever compromised.

Anyway, I have a preemptive bikeshedding request: if this thing proceeds, 
please find another name that does not sound like a confusing portmanteau of 
two of the most widely used resolver implementations :-)

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

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

Re: [DNSOP] Fwd: [EXT] New Version Notification for draft-toorop-dnsop-dns-catalog-zones-01.txt

[Willem Toorop]

Op 16-04-2020 om 14:37 schreef Bob Harold:
> On Wed, Apr 15, 2020 at 5:27 AM Willem Toorop  > wrote:
> 
> Dear all,
> 
> This is the new catalog zones draft as presented yesterday at the
> DNSOP WG Interim meeting. The idea of catalog zones is to establish
> automatic zone provisioning along existing primary/secondary
> relationships.
> 
> This is an earlier idea which was previously worked on by ISC
> authors. The editor's pen has been picked up by authors from
> different DNS Software implementations with the aim to create a
> cross-implementation compatible version of catalog zones.
> Most prominent modifications to earlier versions are:
> 
>  1. There are descriptions nor definitions of zone properties anymore
>  2. A zone is required to reset state when its unique label changes
>  3. The version TXT RR now can be a RRset to allow for versions that
> are backwards compatible with earlier versions.
> 
> Willem
> 
>  Doorgestuurd bericht 
> Onderwerp:[EXT] New Version Notification for
> draft-toorop-dnsop-dns-catalog-zones-01.txt
> Datum:Tue, 14 Apr 2020 04:02:23 -0700
> Van:  internet-dra...@ietf.org 
> Aan:  Ondrej Sury  , Libor
> Peltan  , Peter van
> Dijk 
> , Willem Toorop
>  , Leo
> Vandewoestijne  
> 
> 
> 
> A new version of I-D, draft-toorop-dnsop-dns-catalog-zones-01.txt
> has been successfully submitted by Willem Toorop and posted to the
> IETF repository.
> 
> Name: draft-toorop-dnsop-dns-catalog-zones
> Revision: 01
> Title: DNS Catalog Zones
> Document date: 2020-04-14
> Group: Individual Submission
> Pages: 11
> URL:
> 
> https://www.ietf.org/internet-drafts/draft-toorop-dnsop-dns-catalog-zones-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
> Htmlized:
> https://tools.ietf.org/html/draft-toorop-dnsop-dns-catalog-zones-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-toorop-dnsop-dns-catalog-zones
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-toorop-dnsop-dns-catalog-zones-01
> 
> Abstract:
> This document describes a method for automatic DNS zone provisioning
> among DNS primary and secondary nameservers by storing and
> transferring the catalog of zones to be provisioned as one or more
> regular DNS zones.
> 
> 
> 5.1..  General Requirements
> 
> If there is a clash between an existing member zone's name and an
>    incoming member zone's name (via transfer or update), the new
>    instance of the zone MUST be ignored and an error SHOULD be logged.
> 
> -- I do not understand.  Can you give an example?

An authoritative nameserver might have two or more catalog zones, each
associated with their own set of configuration.  In that case, the
member zone that was configured first (and associated with the settings
of the particular catalog zone it was a member of) will keep that
association, regardless of it being a member zone of other catalog zones
as well.


-- Willem

> 
> -- 
> Bob Harold
>  
> 
> ___
> 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] Fwd: [EXT] New Version Notification for draft-toorop-dnsop-dns-catalog-zones-01.txt

[Richard Gibson]

Doesn't that preclude scenarios in which a zone transitions from one 
catalog to another?


On 4/16/20 09:17, Willem Toorop wrote:

An authoritative nameserver might have two or more catalog zones, each
associated with their own set of configuration.  In that case, the
member zone that was configured first (and associated with the settings
of the particular catalog zone it was a member of) will keep that
association, regardless of it being a member zone of other catalog zones
as well.


-- Willem


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

Re: [DNSOP] Fwd: [EXT] New Version Notification for draft-toorop-dnsop-dns-catalog-zones-01.txt

[Willem Toorop]

Op 16-04-2020 om 16:05 schreef Richard Gibson:
> Doesn't that preclude scenarios in which a zone transitions from one
> catalog to another?

Not necessarily, but we do need to provide more text here to describe
precisely how that would work yes. So thanks for bringing that up!

Something like:

When a member zone is removed from a specific catalog zone, an
authoritative server MUST NOT remove the zone and associated state data
if the zone was not configured from that specific catalog zone.
Only when the zone was configured from a specific catalog zone, and the
zone is removed as a member from that specific catalog zone, the zone
and associated state MUST be removed.
Subsequently, after removal, an implementation MUST check if another
catalog zone is present with has the zone as a member. In that case the
zone must be configured and associated according to the set of
configuration associated with that catalog zone.
If there are multiple other catalog zones which have the previously
removed zone as member, one should be picked randomly.

This is just a quick sketch text proposal.
I've submitted an issue for it in our github repo:

https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/issues/9

-- Willem

> 
> On 4/16/20 09:17, Willem Toorop wrote:
>> An authoritative nameserver might have two or more catalog zones, each
>> associated with their own set of configuration.  In that case, the
>> member zone that was configured first (and associated with the settings
>> of the particular catalog zone it was a member of) will keep that
>> association, regardless of it being a member zone of other catalog zones
>> as well.
>>
>>
>> -- Willem

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

Re: [DNSOP] On Powerbind

[Warren Kumari]

On Tue, Apr 14, 2020 at 10:39 PM Ben Schwartz
 wrote:
>
> Thanks for the explanation, Paul.  Overall, I agree that Powerbind seems 
> low-risk, so I don't mind it being available for people who care about it.

Just checking - the DNSKEY Flags field is 16 bits, and we have so far burned:
Bit 15 - SEP
Bit 7 - Zone key
Bit 8 - Revoked
Did I miss any (I wasn't able to find a registry for this)?

If not, we still have 13 bits left, and so using one for this seems ok
to me, especially if recursives doing something with it is optional...
(I had mistakenly remembered the Flags as being only 8 bits)
I'm still not convinced that DNSSEC Transparency will come to pass,
nor that many zones will use this flag, but I'm now much more sanguine
about giving it a bit...

W


>
> The strongest argument I can think of for Powerbind is that it prevents a 
> certain class of accidental misconfigurations for delegation-only zones.
>
> It also might enable a reduction in how much labor is required to maintain a 
> DNSSEC transparency system, by providing some partial automation.  This 
> requires some assumptions about DNSSEC transparency that are not yet obvious.
>
> On Tue, Apr 14, 2020 at 8:24 PM Paul Wouters  wrote:
>>
>> On Tue, 14 Apr 2020, Ben Schwartz wrote:
>>
>> >   The point of powerbind is to specifically state "I'm delegation 
>> > only".
>> >   Without knowledge of that, you end up having to log everything, per 
>> > your
>> >   own conclusion, because there is no way to know if its a 
>> > delegation-only
>> >   zone.
>> >
>> > I'm still not able to understand this.  Suppose nic.footld puts a 
>> > statement for humans on their website that says
>> > ".footld promises to be delegation-only".
>>
>> First, this approach does not work. Not all TLD's have the ICANN mandated
>> nic.. There is no standard on how to publish this information. There
>> is a chicken and egg problem getting to the website. You have to parse
>> this data. Get the mimetype right. Website outages would be problematic.
>> Website could be blocked to prevent reading the text. What is the expiry
>> date of this data? Look at the various security "web canaries" that have
>> been put up. They all fail to be maintained. And if anything Public Suffix
>> has shown us this kind of data cannot be tracked properly outside the
>> DNS. A few drafts have even attempted to pull in public suffix into some
>> DNS record type because of this. If there is no link between the statement
>> and the policy, they will diverge over time and cause false positives.
>
>
> I actually agree: PSL should live in the DNS, because it is entirely the zone 
> owner's decision whether they want PSL behavior.  However, DNSSEC 
> transparency logging _cannot_ be controlled by the DNS, because log operators 
> must decide for themselves which zones they are willing to log.  Otherwise 
> they become arbitrary data storage systems for anyone in the world.
>
> Powerbind would allow a log operator to say "I will log any delegation-only 
> TLD".  I think any practical log will still need manual intervention to add 
> cases like .co.uk, and perhaps also to remove delegation-only TLDs that 
> nonetheless exhibit spammy behavior, but overall Powerbind still saves some 
> amount of labor in that case.  I tend to think that a log operator could 
> already just log everything in all the TLDs, delegation-only or not, but I 
> don't have the data to prove it.
>
>> Second, with powerbind, you don't have to do a poor man's "after the
>> fact" protection. You can mark violating data as BOGUS and prevent it
>> from being accepted as valid before harm has been done. It's more than
>> just a post-mortem that Certificate Transparency offers for the WebPKI.
>
>
> I don't agree with this characterization.  A hostile or compromised TLD can 
> just as easily impersonate its children with Powerbind as without.
>
>> A third minor advantage is that setting this bit could become part of
>> the IANA/ICANN process for current and new gTLDs. It would then prevent
>> these entities from misusing/abusing their TLD zone in the future.
>
>
> As above, it would not.
>
>>
>> For
>> example to do "sitefinder" type wildcard matching.
>
>
> This is still possible with Powerbind, using online signing or NSEC3 opt-out.
>
>>
>> And this would get
>> free enforcement via validating resolvers.
>>
>> >   As the first sentence in the abstract says "This document
>> >   introduces a new DNSKEY flag called DELEGATION_ONLY that indicates 
>> > that
>> >   the particular zone will never sign zone data across a label.".  IE, 
>> > the
>> >   whole point is to communicate that a zone is such a zone.
>> >
>> > This seems like it can easily be communicated just to humans, manually 
>> > enabling logging for each zone of
>> > interest.  Since only the TLDs and similar zones are really of any 
>> > interest for logging, manually maintaining a
>> > list of zones to log is not difficult.
>>
>> Public suffix has 

Re: [DNSOP] On Powerbind

[Dick Franks]

Warren,

Comments in line

On Thu, 16 Apr 2020 at 20:31, Warren Kumari  wrote:
>8

> Just checking - the DNSKEY Flags field is 16 bits, and we have so far burned:
> Bit 15 - SEP
> Bit 7 - Zone key
> Bit 8 - Revoked
> Did I miss any (I wasn't able to find a registry for this)?
>
> If not, we still have 13 bits left, and so using one for this seems ok
> to me, especially if recursives doing something with it is optional...
> (I had mistakenly remembered the Flags as being only 8 bits)
> I'm still not convinced that DNSSEC Transparency will come to pass,
> nor that many zones will use this flag, but I'm now much more sanguine
> about giving it a bit...
>

The lack(?) of a registry is indeed regrettable.

However, there seems to be some historical meaning attached to some of
the other flag bits.

If I look back at Net::DNS::SEC 0.17, bequeathed to me by one Olaf
Kolkman, the DS create() method contains the following mysterious
(perl) lines, for which I can offer no coherent explanation:

# The key must not be a NULL key.
if (($keyrr->{"flags"} & hex("0xc000") ) == hex("0xc000") ){
croak "\nCreating a DS record for a NULL key is illegal";
}

# Bit 0 must not be set.
if (($keyrr->{"flags"}) & hex("0x8000")) {
croak "\nCreating a DS record for a key with flag bit 0 set ".
"to 0 is illegal";
}

# Bit 6 must be set to 0 bit 7 must be set to 1
if ( ($keyrr->{"flags"} & hex("0x300")) != hex("0x100")){
croak "\nCreating a DS record for a key with flags 6 and 7 not set ".
"0  and 1 respectively is illegal";
}

which would seem to indicate that some of the other bits were thought
to have some meaning circa 2013.

Perhaps Olaf can shed some light on this topic.


Dick Franks


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