that to distinguish it from "DNS Load Balancing".
>
> There is certainly some overlap between these notions (as each can be used
> to implement the other in some fashion), but I would prefer to let both
> topics mature separately for now.
>
> --Ben
> ---
Hi folks,
I noticed the momentum on DNS load balancing and NS selection topics. Our
co-authors have just compiled a draft summarizing the research findings and
best practices in this field, and made some recommendations for developers
on secure and robust NS selection algorithms. Comments are welc
Hi Paul,
I’m sending this email off-list to respond to your comment.
davey, "another indirection" means both more round trips and more
> complexity,
> and will find few friends.
>
I do hope the DNS caters to the requirements without another indirection. I
said "another indirection" because peopl
People add tricks to DNS when DNS does not fit their needs. However, my
customers complained about the difficulties of deploying their DNS on
multiple platforms with different DNS tricks (GeoDNS for example) or
switching from one another.
I agree with Joe. DNS is a layer of indirection. If one ind
Hi Ben,
Good to hear from you about the side meeting on DNS load balance. We
recently came up with a draft on the security and robustness of the NS
selection algorithm and will submit it soon with the final editing.
Is this side meeting accessible on line? Looking forward to hearing from
your gu
> nothing prevents the use of RRSERIAL and NSID in the
> resolvers. Last paragraph of RFC5001 section 2.2 says so,
Yes. Thanks for pointing it out.
> and in
> version -01 of this draft there'll be a relaxation by declaring the
> use of rrserial in resolvers as undefined
>
I'm looking forward to
Hi Hugo,
I like this draft. And I will continue to review and comment when you have
new versions.
Generally, it is helpful to figures out who answer my queries in the
troubleshooting process. So the draft is helpful if out-of-sync occurs
between authoritative servers, such as Hidden Masters, prim
> If a resolver is doing RFC 8806, it knows what address to prime from:
> itself.
Yes. We know it prime to itself, or a specified address which is not the
address of the root servers. It depends on the local settings.
RFC8109 and draft-8109bis says in section-2 which gives an assumption that
pri
If the new draft of priming exchange considers and makes clarification on
the setting of a local resolver like rfc7706, then +1.
Davey
On Wed, 1 Jul 2020 at 07:40, Paul Hoffman wrote:
> Greetings again. Since RFC 8109 has been published, there has been more
> discussion of what DNS priming mean
Dear Paul,
On Wed, 17 Jun 2020 at 00:03, Paul Vixie wrote:
>
> i've described this to you (when you were at BII) several times as a kind
> of
> microtransfer or lease, where cooperating initiators (RDNS in this case)
> and
> responders (ADNS in this case) can agree on a NOTIFY TSIG key to be us
Hi folks,
I happened to run into a discussion of behaviors of Hybrid Resolver/ DNS
invariants where some of the non-typical uses of DNS are listed, especially
on the resolver. I'm encouraged to put them down as a requirement draft of
these uses of DNS and ask the mailing list whether it is a good
IMHO, public DNS is not a technical jargon which needs a DNS terminology
RFC to record (it collects all DNS definition and terms from other DNS
RFC).
The term "Public DNS" or "Public DNS service" belongs to the scope of how
people provide and operate DNS services to their best interests. There ar
>
> Davey - if there is a pervasive/omnipresent man-in-the-middle attacker,
> then no security protocol (DNSSEC, TLS, HTTPS or any other) can
> _prevent_ the attack. All they can do is to _detect_ that an attack is
> taking
> place (and probably abort).
>
> Shumon.
>
Fair enough.
Davey
>
___
That language could probably use some clarification. I would interpret
> "if .. none of the RRSIGs can be validated" as "if .. none of the RRSIGs
> can be validated from _any_ of the authority servers". In practice, every
> validating resolver I'm familiar with will retry other servers upon
> signa
> I think you mean if you receive a BOGUS validation result (eg missing
> RRSIG records, or otherwise are not getting the records needed for proof
> of non-existance or signatures. In that case, I think the existing
> DNS protocol already tells you to try other servers?
>
According to RFC4035 sect
Hi folks,
As far as I know, in DNSSEC the validating resolver is able to identify a
Bad response if signatures do not validate. But it unable to retrieve the
good one for stub resolver if there are other alternatives.
I'm thinking about a draft proposal if signatures do not validate, the
validati
can't access it.
>
> tim
>
>
> On Tue, Apr 21, 2020 at 9:24 AM Davey Song wrote:
>
>> Hi Tim,
>>
>> Thanks for the information. Do you konw is there any audio or video
>> record of this vriturl meeting availalbe?
>>
>> Davey
>>
>>
Hi Tim,
Thanks for the information. Do you konw is there any audio or video record
of this vriturl meeting availalbe?
Davey
On Sun, 19 Apr 2020 at 05:11, Tim Wicinski wrote:
>
> All
>
> I've gone back over the minutes and have uploaded them to the data tracker:
>
> https://datatracker.ietf.org
Some concerns and comments:
1) It sounds to me that the primary targeted outage described in this draft
is on the authoritative server during DDOS attack especially. Think about a
case of outage of resolver due to a failure in its network path to the
authoritative server. Normally end user h
May I ask why dnsop only has 1 slot (2 hours) this time for IETF BKK? for
such a busy working group I mean. Is there any time slot available?
Davey
On Sat, 20 Oct 2018 at 17:46, Tim Wicinski wrote:
>
> All,
>
> We uploaded a rough outline of an agenda based on requests which came in.
> It is th
Hi folks,
I put the thought of IPv6 GeoIP in an draft. I think it more related to
dnsop wg. Hope you like it.
Best regards,
Davey
-- Forwarded message -
From:
Date: Tue, 23 Oct 2018 at 02:46
Subject: New Version Notification for draft-song-dnsop-dualstack-ecs-00.txt
To: Weijian
Hi all,
Recently I'm engaged in a project on the issue of IPv6 GeoIP for a large
Internet company. IPv6 GeoIP is identified as an notable chanllge to
mitigate their Geolocation-based application to IPv6. I come up with a idea
to summarize the existing practice and propsed technologies into a
infor
Hi Tommy,
Thanks for your suggestions.
On Wed, 26 Sep 2018 at 23:38, Tommy Pauly wrote:
> +1 to the point that the proposal for NHE is essentially a mechanism for
> the ISP and/or content provider to work around a broken deployment that
> they should be in a position to fix themselves, or betwe
Hi Barbara,
Thanks for your comments and sharing. I need to note that NHE is not
competing with
Client-side HE or competing with deployment of fully functioning IPv6. The
background of
NHE is :
1) the dualstack is real. Client is facing the choice ipv4 or ipv6.
2) the poor or unpredictable IPv6 p
> If we’re discussing host based versus network based happy eyeballs, would
> it be naive to think that the network based HE would interfere with the
> client’s HE?
>
Currently this draft only considers IPv4/IPv6 racing situation. The general
address
racing is already done for all clients (rfc6724
, I'm more neutral. Maybe, we
> > >> actually don't want modified, better happy eyeballs, because we want
> > >> simpler, more deterministic network stack outcomes with less bias
> > >> hooks?
> > >>
> > >> I barely register if I
>
> But in the general case the network cannot.
> Think host multi-homing.
>
Yes or no.
Generally speaking the races of IPv6 and IPv4 connections on both network
and client are going to be suffered by netowrk dynamics, including
Multi-homing, route flaps, roaming, or other network falilures. Ext
>
> This hints at a general misunderstanding on how "The Internet" works.
>
> Talking to the local ISP on "what would you recommend, IPv4 or IPv6?"
> can give an indication, but if the server you're trying to talk to
> is on the other side of the world, the local ISP's preference for
> IPv4-vs-IPv6
To get to know the current status of HE , I did a simple test on my handy
devices visit top 20 website or open existing apps (currently only DNS). I
captured &A DNS query pairs (intervel less than 10s) and count HE query
pairs whoes interval less than 100ms. There is a prelimiary result:
1) My
Hi Jinmei,
Thanks for your comments. I once had same questions in my mind when this
draft is conceived. I reply inline.
Some quick observations:
>
> - I don't see why the intended status is Standards Track. It seems to
> be a document about an operational practice rather than a new
> protoco
I think people here may be intereted in this draft as well. Comments are
welcome.
Davey
-- Forwarded message -
From: Davey Song
Date: Fri, 21 Sep 2018 at 14:31
Subject: Fwd: New Version Notification for
draft-v6ops-xie-network-happyeyeballs-00.txt
To:
Hi folks,
I just
Hi folks,
After IETF102, this draft got some support and interests in the room. And
Chair marked it as "andidate for adoption, though more contentious."
02 version reflects the feadback I collected . The major changes are as
follows:
o Remove the section of introduction of AT bit as well as r
On Fri, 27 Jul 2018 at 12:04, Evan Hunt wrote:
> On Fri, Jul 27, 2018 at 11:24:33AM +0800, Davey Song wrote:
> > The draft says zone digest is not for protecting zone transmition.
>
> Where did it say that? I didn't notice it.
>
I mean zone digest is not for zone tr
The draft says zone digest is not for protecting zone transmition. IMHO,
the treat model is MITM attack by malicious editing on on-disk data (NS
and glue especially) and server the new zone to end user. DNS digest
intends to enable end users (resolvers) automatically detect the
modifation ( and d
>
> The problem is that when you have every recursive server in the world with
> a copy of the root zone from “random places” you want to reduce the
> possible error spaces into manageable chunks when things go wrong which
> they will. Being able to verify the contents of the root zone you have ar
> - It was not really clear exactly what kind of problem this digest
>tries to solve, especially given that the primarily intended usage
>is for the root zone, which is DNSSEC-signed with NSEC.
>
It puzzled me as well.
It is said in the document that diffferent from DNSSEC (and NSEC), the
Hi folks,
I just update ATR-draft to 01 version with the help of some reviewers and
their comments. I would like to ask if there are enough pepole here think
it is a good document to work on.
As background, ATR was firstly proposed on september 2017 to address Large
DNS response issues in IPv6.
On 7 April 2018 at 07:29, Paul Vixie wrote:
>
>
> i am generally supportive of this approach; in fact i wish i'd thought of
> it. the specifics will be different, as in:
>
> /proxy_dns?proto=tcp
> /proxy_dns?proto=udp
>
> but i agree that encoding the original transport in the URI is better than
>
I'm sorry to hear that. I would like to provide some information as a
background if it's useful.
dns-wireformat-http draft was originally proposed in DNSOP WG as a
experimental draft in early 2016. We focus on the requirement of enhancing
DNS availability bypassing the middlebox on the path via HT
On 3 April 2018 at 17:58, Martin Thomson wrote:
> If I understand your response (not sure that I do), that seems pretty
> academic and not at all persuasive. For instance, if a client cared
> about testing TCP capabilities, it can always do its own resolution.
It's not the emphasis. Peopole ge
On 3 April 2018 at 15:33, Martin Thomson wrote:
> This is intended to do what? Indicate where the response came from?
> Why does the client care?
To keep the proxy (API client and server) transparent and bypass the
middlebox along the path. Without the indicate, the API server has no clue
what
>
>
> Not quite.
>content-type: application/dns-udpwireformat; original_transport=tcp
>
Yes. That's right. I will give a example like that.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hi Paul,
It sounds reasonable as we discussed before.
Best regards,
Davey
On 26 March 2018 at 13:48, Paul Hoffman wrote:
> Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining a
> new media type seems like overkill, particularly given that it will be
> transporting *the exact s
Flattered to be mentioned. Specially thanks to Geoff and Joao for their
effort to demontrate ATR with measurement and facts. You did what I desired
but failed to do.
If you think ATR is worth of doing, I'm looking forward to more comments to
improve it towards a formal document.
-Davey
On 22 Marc
Thanks for your advice.
Davey
Bob Harold 于 2018年3月22日周四 22:41写道：
>
> On Wed, Mar 21, 2018 at 9:36 PM, Davey Song wrote:
>
>> Hi folks,
>>
>> I just submit a updated version of dns wireformat over HTTP. This draft
>> has been adopted as the dnsop wg docu
.
Davey
On 22 March 2018 at 18:23, Dave Lawrence wrote:
> Davey Song writes:
> > Is a media type "application/dns-tcpwireformat" acceptable
>
> Without yet having (re-)read the draft, I'm unclear on what benefit
> this media type is bringing over dns-udpwirefo
Hi folks,
I just submit a updated version of dns wireformat over HTTP. This draft has
been adopted as the dnsop wg document for quite a while before DOH. The
original intention of this draft is to explore the possiblity of DNS over
HTTP(s) use cases and demonstrate its capacity as an experimental
Hi folks,
I just submit a draft dealing with issue of large DNS response especially
in IPv6. Commnets are welcome.
If chairs think it is in the scope of dnsop wg and encourage us to discuss
it in this mailing list, I can submit it as a draft listed in dnsop wg.
Davey
-- Forwarded messa
Accroding to your description, I feel that IPv6 has better chance to win
than its "brother" DNSSEC. LoL
On 16 August 2017 at 14:48, Mukund Sivaraman wrote:
> On Wed, Aug 16, 2017 at 08:21:37AM +0200, Mikael Abrahamsson wrote:
> > On Wed, 16 Aug 2017, Mukund Sivaraman wrote:
> >
> > > 24 / 500 to
On 12 August 2017 at 23:42, Paul Vixie wrote:
>
>
> failing that level of commitment, the IETF ought to kill DNSSEC altogether.
>
> this is very similar to the "shall we had IPv6's features to IPv4, since
> V6 is
> taking so long to deploy, and these features are badly needed?" debate.
>
>
+1.
I
)
-Invite talk: IDN introduction and current status(Marc Blanchet)
-Yeti DNS Project status and development (Davey Song)
-Yeti experiment and findings (Shane Kerr)
Coffee break
-IPv6 issues in Yeti (Akira Kato)
-YmmV(Yeti Many Mirror Verifier) introduction (Shane Kerr
Hi Bob,
inline
On 6 July 2016 at 01:17, Bob Harold wrote:
>
> On Fri, Jul 1, 2016 at 3:51 AM, IETF Secretariat <
> ietf-secretariat-re...@ietf.org> wrote:
>
>>
>> The DNSOP WG has placed draft-song-dns-wireformat-http in state
>> Candidate for WG Adoption (entered by Tim Wicinski)
>>
>> The doc
Hi Colleagues,
Regarding the DNS wire-format over HTTP draft, the authors replied and
addressed all comments in the mailing list. The latest update (04) reflect
the comments on simplify the description of HTTP syntax and make the
protocol less tied related to HTTP version
Can I ask for a call for
Dear colleagues,
I've submitted a draft about the experience we got from Yeti DNS project.
Some technical findings are documented in separate documents like
IXFR-fallback draft I posted days ago. I am not requesting DNSOP adoption,
but I'd welcome any comments and suggestions.
Best regards,
Dave
Hi DNSOP colleagues,
I composed a draft describing a finding when people did experiment in Yeti
DNS project. I would like you know and hope to receive your valuable
comments.
Best regards,
Davey
-- Forwarded message --
From:
Date: 18 May 2016 at 09:18
Subject: New Version Notifi
Hi guys,
Thanks for the comments and discussion. I catch up them after holidays :)
I reply in line and cc Paul's comments to DNSOP WG mailing list, so that
we can continue to comment follow the same context in this mailing list.
Best regards,
Davey.
On 30 April 2016 at 06:23, Paul Vixie wrote
Hi Colleagues,
We have update the dns-wireformat draft according to the advice we gained
from last IETF meeting, changing the well-known URI from dns-over-http to
dns-wireformat according to Paul Hoffman's suggestion. Any further comments
? I would like to ask for WG to adopt it this time.
Best r
We have updated the draft as follows:
* fixed typos
* made "transport:" always required
* mentioned the possibility to use DNS over HTTP in a browser, if you
really want to
* made the language stronger when talking about the 2-byte length label in
TCP
* expanded the security considerations. We go
ere is middlebox misbehavior.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-song
ftware and proxy in the networks.
On Wed, Mar 2, 2016 at 6:04 PM, Davey Song wrote:
> According to RFC7231 (section 4.3.1), payload is not defined for GET and
> GET request with payload will be reject by some implementation (like google
> app
> engine) . It is not say GET should not
. Right?
On Wed, Mar 2, 2016 at 11:08 AM, P Vixie wrote:
> We did not use get because get does not have a request payload.
>
> On March 1, 2016 6:44:16 PM PST, Davey Song wrote:
>
>>
>>
>> On Tue, Mar 1, 2016 at 11:58 AM, Paul Hoffman
>> wrote:
>>
>>
On Tue, Mar 1, 2016 at 11:58 AM, Paul Hoffman wrote:
> This document is a good idea, but it has some faults that need to be fixed
> before it goes forwards.
>
> - In the Introduction, it says in essence that this is just using HTTP to
> tunnel DNS and is not of use to web browsers. This is wrong,
Thanks for Typo fix suggestion. I have some explanation inline to your
questions
> 3.2. Header Fields
> I am trying to understand why the recursive server would care whether the
> original query was UDP or TCP? Would it be concerned about source address
> spoofing?
> If the stub resolver is tal
Kevin
>
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Davey Song
> Sent: Tuesday, August 04, 2015 9:47 PM
> To: dnsop@ietf.org
> Subject: [DNSOP] About DNS over HTTP(s)
>
> Hi folks,
>
> As one of my own observation, there is a trend of using port h
ere might be some parameters need be added in DNS
over HTTP’s header, such as Host IP, UDP/TCP (http-proxy usage),
Json/Octet-stream etc .
Any suggestion please comment.
Best regards,
Davey
--
Davey Song(宋林健)
BII Lab
songlinj...@gmail.com
_
Oh, It's a great work and helpful as a collection of important DNS
terminology. It's not easy to choose the terminology from massive
DNS-related RFCs.
By the way, I notice the "Priming" is not included in the draft. I think it
is a common jargon(not documented yet) used in the community. There ma
On Fri, Nov 28, 2014 at 11:17 PM, Paul Hoffman
wrote:
> On Nov 28, 2014, at 1:25 AM, Davey Song wrote:
> > Yes, two pages is enough to address the problem with your suggestion. It
> actually turns off the EDNS0 during Priming Exchange, right ?
>
> No, not at all. EDNS0 is orth
Mark, thank you for your comments. Sorry for the late response. Please see
inline.
On Fri, Nov 28, 2014 at 6:14 AM, Mark Andrews wrote:
>
> In message , Paul Hoffman
> writes
> :
> > On Nov 26, 2014, at 11:18 AM, Davey Song wrote:
> > > Hi folks, I just post a dra
promising to become a start to evaluation of upgrading the whole DNS
system for more reasons like DNS privacy and prevention of DDoS attack.
Davey
On Fri, Nov 28, 2014 at 5:25 PM, Davey Song wrote:
> Hi Paul Hoffman, I appreciate your comments which touches the key point of
> my concern.
&
014, at 11:18 AM, Davey Song wrote:
> > Hi folks, I just post a draft on Priming Exchange over TCP. Comments are
> welcome!
>
> The proposed solution is not needed as long as the resolver that using the
> priming exchange can fall back to TCP. A different approach to th
On Fri, Nov 28, 2014 at 3:21 PM, Paul Vixie wrote:
>
> for example, if 13 is good, would 130 (10X) or 1300 (100X) be better?
> even with 1300 root name servers, the fallback to TCP after TC=1 in a
> priming query (even with EDNS) would only add one extra round trip over
> the three that are requi
Thanks Paul. Please see the reply in line.
On Thu, Nov 27, 2014 at 10:41 AM, Paul Vixie wrote:
>
>
> Davey Song
> Wednesday, November 26, 2014 11:18 AM
> Hi folks, I just post a draft on Priming Exchange over TCP. Comments are
> welcome!
>
>
> davey, your abst
Hi folks, I just post a draft on Priming Exchange over TCP. Comments are
welcome!
regards,
Davey
-- Forwarded message --
From:
Date: Thu, Nov 27, 2014 at 3:02 AM
Subject: I-D Action: draft-song-dnsop-tcp-primingexchange-00.txt
To: i-d-annou...@ietf.org
A New Internet-Draft is
On Wed, Aug 6, 2014 at 7:47 PM, Toerless Eckert wrote:
>
>
> c) Any example in which the DNS servers utilizing a single shared
>IP address (anycast address) are run by different operators ? Any
>documents describing this ? (RFC3258 seems to focus on single operator
>anycast group of D
74 matches
Mail list logo
