> On 17 Sep 2018, at 5:43 pm, Mukund Sivaraman wrote:
>
> Hi Stephane
>
> On Mon, Sep 17, 2018 at 09:14:14AM +0200, Stephane Bortzmeyer wrote:
>> On Sun, Sep 16, 2018 at 03:26:56PM +0530,
>> Mukund Sivaraman wrote
>> a message of 66 lines which said:
>>
>>> Adding resolver support (to resol
The IESG has approved the following document:
- 'DNS Terminology'
(draft-ietf-dnsop-terminology-bis-14.txt) as Best Current Practice
This document is the product of the Domain Name System Operations Working
Group.
The IESG contact persons are Warren Kumari and Ignas Bagdonas.
A URL of this Int
Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-session-signal-15: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
The IESG has approved the following document:
- 'Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY'
(draft-ietf-dnsop-refuse-any-07.txt) as Proposed Standard
This document is the product of the Domain Name System Operations Working
Group.
The IESG contact persons are Warren K
Hi Evan
On Mon, Sep 17, 2018 at 04:11:24PM +, Evan Hunt wrote:
> On Mon, Sep 17, 2018 at 01:13:27PM +0530, Mukund Sivaraman wrote:
> > Similar things can be said of other proposals.
> >
> > * If SRV for HTTP is brought into use, what about X% of user agents that
> > don't have support for i
On Mon, Sep 17, 2018 at 01:13:27PM +0530, Mukund Sivaraman wrote:
> Similar things can be said of other proposals.
>
> * If SRV for HTTP is brought into use, what about X% of user agents that
> don't have support for it?
>
> * If a new RR type is introduced, what about X% of resolvers that do n
Hi Petr
On Mon, Sep 17, 2018 at 12:29:13PM +0200, Petr Špaček wrote:
> Originally I thought that current workarounds for CNAME at apex (which
> are almost everywhere) deal with it in a more deterministic way.
Do you mean the current workarounds in resolver implementations? These
can be brought i
On 17/09/2018 11:30, Mukund Sivaraman wrote:
> Hi Ray
>
> On Mon, Sep 17, 2018 at 09:47:50AM +0100, Ray Bellis wrote:
>> On 17/09/2018 08:43, Mukund Sivaraman wrote:
>>
>>> The suggestion is only to require support in resolvers going forward for
>>> CNAME co-existing with other types for now. That
Hi Ray
On Mon, Sep 17, 2018 at 09:47:50AM +0100, Ray Bellis wrote:
> On 17/09/2018 08:43, Mukund Sivaraman wrote:
>
> > The suggestion is only to require support in resolvers going forward for
> > CNAME co-existing with other types for now. That should not break any
> > detail of how DNS is used
On 17/09/2018 08:43, Mukund Sivaraman wrote:
> The suggestion is only to require support in resolvers going forward for
> CNAME co-existing with other types for now. That should not break any
> detail of how DNS is used today.
> Although it changes current DNS protocol, AFAICT there does no
Hi Stephane
On Mon, Sep 17, 2018 at 09:14:14AM +0200, Stephane Bortzmeyer wrote:
> On Sun, Sep 16, 2018 at 03:26:56PM +0530,
> Mukund Sivaraman wrote
> a message of 66 lines which said:
>
> > Adding resolver support (to resolvers that don't have it, i.e.,
> > vs. RFC 1035) does not appear to
On 17/09/2018 08:11, Stephane Bortzmeyer wrote:
Since the main use case is "people with a domain name such as
example.com, who wants https://example.com/ to actually work, and who
hosts the stuff at a CDN where the IP address is wildly variable so
they cannot use A or records", I suggest
On 17.09.18 02:27, Mark Andrews wrote:
Actually having the clients time and fudge in those fields for BADKEY
provides spoofing protection for the unsigned responses. This is especially
important with opportunistic TSIG,which is what TSIG with a WKK will be, as
there is no longer the presumption t
On Sun, Sep 16, 2018 at 03:26:56PM +0530,
Mukund Sivaraman wrote
a message of 66 lines which said:
> Adding resolver support (to resolvers that don't have it, i.e.,
> vs. RFC 1035) does not appear to break current DNS, i.e., it can be
> proposed now.
[Algorithm deleted]
The difficult thing i
On Mon, Sep 17, 2018 at 03:51:34AM +,
Evan Hunt wrote
a message of 124 lines which said:
> I don't see how we can responsibly declare a new standard which, if
> followed, will break every prior implementation. Apex CNAME is the
> sort of solution that's clear, simple, and wrong.
+1
> We'
15 matches
Mail list logo