In message <[email protected]>, "Wessels, Duane" writes: > > > On Feb 29, 2016, at 3:36 PM, Mark Andrews <[email protected]> wrote: > > > > > > In message <[email protected]>, "John Levine" writes: > >>> You could apply the technique to any signed zone where you are not > >>> worried about not having instant visibility after adding a new name > >>> to the zone. > >> > >> I don't understand this. If I ask for foo.example and get NXDOMAIN, > >> and 10 ms later you add a record at foo.example, my negative answer is > >> cached for your SOA TTL is. Using NSEC to synthesize responses > >> doesn't fundamentally change the situation, it just increases the set > >> of names that negative cache entries will cover and maybe changes the > >> time if the NSEC and SOA TTLs are different. Unless all of your TTLs > >> are zero, there's no such thing as a new name that's instantly visible > >> to every client. > > > > For 99.999999999% of names you don't look them up unless you have > > a priori knowledge that the name exist. This means you don't have > > many NXDOMAIN records in a cache sans DoS attacks, prefixes to known > > names (e.g. TLSA for service) and Internet reachability tests using > > the DNS etc. Even with search lists you are looking for a known > > name with a set of suffixes. You are not looking for unknown names. > > [CITATION NEEDED] Please? > > Actual data seems to tell a different story: > > $ sudo tcpdump -n -i eth0 -c 10 dst host a.root-servers.net and src host > 74.125.74.4 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 00:14:53.448321 IP 74.125.74.4.36867 > 198.41.0.4.domain: 53200 [1au] A? > u2t11ngt0b-7j.unarubxvgjclkbxmgmfim.tv.adelina.local. (81) > 00:14:53.609935 IP 74.125.74.4.60074 > 198.41.0.4.domain: 47352 [1au] A? > cid:4104657c5b1627c4161ccc7fcb012308.box. (69) > 00:14:53.767055 IP 74.125.74.4.64713 > 198.41.0.4.domain: 30524 [1au] > AAAA? eait3235vr0vk.clients3.google.com.gp3.s86.loc. (74) > 00:14:53.953686 IP 74.125.74.4.49501 > 198.41.0.4.domain: 8537 [1au] SRV? > _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.teh-system.local. (97) > 00:14:54.095375 IP 74.125.74.4.49952 > 198.41.0.4.domain: 35033 [1au] > AAAA? g2xkqe1z1kj1h.ups.virool.com.gbiad. (63) > 00:14:54.096339 IP 74.125.74.4.59901 > 198.41.0.4.domain: 6762 [1au] A? > HH.gkab.loc. (40) > 00:14:54.143732 IP 74.125.74.4.49996 > 198.41.0.4.domain: 42468 A? > q2jv2af4g-jzh.dns1.be.weather.com. (51) > 00:14:54.231436 IP 74.125.74.4.42995 > 198.41.0.4.domain: 52187 [1au] > AAAA? oobca2949e5mc.bd.unba.lan. (54) > 00:14:54.238082 IP 74.125.74.4.54627 > 198.41.0.4.domain: 47410 A? > byz-372osga4d.dns3.be.weather.com. (51) > 00:14:54.321907 IP 74.125.74.4.64277 > 198.41.0.4.domain: 62335 [1au] > SRV? neesb94pfizrq._ldap._tcp.us179._sites.dc._msdcs.gvsucentr.corp. (91)
I see nothing there that disproves my statement. There are lots of leaked names but nothing that says that the lookup wasn't based on a known name. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
