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
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
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
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
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
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
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
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
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
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
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 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 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 use 2119
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, large
On 15Feb15, Paul Hoffman allegedly wrote:
secretary hat on
On Feb 15, 2015, at 4:49 AM, Suzanne Woolf suzworldw...@gmail.com 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:
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 are
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
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
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 SCOPE
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 if
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 proposed
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't
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
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 decade
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 very
30 matches
Mail list logo
