Subject: [DNSOP] Call for Adoption: draft-pwouters-powerbind

From: Tim Wicinski <[email-masked]>
Date: Mon, 20 Apr 2020 14:03:03 -0400

All,

As we stated in the meeting and in our chairs actions, we're going to run
regular call for adoptions over next few months.

>From the presentation during the last meeting, there was interest in
adtoping this document around the idea of DNSSEC transparency.  This
interest comes the privacy side of things, more than the DNS side.

This starts a Call for Adoption for draft-pwouters-powerbind

The draft is available here:
https://datatracker.ietf.org/doc/draft-pwouters-powerbind/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

We are looking for *explicit* support for adoption.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 4 May 2020

Thanks,
tim wicinski
DNSOP co-chair

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 20 Apr 2020 14:35:23 -0400

I support adoption, with the caveat that either the draft name should
be updated with something like s/powerbind/delegation-only-dnssec/, or
the draft should describe why it is being called "powerbind".

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Apr 2020 15:08:38 -0400

> the draft should describe why it is being called "powerbind".

The name was a joke. It is not used anyway in the document text on purpose and will not appear in the name when adopted.

Paul

> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Petr Špaček <[email-masked]>
Date: Thu, 23 Apr 2020 07:45:38 +0200

Hi dnsop,

I support adoption under condition that the envisioned "DNSSEC Transparency" mechanism is documented and somewhat tested before "powerbind" draft progresses into form of RFC.

At the moment there are insufficient details published for the dnsop WG to judge whether powerbind+transparency proposals together fulfill intended purpose.

I would hate to see "powerbind" published for vendors to implement before (at least!) proof-of-concept implementations of powerbind _and_ Transparency are done. That's the only way to make sure some little details are not preventing vendors from implementing practical proposals.

RFCs 7901 (CHAIN extension) and 8094 (DTLS) should serve us as warnings.

Petr Špaček  @  CZ.NIC

On 20. 04. 20 20:03, Tim Wicinski wrote:
> The draft is available here: https://datatracker.ietf.org/doc/draft-pwouters-powerbind/
>

---

From: Joe Abley <[email-masked]>
Date: Thu, 23 Apr 2020 21:37:17 -0400

On 20 Apr 2020, at 14:03, Tim Wicinski <[email-masked]> wrote:

> The draft is available here: https://datatracker.ietf.org/doc/draft-pwouters-powerbind/ <https://datatracker.ietf.org/doc/draft-pwouters-powerbind/>
> 

This draft needs a more compelling problem statement, and a clear description of why other controls (e.g. reputational, contractual) are insufficient. [It's also possible that the draft just needs a clearer problem statement, rather than a more compelling one.]

I identify with Warren's furrowed brow as he asked how this draft would protect against a rogue registrar or registry publishing a zone with a covertly-modified delegation, since such rogue behaviour would not be identified or suppressed by the mechanism proposed in this draft. This seems fundamental to the concept of "delegation-only" which is the central and sole consideration of this proposal.

Perhaps more substantially, but with more rapid oscillation of hands, I am concerned that this draft, if adopted, will gain legitimacy in policy circles where it might actually do damage. An example might be where there is contractual or market pressure to require it for TLDs where its effect might be to cause suppressed orphan glue to break otherwise functional delegations. It seems better to me to understand the implications of the mechanism up front before it gets close to an RFC number, because those RFC numbers can smell deceptively potent.

I would prefer this idea to be better fleshed out in these areas before the draft sees adoption, and hence I do not support adoption at this time. I understand the sentiment expressed by some others with the opinion that the proposal in any case does no harm since it's optional, but I find myself less optimistic about the future than they are.

My day job is at a company responsible for a significant and venerable top-level domain. Lest anybody infer otherwise, let me confirm that we are very much in favour of measures that allow compliance to be ensured through automated and mechanical means and, correspondingly, for trust in our stewardship to be as close as possible to absolute. I am, in general, very open to ideas that would promote those things. However, I am not convinced that this proposal will get us there and I am concerned that the legitimacy that is associated with the work on this group might ultimately result in collateral damage.

Joe

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 27 Apr 2020 13:44:30 -0700

Petr Špaček <[email-masked]> writes:

> I support adoption under condition that the envisioned "DNSSEC
> Transparency" mechanism is documented and somewhat tested before
> "powerbind" draft progresses into form of RFC.

So that statement makes the point that there is no point in the document
except for DNSSEC Transparency.  I'm not sure that's true (and I'm going
to work on a better intro that hopefully may clarify things).

But implementation is pretty much a requirement in dnsop for anything
new; so implementation of the bit would certainly be needed (by both
client and sender).  But, IMHO, it shouldn't be tied to a larger topic's
(DNSSEC Transparency) implementation.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 27 Apr 2020 15:28:17 -0700

Joe Abley <[email-masked]> writes:

> This draft needs a more compelling problem statement, and a clear
> description of why other controls (e.g. reputational, contractual) are
> insufficient. [It's also possible that the draft just needs a clearer
> problem statement, rather than a more compelling one.]

Hi Joe,

Thanks for the comments.  I'm working on a more clear rewrite of the
introduction.  I'd love your feedback on it once I get it wrapped up.  I
think (hope) I can spell out the case for support more clearly.  I agree
the subject is a bit hard to wiggle into your head (as are most
somewhat-complex security cases)
-- 
Wes Hardaker
USC/ISI

---

From: Joe Abley <[email-masked]>
Date: Mon, 27 Apr 2020 16:11:38 -0700

On Apr 27, 2020, at 18:28, Wes Hardaker <[email-masked]> wrote:

> introduction.  I'd love your feedback on it once I get it wrapped up.

Yes, for sure! Happy to do that.

Joe

---

From: Brian Dickson <[email-masked]>
Date: Mon, 27 Apr 2020 17:43:05 -0700

> somewhat-complex security cases)
Hi, Wes,

I was looking at the draft to see if I understood the intent correctly, and
I think there may be a small gap, if my understanding is correct.

So, I think there are two use cases that something doing this kind of thing
needs to handle.

One is the "flat delegation-only zone", like any of the big well-known ones
(com, net, org, info).

The other would be the kind that are multiple-depth delegation zones, where
the Public Suffix List is already kind of necessary.

What I think is needed is a way to explicitly declare the places where the
depth is > 1 (if a normal flat delegation-only zone has depth == 1).

And that would effectively just need a way of making permanent and
well-known, the set of ENTs for the zone (empty non-terminals).

I think that list is likely to be short even for the most convoluted zones.

Without this, it would be theoretically possible for the TLD to add
additional unsigned delegations to bypass a signed delegation.

With the addition of an explicit set of ENTs, there would be double-entry
accounting.
Entries in the zone with depth > 1 would require a chain of ENTs to the
zone apex.
Entries in the zone with depth == 1 would need to not also have
corresponding ENTs.

(My assumption is the ENT declarations would be separate from the intrinsic
ENTs from NSEC or the explicit ones from NSEC3, if I recall my NSEC vs
NSEC3 nuances, and probably in a sibling zone like _ent.TLD for example.)

If two delegations were present, child.example.com and example.com, it
would not be possible to disambiguate them without knowing more about the
zone structure and semantics.

The two example zones I would reference would be ".uk", and ".jp", where
there are SLDs immediately below the TLD, and additional SLD-like
delegations or non-delegations further down in the zones.

Brian

---

From: Paul Wouters <[email-masked]>
Date: Mon, 27 Apr 2020 22:43:49 -0400 (EDT)

On Mon, 27 Apr 2020, Brian Dickson wrote:

> The other would be the kind that are multiple-depth delegation zones, where the Public Suffix List is already kind of necessary.
> 
> What I think is needed is a way to explicitly declare the places where the depth is > 1 (if a normal flat delegation-only zone has depth == 1).

We thought about using two bits instead of one, so we could specify a
variable depth (per zone, not per delegation) but it seemed to add a
lot of complexity. It is far easier for these TLDs to make their ENTs
a signed delegation.

> And that would effectively just need a way of making permanent and well-known, the set of ENTs for the zone (empty non-terminals).
> 
> I think that list is likely to be short even for the most convoluted zones..

Doing things in more variable ways with lists of exceptions to a depth
== 1 seems very complicated and would add complexity for resolvers.

> Without this, it would be theoretically possible for the TLD to add additional unsigned delegations to bypass a signed delegation.

I do not understand this? You mean leaving the ENT unsigned, and then
adding NS records to create a false shadow tree? At best that would
result in DS records for the real delegations to be ignored because
there is a validation error in the path. Or if the DS records would
still be served signed from the parent, then this hostile takeover
via unsigned records would not work because the shadow tree would not
have the DNSKEYs matching the signed DS record.

> If two delegations were present, child.example.com and example.com, it would not be possible to disambiguate them without knowing more about the zone
> structure and semantics.

This is an interesting case I had not considered. If a TLD hands out
domains in a mix of 1 level and 2 levels deep, what can be done
other than not using this draft? If the ENTs are limited, then
I'd still be tempted to say to turn those into real signed zones.
Any mechanism that would convey this list of ENT's would really
complicate things far more than just turning the ENTs into real
signed zones.

Paul

---

From: "John Levine" <[email-masked]>
Date: 28 Apr 2020 03:18:53 -0000

In article <CAH1iCiom2O0tYSF=[email-masked]>,
>delegations or non-delegations further down in the zones.

I think you will find ENTs in more TLDs than not.  They certainly
exist in .US and .CA and lots of others like .AC .AD .AE .AERO .AF .AG
.AI .AL .AM .AO .AR .ARPA .AS .AT .AU .AW .AZ and those are just the
ones that start with A.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 28 Apr 2020 13:27:27 -0700

> Yes, for sure! Happy to do that.

Half done.  Either tonight or tomorrow.
-- 
Wes Hardaker
USC/ISI

---

From: "John Levine" <[email-masked]>
Date: 28 Apr 2020 18:26:54 -0400

I did a little greppage on gTLD zone files, and found 93,000 signed A
and AAAA records, most of which appear to be stale glue, except for
some that look deliberate.

I think we will find that the assumption that TLD zone files are
delegation-only does not hold up very well in practice, so I am
wondering how useful a hack to technically enforce it would really be.

R's,
John

Number of signed A/AAAA by TLD:

54952 info
28012 org
6610 pro
 816 top
 653 promo
 648 mobi
 496 asia
 282 tel
  65 red
  61 blue
  58 ltda
  55 pet
  46 kim
  42 global
  36 xn--6frz82g
  32 pink
  30 xn--kput3i
  24 travel
  24 bet
  22 xin
  19 cat
  14 bio
  10 poker
  10 green
  10 black
   9 llc
   8 weber
   8 warman
   8 symantec
   8 rwe
   8 realtor
   8 orange
   8 obi
   8 norton
   8 med
   8 markets
   8 lundbeck
   8 linde
   8 liaison
   8 lefrak
   8 ladbrokes
   8 kuokgroup
   8 kerrylogistics
   8 frontdoor
   8 forex
   8 fidelity
   8 csc
   8 crs
   8 chanel
   8 career
   8 bofa
   8 bbva
   8 aol
   8 afamilycompany
   8 aeg
   8 accenture
   7 visa
   7 tiffany
   7 tiaa
   7 tatamotors
   7 ses
   7 pictet
   7 oracle
   7 onyourside
   7 onl
   7 off
   7 nextdirect
   7 microsoft
   7 makeup
   7 maif
   7 lupin
   7 kerryproperties
   7 kerryhotels
   7 ice
   7 hgtv
   7 guardian
   7 glade
   7 foodnetwork
   7 food
   7 ericsson
   7 duck
   7 diy
   7 cookingchannel
   7 clubmed
   7 cfa
   7 broker
   7 bms
   7 bloomberg
   7 bing
   7 barefoot
   7 arte
   7 airbus
   7 abc
   7 abb
   6 xn--5su34j936bgsg
   6 xerox
   6 weir
   6 rexroth
   6 omega
   6 ngo
   6 nationwide
   6 nab
   6 lipsy
   6 lego
   6 landrover
   6 juniper
   6 java
   6 jaguar
   6 istanbul
   6 hotmail
   6 genting
   6 gallo
   6 fujixerox
   6 crown
   6 bosch
   6 bbt
   6 azure
   6 aarp
   5 nadex
   5 ist
   5 blanco
   4 lgbt
   4 cpa
   4 biz
   3 xn--tckwe
   3 xn--t60b56a
   3 xn--9et52u
   3 windows
   3 vanguard
   3 trading
   3 swatch
   3 sky
   3 shangrila
   3 scjohnson
   3 scb
   3 sca
   3 sbs
   3 sanofi
   3 realestate
   3 raid
   3 nissay
   3 nikon
   3 next
   3 eco
   3 archi
   2 xn--w4rs40l
   2 xn--w4r85el8fhu5dnra
   2 xn--ngbrx
   2 xn--mxtq1m
   2 xn--mk1bu44c
   2 xn--efvy88h
   2 xn--9dbq2a
   2 xn--30rr7y
   2 xbox
   2 volvo
   2 ubs
   2 ubank
   2 srl
   2 shell
   2 sener
   2 politie
   2 llp
   2 arab
   1 zappos
   1 you
   1 yoga
   1 yamaxun
   1 xn--nqv7f
   1 xn--i1b6b1a6a2e
   1 xn--c1avg
   1 xfinity
   1 wow
   1 work
   1 wedding
   1 wanggou
   1 wang
   1 wales
   1 vodka
   1 vip
   1 tushu
   1 tunes
   1 travelchannel
   1 talk
   1 surf
   1 spot
   1 smile
   1 silk
   1 shiksha
   1 secure
   1 save
   1 safe
   1 room
   1 rodeo
   1 read
   1 prime
   1 pin
   1 pay
   1 paris
   1 organic
   1 now
   1 moi
   1 miami
   1 luxe
   1 london
   1 locus
   1 like
   1 law
   1 kindle
   1 joy
   1 jot
   1 imdb
   1 hot
   1 horse
   1 got
   1 gop
   1 garden
   1 free
   1 fit
   1 fishing
   1 fire
   1 fast
   1 fashion
   1 deal
   1 dds
   1 cymru
   1 cooking
   1 comcast
   1 circle
   1 casa
   1 call
   1 buy
   1 budapest
   1 broadway
   1 bradesco
   1 bot
   1 boston
   1 book
   1 bentley
   1 beer
   1 bbc
   1 bayern
   1 aws
   1 author
   1 audible
   1 abogado

Some mystery names:

monitor-nominet.abogado has address 127.0.0.1
monitor-nominet.audible has address 127.0.0.1
monitor-nominet.author has address 127.0.0.1
monitor-nominet.aws has address 127.0.0.1
monitor-nominet.bayern has address 127.0.0.1
monitor-nominet.bbc has address 127.0.0.1
monitor-nominet.beer has address 127.0.0.1
monitor-nominet.bentley has address 127.0.0.1
monitor-nominet.book has address 127.0.0.1
monitor-nominet.boston has address 127.0.0.1
monitor-nominet.bot has address 127.0.0.1
monitor-nominet.bradesco has address 127.0.0.1
monitor-nominet.broadway has address 127.0.0.1
monitor-nominet.budapest has address 127.0.0.1
monitor-nominet.buy has address 127.0.0.1
monitor-nominet.call has address 127.0.0.1
monitor-nominet.casa has address 127.0.0.1
monitor-nominet.circle has address 127.0.0.1
monitor-nominet.comcast has address 127.0.0.1
monitor-nominet.cooking has address 127.0.0.1
monitor-nominet.cymru has address 127.0.0.1
monitor-nominet.dds has address 127.0.0.1
monitor-nominet.deal has address 127.0.0.1
monitor-nominet.fashion has address 127.0.0.1
monitor-nominet.fast has address 127.0.0.1
monitor-nominet.fire has address 127.0.0.1
monitor-nominet.fishing has address 127.0.0.1
monitor-nominet.fit has address 127.0.0.1
monitor-nominet.free has address 127.0.0.1
monitor-nominet.garden has address 127.0.0.1
monitor-nominet.gop has address 127.0.0.1
monitor-nominet.got has address 127.0.0.1
monitor-nominet.horse has address 127.0.0.1
monitor-nominet.hot has address 127.0.0.1
monitor-nominet.imdb has address 127.0.0.1
monitor-nominet.jot has address 127.0.0.1
monitor-nominet.joy has address 127.0.0.1
monitor-nominet.kindle has address 127.0.0.1
monitor-nominet.law has address 127.0.0.1
monitor-nominet.like has address 127.0.0.1
monitor-nominet.locus has address 127.0.0.1
monitor-nominet.london has address 127.0.0.1
monitor-nominet.luxe has address 127.0.0.1
monitor-nominet.miami has address 127.0.0.1
monitor-nominet.moi has address 127.0.0.1
monitor-nominet.now has address 127.0.0.1
monitor-nominet.pay has address 127.0.0.1
monitor-nominet.pin has address 127.0.0.1
monitor-nominet.prime has address 127.0.0.1
monitor-nominet.read has address 127.0.0.1
monitor-nominet.rodeo has address 127.0.0.1
monitor-nominet.room has address 127.0.0.1
monitor-nominet.safe has address 127.0.0.1
monitor-nominet.save has address 127.0.0.1
monitor-nominet.secure has address 127.0.0.1
monitor-nominet.silk has address 127.0.0.1
monitor-nominet.smile has address 127.0.0.1
monitor-nominet.spot has address 127.0.0.1
monitor-nominet.surf has address 127.0.0.1
monitor-nominet.talk has address 127.0.0.1
monitor-nominet.tunes has address 127.0.0.1
monitor-nominet.tushu has address 127.0.0.1
monitor-nominet.vip has address 127.0.0.1
monitor-nominet.vodka has address 127.0.0.1
monitor-nominet.wales has address 127.0.0.1
monitor-nominet.wanggou has address 127.0.0.1
monitor-nominet.wedding has address 127.0.0.1
monitor-nominet.work has address 127.0.0.1
monitor-nominet.wow has address 127.0.0.1
monitor-nominet.xfinity has address 127.0.0.1
monitor-nominet.yamaxun has address 127.0.0.1
monitor-nominet.yoga has address 127.0.0.1
monitor-nominet.you has address 127.0.0.1
monitor-nominet.zappos has address 127.0.0.1

emt-ns1.emt-t-1070866640-1587743943997-2-ag.aarp has address 198.41.1.167
emt-ns1.emt-t-1581810123-1587750701570-2-r.aarp has address 198.41.1.146
emt-ns1.emt-t-2122056968-1587840493332-2-kzy.aarp has address 198.41.1.11
emt-ns1.emt-t-797141873-1587740243705-2-affcq.aarp has address 198.41.1.27
emt-ns1.emt-t-1426866505-1587741929025-2-sin.abb has address 198.41.1.13
emt-ns1.emt-t-1618874095-1587749734839-2-immg.abb has address 198.41.1.92
emt-ns1.emt-t-1877307836-1587742971230-2-tvhw.abb has address 198.41.1.78
emt-ns1.emt-t-444394602-1587739271951-2-ane.abb has address 198.41.1.180
emt-ns1.emt-t-635696068-1587839524089-2-tjvrg.abb has address 198.41.1.135
emt-ns1.emt-t-1531485331-1587739575679-2-hgh.abc has address 198.41.1.25
emt-ns1.emt-t-573838951-1587743275513-2-a.abc has address 198.41.1.31
emt-ns1.emt-t-620878946-1587742259022-2-pfsfm.abc has address 198.41.1.13
emt-ns1.emt-t-684140705-1587750037098-2-cekp.abc has address 198.41.1.29
emt-ns1.emt-t-759476367-1587839827330-2-owj.abc has address 198.41.1.25
emt-ns1.emt-t-1036110132-1587748870619-2-tfprr.accenture has address 198.41.1.54
emt-ns1.emt-t-1197342691-1587747827053-2-xi.accenture has address 198.41.1.118
emt-ns1.emt-t-1329392680-1587735313713-2-s.accenture has address 198.41.1.96
emt-ns1.emt-t-1428588270-1587739048311-2-xuai.accenture has address 198.41.1.137
emt-ns1.emt-t-1859089526-1587745141366-2-m.accenture has address 198.41.1.12
emt-ns1.emt-t-1926755290-1587649422533-2-zni.accenture has address 198.41.1.82
emt-ns1.emt-t-1035642598-1587743239521-2-rd.aeg has address 198.41.1.167
emt-ns1.emt-t-1321072410-1587737171149-2-agycl.aeg has address 198.41.1.119
emt-ns1.emt-t-145606680-1587839610682-2-suy.aeg has address 198.41.1.81
emt-ns1.emt-t-2129079115-1587746971241-2-nv.aeg has address 198.41.1.72
emt-ns1.emt-t-2147438856-1587745928507-2-edome.aeg has address 198.41.1.65
emt-ns1.emt-t-326633427-1587753670939-2-fyq.aeg has address 198.41.1.70
emt-ns1.emt-t-118188678-1587743905947-2-cri.afamilycompany has address 198.41.1.77
emt-ns1.emt-t-1312323319-1587840273913-2-h.afamilycompany has address 198.41.1.160
emt-ns1.emt-t-1646113413-1587737835867-2-nnxc.afamilycompany has address 198.41.1.200
emt-ns1.emt-t-245317722-1587648214433-2-cytas.afamilycompany has address 198.41.1.104
emt-ns1.emt-t-300366154-1587746596750-2-oj.afamilycompany has address 198.41.1.55
emt-ns1.emt-t-393523012-1587747638467-2-s.afamilycompany has address 198.41.1.54
emt-ns1.emt-t-1314876865-1587743173145-2-vc.airbus has address 198.41.1.47
emt-ns1.emt-t-1490373073-1587840736279-2-bha.airbus has address 198.41.1.167
emt-ns1.emt-t-479336548-1587744188347-2-qyzyv.airbus has address 198.41.1.62
emt-ns1.emt-t-74916694-1587750948452-2-eb.airbus has address 198.41.1.137
emt-ns1.emt-t-916740585-1587740487314-2-milje.airbus has address 198.41.1.113
emt-ns1.emt-t-212293868-1587735495398-2-ufrq.aol has address 198.41.1.46
emt-ns1.emt-t-335101131-1587739230638-2-ods.aol has address 198.41.1.48
emt-ns1.emt-t-448613887-1587749053726-2-f.aol has address 198.41.1.59
emt-ns1.emt-t-46343820-1587745324199-2-e.aol has address 198.41.1.113
emt-ns1.emt-t-496951039-1587748010073-2-i.aol has address 198.41.1.38
emt-ns1.emt-t-968165964-1587649603958-2-cbje.aol has address 198.41.1.80
emt-ns1.emt-t-1479697409-1587741564078-2-n.arte has address 198.41.1.77
emt-ns1.emt-t-1770192072-1587742606055-2-kv.arte has address 198.41.1.87
emt-ns1.emt-t-2073625011-1587839160288-2-m.arte has address 198.41.1.190
emt-ns1.emt-t-270926844-1587749371810-2-qslhm.arte has address 198.41.1.151
emt-ns1.emt-t-425393079-1587738896492-2-n.arte has address 198.41.1.143
emt-ns1.emt-t-1096876923-1587747979181-2-u.azure has address 198.41.1.50
emt-ns1.emt-t-529388249-1587737490281-2-fe.azure has address 198.41.1.112
emt-ns1.emt-t-748039817-1587740151374-2-l.azure has address 198.41.1.58
emt-ns1.emt-t-857289624-1587741203056-2-qkxkh.azure has address 198.41.1.175
emt-ns1.emt-t-269458891-1587744570988-2-z.barefoot has address 198.41.1.114
emt-ns1.emt-t-280865221-1587735827370-2-m.barefoot has address 198.41.1.116
emt-ns1.emt-t-329160431-1587752336389-2-qki.barefoot has address 198.41.1.78
emt-ns1.emt-t-624716208-1587745613518-2-bltq.barefoot has address 198.41.1.187
emt-ns1.emt-t-760515055-1587741883721-2-iwov.barefoot has address 198.41.1.53
emt-ns1.emt-t-1300078624-1587741754510-2-de.bbt has address 198.41.1.67
emt-ns1.emt-t-1528954226-1587740713231-2-xbdsb.bbt has address 198.41.1.182
emt-ns1.emt-t-159423223-1587738038925-2-d.bbt has address 198.41.1.81
emt-ns1.emt-t-1715727606-1587748523745-2-ykq.bbt has address 198.41.1.184
emt-ns1.emt-t-11300246-1587746050749-2-c.bbva has address 198.41.1.76
emt-ns1.emt-t-1625995355-1587753791955-2-qqjby.bbva has address 198.41.1.48
emt-ns1.emt-t-1878229293-1587743361498-2-us.bbva has address 198.41.1.145
emt-ns1.emt-t-32141019-1587839731742-2-otcbs.bbva has address 198.41.1.178
emt-ns1.emt-t-331821270-1587747093527-2-btl.bbva has address 198.41.1.126
emt-ns1.emt-t-891496480-1587737292640-2-lwint.bbva has address 198.41.1.169
emt-ns1.emt-t-1387798843-1587743761770-2-i.bing has address 198.41.1.64
emt-ns1.emt-t-1437601042-1587742745974-2-idyc.bing has address 198.41.1.67
emt-ns1.emt-t-1974345431-1587740061571-2-ki.bing has address 198.41.1.112
emt-ns1.emt-t-2076025395-1587750520445-2-cfykp.bing has address 198.41.1.57
emt-ns1.emt-t-992831909-1587840311806-2-hi.bing has address 198.41.1.55
emt-ns1.emt-t-2054544806-1587742309155-2-e.bloomberg has address 198.41.1.191
emt-ns1.emt-t-575636088-1587736251516-2-mlp.bloomberg has address 198.41.1.52
emt-ns1.emt-t-586582387-1587746040017-2-pvd.bloomberg has address 198.41.1.154
emt-ns1.emt-t-670687143-1587752764521-2-s.bloomberg has address 198.41.1.15
emt-ns1.emt-t-674383339-1587744997802-2-otl.bloomberg has address 198.41.1.147
emt-ns1.emt-t-1370919752-1587735094205-2-n.bms has address 198.41.1.191
emt-ns1.emt-t-1389139303-1587743840996-2-uzdy.bms has address 198.41.1.111
emt-ns1.emt-t-2064219177-1587744883235-2-bszsi.bms has address 198.41.1.52
emt-ns1.emt-t-286674341-1587751611855-2-vprp.bms has address 198.41.1.145
emt-ns1.emt-t-494549777-1587741155531-2-m.bms has address 198.41.1.151
emt-ns1.emt-t-1161488054-1587747024194-2-srrt.bofa has address 198.41.1.80
emt-ns1.emt-t-1194633252-1587648637664-2-kfyfj.bofa has address 198.41.1.111
emt-ns1.emt-t-1368375185-1587748079851-2-yxfsd.bofa has address 198.41.1.36
emt-ns1.emt-t-1773178122-1587738260540-2-igo.bofa has address 198.41.1.161
emt-ns1.emt-t-612560638-1587734528051-2-s.bofa has address 198.41.1.85
emt-ns1.emt-t-889807542-1587744331757-2-v.bofa has address 198.41.1.131
emt-ns1.emt-t-1898955155-1587741693230-2-hcix.bosch has address 198.41.1.106
emt-ns1.emt-t-2016924135-1587748463150-2-f.bosch has address 198.41.1.27
emt-ns1.emt-t-2025517443-1587737977847-2-b.bosch has address 198.41.1.122
emt-ns1.emt-t-569708388-1587740652247-2-qaufh.bosch has address 198.41.1.26
emt-ns1.emt-t-1029842786-1587743578641-2-vhk.broker has address 198.41.1.20
emt-ns1.emt-t-1045154728-1587742562642-2-tke.broker has address 198.41.1.180
emt-ns1.emt-t-1151964857-1587750338783-2-fizrl.broker has address 198.41.1.75
emt-ns1.emt-t-1238049581-1587840129555-2-e.broker has address 198.41.1.167
emt-ns1.emt-t-244770373-1587739878408-2-a.broker has address 198.41.1.166
emt-ns1.emt-t-2031912973-1587839402653-2-hqijn.cfa has address 198.41.1.46
emt-ns1.emt-t-366414042-1587749613763-2-bwfz.cfa has address 198.41.1.139
emt-ns1.emt-t-415648091-1587742849181-2-xhn.cfa has address 198.41.1.65
emt-ns1.emt-t-646596645-1587739150091-2-fsmv.cfa has address 198.41.1.145
emt-ns1.emt-t-865247348-1587741807012-2-uegma.cfa has address 198.41.1.16
emt-ns1.emt-t-1171079889-1587753005552-2-vopnm.chanel has address 198.41.1.165
emt-ns1.emt-t-1290773151-1587746298724-2-rszu.chanel has address 198.41.1.59
emt-ns1.emt-t-1402976268-1587745239756-2-n.chanel has address 198.41.1.91
emt-ns1.emt-t-1637731431-1587742550930-2-afmfs.chanel has address 198.41.1.160
emt-ns1.emt-t-1858664344-1587736493027-2-hgiud.chanel has address 198.41.1.138
emt-ns1.emt-t-259139686-1587838944554-2-ofjk.chanel has address 198.41.1.52
emt-ns1.emt-t-1021398721-1587736130089-2-ribet.clubmed has address 198.41.1.177
emt-ns1.emt-t-1294980809-1587744875318-2-sbl.clubmed has address 198.41.1.200
emt-ns1.emt-t-1759283934-1587745917767-2-fn.clubmed has address 198.41.1.151
emt-ns1.emt-t-372866702-1587752643463-2-g.clubmed has address 198.41.1.33
emt-ns1.emt-t-461284507-1587742187368-2-yxvrx.clubmed has address 198.41.1.59
emt-ns1.emt-t-142343981-1587740365543-2-qnkl.cookingchannel has address 198.41.1.11
emt-ns1.emt-t-1461335679-1587840614823-2-bepar.cookingchannel has address 198.41.1.25
emt-ns1.emt-t-1812897932-1587744066170-2-ouwf.cookingchannel has address 198.41.1.106
emt-ns1.emt-t-2119396494-1587750827419-2-hadb.cookingchannel has address 198.41.1.150
emt-ns1.emt-t-946126623-1587743050763-2-jw.cookingchannel has address 198.41.1.29
emt-ns1.emt-t-1107909017-1587741264359-2-jtxya.crown has address 198.41.1.113
emt-ns1.emt-t-274458118-1587740212639-2-mde.crown has address 198.41.1.63
emt-ns1.emt-t-657632483-1587748039675-2-edlfl.crown has address 198.41.1.43
emt-ns1.emt-t-888728852-1587737551191-2-gd.crown has address 198.41.1.139
emt-ns1.emt-t-1597806346-1587738199741-2-mxy.crs has address 198.41.1.113
emt-ns1.emt-t-1926226091-1587746962990-2-vwgjw.crs has address 198.41.1.188
emt-ns1.emt-t-422168639-1587748005057-2-mk.crs has address 198.41.1.145
emt-ns1.emt-t-507775071-1587734467502-2-irus.crs has address 198.41.1.160
emt-ns1.emt-t-913843642-1587648577186-2-to.crs has address 198.41.1.123
emt-ns1.emt-t-998134549-1587744270854-2-rfy.crs has address 198.41.1.117
emt-ns1.emt-t-1071156329-1587748626529-2-g.csc has address 198.41.1.40
emt-ns1.emt-t-1249130536-1587649180614-2-ufm.csc has address 198.41.1.151
emt-ns1.emt-t-1830320591-1587735071527-2-cjrj.csc has address 198.41.1.23
emt-ns1.emt-t-388238313-1587738805306-2-c.csc has address 198.41.1.58
emt-ns1.emt-t-823370735-1587744897796-2-zx.csc has address 198.41.1.125
emt-ns1.emt-t-85258582-1587747572022-2-eynwx.csc has address 198.41.1.13
emt-ns1.emt-t-1104804413-1587752215415-2-pjygp.diy has address 198.41.1.127
emt-ns1.emt-t-145215840-1587745491220-2-oi.diy has address 198.41.1.135
emt-ns1.emt-t-1529278350-1587735706023-2-ndre.diy has address 198.41.1.93
emt-ns1.emt-t-1627342327-1587744448826-2-x.diy has address 198.41.1.130
emt-ns1.emt-t-201804538-1587741761922-2-zacd.diy has address 198.41.1.138
emt-ns1.emt-t-1048690251-1587744509820-2-nfw.duck has address 198.41.1.44
emt-ns1.emt-t-1780528888-1587741822834-2-onsq.duck has address 198.41.1.147
emt-ns1.emt-t-2075059162-1587735766693-2-rhvfu.duck has address 198.41.1.186
emt-ns1.emt-t-2094286142-1587752275894-2-dh.duck has address 198.41.1.37
emt-ns1.emt-t-472468114-1587745552285-2-xnc.duck has address 198.41.1.177
emt-ns1.emt-t-1262105220-1587750887891-2-lspdj.ericsson has address 198.41.1.65
emt-ns1.emt-t-1565428553-1587840675590-2-muv.ericsson has address 198.41.1.148
emt-ns1.emt-t-1652979466-1587744127287-2-tpt.ericsson has address 198.41.1.194
emt-ns1.emt-t-310584212-1587743111959-2-ara.ericsson has address 198.41.1.167
emt-ns1.emt-t-536402109-1587740426432-2-ojj.ericsson has address 198.41.1.52
emt-ns1.emt-t-1212963766-1587746232405-2-u.fidelity has address 198.41.1.123
emt-ns1.emt-t-170228918-1587753972457-2-y.fidelity has address 198.41.1.44
emt-ns1.emt-t-2060302866-1587743542643-2-da.fidelity has address 198.41.1.38
emt-ns1.emt-t-217870016-1587737473453-2-g.fidelity has address 198.41.1.83
emt-ns1.emt-t-686652257-1587839912278-2-c.fidelity has address 198.41.1.105
emt-ns1.emt-t-925716487-1587747274773-2-huvf.fidelity has address 198.41.1.154
emt-ns1.emt-t-1024478172-1587750399329-2-izuuy.food has address 198.41.1.18
emt-ns1.emt-t-1608069075-1587743639668-2-ix.food has address 198.41.1.12
emt-ns1.emt-t-1718312563-1587742623734-2-ymwx.food has address 198.41.1.48
emt-ns1.emt-t-2001958616-1587739939602-2-yja.food has address 198.41.1.150
emt-ns1.emt-t-554161390-1587840190358-2-ehkv.food has address 198.41.1.94
emt-ns1.emt-t-1254310282-1587840008102-2-zzeax.foodnetwork has address 198.41.1.20
emt-ns1.emt-t-1834661086-1587739756580-2-zsn.foodnetwork has address 198.41.1.113
emt-ns1.emt-t-1892576974-1587743456556-2-k.foodnetwork has address 198.41.1.75
emt-ns1.emt-t-317433526-1587750217660-2-hgbf.foodnetwork has address 198.41.1.161
emt-ns1.emt-t-72568867-1587742440440-2-nlcv.foodnetwork has address 198.41.1.165
emt-ns1.emt-t-1145061912-1587747206787-2-backu.forex has address 198.41.1.160
emt-ns1.emt-t-1595941220-1587744534102-2-lydt.forex has address 198.41.1.13
emt-ns1.emt-t-1712861209-1587738442088-2-zhqr.forex has address 198.41.1.50
emt-ns1.emt-t-195589122-1587748262170-2-ykk.forex has address 198.41.1.103
emt-ns1.emt-t-257073392-1587648818634-2-zd.forex has address 198.41.1.71
emt-ns1.emt-t-845643355-1587734709200-2-nphi.forex has address 198.41.1.31
emt-ns1.emt-t-1203423929-1587748687559-2-uh.frontdoor has address 198.41.1.108
emt-ns1.emt-t-306138678-1587649241094-2-b.frontdoor has address 198.41.1.14
emt-ns1.emt-t-528643356-1587735132064-2-tqpmu.frontdoor has address 198.41.1.13
emt-ns1.emt-t-718009972-1587747634115-2-pju.frontdoor has address 198.41.1.168
emt-ns1.emt-t-780629129-1587738866119-2-fr.frontdoor has address 198.41.1.69
emt-ns1.emt-t-875795225-1587744958685-2-al.frontdoor has address 198.41.1.138
emt-ns1.emt-t-1243755830-1587740835166-2-wlc.fujixerox has address 198.41.1.151
emt-ns1.emt-t-189255846-1587738161011-2-hvzb.fujixerox has address 198.41.1.132
emt-ns1.emt-t-1905471701-1587748644744-2-e.fujixerox has address 198.41.1.37
emt-ns1.emt-t-356553182-1587741876571-2-lh.fujixerox has address 198.41.1.105
emt-ns1.emt-t-1005242984-1587736994198-2-h.gallo has address 198.41.1.168
emt-ns1.emt-t-1650423274-1587747496070-2-mfrvp.gallo has address 198.41.1.15
emt-ns1.emt-t-1869039791-1587739665460-2-il.gallo has address 198.41.1.106
emt-ns1.emt-t-875708865-1587740715199-2-mzyzg.gallo has address 198.41.1.49
emt-ns1.emt-t-1684961421-1587739119494-2-qtxi.genting has address 198.41.1.62
emt-ns1.emt-t-1861699157-1587736448693-2-vnvc.genting has address 198.41.1.164
emt-ns1.emt-t-1916618508-1587746949035-2-n.genting has address 198.41.1.65
emt-ns1.emt-t-402586284-1587740152923-2-mtjh.genting has address 198.41.1.112
emt-ns1.emt-t-1482481926-1587838797380-2-tympe.glade has address 198.41.1.19
emt-ns1.emt-t-1735023616-1587738526083-2-hmi.glade has address 198.41.1.35
emt-ns1.emt-t-318184610-1587749009731-2-o.glade has address 198.41.1.83
emt-ns1.emt-t-612198652-1587741200114-2-uny.glade has address 198.41.1.74
emt-ns1.emt-t-793178083-1587742241717-2-zazc.glade has address 198.41.1.81
emt-ns1.emt-t-1776188952-1587749553265-2-v.guardian has address 198.41.1.163
emt-ns1.emt-t-34103169-1587741746027-2-vmc.guardian has address 198.41.1.174
emt-ns1.emt-t-379986527-1587839341972-2-nmz.guardian has address 198.41.1.130
emt-ns1.emt-t-393123684-1587742788151-2-m.guardian has address 198.41.1.191
emt-ns1.emt-t-938925305-1587739089174-2-yvkb.guardian has address 198.41.1.160
emt-ns1.emt-t-1191346095-1587738683789-2-liib.hgtv has address 198.41.1.160
emt-ns1.emt-t-1359561790-1587747449589-2-nxhkr.hgtv has address 198.41.1.82
emt-ns1.emt-t-234293687-1587649059632-2-sf.hgtv has address 198.41.1.172
emt-ns1.emt-t-605798240-1587734950342-2-kvt.hgtv has address 198.41.1.147
emt-ns1.emt-t-621697585-1587744775994-2-ifg.hgtv has address 198.41.1.182
emt-ns1.emt-t-1901821807-1587747131490-2-k.hotmail has address 198.41.1.79
emt-ns1.emt-t-2057153002-1587740335009-2-czh.hotmail has address 198.41.1.82
emt-ns1.emt-t-357531889-1587736630550-2-a.hotmail has address 198.41.1.113
emt-ns1.emt-t-580270813-1587739301464-2-fa.hotmail has address 198.41.1.18
emt-ns1.emt-t-1069753241-1587751732344-2-o.ice has address 198.41.1.46
emt-ns1.emt-t-1901303560-1587735215046-2-pldvu.ice has address 198.41.1.34
emt-ns1.emt-t-2123944440-1587745004260-2-q.ice has address 198.41.1.197
emt-ns1.emt-t-740603131-1587741276427-2-qbigw.ice has address 198.41.1.98
emt-ns1.emt-t-806854160-1587743962185-2-rnw.ice has address 198.41.1.88
emt-ns1.emt-t-1542266569-1587741997579-2-fgelg.jaguar has address 198.41.1.150
emt-ns1.emt-t-1770950092-1587748765280-2-tyubc.jaguar has address 198.41.1.43
emt-ns1.emt-t-1820455052-1587738282089-2-yr.jaguar has address 198.41.1.149
emt-ns1.emt-t-1997120983-1587740956133-2-vbsd.jaguar has address 198.41.1.37
emt-ns1.emt-t-1428042936-1587741080534-2-kx.java has address 198.41.1.133
emt-ns1.emt-t-1464866306-1587747858097-2-zzho.java has address 198.41.1.10
emt-ns1.emt-t-1505466559-1587737368483-2-h.java has address 198.41.1.117
emt-ns1.emt-t-281313130-1587740029421-2-ut.java has address 198.41.1.183
emt-ns1.emt-t-1058439750-1587740530288-2-b.juniper has address 198.41.1.82
emt-ns1.emt-t-1479724101-1587741570632-2-lh.juniper has address 198.41.1.46
emt-ns1.emt-t-250056741-1587748342119-2-moss.juniper has address 198.41.1.31
emt-ns1.emt-t-351254307-1587737855847-2-fr.juniper has address 198.41.1.108
emt-ns1.emt-t-1722891160-1587740122472-2-efya.kerryhotels has address 198.41.1.56
emt-ns1.emt-t-1729847572-1587742807002-2-wcrd.kerryhotels has address 198.41.1.87
emt-ns1.emt-t-346159129-1587743822839-2-o.kerryhotels has address 198.41.1.116
emt-ns1.emt-t-912379280-1587750580940-2-byytf.kerryhotels has address 198.41.1.125
emt-ns1.emt-t-935535570-1587840372480-2-nc.kerryhotels has address 198.41.1.88
emt-ns1.emt-t-1077111886-1587745667321-2-xd.kerrylogistics has address 198.41.1.135
emt-ns1.emt-t-1812514520-1587753428980-2-touoh.kerrylogistics has address 198.41.1.116
emt-ns1.emt-t-1973416826-1587736918358-2-rvm.kerrylogistics has address 198.41.1.73
emt-ns1.emt-t-334583744-1587742995887-2-vovqo.kerrylogistics has address 198.41.1.72
emt-ns1.emt-t-572059521-1587839368508-2-jndsm.kerrylogistics has address 198.41.1.19
emt-ns1.emt-t-618377368-1587746726730-2-f.kerrylogistics has address 198.41.1.196
emt-ns1.emt-t-1160180125-1587751370898-2-apdu.kerryproperties has address 198.41.1.182
emt-ns1.emt-t-1546126364-1587743598595-2-adreo.kerryproperties has address 198.41.1.30
emt-ns1.emt-t-1690983153-1587734852834-2-ucccb.kerryproperties has address 198.41.1.103
emt-ns1.emt-t-267093341-1587744640772-2-d.kerryproperties has address 198.41.1.108
emt-ns1.emt-t-37909181-1587740913730-2-ooxvy.kerryproperties has address 198.41.1.64
emt-ns1.emt-t-1067973452-1587745545132-2-gxwpv.kuokgroup has address 198.41.1.193
emt-ns1.emt-t-1325365877-1587746604497-2-tqfw.kuokgroup has address 198.41.1.41
emt-ns1.emt-t-1413130249-1587753307982-2-wji.kuokgroup has address 198.41.1.70
emt-ns1.emt-t-1863506878-1587742874091-2-xusgr.kuokgroup has address 198.41.1.61
emt-ns1.emt-t-453609122-1587736796921-2-v.kuokgroup has address 198.41.1.99
emt-ns1.emt-t-822398158-1587839247382-2-wj.kuokgroup has address 198.41.1.68
emt-ns1.emt-t-1119776436-1587747315577-2-qo.landrover has address 198.41.1.108
emt-ns1.emt-t-1267856436-1587736813257-2-zy.landrover has address 198.41.1.100
emt-ns1.emt-t-1285912917-1587740519755-2-kw.landrover has address 198.41.1.156
emt-ns1.emt-t-1837772469-1587739484442-2-ioz.landrover has address 198.41.1.102
emt-ns1.emt-t-1042460215-1587738139046-2-w.lefrak has address 198.41.1.194
emt-ns1.emt-t-1151704947-1587648516464-2-aj.lefrak has address 198.41.1.164
emt-ns1.emt-t-1446540857-1587744209961-2-o.lefrak has address 198.41.1.199
emt-ns1.emt-t-2087658742-1587746901789-2-iby.lefrak has address 198.41.1.81
emt-ns1.emt-t-407660699-1587840576131-2-z.lefrak has address 198.41.1.182
emt-ns1.emt-t-933828629-1587747943314-2-ikap.lefrak has address 198.41.1.177
emt-ns1.emt-t-1427997156-1587747797582-2-vrp.lego has address 198.41.1.141
emt-ns1.emt-t-2083843713-1587739968454-2-tejg.lego has address 198.41.1.133
emt-ns1.emt-t-327323793-1587737307571-2-k.lego has address 198.41.1.42
emt-ns1.emt-t-42675261-1587741019315-2-w.lego has address 198.41.1.127
emt-ns1.emt-t-1050611474-1587747510790-2-qmn.linde has address 198.41.1.153
emt-ns1.emt-t-1545913622-1587748565429-2-ltmlr.linde has address 198.41.1.107
emt-ns1.emt-t-1621483155-1587649120151-2-x.linde has address 198.41.1.134
emt-ns1.emt-t-1663499950-1587738744595-2-obd.linde has address 198.41.1.142
emt-ns1.emt-t-2104807031-1587744836882-2-hjv.linde has address 198.41.1.186
emt-ns1.emt-t-244593858-1587735010923-2-khyj.linde has address 198.41.1.42
emt-ns1.emt-t-1733908993-1587741141765-2-d.lipsy has address 198.41.1.52
emt-ns1.emt-t-1813016551-1587747918668-2-ewf.lipsy has address 198.41.1.97
emt-ns1.emt-t-455345976-1587740090389-2-k.lipsy has address 198.41.1.48
emt-ns1.emt-t-850850349-1587737429372-2-tzyaz.lipsy has address 198.41.1.94
emt-ns1.emt-t-1563505782-1587649301575-2-de.lundbeck has address 198.41.1.38
emt-ns1.emt-t-1566937176-1587745019587-2-m.lundbeck has address 198.41.1.34
emt-ns1.emt-t-1785264974-1587748748594-2-w.lundbeck has address 198.41.1.43
emt-ns1.emt-t-1946457333-1587735192613-2-bxz.lundbeck has address 198.41.1.196
emt-ns1.emt-t-222787281-1587747705083-2-z.lundbeck has address 198.41.1.140
emt-ns1.emt-t-740962126-1587738926827-2-qrlz.lundbeck has address 198.41.1.90
emt-ns1.emt-t-1121979030-1587738586999-2-kt.lupin has address 198.41.1.151
emt-ns1.emt-t-1764831713-1587838858042-2-b.lupin has address 198.41.1.31
emt-ns1.emt-t-430959452-1587749070261-2-wta.lupin has address 198.41.1.91
emt-ns1.emt-t-487196349-1587741261072-2-rpxo.lupin has address 198.41.1.191
emt-ns1.emt-t-777018221-1587742302724-2-d.lupin has address 198.41.1.32
emt-ns1.emt-t-1512434864-1587734792158-2-saaq.maif has address 198.41.1.153
emt-ns1.emt-t-1705664469-1587744579741-2-x.maif has address 198.41.1.77
emt-ns1.emt-t-1763562412-1587740852839-2-h.maif has address 198.41.1.26
emt-ns1.emt-t-1993239398-1587751310418-2-f.maif has address 198.41.1.171
emt-ns1.emt-t-583758205-1587743537346-2-cwqat.maif has address 198.41.1.188
emt-ns1.emt-t-2102909797-1587744518708-2-t.makeup has address 198.41.1.137
emt-ns1.emt-t-283604772-1587751249898-2-uad.makeup has address 198.41.1.144
emt-ns1.emt-t-607281884-1587740791871-2-d.makeup has address 198.41.1.71
emt-ns1.emt-t-790422402-1587734731426-2-qftk.makeup has address 198.41.1.91
emt-ns1.emt-t-928565231-1587743476309-2-wdhv.makeup has address 198.41.1.194
emt-ns1.emt-t-1058585482-1587753187014-2-rlbot.markets has address 198.41.1.43
emt-ns1.emt-t-1133860863-1587745422921-2-wvf.markets has address 198.41.1.167
emt-ns1.emt-t-1224389827-1587839126328-2-hvy.markets has address 198.41.1.62
emt-ns1.emt-t-36878143-1587742752252-2-mbfr.markets has address 198.41.1.116
emt-ns1.emt-t-541311742-1587746482018-2-lm.markets has address 198.41.1.106
emt-ns1.emt-t-89699837-1587736675532-2-x.markets has address 198.41.1.128
emt-ns1.emt-t-1660730297-1587747456219-2-cd.med has address 198.41.1.66
emt-ns1.emt-t-192181203-1587754152970-2-k.med has address 198.41.1.49
emt-ns1.emt-t-2145518526-1587840092823-2-ep.med has address 198.41.1.52
emt-ns1.emt-t-266950688-1587746414047-2-wpt.med has address 198.41.1.24
emt-ns1.emt-t-449870907-1587743723767-2-a.med has address 198.41.1.73
emt-ns1.emt-t-787236908-1587737654375-2-ojks.med has address 198.41.1.85
emt-ns1.emt-t-1061756324-1587744144390-2-j.microsoft has address 198.41.1.79
emt-ns1.emt-t-1349724017-1587735403267-2-vzy.microsoft has address 198.41.1.155
emt-ns1.emt-t-1740654716-1587751913424-2-mhd.microsoft has address 198.41.1.150
emt-ns1.emt-t-1934650855-1587741458273-2-xnejc.microsoft has address 198.41.1.142
emt-ns1.emt-t-479866296-1587745186579-2-mbt.microsoft has address 198.41.1.166
emt-ns1.emt-t-1100876215-1587747556568-2-a.nab has address 198.41.1.115
emt-ns1.emt-t-1148448041-1587737065732-2-skw.nab has address 198.41.1.12
emt-ns1.emt-t-1418968338-1587739726466-2-yndxc.nab has address 198.41.1.195
emt-ns1.emt-t-430865991-1587740776428-2-heqe.nab has address 198.41.1.73
emt-ns1.emt-t-1111992103-1587741815532-2-adsqv.nationwide has address 198.41.1.186
emt-ns1.emt-t-1651940709-1587748584238-2-felk.nationwide has address 198.41.1.30
emt-ns1.emt-t-1826271198-1587738099852-2-s.nationwide has address 198.41.1.185
emt-ns1.emt-t-967271706-1587740774196-2-prhk.nationwide has address 198.41.1.85
emt-ns1.emt-t-1257146623-1587839489592-2-uik.next has address 198.41.1.20
emt-ns1.emt-t-1770152871-1587737044950-2-u.next has address 198.41.1.174
emt-ns1.emt-t-1171447733-1587744387638-2-ws.nextdirect has address 198.41.1.19
emt-ns1.emt-t-154131994-1587741701013-2-rgwsx.nextdirect has address 198.41.1.109
emt-ns1.emt-t-1615239806-1587735645347-2-uuvi.nextdirect has address 198.41.1.99
emt-ns1.emt-t-2095467882-1587752154925-2-shsy.nextdirect has address 198.41.1.155
emt-ns1.emt-t-52879198-1587745430172-2-mv.nextdirect has address 198.41.1.51
emt-ns1.emt-t-1688952952-1587737715071-2-ocsh.nikon has address 198.41.1.181
emt-ns1.emt-t-616915870-1587840153368-2-nuv.nikon has address 198.41.1.117
emt-ns1.emt-t-1509423238-1587739392949-2-rd.nissay has address 198.41.1.169
emt-ns1.emt-t-1883407463-1587839645091-2-sf.nissay has address 198.41.1.112
emt-ns1.emt-t-320331890-1587835778877-2-i.nissay has address 198.41.1.139
emt-ns1.emt-t-1292958140-1587840515597-2-zjsq.norton has address 198.41.1.182
emt-ns1.emt-t-1580367894-1587744149016-2-u.norton has address 198.41.1.39
emt-ns1.emt-t-1595478609-1587746840563-2-o.norton has address 198.41.1.187
emt-ns1.emt-t-1948929072-1587747882039-2-vdsa.norton has address 198.41.1.121
emt-ns1.emt-t-2016281433-1587738078240-2-f.norton has address 198.41.1.37
emt-ns1.emt-t-78462262-1587648455996-2-ymag.norton has address 198.41.1.200
emt-ns1.emt-t-1117114487-1587745080473-2-w.obi has address 198.41.1.112
emt-ns1.emt-t-1778169565-1587748809611-2-yx.obi has address 198.41.1.50
emt-ns1.emt-t-1867504155-1587738987644-2-abqz.obi has address 198.41.1.140
emt-ns1.emt-t-347170566-1587735253160-2-gj.obi has address 198.41.1.123
emt-ns1.emt-t-394684528-1587649362052-2-y.obi has address 198.41.1.110
emt-ns1.emt-t-998170844-1587747766092-2-wf.obi has address 198.41.1.91
emt-ns1.emt-t-1903046084-1587742684947-2-c.off has address 198.41.1.183
emt-ns1.emt-t-2039417597-1587740000495-2-xy.off has address 198.41.1.68
emt-ns1.emt-t-73388549-1587743700701-2-zmx.off has address 198.41.1.192
emt-ns1.emt-t-850157535-1587840251039-2-ied.off has address 198.41.1.16
emt-ns1.emt-t-997102669-1587750459879-2-hc.off has address 198.41.1.44
emt-ns1.emt-t-1907735166-1587737916948-2-fi.omega has address 198.41.1.179
emt-ns1.emt-t-1912052054-1587748402594-2-tkmcd.omega has address 198.41.1.79
emt-ns1.emt-t-609569321-1587741631876-2-qxen.omega has address 198.41.1.17
emt-ns1.emt-t-853627033-1587740591270-2-rjd.omega has address 198.41.1.50
emt-ns1.emt-t-1107905180-1587749311331-2-j.onyourside has address 198.41.1.95
emt-ns1.emt-t-2070331632-1587738829154-2-mwb.onyourside has address 198.41.1.77
emt-ns1.emt-t-224516951-1587742545031-2-gqnnz.onyourside has address 198.41.1.35
emt-ns1.emt-t-543632461-1587839099604-2-snhwq.onyourside has address 198.41.1.156
emt-ns1.emt-t-957196279-1587741503033-2-txx.onyourside has address 198.41.1.194
emt-ns1.emt-t-1490008668-1587744814342-2-wjev.oracle has address 198.41.1.140
emt-ns1.emt-t-1589864223-1587752579677-2-q.oracle has address 198.41.1.128
emt-ns1.emt-t-298119256-1587736069403-2-ir.oracle has address 198.41.1.83
emt-ns1.emt-t-415656249-1587745856743-2-qsnb.oracle has address 198.41.1.157
emt-ns1.emt-t-451979981-1587742126465-2-njal.oracle has address 198.41.1.162
emt-ns1.emt-t-1131583997-1587734889792-2-kfv.orange has address 198.41.1.151
emt-ns1.emt-t-1189279687-1587648999152-2-a.orange has address 198.41.1.32
emt-ns1.emt-t-1838627960-1587744715084-2-dnjeu.orange has address 198.41.1.20
emt-ns1.emt-t-343424019-1587748443215-2-v.orange has address 198.41.1.16
emt-ns1.emt-t-625159643-1587747388400-2-j.orange has address 198.41.1.173
emt-ns1.emt-t-947147209-1587738623098-2-ehdra.orange has address 198.41.1.22
emt-ns1.emt-t-1220584060-1587738768251-2-omx.pictet has address 198.41.1.19
emt-ns1.emt-t-1234326994-1587741442045-2-e.pictet has address 198.41.1.110
emt-ns1.emt-t-137478427-1587742483985-2-tlq.pictet has address 198.41.1.79
emt-ns1.emt-t-1484212768-1587749250802-2-rnzr.pictet has address 198.41.1.13
emt-ns1.emt-t-200024109-1587839038933-2-d.pictet has address 198.41.1.174
emt-ns1.emt-t-1546442759-1587839429061-2-kt.raid has address 198.41.1.115
emt-ns1.emt-t-583200964-1587736979060-2-rzzo.raid has address 198.41.1.197
emt-ns1.emt-t-1022406860-1587835839516-2-y.realestate has address 198.41.1.20
emt-ns1.emt-t-587400481-1587739453857-2-fs.realestate has address 198.41.1.163
emt-ns1.emt-t-786674603-1587839705889-2-ffrco.realestate has address 198.41.1.41
emt-ns1.emt-t-1206697042-1587748160644-2-ntir.rexroth has address 198.41.1.84
emt-ns1.emt-t-311018835-1587741386834-2-lsdq.rexroth has address 198.41.1.157
emt-ns1.emt-t-501326697-1587737673084-2-ii.rexroth has address 198.41.1.88
emt-ns1.emt-t-857271380-1587740347311-2-ld.rexroth has address 198.41.1.163
emt-ns1.emt-t-1064595588-1587839550140-2-btm.rwe has address 198.41.1.125
emt-ns1.emt-t-1328149193-1587753610451-2-pjs.rwe has address 198.41.1.128
emt-ns1.emt-t-1531354038-1587745867333-2-xvv.rwe has address 198.41.1.105
emt-ns1.emt-t-1789071066-1587743178608-2-acgw.rwe has address 198.41.1.48
emt-ns1.emt-t-1853596581-1587737110360-2-a.rwe has address 198.41.1.152
emt-ns1.emt-t-794399445-1587746910009-2-feoi.rwe has address 198.41.1.38
emt-ns1.emt-t-1198485086-1587839221166-2-h.sanofi has address 198.41.1.120
emt-ns1.emt-t-1593662411-1587738968261-2-mfqqb.sanofi has address 198.41.1.186
emt-ns1.emt-t-342835527-1587835355797-2-e.sanofi has address 198.41.1.37
emt-ns1.emt-t-1248786140-1587837015957-2-jjqtk.sbs has address 198.41.1.32
emt-ns1.emt-t-2006358227-1587736752370-2-prriu.sbs has address 198.41.1.51
emt-ns1.emt-t-85547773-1587833164630-2-i.sbs has address 198.41.1.67
emt-ns1.emt-t-33356786-1587737186679-2-io.sca has address 198.41.1.116
emt-ns1.emt-t-641982967-1587837438676-2-tn.sca has address 198.41.1.59
emt-ns1.emt-t-739651167-1587833592687-2-z.sca has address 198.41.1.21
emt-ns1.emt-t-1788684503-1587737794931-2-tdkt.scjohnson has address 198.41.1.86
emt-ns1.emt-t-207950858-1587838052240-2-agmlo.scjohnson has address 198.41.1.93
emt-ns1.emt-t-789585257-1587834197727-2-p.scjohnson has address 198.41.1.82
emt-ns1.emt-t-1710087012-1587735463983-2-z.sener has address 198.41.1.150
emt-ns1.emt-t-1834211227-1587837902598-2-cs.sener has address 198.41.1.167
emt-ns1.emt-t-1099827212-1587739210992-2-lpoo.ses has address 198.41.1.37
emt-ns1.emt-t-1723536935-1587741867993-2-ueqat.ses has address 198.41.1.20
emt-ns1.emt-t-1835843416-1587742910216-2-q.ses has address 198.41.1.172
emt-ns1.emt-t-447329077-1587749674342-2-jtlfk.ses has address 198.41.1.10
emt-ns1.emt-t-845987679-1587839463426-2-e.ses has address 198.41.1.181
emt-ns1.emt-t-217376703-1587737957406-2-ljqy.shangrila has address 198.41.1.145
emt-ns1.emt-t-275110097-1587840395063-2-vpul.shangrila has address 198.41.1.126
emt-ns1.emt-t-1435785278-1587839186858-2-ime.shell has address 198.41.1.81
emt-ns1.emt-t-1857222464-1587736736233-2-ysxs.shell has address 198.41.1.63
emt-ns1.emt-t-253981276-1587737612159-2-y.sky has address 198.41.1.171
emt-ns1.emt-t-472391950-1587834016006-2-rq.sky has address 198.41.1.107
emt-ns1.emt-t-663716087-1587837862806-2-mgkk.sky has address 198.41.1.180
emt-ns1.emt-t-1829164288-1587737231837-2-i.swatch has address 198.41.1.108
emt-ns1.emt-t-896014987-1587839671227-2-y.swatch has address 198.41.1.34
emt-ns1.emt-t-10716633-1587737896706-2-cfmy.symantec has address 198.41.1.134
emt-ns1.emt-t-14806425-1587840334453-2-qusy.symantec has address 198.41.1.140
emt-ns1.emt-t-1943953622-1587746657980-2-ub.symantec has address 198.41.1.174
emt-ns1.emt-t-326034762-1587747699769-2-bzf.symantec has address 198.41.1.22
emt-ns1.emt-t-510488620-1587743966827-2-v.symantec has address 198.41.1.67
emt-ns1.emt-t-677795320-1587648275035-2-uwj.symantec has address 198.41.1.19
emt-ns1.emt-t-1005233655-1587840554143-2-x.tatamotors has address 198.41.1.124
emt-ns1.emt-t-1506043896-1587740304625-2-kkmys.tatamotors has address 198.41.1.144
emt-ns1.emt-t-451937995-1587744005051-2-vcyi.tatamotors has address 198.41.1.23
emt-ns1.emt-t-494463612-1587750764781-2-tiwir.tatamotors has address 198.41.1.52
emt-ns1.emt-t-804167420-1587742989566-2-um.tatamotors has address 198.41.1.87
emt-ns1.emt-t-1560825430-1587739514764-2-nekq.tiaa has address 198.41.1.97
emt-ns1.emt-t-1745011837-1587749976558-2-pena.tiaa has address 198.41.1.138
emt-ns1.emt-t-2054500613-1587742198049-2-bj.tiaa has address 198.41.1.178
emt-ns1.emt-t-479420468-1587743214463-2-piu.tiaa has address 198.41.1.91
emt-ns1.emt-t-625719643-1587839766543-2-nvyew.tiaa has address 198.41.1.174
emt-ns1.emt-t-2092002100-1587752396935-2-nfohs.tiffany has address 198.41.1.28
emt-ns1.emt-t-491860446-1587741944647-2-bif.tiffany has address 198.41.1.166
emt-ns1.emt-t-544820676-1587735888067-2-yn.tiffany has address 198.41.1.100
emt-ns1.emt-t-636253794-1587744631957-2-ehhy.tiffany has address 198.41.1.111
emt-ns1.emt-t-846397057-1587745674613-2-wy.tiffany has address 198.41.1.13
emt-ns1.emt-t-1018289523-1587834863707-2-v.trading has address 198.41.1.93
emt-ns1.emt-t-197553515-1587838736606-2-e.trading has address 198.41.1.186
emt-ns1.emt-t-882200369-1587738465002-2-xm.trading has address 198.41.1.149
emt-ns1.emt-t-541301757-1587839005108-2-ca.travelchannel has address 198.41.1.91
emt-ns1.emt-t-1585391818-1587736614854-2-hdexe.ubank has address 198.41.1.118
emt-ns1.emt-t-698241085-1587839065740-2-gix.ubank has address 198.41.1.36
emt-ns1.emt-t-2015276403-1587735033535-2-hgf.ubs has address 198.41.1.103
emt-ns1.emt-t-2131976659-1587837479859-2-bqrdh.ubs has address 198.41.1.10
emt-ns1.emt-t-13260938-1587739109122-2-gn.vanguard has address 198.41.1.150
emt-ns1.emt-t-1533151370-1587735374304-2-k.vanguard has address 198.41.1.146
emt-ns1.emt-t-1149950846-1587751008941-2-v.visa has address 198.41.1.52
emt-ns1.emt-t-1182897981-1587743234327-2-oq.visa has address 198.41.1.69
emt-ns1.emt-t-1706131652-1587734490046-2-samn.visa has address 198.41.1.192
emt-ns1.emt-t-799213838-1587740548215-2-rrk.visa has address 198.41.1.83
emt-ns1.emt-t-99646511-1587744262561-2-tkl.visa has address 198.41.1.82
emt-ns1.emt-t-1149348146-1587837057613-2-lug.volvo has address 198.41.1.88
emt-ns1.emt-t-67758947-1587734610737-2-mv.volvo has address 198.41.1.174
emt-ns1.emt-t-1154415847-1587839307941-2-j.weber has address 198.41.1.164
emt-ns1.emt-t-1248016283-1587736857665-2-gefe.weber has address 198.41.1.149
emt-ns1.emt-t-1287344187-1587745606333-2-kom.weber has address 198.41.1.53
emt-ns1.emt-t-464609808-1587742934998-2-h.weber has address 198.41.1.51
emt-ns1.emt-t-716319264-1587753368472-2-pdoap.weber has address 198.41.1.169
emt-ns1.emt-t-789308546-1587746665505-2-om.weber has address 198.41.1.48
emt-ns1.emt-t-1108897990-1587742119622-2-hkoh.weir has address 198.41.1.171
emt-ns1.emt-t-321235309-1587738404109-2-xtnec.weir has address 198.41.1.64
emt-ns1.emt-t-42097871-1587741078179-2-ekhx.weir has address 198.41.1.142
emt-ns1.emt-t-543973265-1587748886272-2-pm.weir has address 198.41.1.148
emt-ns1.emt-t-1103324286-1587738381352-2-p.windows has address 198.41.1.12
emt-ns1.emt-t-2002386409-1587734648605-2-zhuo.windows has address 198.41.1.182
emt-ns1.emt-t-640250843-1587840068893-2-g.xbox has address 198.41.1.61
emt-ns1.emt-t-779888918-1587836201897-2-prkm.xbox has address 198.41.1.61
emt-ns1.emt-t-1339458247-1587736691456-2-nde.xerox has address 198.41.1.106
emt-ns1.emt-t-1615197122-1587739362453-2-thov.xerox has address 198.41.1.148
emt-ns1.emt-t-1657873588-1587747194602-2-p.xerox has address 198.41.1.91
emt-ns1.emt-t-353381044-1587740396095-2-iemi.xerox has address 198.41.1.74
emt-ns1.emt-t-1379402155-1587741448180-2-n.xn--5su34j936bgsg has address 198.41.1.43
emt-ns1.emt-t-1412198275-1587740408291-2-k.xn--5su34j936bgsg has address 198.41.1.102
emt-ns1.emt-t-2009806604-1587748221132-2-duner.xn--5su34j936bgsg has address 198.41.1.39
emt-ns1.emt-t-2061071040-1587737733991-2-fxrks.xn--5su34j936bgsg has address 198.41.1.83
emt-ns1.emt-t-1471827913-1587735282585-2-cph.xn--9dbq2a has address 198.41.1.103
emt-ns1.emt-t-872869772-1587837721513-2-znewr.xn--9dbq2a has address 198.41.1.19
emt-ns1.emt-t-306088970-1587735948724-2-uhku.xn--mk1bu44c has address 198.41.1.16
emt-ns1.emt-t-828905290-1587838386567-2-xlvin.xn--mk1bu44c has address 198.41.1.108
emt-ns1.emt-t-1005160847-1587834742494-2-ono.xn--t60b56a has address 198.41.1.181
emt-ns1.emt-t-1253944888-1587738343050-2-yra.xn--t60b56a has address 198.41.1.22
emt-ns1.emt-t-1560187039-1587838615122-2-ni.xn--t60b56a has address 198.41.1.140
emt-ns1.emt-t-1280484617-1587735434855-2-kmvs.xn--tckwe has address 198.41.1.128
emt-ns1.emt-t-878020441-1587739169810-2-f.xn--tckwe has address 198.41.1.19
emt-ns1.emt-t-1264753381-1587838637196-2-siatb.xn--w4r85el8fhu5dnra has address 198.41.1.200
emt-ns1.emt-t-838477768-1587736190765-2-nyl.xn--w4r85el8fhu5dnra has address 198.41.1.147
emt-ns1.emt-t-594953549-1587838763913-2-oy.xn--w4rs40l has address 198.41.1.112
emt-ns1.emt-t-62448515-1587736312329-2-eqfw.xn--w4rs40l has address 198.41.1.121

---

From: Daniel Migault <[email-masked]>
Date: Wed, 29 Apr 2020 10:31:30 -0400

My understanding of the draft is that it attempts to prevent a key to sign
a RRset it is not necessarily authoritative for. I think the WG should work
on this, and support adoption of the draft. I am happy to review further
version of the draft.
Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 29 Apr 2020 12:52:59 -0400

Following up on Petr's suggestion that the "DNSEC Transparency" mechanism
is documented
and somewhat tested.

I totally agree on this idea and can assure the WG that if this draft is
adopted, this will be one of the
conditions on progressing forward.

tim

On Thu, Apr 23, 2020 at 1:46 AM Petr Špaček <[email-masked]> wrote:

> At the moment there are insufficient details published for the dnsop WG to
> judge whether powerbind+transparency proposals together fulfill intended
> purpose.
>
> I would hate to see "powerbind" published for vendors to implement before
> (at least!) proof-of-concept implementations of powerbind _and_
> Transparency are done. That's the only way to make sure some little details
> are not preventing vendors from implementing practical proposals.
>

---

From: Linus Nordberg <[email-masked]>
Date: Wed, 29 Apr 2020 23:44:53 +0200

Tim Wicinski <[email-masked]> wrote

> This starts a Call for Adoption for draft-pwouters-powerbind

I am interested in the idea of a DNSSEC transparency system, i.e.
externally verifiable append-only logs of observed DNSSEC data, and do
support adoption of draft-pwouters-powerbind which I'm also willing to
review.

My experience with DNSSEC transparency is limited to an implementation
of such a log and the operation of a log instance. This experiment was
based on an implementation of [draft-zhang-trans-ct-dnssec] and was set
up at IETF96.

[draft-zhang-trans-ct-dnssec] https://tools.ietf.org/html/draft-zhang-trans-ct-dnssec-03

---

From: "John Levine" <[email-masked]>
Date: 29 Apr 2020 22:21:44 -0400

In article <CADZyTk=y5RC3_mEROYF0mro0=[email-masked]> you write:
>a RRset it is not necessarily authoritative for.

If that's what it means, that's what it should say.  As I read it, the flag it defines
says that the zone will only sign NS and DS and perhaps the occasional _flag.

The 95,000 signed A and AAAA records I found in TLD files are all
authoritative, since there is no zone cut between them and the TLD.
But that's over 200 TLDs which this proposal would not apply to.

Perhaps we should ask some TLD operators if they'd be interested.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Apr 2020 23:39:01 -0400

> wondering how useful a hack to technically enforce it would really be.

There are indeed some TLDs which are not delegation-only.

For example, DeNIC is known for directly serving some small (IIRC ~5
RRsets) child domains directly out of the .DE parent zone with no zone
cut.

But that's just an implementation detail, and could change in the
future, if there was good reason to care.

But there are also some large TLDs that are delegation-only, and could
be a good place to get started.  I don't see ".com" or ".net" on your
list, most of those are brand domains without open registration, and
they are legitimately free to delegate or not delegate whatever they
want.

> 6610 pro

Pretty much the the only two or three with non-trivial numbers that
matter on the list.

> Some mystery names:

These two patterns have been around for ages, used for some sort of
automated monitoring, and don't matter.

> emt-ns1.emt-t-1070866640-1587743943997-2-ag.aarp has address 198.41.1.167

My .com zone processing code has for many years now being moving right
past these:

    next if (m{^(emt-)?t-[^.]+-[^.]+-[^.]+-}io);

I am sure ways can be found to handle these sentinels (not real
child-domain delegations).  For example, the spec could exclude domain
names that start with "_" or "_sentinel".  And the sentinel names could
then all live there.

-- 
    Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Apr 2020 23:46:31 -0400

> On Apr 29, 2020, at 23:39, Viktor Dukhovni <[email-masked]> wrote:
> 
> 
>  For example, the spec could exclude domain

It already does, because the _prefix really belongs to the domain and is never a delegation. It would be a hassle if we have to make signed delegations for _tcp (for TLSA) or _opengpgkey or _smimea records.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Apr 2020 23:50:05 -0400

> On Apr 29, 2020, at 11:46 PM, Paul Wouters <[email-masked]> wrote:
> 

Yes, just finished finished reading the draft and noticed the same.  Perhaps not
such a crazy refinement, if we're arriving at it independently.

I support the adoption of the draft.

-- 
	Viktor.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 30 Apr 2020 09:12:03 -0800

Hi, there:

Here's a supporting voice from transparency-land (I co-chair
the trans working group).  DNSSEC was the first application
outside the PKI for which there was interest in developing a CT-like
auditable log, but some obvious questions about scope and scalability
have stalled the work.  This is a tidy approach that provides a basis
for moving forward, and I'd be very happy indeed to see it adopted by
dnsop.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 30 Apr 2020 14:41:26 -0700

Hi Joe,

Sorry for the delay (Paul and I did a bit of back and forth with text
changes that took a bit longer, but made it better!)

> This draft needs a more compelling problem statement, and a clear description of why other controls
> (e.g. reputational, contractual) are insufficient. [It's also possible that the draft just needs a
> clearer problem statement, rather than a more compelling one.]

I've just pushed the -04 version of the draft that has a fairly major
overhaul of the problem statement.  I'd appreciate if it helps clarify
the technical reasons why deployment of the bit would be beneficial in
ways that are unrelated to contractual type controls.  I'll include the
first three sections below, which are the parts that really changed.

> Perhaps more substantially, but with more rapid oscillation of hands,
> I am concerned that this draft, if adopted, will gain legitimacy in
> policy circles where it might actually do damage.

I can't speculate whether zones would be under increased market pressure
for a DNS feature you clearly indicate might be desired.  I find this
statement that "this looks too helpful to some people; let's not do it"
fascinating :-) More seriously, if a customer base wanted to ensure
their parent promised never to sign lower data with their key, there is
nothing stopping contractual wording around that from existing today.
This draft merely offers a technical solution to prevent parents from
*successfully* signing lower data and having it be accepted by
validating resolvers.

> An example might be where there is contractual or market pressure to
> require it for TLDs where its effect might be to cause suppressed
> orphan glue to break otherwise functional delegations.

I'd love to see some registration point cases where this technique would
cause harm.  It is an all or nothing solution, so if a zone had 1M
customers and 1 of them needed to be signed by the parental key, then
they couldn't set this flag.  That being said, if they're truly serving
client data, it would be strange that they couldn't just create a
new delegation to handle the issue.

Here's the next for the newly wording sections 1 and 3, that describe
the problem (2 was keywords):

----

1.  Introduction

   The DNS Security Extensions [DNSSEC] use public key cryptography to
   create an hierarchical trust base with the DNSSEC root public keys at
   the top, followed by Top Level domain (TLD) keys one level
   underneath.  While the root and most TLD zones are asumed to be
   exclusively delegation-only zones, there is currently no
   interoperable and automatable mechanism for auditing these zones to
   ensure they behave as a delegation-only zone.  This creates a target
   for malicious use of these zones - either by their owners or through
   coercion.

   This document defines a mechanism for delegation-only zone owners to
   create a DNSKEY that indicate they will only delegate the remainder
   of the DNS tree to lower-level zones.  This allows for easier
   delegation policy verification and logging and auditing of DNS
   responses served by their infrastructure.

   Specifically, this document introduces a new DNSKEY flag allowing
   zone owners to commit to only signing records relating to delegation.

   If a DNSSEC validator discovers any non-delegation zone data signed
   by a flagged key, this data can be interpreted as BOGUS.

3.  The Deep Signing problem

   The hierarchical model of DNS and DNSSEC ([RFC1034], [RFC1035],
   [RFC4033], [RFC4034] and [RFC4035]) comes with the property that a
   zone at one point in the hierarchy can define, and therefor override,
   everything below it in the DNS tree.  And this is possible to achieve
   on a per-client basis.

   For example, the owner of the DNSSEC root key could generate a
   specially crafted zone file that ignores the intended NS records for
   ".org" and "example.org".  It could place a AAAA record for
   "www.example.org" directly into the specially crafted zone, with a
   corresponding RRSIG signed by the root DNSKEY itself.  Validating
   resolvers would find this record perfectly acceptable, as it was
   signed by a key within the proper chain of trust (in this case, a
   root DNSKEY).  This specially crafted zone could then even be served
   to specific clients in an effort to subvert a portion of the DNS
   ecosystem for a portion of the Internet.

   Similarly, the TLD "example" could circumvent company.example for
   certain clients.  It is important to note that this can be done
   without changing the upstream DS record or trust anchor -- the DNSKEY
   is (again) already in the trust path and is merely signing deeper DNS
   records than the zone owner's clients may have expected it to sign.

   It is important to note that this "feature" has always been present.
   Since the creation of the DNS, it has always been possible to serve
   "split zones".  Specifically, it is not a problem created by DNSSEC
   -- DNSSEC was not designed to protect against this use case.

   Exposing such targeted attacks requires a transparency audit
   infrastructure similar to what is deployed for PKIX ([RFC6962]).
   However, a DNSSEC version would need to log significantly more data,
   as all signed DNS data used by a DNSKEY must be recorded in order to
   prove that data signed by a parent zone's DNSKEY was out of expected
   policy.  The very distributed nature of the DNS combined with the

   typically frequent zone resigning rate makes such transparency logs
   prohibitively expensive and nearly impossible to operate.

   Additionally, it would require zone owners to expose all their zone
   data to any public log operators, thereby introducing privacy
   implications and exposing all relevant DNS data to a public archive.
   This may be acceptable for some domains, such as the root, where DNS
   data is already considered public.  However, other delegation domains
   have legal implications that prohibit them from participating in such
   a system.

   Furthermore, there is no signaling mechanism that lets validating
   resolvers know which zones are supposedly delegation-only, and what
   zones can be logged.  Today there are over 1500 TLDs in the root
   zone, some of which may be considered delegation-only while others
   may not be.  At the time of this writing, the list of entries in the
   public suffix list contains over 8800 entries as well, with 73 wild-
   card entries (prefixed with a "*") indicating that all of their
   (unknown number of) children are public registration points.  In the
   absence of an interoperable mechanism (like this draft provides), it
   is infeasible that a validating resolver or auditing log could know
   which of these zones are delegation-only without individual policy
   statements from each of them.  [todo: xref psl]

3.1.  Affected parties and their roles

   Upon deployment of this specification, the following parties would be
   potentially benefit or be affected by:

   Authoritative parent: If (and only if) an authoritative parent is a
   "delegation only" zone, it could generate a DNSKEY with the
   DELEGATION_ONLY flag set, indicating a verifiable promise to the
   world that will not sign any records other than delegation records.

   Authoritative Child / Delegated Zone: child zones existing underneath
   a marked delegation-only zone get the added benefit of knowing their
   parent will not (and cannot) sign DNS records within the child's
   portion of the DNS tree using the marked DNSKEY.

   Validating Resolver: A validating that supports verifying the
   DELEGATION_ONLY flag is capable of rejecting or discarding any data
   from an authoritative parent that incorrectly signs non-delegation
   records too low in the DNS tree.  If the validating resolver supports
   a (future-defined) DNSSEC transparency audit log as well, it may
   submit the appropriate data to a DNSSEC transparency log that
   appropriately tracks DNSSEC signatures.

   DNSSEC Transparency Log (optional future): a DNSSEC transparency log
   would create a non-modifiable trace of log entries submitted to it,
   for public verification, similar to [RFC6962].  What it chooses to
   accept into its log might be only certain zone data, or any zone with
   a marked DNSKEY.

   Note that without a DNSSEC Log, the DELEGATION_ONLY flag is still
   useful per the discussion in the Validating Resolvers role: the
   resolver will reject incorrectly signed, non-delegation data.
   However, malicious parent zones are still capable of creating two (or
   more) DNSKEYs, one with the DELEGATION_ONLY flag and one without.
   However, they would also have to publish those DS records as well,
   which is detectable by DNSSEC monitoring platforms, regardless of the
   existence of a DNSSEC Transparency Log.  Any zone with multiple DS
   records that link to both a DELEGATION_ONLY marked and an unmarked
   DNSKEY would be considered suspicious (or at least in transition).
   Circumventing this through obfuscation would require the collusion of
   their parent as well.  Finally, a DELEGATION_ONLY flagged DNSKEY for
   the root zone cannot be overridden easily, as it would require a
   trust anchor update in all validating resolvers.

-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 30 Apr 2020 14:45:46 -0700

Tim Wicinski <[email-masked]> writes:

> Following up on Petr's suggestion that the "DNSEC Transparency" mechanism is documented
> and somewhat tested. 

FYI, the new version (-04) that I just published hopefully clarifies
better why this draft is useful with or without DNSEC Transparency.
DNSSEC Transparency would certainly be helpful for auditing purposes.
But protection is provided to validating resolvers even without it.  And
yes, DNSSEC Transparency probably needs our draft in order to reach scalability.
-- 
Wes Hardaker
USC/ISI

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Apr 2020 18:17:33 -0400

Hi Wes.

> first three sections below, which are the parts that really changed.

Thanks! It's on the list :-)

> fascinating :-)

Well, no. I was really concerned that it would be of no help at all whilst simultaneously sounding tremendously necessary ("transparency!"), and that it might have collateral damage.

> cause harm.

Well, for example there are some 28,000 examples of orphan glue in the ORG zone. There are about 93,000 across all gTLDs. I haven't analysed these orphan glue records in any useful detail (that's on the list, too :-) but I'm wary of assuming that they could all be safely suppressed without harming any other delegation.

Anyway, thanks for the edits; I will send comments back to the list when I've had a chance to read them thoroughly.

Joe

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 30 Apr 2020 15:39:20 -0700

Joe Abley <[email-masked]> writes:

> Well, for example there are some 28,000 examples of orphan glue in the
> ORG zone.

Yep, I suspect some of the bigger TLDs probably couldn't opt in to this
draft simply because they're full of, um, "history".  Until that history
is cleaned, they probably couldn't deploy it.

> Anyway, thanks for the edits; I will send comments back to the list
> when I've had a chance to read them thoroughly.

Great!
-- 
Wes Hardaker
USC/ISI

---

From: Mark Andrews <[email-masked]>
Date: Fri, 1 May 2020 09:52:35 +1000

> On 1 May 2020, at 08:39, Wes Hardaker <[email-masked]> wrote:
> 

I doubt there is any real history here other than “we didn’t properly clean
up the records when the delegation was removed”.  If a DNS provider goes belly
up then all the zones dependent on that provider should FAIL.  Its just poor
zone hygiene that leaves orphaned glue in the ORG zone.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Apr 2020 20:07:12 -0400

Hi Mark,

> zone hygiene that leaves orphaned glue in the ORG zone.

I don't want to speculate on the actual reasons that orphan glue exists in the ORG zone before actually taking the time to investigate, but I'll note that the EPP data model provides some constraints around host objects and domain objects (e.g. domain objects can't be deleted when there subordinate host objects that exist) and there are reasons for delegations to be removed from the TLD zone while the corresponding domain object in the registry still exists (e.g. as part of domains that are suspended through the normal processes by registrars when they are found to be abusive).

I also don't understand the theory that any of these glue records exist because a DNS provider ceases operations. DNS providers don't feature in the RRR model. A failure in a set of nameservers could cause delegations to become lame, but there is no process that I'm aware of where orphan glue is a direct or necessary consequence.

Anyway, I am fairly confident in saying that there are legitimate, normal operational processes that can result in orphan glue, and that it's not correct to infer that they all exist for reasons of poor hygiene.

This is a topic of interest in a number of places right now. It is definitely on the list of things to investigate.

Joe

---

From: "John Levine" <[email-masked]>
Date: 30 Apr 2020 21:44:27 -0400

>is cleaned, they probably couldn't deploy it.

It's not just history.  All of the nominet TLDs and many Verisign TLDs
have signed A records that are clearly deliberate.  There's also a fair
number of TXT records named zz--zz.<domain> that have some sort of info
about when the zone was updated.

I think it's benign to allow any sort of record as an immediate child
of the domain, since you need to go two levels down for split zones.
That handes the nominet and zz--zz cases.

R's,
John