Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Amreesh Phokeer]

On Wed, May 2, 2018 at 11:47 PM, Edward Lewis 
wrote:
>
>
> If I can't find the text soon, I'll try to recreate the list of references
> at least.
>

We are in process of implementing a "Lame delegations" policy at AFRINIC


We consider "lame" any NS which is either:
- Not responding at all.
- Responding in some way, but not for the specific domain queried.
- Responding for the correct domain, but without the authority bit set.

We used the definition in RFC1713:

A lame delegation is a serious error in DNS configurations, yet a
   (too) common one.  It happens when a name server is listed in the NS
   records for some domain and in fact it is not a server for that
   domain.  Queries are thus sent to the wrong servers, who don't know
   nothing (at least not as expected) about the queried domain.
   Furthermore, sometimes these hosts (if they exist!) don't even run
   name servers.  As a result, queries are timed out and resent, only to
   fail, thus creating (more) unnecessary traffic.


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

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Ondřej Surý]

> On 26 Mar 2018, at 16:47, Jim Reid  wrote:
> 
> On 24 Mar 2018, at 20:20, Ondřej Surý  wrote:
>> 
>>> It might be a different story if one of those zombie RRtypes required 
>>> additional processing. None spring to mind though.
>> 
>> But (most of) those I picked actually *DO*:
>> 
>> a) compression is allowed, so compliant and non-compliant servers can’t 
>> speak together, because non-compliant will just store junk in the RDATA when 
>> received from compliant server;
>> b) the RDATA needs to be understood and lowercased for canonical form when 
>> DNSSEC signing; again you need to *implement* this in DNSSEC Validator as it 
>> would cause validation failures if you don't
> 
> Fair enough Ondřej. Though I suspect the number of servers that sign or 
> validate MAILA records  (or whatever) can be counted on the number of ears on 
> one hand. :-)

On a sunny day, while casually strolling the BIND source code, I found this:

case dns_rdatatype_maila:
case dns_rdatatype_mailb:
query_error(client, DNS_R_NOTIMP, __LINE__);
return;

So, again, making this _official_ and actually obsolete types that even BIND 
doesn’t implement, somehow still makes sense to me.

Ondrej
--
Ondřej Surý
ond...@isc.org

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

[DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

[Geoff Huston]

Hi WG Chairs (and WG)

We have submitted -12 of this draft which we believe incorperates the 
substantive review comments made during the WG Last Call period that were 
posted to the WG Mailing List.
> 
> Editors: Please take “concern about a description of current implementation 
> status” as WGLC input, and consider what you might be able to add to the 
> draft to address it. 

We have also taken the implementation comments posted to the WG mailing list 
and collected them in a new section titled "Implementation Experience” in the 
light of Suzanne’s request

So we would like to pass this draft back to the WG Chairs at this point for 
your review for potential submission as an RFC.

Thanks,

 Geoff (for co-editors Joao and Warren)

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

[DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-12.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 Root Key Trust Anchor Sentinel for DNSSEC
Authors : Geoff Huston
  Joao Silva Damas
  Warren Kumari
Filename: draft-ietf-dnsop-kskroll-sentinel-12.txt
Pages   : 17
Date: 2018-05-03

Abstract:
   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be verified by building a
   chain of trust starting from a trust anchor and proceeding down to a
   particular node in the DNS.  This document specifies a mechanism that
   will allow an end user and third parties to determine the trusted key
   state for the root key of the resolvers that handle that user's DNS
   queries.  Note that this method is only applicable for determining
   which keys are in the trust store for the root key.

   There is an example / toy implementation of this at http://www.ksk-
   test.net .

   [ This document is being collaborated on in Github at:
   https://github.com/APNIC-Labs/draft-kskroll-sentinel.  The most
   recent version of the document, open issues, etc should all be
   available here.  The authors (gratefully) accept pull requests.  Text
   in square brackets will be removed before publication. ]

   [ NOTE: This version uses the labels "root-key-sentinel-is-ta-", and
   "root-key-sentinel-not-ta-".; older versions of this document used
   "kskroll-sentinel-is-ta-", "kskroll-sentinel-not-ta-", and before that, "_is-ta-", "_not-ta-".
   Also note that the format of the tag-index is now zero-filled
   decimal.  Apologies to those who have begun implementing earlier
   versions of this specification.]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-12
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-12


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] draft-ietf-dnsop-kskroll-sentinel-12

[Ralph Dolmans]

Hi,

On 03-05-18 10:15, Geoff Huston wrote:
> We have also taken the implementation comments posted to the WG mailing list 
> and collected them in a new section titled "Implementation Experience” in the 
> light of Suzanne’s request

This draft is by now implemented in Unbound and is in version 1.7.1
which we just released. I didn't find deficiencies in the latest version
of the draft that would hinder implementation.

I like to second Ondrej's earlier remark that from an implementors point
making an implementation for an early draft makes little sense, which is
why we waited until now. We need a somewhat stable specification before
we make code that will be used in the real world to prevent pollution
and in this case would make it even harder to do proper measurements.

-- Ralph

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

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[David Huberman]

Ed Lewis wrote:

> (Only if you like reading history:)
   
> The reason was a flaw in "certain old resolvers" that followed the "upwards 
> referral" to the root that 
> the "predominate server code of the time" had decided to use for lameness..  
> The result was a lot of 
> resolver stuck in an infinite loop, hitting the root servers.  I.e., this was 
> an operational issue.  The 
> solution was updating and redeploying the buggy code, not stamping out lame 
> servers (which was 
> the goal of the task).  FWIW, the "upwards referrals" were discontinued when 
> it became apparent 
> they were being used in noticeable amplification attacks.
  
I sat on the front lines of ARIN’s war against lame delegations for the entire 
war.  We spent quite a few
years testing delegations for our definition of lameness, and then notifying 
the listed tech-c and admin-c.
E-mail recipients would either ignore the email, not understand the email and 
move on to the next thing,
or would write-in or call-in and speak to either me or my co-worker Jon Worley. 
Very few lame delegations
were fixed, even among those who called-in or wrote-in for clarification.  rDNS 
worked for the user, and
they weren’t willing to change anything.

The war was unwinnable. 

/david 


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

[Paul Vixie]

what are the implications for older (pre-KSKROLL) validators when icann 
eventually rolls the key?


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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

[Paul Hoffman]

On 3 May 2018, at 10:06, Paul Vixie wrote:

what are the implications for older (pre-KSKROLL) validators when 
icann eventually rolls the key?


None. That is, they will either be ready or they won't be, and this 
draft doesn't change that. This draft is about signaling, not about 
actually being ready for a roll.


--Paul Hoffman

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

[Paul Vixie]

Geoff Huston wrote:



On 4 May 2018, at 3:06 am, Paul Vixie  wrote:

what are the implications for older (pre-KSKROLL) validators when
icann eventually rolls the key?


I assume that you are referring to security-aware resolvers that do
not perform the actions specified in this draft. There are no
implications at all for these resolvers.

Any trusted key measurement conducted using such a resolver will show
that the resolver is a security-aware resolver, but is not performing
the sentinel method.


thanks. i feared for a moment a second TCR.

--
P Vixie

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

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Mark Andrews]

It’s amazing how fast people can fix lame delegations once email and other 
services stop flowing. The only reason you think it is un- winnable is that you 
are unwilling to remove the delegation for failing to maintain a properly 
working configuration. 

Start removing lame delegation after fair warnings and you will see others 
fixing their lame delegations on initial notice.  No system works if there are 
not checks and balances.
-- 
Mark Andrews

> On 4 May 2018, at 01:05, David Huberman  wrote:
> 
> Ed Lewis wrote:
> 
>> (Only if you like reading history:)
> 
>> The reason was a flaw in "certain old resolvers" that followed the "upwards 
>> referral" to the root that 
>> the "predominate server code of the time" had decided to use for lameness..  
>> The result was a lot of 
>> resolver stuck in an infinite loop, hitting the root servers.  I.e., this 
>> was an operational issue.  The 
>> solution was updating and redeploying the buggy code, not stamping out lame 
>> servers (which was 
>> the goal of the task).  FWIW, the "upwards referrals" were discontinued when 
>> it became apparent 
>> they were being used in noticeable amplification attacks.
> 
> I sat on the front lines of ARIN’s war against lame delegations for the 
> entire war.  We spent quite a few
> years testing delegations for our definition of lameness, and then notifying 
> the listed tech-c and admin-c.
> E-mail recipients would either ignore the email, not understand the email and 
> move on to the next thing,
> or would write-in or call-in and speak to either me or my co-worker Jon 
> Worley. Very few lame delegations
> were fixed, even among those who called-in or wrote-in for clarification.  
> rDNS worked for the user, and
> they weren’t willing to change anything.
> 
> The war was unwinnable. 
> 
> /david 
> ___
> 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] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[David Huberman]

Mark Andrews stated:

>It’s amazing how fast people can fix lame delegations once email and other 
>services stop flowing. The only reason you think it is un- winnable is that 
>you 
>are unwilling to remove the delegation for failing to maintain a properly 
>working configuration. 

Ideally, yes – of course.

But in practical terms, when any type of registry strips away a lame delegation
attached to a real, operating network with users behind it, and things break
as a result, it has a high potential of affecting the innocent 3rd parties 
using that
network.  Especially at scale, the legal liability issues implicated by such an 
action
are frightening, and quickly outweigh the ‘for the common good’ arguments. 


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Bill Woodcock]

> On May 3, 2018, at 3:27 PM, David Huberman  wrote:
> In practical terms, when any type of registry strips away a lame delegation
> attached to a real, operating network with users behind it, and things break
> as a result…

But isn’t that, by definition, impossible?  What could break as a result of a 
_lame_ delegation being removed?

They’d have to be spoofing a real IP address behind their firewall, which isn’t 
supposed to work anyway.

-Bill



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

[Geoff Huston]

> On 4 May 2018, at 3:06 am, Paul Vixie  wrote:
> 
> what are the implications for older (pre-KSKROLL) validators when icann 
> eventually rolls the key?

I assume that you are referring to security-aware resolvers that do not perform 
the actions specified in this draft. There are no implications at all for these 
resolvers.

Any trusted key measurement conducted using such a resolver will show that the 
resolver is a security-aware resolver, but is not performing the sentinel 
method.


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

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Frederico A C Neves]

On Thu, May 03, 2018 at 10:27:30PM +, David Huberman wrote:
> Mark Andrews stated:
> 
> >It’s amazing how fast people can fix lame delegations once email and other 
> >services stop flowing. The only reason you think it is un- winnable is that 
> >you 
> >are unwilling to remove the delegation for failing to maintain a properly 
> >working configuration. 
> 
> Ideally, yes – of course.
> 
> But in practical terms, when any type of registry strips away a lame 
> delegation
> attached to a real, operating network with users behind it, and things break
> as a result, it has a high potential of affecting the innocent 3rd parties 
> using that
> network.  Especially at scale, the legal liability issues implicated by such 
> an action
> are frightening, and quickly outweigh the ‘for the common good’ arguments. 

As long as there is community support Mark's observation works as
expected.

Slightly variatios of this policy are in place for LACNIC and APNIC
regions and is very effective.

http://www.lacnic.net/686/2/lacnic/6-lame-delegation-policy
https://www.apnic.net/manage-ip/manage-resources/reverse-dns/lame-dns-reverse-delegation/

Fred

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

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Mark Andrews]

> On 4 May 2018, at 8:36 am, Bill Woodcock  wrote:
> 
> 
> 
>> On May 3, 2018, at 3:27 PM, David Huberman  wrote:
>> In practical terms, when any type of registry strips away a lame delegation
>> attached to a real, operating network with users behind it, and things break
>> as a result…
> 
> But isn’t that, by definition, impossible?  What could break as a result of a 
> _lame_ delegation being removed?
> 
> They’d have to be spoofing a real IP address behind their firewall, which 
> isn’t supposed to work anyway.
> 
>-Bill

A “Lame Delegation” can be to a particular machines.  These delegation for .fj 
are lame and have been for over a year.

fj. @128.32.136.3 (adns1.berkeley.edu.): dns=refused edns=refused edns1=ok 
edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused 
optlist=refused signed=refused ednstcp=refused
fj. @2607:f140::fffe::3 (adns1.berkeley.edu.): dns=refused edns=refused 
edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused 
ednsflags=refused optlist=refused signed=refused ednstcp=refused
fj. @128.32.136.14 (adns2.berkeley.edu.): dns=refused edns=refused edns1=ok 
edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused 
optlist=refused signed=refused ednstcp=refused
fj. @2607:f140::fffe::e (adns2.berkeley.edu.): dns=refused edns=refused 
edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused 
ednsflags=refused optlist=refused signed=refused ednstcp=refused

But because .fj has multiple servers

fj. 86400   IN  NS  ns1.berkeley.edu.
fj. 86400   IN  NS  teri.usp.ac.fj.
fj. 86400   IN  NS  ns2.berkeley.edu.
fj. 86400   IN  NS  rip.psg.com.
fj. 86400   IN  NS  manu.usp.ac.fj.
fj. 86400   IN  NS  auth00.ns.uu.net.

the service is still up.  In the meantime .fj doesn’t have the level of 
redundancy they presumably think they have and every resolver in the world 
spends time discovering that they are broken.

There are others like these where the servers fail to respond to certain 
classes of legitimate DNS queries.

westlaw.com.au. @146.242.20.65 (ns-emea-1.thomsonreuters.net.): dns=ok 
edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok 
ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok
westlaw.com.au. @146.242.18.65 (ns-amers-1.thomsonreuters.net.): dns=ok 
edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok 
ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok
westlaw.com.au. @146.242.19.65 (ns-amers-2.thomsonreuters.net.): dns=ok 
edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok 
ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok
westlaw.com.au. @146.242.21.65 (ns-emea-2.thomsonreuters.net.): dns=ok 
edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok 
ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok
westlaw.com.au. @146.242.22.65 (ns-apac-1.thomsonreuters.net.): dns=ok 
edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok 
ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok
westlaw.com.au. @146.242.24.65 (ns-apac-2.thomsonreuters.net.): dns=ok 
edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok 
ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok

Why should resolvers have to work around idiocy like this?

Mark
-- 
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] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[David Huberman]

>> On May 3, 2018, at 3:27 PM, David Huberman  wrote:
>> In practical terms, when any type of registry strips away a lame delegation
>> attached to a real, operating network with users behind it, and things break
>> as a result…

Woody replied:  
> But isn’t that, by definition, impossible?  What could break as a result of a 
> _lame_ delegation 
> being removed?

Mark provided you with a forward DNS example. Here’s a _common_ reverse DNS 
example:

You are the registrant of 192.168.0.0/17.
You setup a single SOA record for 168.192.in-addr.arpa instead of properly 
defining 128 records 
for each /24 reverse zone.

PTR queries to the NSes will work (for the /17).  

But you’ll fail the lameness checking at an RIR because the RIR checks all 
zones in the
SOA record, and assumes that if you assert 168.192.in-addr.arpa, that you 
really meant
to claim authority over the /16.



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Bill Woodcock]

> On May 3, 2018, at 4:23 PM, Mark Andrews  wrote:
> A “Lame Delegation” can be to a particular machines.  These delegation for 
> .fj are lame and have been for over a year.

Right, of course, but what breaks if you remove the lame nameservers from the 
NS list?  What am I not understanding?

-Bill



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Bill Woodcock]

> On May 3, 2018, at 4:33 PM, Mark Andrews  wrote:
> You see the same with forward zones with domain parking. They set up a ..com 
> (or root) zone for all the *.com zones parked on the server and break all 
> negative responses as a consequence.

Right, but again, that’s not lameness, per se, it’s just a bad configuration.  
They’re not denying that they know anything about the zones that are delegated 
to them.

-Bill



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Mark Andrews]

> On 4 May 2018, at 10:11 am, Bill Woodcock  wrote:
> 
> 
> 
>> On May 3, 2018, at 4:23 PM, Mark Andrews  wrote:
>> A “Lame Delegation” can be to a particular machines.  These delegation for 
>> .fj are lame and have been for over a year.
> 
> Right, of course, but what breaks if you remove the lame nameservers from the 
> NS list?  What am I not understanding?
> 
>-Bill

The problem is that you can’t just remove the NS records from the parent side 
because name servers learn the NS records from the child side of the delegation 
as well as the parent side.  The offending NS records need to be removed from 
both sides.  This (or fixing whatever is broken) is what should be happening 
when faults are reported.  When that doesn’t happen in a *reasonable* amount of 
time the *entire* delegation needs to be removed to force the issue.

-- 
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] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Mark Andrews]

> On 4 May 2018, at 10:13 am, Bill Woodcock  wrote:
> 
> 
> 
>> On May 3, 2018, at 4:28 PM, David Huberman  wrote:
>> 
 On May 3, 2018, at 3:27 PM, David Huberman  
 wrote:
 In practical terms, when any type of registry strips away a lame delegation
 attached to a real, operating network with users behind it, and things 
 break
 as a result…
>> 
>> Woody replied:
>>> But isn’t that, by definition, impossible?  What could break as a result of 
>>> a _lame_ delegation
>>> being removed?
>> 
>> Mark provided you with a forward DNS example. Here’s a _common_ reverse DNS 
>> example:
>> 
>> You are the registrant of 192.168.0.0/17.
>> You setup a single SOA record for 168.192.in-addr.arpa instead of properly 
>> defining 128 records
>> for each /24 reverse zone.
>> 
>> PTR queries to the NSes will work (for the /17).
>> 
>> But you’ll fail the lameness checking at an RIR because the RIR checks all 
>> zones in the
>> SOA record, and assumes that if you assert 168.192.in-addr.arpa, that you 
>> really meant
>> to claim authority over the /16.
> 
> E, but that’s a special RIR alternate understanding of what lameness 
> means, specific to CIDR, no?

No.  That is one form of basic DNS lameness.  The server delegated to doesn’t 
server the delegated zone.

> In the general DNS sense, if the NS can answer PTR queries for the thing 
> delegated to it, it’s not lame.  And we’re talking about forward here, not 
> in-addr, and more specifically, not the special CIDR in-addr.

DNS servers need to produce VALID negative answers as well as VALID positive 
answers for the name space delegated to them.  You need to test for BOTH types 
of answers.  Failure to produce VALID negative answers causes problems when new 
types are introduced.

Look at the history of , SPF, and TLSA records.  All of these are/were 
issued by clients to see if the records existed at given names.  While these 
are mostly forward zone issues the same issues could arise in the IN-ADDR.ARPA 
and IP6.ARPA name spaces.  We don’t know what is coming in the future.  We have 
however defined how those queries should be answered.  We can test to ensure 
that correct behaviour occurs.

>-Bill
-- 
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] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Mark Andrews]

> On 4 May 2018, at 9:28 am, David Huberman  wrote:
> 
>>> On May 3, 2018, at 3:27 PM, David Huberman  wrote:
>>> In practical terms, when any type of registry strips away a lame delegation
>>> attached to a real, operating network with users behind it, and things break
>>> as a result…
> 
> Woody replied:  
>> But isn’t that, by definition, impossible?  What could break as a result of 
>> a _lame_ delegation 
>> being removed?
> 
> Mark provided you with a forward DNS example. Here’s a _common_ reverse DNS 
> example:
> 
> You are the registrant of 192.168.0.0/17.
> You setup a single SOA record for 168.192.in-addr.arpa instead of properly 
> defining 128 records 
> for each /24 reverse zone.
> 
> PTR queries to the NSes will work (for the /17).  
> 
> But you’ll fail the lameness checking at an RIR because the RIR checks all 
> zones in the
> SOA record, and assumes that if you assert 168.192.in-addr.arpa, that you 
> really meant
> to claim authority over the /16.

You see the same with forward zones with domain parking. They set up a .com (or 
root) zone for all the *.com zones parked on the server and break all negative 
responses as a consequence.

-- 
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] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[David Huberman]

Fred wrote:
>As long as there is community support Mark's observation works as
>expected.

>Slightly variatios of this policy are in place for LACNIC and APNIC
>regions and is very effective.
 
Thank you, Fred, and apologies for my incomplete answer that was biased
by my geography. 



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Mark Andrews]

> On 4 May 2018, at 9:37 am, David Huberman  wrote:
> 
> Fred wrote:
>> As long as there is community support Mark's observation works as
>> expected.
> 
>> Slightly variatios of this policy are in place for LACNIC and APNIC
>> regions and is very effective.
> 
> Thank you, Fred, and apologies for my incomplete answer that was biased
> by my geography. 

Which is easily fixed by having wording that says that you need to maintain
working RFC compliant DNS servers for the delegated reverse zones or the
delegation will be removed.  This is a policy failure on ARIN’s part for
failure to make explicit what is implicit in the RFCs.

List the tests you know intend to make.  Mark the list as being non-exhaustive
which allows you to add additional tests in the future.  Start testing and
reporting immediately.  Enforce after next contract renewal. 

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

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

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

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Bill Woodcock]

> On May 3, 2018, at 4:28 PM, David Huberman  wrote:
> 
>>> On May 3, 2018, at 3:27 PM, David Huberman  wrote:
>>> In practical terms, when any type of registry strips away a lame delegation
>>> attached to a real, operating network with users behind it, and things break
>>> as a result…
> 
> Woody replied:
>> But isn’t that, by definition, impossible?  What could break as a result of 
>> a _lame_ delegation
>> being removed?
> 
> Mark provided you with a forward DNS example. Here’s a _common_ reverse DNS 
> example:
> 
> You are the registrant of 192.168.0.0/17.
> You setup a single SOA record for 168.192.in-addr.arpa instead of properly 
> defining 128 records
> for each /24 reverse zone.
> 
> PTR queries to the NSes will work (for the /17).
> 
> But you’ll fail the lameness checking at an RIR because the RIR checks all 
> zones in the
> SOA record, and assumes that if you assert 168.192.in-addr.arpa, that you 
> really meant
> to claim authority over the /16.

E, but that’s a special RIR alternate understanding of what lameness means, 
specific to CIDR, no?

In the general DNS sense, if the NS can answer PTR queries for the thing 
delegated to it, it’s not lame.  And we’re talking about forward here, not 
in-addr, and more specifically, not the special CIDR in-addr.

-Bill



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fixing lame delegations

[Paul Hoffman]

Please not the change of the subject line. Discussion of how to fix the 
problem has nothing to do with the definition.


Carry on.

--Paul Hoffman

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

Re: [DNSOP] draft-ietf-dnsop-terminology-bis-10

[Paul Hoffman]

Thanks, those were all good editorial comments. They'll make it into the 
next draft.


--Paul Hoffman

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

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[John Kristoff]

On Thu, 3 May 2018 06:12:42 +
Amreesh Phokeer  wrote:

> We consider "lame" any NS which is either:
> - Not responding at all.
> - Responding in some way, but not for the specific domain queried.
> - Responding for the correct domain, but without the authority bit set.

Friends,

I've been referring to a class of problems I call DNS Inconsistency.
This can be thought to be a bit broader in scope than what is typically
meant by a delegation, but it is related.

I'm particularly interested in parent/child NS RRset consistency at the
moment and I recently compiled this list of possible NS RR results when
considering what may happen as one might try to traverse a graph to a
domain name node.  Imperfect list, classifications, and severity
perhaps, but maybe stimulates more useful discussion than it does
detract from it.

--- some amount of broken ---
error   |  bad type (e.g. CNAME)
error   |  bad rdata (e.g. IPaddr for NS)
error   |  TTL disagreement in the NS RRset
error   |  DNSSEC validation error
error   |  timeout/unreachable transient (e.g. down time)
error   |  timeout/unreachable permanent (e.g. misconfiguration)
query_response  |  NXDomain
query_response  |  REFUSED
query_response  |  SERVFAIL / FORMERR / NOTIMP / etc...
query_response  |  referral after a referral
query_response  |  aa==0 when aa==1 expected
query_response  |  malicious or incorrect rdata

--- properly formed answer, but not yet provably correct ---
name|  maps to an ipv4addr
name|  maps to an ipv4addr set
name|  maps to an ipv6addr
name|  maps to an ipv6addr set
name|  maps to an ipv4addr + ipv6addr
name|  maps to an ipv4addr set + ipv6addr
name|  maps to an ipv4addr + ipv6addr set
name|  maps to an ipv4addr set + ipv6addr set

John

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

Re: [DNSOP] [Ext] Lameness terminology

[Paul Vixie]

Mark Andrews wrote:

...


The problem is that you can’t just remove the NS records from the
parent side because name servers learn the NS records from the child
side of the delegation as well as the parent side.  The offending NS
records need to be removed from both sides.  This (or fixing whatever
is broken) is what should be happening when faults are reported.
When that doesn’t happen in a *reasonable* amount of time the
*entire* delegation needs to be removed to force the issue.


+1. it's a cooperative ecosystem. destructive noncooperation can't be 
ignored.


--
P Vixie

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