On Mon, Jan 29, 2018 at 11:37:55PM +0100, Martin Hoffmann wrote:
> Perhaps define a term for "A or " such as "address record"?
I went and looked at terminology-bis and noted that we use "address
record" and parenthetically define it. Should we define it more
formally?
A
--
Andrew Sullivan
Hey,
> On Jan 30, 2018, at 10:24, Andrew Sullivan wrote:
>
>> On Mon, Jan 29, 2018 at 11:37:55PM +0100, Martin Hoffmann wrote:
>> Perhaps define a term for "A or " such as "address record"?
>
> I went and looked at terminology-bis and noted that we use "address
> record" and parenthetically
On Mon, Jan 29, 2018 at 12:42 PM, Paul Vixie wrote:
> chiming in for the hum:
>
> Andrew Sullivan wrote:
>
>> Dear colleagues,
>>
>> On Mon, Jan 22, 2018 at 11:18:08AM -0500, Suzanne Woolf wrote:
>>
>>> Hi all,
>>>
>>> This is the opening of the Working Group Last Call for "Let 'localhost'
>>> be
On Jan 30, 2018, at 9:44 AM, Bob Harold wrote:
> I would prefer to extend that to the root, and have a DNSSEC signed answer,
> although I realize that is difficult, and would accept the draft without it.
> But we should give some guidance for DNSSEC queries - do we give a bogus
> response with
On Tue, Jan 30, 2018 at 10:42:15AM -0500, Joe Abley wrote:
>
> I realise that the following is not what anybody means in this thread
Hmm. Actually, I wasn't sure :-)
> I probably missed some. Anyway, I think when people are saying "address
> record" here they actually mean "IP address record".
I have read through the draft. I like it a lot and I really want this
feature! I've quoted bits of it below (indented) and added my comments
and questions. Warning, this is nearly 1400 words...
1. Introduction
Is it worth explicitly mentioning the case of subdomains such as
`department.example.e
On Tue, Jan 30, 2018 at 11:39:31AM -0600, Ted Lemon wrote:
>
> It is possible to produce a signed answer, because the domain doesn't exist
I think I was arguing yesterday that that is in fact not true. The
domain (name) does exist, and it is defined in RFC 6761 precisely to
be special. In addit
I think we're rat holing. I'm not an author on this draft, but I know
them both, and I work with one, and I believe the draft is basically
in the right space and .. well.. we're rat holing.
So, noting my disclaimer of bias, can we .. move on? Is there real
matters of substance left on this one? It
On Tue, Jan 30, 2018 at 6:44 PM, George Michaelson wrote:
> I think we're rat holing. I'm not an author on this draft, but I know
> them both, and I work with one, and I believe the draft is basically
> in the right space and .. well.. we're rat holing.
>
> So, noting my disclaimer of bias, can we
I tested this. you can bind _label onto CNAME but not A/. bind
won't serve zones with it.
So yea.. I think the change is needed.
thats substantful.
-G
On Wed, Jan 31, 2018 at 10:29 AM, Warren Kumari wrote:
> On Tue, Jan 30, 2018 at 6:44 PM, George Michaelson wrote:
>> I think we're rat ho
On 30 Jan 2018, at 16:29, Warren Kumari wrote:
There is one matter of substance (but, IMO, very minor substance!) --
the original document said that the names are of the form:
_is-ta-[key].example.com
_not-ta-[key].example.com
This works, but some implementations really don't like having A/AAA
>The problem you hit was in BIND. To get around it, you simply add "check-names
>master warn;" to the options.
And with this.. he was good again. So, modulo the implementation
cost/consequence, I'm good here.
But, if this is detail, then I'm back at 10,000ft: noting the IETF is
all about detail,
Hi George,
On Jan 30, 2018, at 21:49, George Michaelson wrote:
>> The problem you hit was in BIND. To get around it, you simply add
>> "check-names master warn;" to the options.
>
> And with this.. he was good again. So, modulo the implementation
> cost/consequence, I'm good here.
>
> But, if
I stress, I'm not an author on this one. I'm also heavily biassed by
role and relationship(s) with the authors.
I'm trying to play nice, in that context: I want it shipped. I think
its a net useful contribution.
So, I think your suggestion of guiding words is good. If it was my
draft, I'd welcome
I realised that the primary/secondary split I talked about in my previous
message turned out to be the wrong idea. There were lots of complicating issues
that made it clear that auth server ANAME behaviour does not cleanly follow the
traditional primary/secondary split.
Instead I think the spli
15 matches
Mail list logo
