On 09Jan25, Edward Lewis apparently wrote:
> One option (blue sky again) is to switch to an arrangement where the server,
> for
> synthetic or tailored responses, reply with a formula (function).
(Haven't we talked about this in previous threads?)
I guess my first question is, what constitutes
On 13Mar24, Mark Andrews apparently wrote:
> > ways. For applications like CDNs, you need two or three link CNAME
> > chains and nobody appears to find that a problem.
>
> Actually it is a problem. It results in lots of additional lookups.
> of this. All of the CNAMES could be done in the backg
On 19Jan24, Dave Lawrence apparently wrote:
> Mark Andrews writes:
> > It’s a couple of lines of code in a nameserver to support QCOUNT=0.
> > It will take more time debating this than it took to implement
> > support for QCOUNT=0.
>
> Miek Gieben writes:
> > yes, please, the amount of code that d
On 10Nov23, Paul Wouters apparently wrote:
> > I'd like to write a draft that updates RFC 9156 by describing situations
> > like this that caches could recognize and avoid useless churn, added to
> > section 2.3 which already suggests special casing underscored labels.
>
> Couldn't the RBL's add a
On 05May23, Warren Kumari apparently wrote:
> I think that a parent should check if the name servers that are
> being proposed actually answer for the domain[0], and strongly
> suggest (but do not prevent) that that be fixed[1].
"Strongly suggest" is definitely as far as I would go because you ma
On 03May23, Edward Lewis apparently wrote:
> > Was any "lame" situation defined which wasn't the result of a bad
> > configuration?
> The difference between observing a symptom and diagnosing a cause is
> great. I say this to caution against tying the "why it is" with
> "what it is."
This is a g
On 01May23, John Kristoff apparently wrote:
> (usually due to a bad configuration)
Was any "lame" situation defined which wasn't the result of a bad configuration?
As I understand it from this discussion, all "lame" delegations require a
config change to
rectify, but not all mis-configurations i
On 11Apr23, Warren Kumari apparently wrote:
> lame delegation
> lame server
Notwithstanding an unresponsive/unreachable server, perhaps due to an ephemeral
network
error, is there any scenario where a misconfigured server is not described as
lame in some
way?
Put another way, fixing a lame sit
On 03Apr23, Viktor Dukhovni apparently wrote:
> I believe that the most natural perspective is from the view point of a
> resolver attempting to classify a (non?)response to a query sent to an
> authoritative server.
It is certainly true that a resolver detects a lame delegation and has to deal
On 03Apr23, Wessels, Duane apparently wrote:
> Naturally, we turned to RFC 8499, DNS Terminology, but found the entry not
> particularly helpful
Having recently been involved in writing a tool to check delegations and report
errors in
a "call to action" way for generalist admins, I agree that t
On 16Feb23, Dick Franks allegedly wrote:
> The last statement is informatively and normatively mistaken.
> The counterexample is to be found in RFC8490(5.4):
>
> A DSO message begins with the standard twelve-byte DNS message header
> [RFC1035] with the OPCODE field set to the DSO OPCODE (6).
On 29Jul21, Geoff Huston allegedly wrote:
> For me it appears to depend on the actions of the resolver as to whether this
> would be faster
> or not. If all resolvers blindly re-query using TCP for all UDP responses
> where TC=1 is seen in
I'm not sure I follow this bit. Are you merely implying
On 31Aug19, Wes Hardaker allegedly wrote:
> Naveen Kottapalli writes:
>
> > Can one of you tell why would a v4 client send query or a by client
> > send a
> > A query when the resolved address cannot be used?
>
> As others have pointed out it's very common.
>
> As an example, I looked at
> > And since shane-review states:
> >
> > "This memo reviews the possible approaches..."
> >
> > I take it to mean that shane-review could encompass implementations
> > like dpriv that imply or propose out-of-order. If that is the case ...
>
> no.
Then I'd like to suggest a "yes" for this
On 20Dec15, Paul Vixie allegedly wrote:
> since DNS-over-HTTP does not call for out-of-order HTTP responses
But at least according to dpriv:
"Since pipelined responses can arrive out-of-order, clients MUST
match responses to outstanding queries using the ID field, query
name, type, a
On 17Dec15, Paul Vixie allegedly wrote:
> > That the request pipeline order doesn't necesarily match the response
> > pipeline order is particularly unexpected in some protocols (and
> > likely non-compliant), such as HTTP < 2.0
>
> i think this is opaque to the dns-over-http specification. that
It might be obvious to most, but should there be a section on
out-of-order processing of requests?
That the request pipeline order doesn't necesarily match the response
pipeline order is particularly unexpected in some protocols (and
likely non-compliant), such as HTTP < 2.0
Mark.
_
On 16Jul15, Dave Lawrence allegedly wrote:
> > I would think that if we're to proceed with this protocol then the
> > white list requirement should be removed from the spec.
>
> I don't see language in the current draft that makes a whitelist a
> requirement. The language I do see doesn't even us
On 06Jul15, internet-dra...@ietf.org allegedly wrote:
>
> 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 : Client Subnet in DNS Queries
>
On 01Apr15, Stephane Bortzmeyer allegedly wrote:
> [I am not a big fan of the idea, because I see it as useful mostly for
> big public resolvers and I am not a big fan of big public resolvers.]
It's also useful for big "private" resolvers too. Such as those run by
ISPs, mobile phone networks, larg
On 26Mar15, David C Lawrence allegedly wrote:
> At IETF this week it was decided to refocus the effort on the
> edns-client-subnet draft on only documenting the existing behaviour of
> deployed implementations.
That's disappointing and somewhat at odds with the theme of the
on-list discussions sin
On 15Feb15, Paul Hoffman allegedly wrote:
>
>
> On Feb 15, 2015, at 4:49 AM, Suzanne Woolf wrote:
> >
> > The WG adopted this document some time ago (the announcement to the list is
> > dated Nov. 14, 2014).
>
> Yep, and the authors turned in an WG-named draft:
> https://tools.ietf.org/html
On 12Feb15, George Michaelson allegedly wrote:
>
> we've got two agencies who do DNS, and probably have > 20% worldwide
> eyeball share in DNS (I don't know, thats a guesstimate) now doing
> edns0_client_subnet albiet with whitelist, so its a permit-list, but its
> functionally 'there'
Whitelists
On 24Dec14, Mark Delany allegedly wrote:
> > The draft is available here:
> > http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
>
> a) 6.2 - Intent of SCOPE NETMASK
>
> "In both cases, the value of the SCOPE NETMASK in the reply has
> Why do you think this? RFC 103[45] has client initiated shutdown.
> The client sends out x queries withe unique ids. It waits for
> responses to all of them. It then closes the connection. The
> client still has to cope with the connection being closed early.
Indeed. Please let's not go down
On 25Jan15, John Heidemann allegedly wrote:
> I think these statements are both overly strong. They both suggest
> that careful signaling is required before deploying DNS over TCP with
> pipelining or
> persistence.
If virtually no initiators send multiple requests then your conclusion
seems re
On 24Jan15, Paul Vixie allegedly wrote:
> could violate older implementations' reasonable-at-the-time assumptions,
> against the burden of choosing a non-interfering signal pattern, like a
> new port number, or a new protocol verb.
Does it have to be that drastic? Wouldn't an EDNS option "I under
> The draft is available here:
> http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
a) 6.2 - Intent of SCOPE NETMASK
"In both cases, the value of the SCOPE NETMASK in the reply has strong
implications with regard to how the reply will be cached"
I wonder whether SCO
On 24Jul14, Kevin Darcy allegedly wrote:
> So, if the TTL on the record were higher than the queue-expire setting
> of the MTA, wouldn't the *intelligent* strategy be to promote the
> tempfail to a permfail?
Most SMTP clients use a DNS cache so they have no idea what the
original TTL is.
Even i
In message <53cfbb29.7040...@chrysler.com>, Kevin Darcy writes:
> Potentially dumb question: what does this "magic meaning" MX target
> (".") offer, that a target resolving to a null address (0.0.0.0 and/or
> ::0) does not? No protocol or code changes required.
And just to be clear, nullmx as pr
> I think it would be great to have this document use ?no-mail.invalid.? as the
> domain name rather
> than ?.? in the MX record i.e.
> foo.bar.example MX 0 no-mail.invalid.
>
> But this is just a question of preference and installed base.
The aspirations of this document were far more
> one can lookup A, and SRV in parallel and positive answer
> to SRV, as Paul mentioned, can have additional A and RRs.
A downside is that clients has to wait for the SRV query to complete
so they can be sure of the presence or not of an SRV. First-win
approaches like happy eyeballs don'
On 17May14, Mark Andrews allegedly wrote:
>
> domain ENAME domain {0|1} [type list of included / excluded types]
> (0 == include, 1 == exclude)
As I recall, the HTTP/2.0 folks have been intermittently talking about
supporting SRV. Would encouraging that group on that front be
> > I see now that some newer CPE defaults to 8.8.8.8 - at least that
> > eliminates the local implementation bugs...
>
> And I would have gone ahead and implemented it as Autralian Consumer
> Law
Probably true for most jurisdictions running u-verse modems too as
they too had breakage in my (not
On 19Feb14, Mark Andrews allegedly wrote:
> The process for getting a new type hasn't been *hard* for a decade
> now.
>
> Nameserver developers have been deploying new types quickly for
> over a decade now.
>
> Recursive servers have had the bugs w.r.t. handling unknown types
> removed over a dec
35 matches
Mail list logo
