At Fri, 16 Oct 2015 17:07:27 +,
"Darcy Kevin (FCA)" wrote:
> Let's see, millions of full-service resolvers, times the
> packet-count differential between UDP and TCP, times the average
> reload/restart frequency of those full-service resolvers per
> day/week/month. Can't a case be made from s
I agree, the priming volume for a private enterprise is on a much smaller scale
than the public Internet. But, at the same time, a notable difference between
priming and normal DNS traffic (or mDNS, or ARP, etc.) is that priming traffic
is more likely to traverse WAN links (because, unlike the p
On 16 Oct 2015, at 16:36, Darcy Kevin (FCA) wrote:
It would be wise to get a clear statement of preference from the
Internet root operators on this, but don't forget that whatever gets
defined in IETF standards, and implemented in leading DNS software
packages, also affects private enterpris
It would be wise to get a clear statement of preference from the Internet root
operators on this, but don't forget that whatever gets defined in IETF
standards, and implemented in leading DNS software packages, also affects
private enterprises too. Many of us run internal roots and I, for one, d
Joe,
On Fri, 16 Oct 2015 15:06:50 -0400
"Joe Abley" wrote:
> On 16 Oct 2015, at 14:42, Shane Kerr wrote:
>
> > Seems like quite an easy attack at first blush. One could send a
> > constant stream of priming answers to resolvers since they would get
> > made once a day.
>
> The successful attac
On 16 Oct 2015, at 14:42, Shane Kerr wrote:
Seems like quite an easy attack at first blush. One could send a
constant stream of priming answers to resolvers since they would get
made once a day.
The successful attacks like this that I've seen rely upon being able to
trigger a particular que
PaulOn Friday, October 16, 2015 11:47:54 Hoffman wrote:
> On 16 Oct 2015, at 11:30, Paul Vixie wrote:
>
> > i don't want tcp tried first, ever. i understand that tcp would be
> > tried
> > first, for new-fangled clients who want to try to negotiate persistent
> > tcp.
> > but that should not incl
On 16 Oct 2015, at 11:30, Paul Vixie wrote:
On Friday, October 16, 2015 13:58:00 Joe Abley wrote:
On 16 Oct 2015, at 13:15, Paul Hoffman wrote:
On 16 Oct 2015, at 10:07, Darcy Kevin (FCA) wrote:
Let's see, millions of full-service resolvers, times the
packet-count
differential between UDP an
Joe,
On Fri, 16 Oct 2015 13:58:00 -0400
"Joe Abley" wrote:
> On 16 Oct 2015, at 13:15, Paul Hoffman wrote:
>
> > On 16 Oct 2015, at 10:07, Darcy Kevin (FCA) wrote:
> >
> >> Let's see, millions of full-service resolvers, times the packet-count
> >> differential between UDP and TCP, times the av
On Friday, October 16, 2015 13:58:00 Joe Abley wrote:
> On 16 Oct 2015, at 13:15, Paul Hoffman wrote:
> > On 16 Oct 2015, at 10:07, Darcy Kevin (FCA) wrote:
> >> Let's see, millions of full-service resolvers, times the packet-count
> >> differential between UDP and TCP, times the average reload/res
On 16 Oct 2015, at 13:15, Paul Hoffman wrote:
On 16 Oct 2015, at 10:07, Darcy Kevin (FCA) wrote:
Let's see, millions of full-service resolvers, times the packet-count
differential between UDP and TCP, times the average reload/restart
frequency of those full-service resolvers per day/week/mo
Warren,
On Thu, 15 Oct 2015 13:53:51 -0400
Warren Kumari wrote:
> I wanted to mention a document that Geoff and I wrote a few weeks back:
>
> draft-wkumari-dnsop-cheese-shop-00 - "Believing NSEC records in the
> DNS root" - https://datatracker.ietf.org/doc/draft-wkumari-dnsop-cheese-shop/
>
> B
On 16 Oct 2015, at 10:07, Darcy Kevin (FCA) wrote:
Let's see, millions of full-service resolvers, times the packet-count
differential between UDP and TCP, times the average reload/restart
frequency of those full-service resolvers per day/week/month. Can't a
case be made from sheer volume?
Th
Let's see, millions of full-service resolvers, times the packet-count
differential between UDP and TCP, times the average reload/restart frequency of
those full-service resolvers per day/week/month. Can't a case be made from
sheer volume?
Sorry for bringing math into the discussion.
At Fri, 16 Oct 2015 08:35:30 -0700,
Paul Vixie wrote:
> > I have separate issue, which is this text:
> >
> > The priming query MUST be sent over UDP (section 6.1.3.2 of
> > [RFC1123]).
> >
> > This seems like a super-strong recommendation that doesn't actually
> > help anything in operati
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 Working Group
of the IETF.
Title : Reverse DNS in IPv6 for Internet Service Providers
Author : Lee Howard
Fil
Shane Kerr wrote:
> ...
>
>>
>>
>> Greetings. The WG has a draft, draft-ietf-dnsop-resolver-priming, which
>> has somewhat fallen off the table, and it is time to bring it back. The
>> draft has two identified open issues, and the authors would like the WG
>> to clear those up before issuing
On 15 Oct 2015, at 20:06, Paul Hoffman wrote:
The two open issues are in Section 4:
4. Requirements for Root Name Servers and the Root Zone
I think it might be worth stepping up a level here and understanding
what this document can reasonably specify.
2870 has long been recognised to be
On Thu, Oct 15, 2015 at 8:06 PM, Paul Hoffman wrote:
>
>
> Greetings. The WG has a draft, draft-ietf-dnsop-resolver-priming, which
> has somewhat fallen off the table, and it is time to bring it back. The
> draft has two identified open issues, and the authors would like the WG to
> clear those
Paul,
Thanks for not letting this document die. :)
On Thu, 15 Oct 2015 17:06:11 -0700
"Paul Hoffman" wrote:
>
>
> Greetings. The WG has a draft, draft-ietf-dnsop-resolver-priming, which
> has somewhat fallen off the table, and it is time to bring it back. The
> draft has two identified open
FYI. I once proposed this in draft-davey-sunset4-ipv6onlydns-00.
3.2. IPv6-aware DNS Referral Response Mechanism
In section 2.2, due to the limitation of DNS referral response size,it may
occur that when new NS server updated to IPv6, the address cannot be carry in
the referral response in the
> On 15 Oct 2015, at 18:00, 神明達哉 wrote:
>
> I see your point. But whether the updated notification from the
> server works relies on whether the client includes an OPT RR in
> subsequent queries, ambiguity on the latter can easily lead to
> interoperability problem. So I thought this should be
Mark Andrews wrote:
> In message <8149bc4d-f11e-4e4f-bbb8-c38d865a4...@vpnc.org>, "Paul Hoffman"
> writ
> es:
> >
> > If the response packet does not provide for more than 512 octets due
> > to lack of EDNS0 support, A RRSets SHOULD be given preference over
> > RRSets when fillin
23 matches
Mail list logo
