Mr Paul is correct - getdns is the best path for developers.
On Thu, Nov 8, 2018 at 1:07 AM Paul Vixie wrote:
>
>
> Tony Finch wrote:
> > ...
> >
> > And even if you can get the recursive server addresses, you should still
> > go through the name service switch to deal with names that aren't in
This is such a salient point, and always draws me back towards a desire
for accompanying questions. They wouldn't directly address exactly the
issue handled by ANAME (the addresses of one host corresponding to those
of a distinct [probably out-of-bailiwick] name), but might make it
moot—or at
Tony Finch wrote:
...
And even if you can get the recursive server addresses, you should still
go through the name service switch to deal with names that aren't in the
DNS.
agreed.
The custom DNS stub resolvers that I know about (adns, ldns, libevent)
reimplement the libc resolver, with
Vladimír Čunát wrote:
> On 11/7/18 4:00 PM, Matthew Pounsett wrote:
> > Can you point to a major browser that does *not* implement its own
> > resolver already?
>
> I believe Firefox on Linux uses libc call (in my basically default
> setup).
There's a problem on Unix that there isn't a way to
On 08/11/2018 04:13, Tim Wicinski wrote:
I can't stress this enough - when you see ALIAS records at zone cuts
that point to a database server, already, then we've missed the
"server specific" ball.
This sounds like it ought to be a very unusual configuration.
Even with a zone cut, couldn't
On 11/07/2018 02:13 PM, Tim Wicinski wrote:
> Tony says this:
>
> " It isn't a judgment about what's good, but an observation about what
> is done."
>
> I can't stress this enough - when you see ALIAS records at zone cuts
> that point to a database server,
> already, then we've missed the
Tony says this:
" It isn't a judgment about what's good, but an observation about what is
done."
I can't stress this enough - when you see ALIAS records at zone cuts that
point to a database server,
already, then we've missed the "server specific" ball.
And can someone show a significant number
Brian,
> On Nov 8, 2018, at 10:30 AM, Brian Dickson
> wrote:
>
> For new RRtypes, registries, registrars, and their provisioning services do
> NOT need to support them; the new types are in the zones only.
DY> (Experiencing a "DUH!" moment.) Yes, of course. It's zone data so only
those
On Nov 8, 2018, at 9:38 AM, p vixie wrote:
>
> If additional data is optional, so most resolvers can just pass it through,
> the DNS techs will say yes but the HTTP techs will say no.
We have a bad track record of predicting what other groups will want from the
DNS or use it for. Specifying
On 08/11/2018 11:47, Dan York wrote:
For that reason, wouldn't all the resolvers (or at least an extremely high %)
need to be upgraded to support the new record?
They don't _have_ to be, but performance is improved when they are
(since only an upgraded resolver will include the A and
> On 8 Nov 2018, at 2:30 pm, Brian Dickson
> wrote:
>
>
>
> On Thu, Nov 8, 2018 at 10:06 AM Dan York wrote:
> Brian,
>
> DY> Upgrading our DNS infrastructure is VERY difficult. Because it is still
> massively distributed and decentralized (even though we do have ongoing
>
From my high tech gadget
> On Nov 8, 2018, at 06:30, Ray Bellis wrote:
>
>> On 08/11/2018 04:13, Tim Wicinski wrote:
>>
>> I can't stress this enough - when you see ALIAS records at zone cuts
>> that point to a database server, already, then we've missed the
>> "server specific" ball.
>
>
On Nov 8, 2018, at 9:38 AM, p vixie ; wrote:
If additional data is optional, so most resolvers can just pass it
through, the DNS techs will say yes but the HTTP techs will say
no.
We have a bad track record of predicting what other groups will want
from the DNS or use it for. Specifying what
> On 8 Nov 2018, at 5:07 am, Paul Vixie wrote:
>
>
>
> Tony Finch wrote:
>> ...
>>
>> And even if you can get the recursive server addresses, you should still
>> go through the name service switch to deal with names that aren't in the
>> DNS.
>
> agreed.
For A and , but not for HTTP,
I'm going to start a clean, related thread, to discuss a bunch of
questions, that I think can help with the ongoing threads.
Rationale:
I think many of the viewpoints some folks have are skewed by pre-existing
familiarity with the protocol, and implementations (including browsers,
libraries,
On Thu, Nov 8, 2018 at 11:47 AM Dan York wrote:
> Brian,
>
> > On Nov 8, 2018, at 10:30 AM, Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
> >
> > For new RRtypes, registries, registrars, and their provisioning services
> do NOT need to support them; the new types are in the zones only.
If additional data is optional, so most resolvers can just pass it through, the
DNS techs will say yes but the HTTP techs will say no.
- Original Message -
From: Brian Dickson
Sent: 2018-11-07 - 18:30
To: "dnsop@ietf.org WG"
Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs
On 11/6/18 6:28 PM, Tony Finch wrote:
But thinking about the discussions from the weekend and yesterday, it
occurs to me that it might make sense to simplify ANAME even further:
* Make all authoritative processing optional, whether UPDATE style or
dynamic on-demand.
* The sibling
On Mon, 5 Nov 2018 at 06:11, Vladimír Čunát
wrote:
> On 11/2/18 10:41 PM, Evan Hunt wrote:
> > Speaking as a co-author of ANAME, I agree about this. URI, SRV, a
> proposed
> > new HTTP RRtype, whatever - service lookup is absolutely the correct way
> to
> > accomplish this goal.
> >
> > However,
On 2018-11-05 06:10 -0500, Vladimír Čunát wrote:
On 11/2/18 10:41 PM, Evan Hunt wrote:
Speaking as a co-author of ANAME, I agree about this. URI, SRV, a proposed
new HTTP RRtype, whatever - service lookup is absolutely the correct way to
accomplish this goal.
However, browser vendors are
20 matches
Mail list logo
