Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[John Levine]

>The next step is experimentation, we wanted to see if the community thought
>this was a stupid idea before going forward.

I certainly don't think it's stupid.

>There are 3 possible outcomes when a DNS querier gets an aswer like this
>#1 It accepts everything from authority section
>#2 It tosses the non queried RRset
>#3 it Rejects the answer and tries again

#4 it ignores the answer and doesn't try again
#5 it misinterprets the  records as A records (they're not CNAME, what else 
could they be?)
#6 it dereferences an uninitialized pointer and gets random junk sometimes, 
crashes other times

I don't think any of those are particularly likely, but I've never
sent answers with extra records other than CNAME, DNAME, and (when DO
is set) DNSSEC stuff.  So I think we agree that reports of what
current code really does would be helpful.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Ólafur Guðmundsson]

On Fri, Mar 25, 2016 at 10:51 PM, John Levine  wrote:

> >As I think many here know, I am not of the get-off-my-lawn persuasion
> >for DNS innovations.  I don't think it's a bad idea in principle.  I'm
> >just aware that we have this long history, and that history was based
> >on a certain kind of conservatism that is arguably appropriate to a
> >technology quite as fundamental to the Internet functioning as the DNS
> >is.  If we're going to abandon that conservatism, I think it needs
> >quite a lot more early IETF buy-in than we might get by developing
> >this work here in DNSOP.  The more signal we can get to suggest that
> >DNS actors are ok with the innovation, the lower I think that bar gets.
>
> I'd be a lot more comfortable if we had some field test data about
> what real DNS caches do with the extra  records.  In theory
> nothing bad should happen, in practice ...
>
> John
The next step is experimentation, we wanted to see if the community thought
this was a stupid idea before going forward.
There are 3 possible outcomes when a DNS querier gets an aswer like this
#1 It accepts everything from authority section
#2 It tosses the non queried RRset
#3 it Rejects the answer and tries again

If the result is #1 nothing needs to be done
For #2 that means convincing the software vendors to adopt more relaxed
approach
On the other hand if #3 is the case for a significant part of the
infrastructure we can not do this w/o signaling


Olafur
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

On Fri, Mar 25, 2016 at 7:51 PM, John Levine  wrote:

> >As I think many here know, I am not of the get-off-my-lawn persuasion
> >for DNS innovations.  I don't think it's a bad idea in principle.  I'm
> >just aware that we have this long history, and that history was based
> >on a certain kind of conservatism that is arguably appropriate to a
> >technology quite as fundamental to the Internet functioning as the DNS
> >is.  If we're going to abandon that conservatism, I think it needs
> >quite a lot more early IETF buy-in than we might get by developing
> >this work here in DNSOP.  The more signal we can get to suggest that
> >DNS actors are ok with the innovation, the lower I think that bar gets.
>
> I'd be a lot more comfortable if we had some field test data about
> what real DNS caches do with the extra  records.  In theory
> nothing bad should happen, in practice ...
>
> R's,
> John


I agree, working on it.

Marek

___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[John Levine]

>As I think many here know, I am not of the get-off-my-lawn persuasion
>for DNS innovations.  I don't think it's a bad idea in principle.  I'm
>just aware that we have this long history, and that history was based
>on a certain kind of conservatism that is arguably appropriate to a
>technology quite as fundamental to the Internet functioning as the DNS
>is.  If we're going to abandon that conservatism, I think it needs
>quite a lot more early IETF buy-in than we might get by developing
>this work here in DNSOP.  The more signal we can get to suggest that
>DNS actors are ok with the innovation, the lower I think that bar gets.

I'd be a lot more comfortable if we had some field test data about
what real DNS caches do with the extra  records.  In theory
nothing bad should happen, in practice ...

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Andrew Sullivan]

On Thu, Mar 24, 2016 at 08:33:28AM +1000, George Michaelson wrote:
> Very strong +1. The % of incoming query with DO set is far, far higher
> than the % of incoming query seen at authority who subsequently ask
> for DS/DNSKEY at zone and parent. There is a good, strong indication
> that resolvers pass DO as a compile/run flag of capability to handle
> additional records in response, not as an indication of intent to
> perform any function using them.

I might feel more comfortable if the proposal required DO, but AFAICT
it doesn't (I might have misread, of course.  I found the I-D a little
terse).  If it does require DO, however, we're back to requiring
EDNS0.  In that case, we could just use an EDNS0-based signal.

As I think many here know, I am not of the get-off-my-lawn persuasion
for DNS innovations.  I don't think it's a bad idea in principle.  I'm
just aware that we have this long history, and that history was based
on a certain kind of conservatism that is arguably appropriate to a
technology quite as fundamental to the Internet functioning as the DNS
is.  If we're going to abandon that conservatism, I think it needs
quite a lot more early IETF buy-in than we might get by developing
this work here in DNSOP.  The more signal we can get to suggest that
DNS actors are ok with the innovation, the lower I think that bar gets.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[George Michaelson]

On Thu, Mar 24, 2016 at 7:10 AM, Florian Weimer  wrote:
> DO was used initially for SIG and kept for RRSIG.  For an early DNSSEC
> implementation, RRSIG was just another unsolicited RR type because it
> could only know about SIG.  This suggests (to me at least) that
> practically speaking, DO isn't strongly tied to DNSSEC.
>
> Florian


Very strong +1. The % of incoming query with DO set is far, far higher
than the % of incoming query seen at authority who subsequently ask
for DS/DNSKEY at zone and parent. There is a good, strong indication
that resolvers pass DO as a compile/run flag of capability to handle
additional records in response, not as an indication of intent to
perform any function using them.

(this is with fresh unseen domains, where there is no opportunistic
cache of the DNSKEY or DS, so the absence of a fetch of them is a very
good indicator there was no intent to try and use the RRSIG sent back
as a result of DO being sent in query)

-G

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Florian Weimer]

On 03/23/2016 09:03 PM, Andrew Sullivan wrote:
> I don't understand how it's a way to evaluate this claim.  DNSSEC
> includes a bit (DO) that says you're prepared to handle the additional
> data in the answer section.  Indeed, the unpreparedness of people for
> this data was just exactly the reason for the DO bit.  What isn't
> clear to me is whether people implemented that as, "Take whatever
> comes in the answer even if you didn't ask for it," or whether they're
> looking for DNSSEC data.  The latter is what DO says one is prepared
> to do.

DO was used initially for SIG and kept for RRSIG.  For an early DNSSEC
implementation, RRSIG was just another unsolicited RR type because it
could only know about SIG.  This suggests (to me at least) that
practically speaking, DO isn't strongly tied to DNSSEC.

Florian

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Andrew Sullivan]

Hi,

On Wed, Mar 23, 2016 at 09:37:57AM -0700, Marek Vavruša wrote:
> > 1.  We had no idea what resolvers who weren't expecting the 
> > in the Answer section would do.  This draft says what is "more
> > likely", but I have no way of evaluating that claim.  Without an
> > EDNS0 signal, I think this proposal is pretty dangerous.
> 
> 
> We have a way of measuring DNSSEC algorithms penetration, QNAME
> minimisation-enabled resolvers etc., thus also a way to evaluate this
> claim. I'm setting up a special domain using this I-D and then we can use
> RIPE Atlas or 1x1 test, should Google or someone be interested in testing
> this.

I don't understand how it's a way to evaluate this claim.  DNSSEC
includes a bit (DO) that says you're prepared to handle the additional
data in the answer section.  Indeed, the unpreparedness of people for
this data was just exactly the reason for the DO bit.  What isn't
clear to me is whether people implemented that as, "Take whatever
comes in the answer even if you didn't ask for it," or whether they're
looking for DNSSEC data.  The latter is what DO says one is prepared
to do.

> > 3.  This amounts to special server-side processing, and there'd
> > been a traditional resistance to
> 
> I'm happy to back this with patches.

That _you_ can produce the code is not the question.  The question is
whether people are comfortable adding additional server side
processing to the protocol.  It's always been a big deal before (which
is part of the reason RRTYPEs that require this aren't eligible for
allocation by expert review).  I confess I'm susprised that this
aspect of your proposal isn't getting more push back, but maybe that's
because it's supposed to be optional.

> With all respect, I'm not in a position to be an IETF librarian.

No, but I observe you're not the only author on this document, and
since I was Olafur's co-chair when we dealt with this kind of proposal
last time I sort of assumed his memory would be as good as mine.

> If it's coming back then it means the idea is probably interesting,

There was never any question that the idea has some value.  The
question was always whether it would work reliably on the Internet we
have.  Maybe what we're saying is either (1) the Internet has in fact
changed or (2) that we're going to have to abandon some of the old
functionality.  If so, ok, but we ought to say so explicitly.  (Also,
without some significant changes to the charter and maybe to the area
in which this WG lives, I'm not sure this WG is in fact the right
place for fundamental changes to assumptions about the protocol
functioning.  Minor maintenance, sure.  Note that I don't want to play
charter games -- I think they're useless and boring -- but this kind
of major change to the protocol doesn't obviously fit to me under the
provisions in 5 of the DNSOP charter, though this is the right place
to start the discussion.  The same, note, is true of the
deprecate-classes discussion.)

> Talking to upstream is the most expensive operation for resolver
> next to signature verification.

So, yes.  It strikes me, however, that if that's the real use case you
could definitely use EDNS0, on the assumption that the end client
could use happy eyeballs.  The resolver would of course get two
queries, but it would only need to send one and could re-use the
single answer it gets over and over, meaning that cache re-use ought
to be pretty good.  

> I admit I'm not a big fan of EDNS, but I'm okay with using it if I'm proven
> that resolvers will panic
> on a sight of different record in any of the packet sections.

This is putting the burden of proof in the wrong place.  You're
proposing to change the protocol behaviour in a pretty fundamental
way.  You need to be able to show that the new behaviour doesn't break
old-but-conforming implementations.  That's how standards work.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Florian Weimer]

On 03/22/2016 12:45 AM, Marek Vavruša wrote:

> there was an interest in reducing latency for address record lookups.
> Me and Olafur wrote a draft on adding  records to A answers and
> treating them as authoritative. This fixes latency issues with NS
> A/ discovery in resolvers and improves caching for clients (
> already cached by the time client comes asking for it).
> 
> Comments, feedback and snarky remarks would be great!
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/

The glibc stub resolver already implements this draft in its response
processing by accident.  I was planning to fix that.

I don't see how this proposal reduces latency or server load.  We still
have to do dual A/ queries.  In the majority of cases, there is no
 record, so we have to wait for the second reply to arrive.

We could reduce server load by sending the  query only after the A
response, but we'd have to send it in most cases because we cannot take
absence of an  RRset as proof of its non-existence.

On the server side, doing  lookups for all incoming A queries, on
top of A lookups, isn't free (although it should be fairly cheap because
the server at least knows where to send the  query).

Florian

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Florian Weimer]

On 03/22/2016 01:15 AM, Paul Vixie wrote:
> 
> 
> Marek Vavruša wrote:
>> ...
>>
>> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
> 
> +1. we ought to have done this from the get-go.

It did not work back then because unexpected RRsets in the answer broke
resolvers.  This is how we got the DO flag, I think.

I doubt  was any different from SIG in that regard, unknown is
unknown after all.

Therefore, technically, sending  along should only be done for
replies to DO=1 queries because there is a reasonable expectation that
the recipient will be able to deal with unexecpted RRsets.

Florian

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Joao Damas]

In one of the experiments we are conducting we stuff the response with other 
QTYPE data and this seems to not interfere with resolver behaviour (unless we 
trigger it). So #3 doesn’t seem to be a common case (we could look in the 
fringes for this behaviour).

Towards the resolver’s clients, all extraneous data gets cleaned out of the 
response, which is quite sane behaviour in the current DNS. Have not tested 
what the resolver does with the data (keep it in cache, something in between #1 
and #2, or discard it altogether, as in #2).

Joao


> On 23 Mar 2016, at 19:17, Ólafur Guðmundsson  wrote:
> 
> 
> On Tue, Mar 22, 2016 at 6:11 PM, Mark Andrews  > wrote:
> 
> In message <2016030345.29993...@pallas.home.time-travellers.org 
> >, Shane Kerr 
> writes:
> > Maybe we just need a new RTYPE. It would be awesome if CloudFlare
> > killed ANY and then gave us ANYA ("any address"). ;)
> 
> You would then need to do ANYA, A and  queries or you have to
> have signaling to indicate if the server supports ANYA with fallback
> to A and  on no support.  Now for named you go from NOTIMP ->
> NOERROR/NXDOMAIN introducing a meta type but for other servers you
> start at NOERROR/NXDOMAIN so explicit signaling of support for a
> meta type is needed.
> 
>  
> There are two ways to approach the address distribution problem, 
> a) from the client side 
> b) from the server side 
> our proposal is strictly in camp b) i.e. just servers put this out. 
> 
> The OPEN question is what will resolvers do 
> #1 Accept but RRsets
> #2 Discard non QTYPE covered set 
> #3 discard the answer 
> 
> If it is #3 then this is a horrible idea, 
> if is #2 then there is no loss and resolvers will improve over time. 
> if it is #1 then it is a win without any resolver changes. 
> 
> Tony, 
> Same questions apply if  set is put in the additional section. 
> 
> Andrew, 
> We need data to determine if this is feasible. 
> 
> 
> Olafur
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Ólafur Guðmundsson]

On Tue, Mar 22, 2016 at 6:11 PM, Mark Andrews  wrote:

>
> In message <2016030345.29993...@pallas.home.time-travellers.org>,
> Shane Kerr writes:
> > Maybe we just need a new RTYPE. It would be awesome if CloudFlare
> > killed ANY and then gave us ANYA ("any address"). ;)
>
> You would then need to do ANYA, A and  queries or you have to
> have signaling to indicate if the server supports ANYA with fallback
> to A and  on no support.  Now for named you go from NOTIMP ->
> NOERROR/NXDOMAIN introducing a meta type but for other servers you
> start at NOERROR/NXDOMAIN so explicit signaling of support for a
> meta type is needed.
>
>
There are two ways to approach the address distribution problem,
a) from the client side
b) from the server side
our proposal is strictly in camp b) i.e. just servers put this out.

The OPEN question is what will resolvers do
#1 Accept but RRsets
#2 Discard non QTYPE covered set
#3 discard the answer

If it is #3 then this is a horrible idea,
if is #2 then there is no loss and resolvers will improve over time.
if it is #1 then it is a win without any resolver changes.

Tony,
Same questions apply if  set is put in the additional section.

Andrew,
We need data to determine if this is feasible.


Olafur
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Philip Homburg]

>We have a way of measuring DNSSEC algorithms penetration, QNAME
>minimisation-enabled resolvers etc., thus also a way to evaluate this
>claim. I'm setting up a special domain using this I-D and then we can use
>RIPE Atlas or 1x1 test, should Google or someone be interested in testing
>this.

The 1x1 test would be APNIC.

It should be easy to measure with RIPE Atlas. The advantage of Atlas is that
you will get the DNS reply packet, so it is possible to investigate if the
a middle box mangles the reply in one way or another. I wonder if
any existing code would already cache the .


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

Hi Andrew, first of all - thanks for being constructive.

On Wed, Mar 23, 2016 at 6:07 AM, Andrew Sullivan 
wrote:

> Hi,
>
> On Mon, Mar 21, 2016 at 04:45:51PM -0700, Marek Vavruša wrote:
> > Me and Olafur wrote a draft on adding  records to A answers and
> > treating them as authoritative.
>
> The last time this was proposed, in DNSEXT when Olafur was co-chair,
> the proposal was rejected on the following grounds:
>
> 1.  We had no idea what resolvers who weren't expecting the 
> in the Answer section would do.  This draft says what is "more
> likely", but I have no way of evaluating that claim.  Without an
> EDNS0 signal, I think this proposal is pretty dangerous.


We have a way of measuring DNSSEC algorithms penetration, QNAME
minimisation-enabled resolvers etc., thus also a way to evaluate this
claim. I'm setting up a special domain using this I-D and then we can use
RIPE Atlas or 1x1 test, should Google or someone be interested in testing
this.

2.  It isn't clear what a cache is supposed to do when it gets an
> A and has a  already in cache, particularly if there isn't an
> A record.  This draft is far too sketchy on that case.  Can the
>  satisfy queries for ?  (I think section 4 says yes, but
> it's a little terse.)
>

The draft suggests following 2181 and all these records should be treated
as authoritative.
I'm comfortable with shoving the  into authority/additional which would
lower their rank and
 query would replace them.


>
> 3.  This amounts to special server-side processing, and there'd
> been a traditional resistance to
>

I'm happy to back this with patches.


>
> 4.  The proposal had been made several times before, and always
> rejected; what's different this time?  (This argument always
> seemed the weakest to me.)
>

With all respect, I'm not in a position to be an IETF librarian.
I'm happy to discuss this draft and whether it has any merit or not.
If it's coming back then it means the idea is probably interesting,
as for me the proposition of cutting query rate for most sought-after
QTYPEs in half is too good to be ignored.

Making it optional behaviour the way this proposal does seems to
> introduce quite a lot of confusion.  Is a happy-eyeballs resolver
> supposed to take the non-existence of the  in the answer as some
> sort of evidence that the  is never coming?  (I think this
> proposal says, "No," but I'm sceptical that's what will happen.)  Why
> doesn't happy eyeballs do what is necessary here?
>

For TTL, yes, if the authoritative provides non-existence proof.
"Happy eyeballs" means a resolver will maybe get both answers in ~ same RTT,
this I-D means it will have to send only half of the queries to get this
information.
Talking to upstream is the most expensive operation for resolver next to
signature
verification.


> I think I'd feel a lot more comfortable with anything along these
> lines if there were a signal from the resolver stating that it knows
> what to do, but that still brings up server-side processing.
>
> Best regards,
>
> A
>

I admit I'm not a big fan of EDNS, but I'm okay with using it if I'm proven
that resolvers will panic
on a sight of different record in any of the packet sections. Shoving the
records into NS/AR and thus
degrading their 2181 trustworthiness rank would be a better compromise to
explore first.

Best,

M



>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Tony Finch]

Andrew Sullivan  wrote:
> On Mon, Mar 21, 2016 at 04:45:51PM -0700, Marek Vavruša wrote:
> > Me and Olafur wrote a draft on adding  records to A answers and
> > treating them as authoritative.
>
> The last time this was proposed, in DNSEXT when Olafur was co-chair,
> the proposal was rejected on the following grounds:
>
> 1.  We had no idea what resolvers who weren't expecting the 
> in the Answer section would do.  This draft says what is "more
> likely", but I have no way of evaluating that claim.  Without an
> EDNS0 signal, I think this proposal is pretty dangerous.

This makes me wonder, if you put the extra records in the additional
section instead, what implications does that have wrt RFC 2181
trustworthiness ranking.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Biscay: Northerly or northwesterly 4 or 5, becoming variable 4, then becoming
southwesterly 5 later in north. Moderate or rough, occasionally slight at
first in east. Fair. Good.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Andrew Sullivan]

On Mon, Mar 21, 2016 at 06:55:00PM -0700, Paul Vixie wrote:
> i think we have to start planning for a world in which EDNS0 never reaches
> 75% penetration due to middleboxes having the high ground.

Well, you could get most of the way there for this proposal by having
just recursives do it.  End users are mostly going to do happy
eyeballs anyway, so if a recursive gets the  with the A its own
load goes down because it can answer more stuff from cache.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Andrew Sullivan]

Hi,

On Mon, Mar 21, 2016 at 04:45:51PM -0700, Marek Vavruša wrote:
> Me and Olafur wrote a draft on adding  records to A answers and
> treating them as authoritative.

The last time this was proposed, in DNSEXT when Olafur was co-chair,
the proposal was rejected on the following grounds:

1.  We had no idea what resolvers who weren't expecting the 
in the Answer section would do.  This draft says what is "more
likely", but I have no way of evaluating that claim.  Without an
EDNS0 signal, I think this proposal is pretty dangerous.

2.  It isn't clear what a cache is supposed to do when it gets an
A and has a  already in cache, particularly if there isn't an
A record.  This draft is far too sketchy on that case.  Can the
 satisfy queries for ?  (I think section 4 says yes, but
it's a little terse.)

3.  This amounts to special server-side processing, and there'd
been a traditional resistance to

4.  The proposal had been made several times before, and always
rejected; what's different this time?  (This argument always
seemed the weakest to me.)

Making it optional behaviour the way this proposal does seems to
introduce quite a lot of confusion.  Is a happy-eyeballs resolver
supposed to take the non-existence of the  in the answer as some
sort of evidence that the  is never coming?  (I think this
proposal says, "No," but I'm sceptical that's what will happen.)  Why
doesn't happy eyeballs do what is necessary here?

I think I'd feel a lot more comfortable with anything along these
lines if there were a signal from the resolver stating that it knows
what to do, but that still brings up server-side processing.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Tony Finch]

Marek Vavruša  wrote:
>
> 1. No signalling to client when  is unavailable
>
> I didn't want to include it in the beginning but I see it has a merit.

Yep. Also, while improving this for direct address queries, it should also
be improved for additional data in MX, NS, SRV (etc.) queries.

> DNSSEC has means to provide authenticated non-existence for free, so I
> think it's worth for auth server to add either data or non-existence proof
> for any applicable RR.
> e.g. if it has , but not A, it would provide  RRs and NSECX for A;
> if it has A but not , it would provide A RRs and NSECX for 
>
> For legacy case of no DNSSEC, an SOA in the authority indicates that no
> record matching QNAME+QTYPE exists, but can't effectively signalise
> non-existence of the additional address records. Which is not great, but
> I'm not in for legalising yet-another EDNS option, and it also would
> require client to signalise that it can handle such option before an auth
> server raises it in the answer.

Another option might be to define a couple of meta-TYPEs, NOA and NO
(same RDATA format as NULL), so the server could say, "I wanted to put
 records here, but there aren't any, and there isn't a DNSSEC pone
either".

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Forties: Variable 3 or 4, becoming southwest 4 or 5 later. Slight or moderate.
Occasional drizzle. Good, occasionally poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Mark Andrews]

In message <2016030345.29993...@pallas.home.time-travellers.org>, Shane 
Kerr writes:
> Maybe we just need a new RTYPE. It would be awesome if CloudFlare
> killed ANY and then gave us ANYA ("any address"). ;)

You would then need to do ANYA, A and  queries or you have to
have signaling to indicate if the server supports ANYA with fallback
to A and  on no support.  Now for named you go from NOTIMP ->
NOERROR/NXDOMAIN introducing a meta type but for other servers you
start at NOERROR/NXDOMAIN so explicit signaling of support for a
meta type is needed.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

On Tue, Mar 22, 2016 at 2:03 PM, Shane Kerr 
wrote:

> Marek,
>
> At 2016-03-22 12:12:08 -0700
> Marek Vavruša  wrote:
>
> > 2. Behavior of stubs is not explicit in the draft
> >
> > I should have stated this explicitly, the draft doesn't update behaviour
> of
> > stub resolvers. In my opinion, they should use the most basic form of DNS
> > and work only over local or trusted network, hence no latency issues.
>
> 8.8.8.8 isn't local or trusted, and is the largest resolver in the
> world. ;)
>
> One other important issue is that that the resolver main bottleneck is
> in packets/second, so reducing the total number of queries - potentially
> by half, but conservatively by a quarter - seems like too big of a win
> to ignore.
>
> Specifying resolver behavior when answering queries would be more
> difficult. Not impossibly so, but more complex.


Fair enough. As I wrote in the previous email, I meant stub as in
getaddrinfo() not forwarders, so hopefully that answers the question.
Public resolvers in 2016 are bizarre but that's what we got.


>
> > 2. Stubs and recursors during NS resolution issue parallel queries
> >
> > That is correct, the draft expects software changes if accepted. Saying
> > that it doesn't have any effect is not entirely true though. The latency
> is
> > max(rtt_a, rtt_) in the best case and one of the queries time out or
> is
> > blocked in the worst case. In addition, this doubles query rate on
> > authoritatives and requires more logic on clients (which is error prone -
> > see latest glibc bug), especially when one of the replies gets
> ratelimited,
> > truncated or answered from different node. On the contrary, waiting for
> > single answer is simple.
>
> I don't think this makes things too much more complicated on the
> client, especially with happy eyeballs being best practice these days.
> We kind of expect clients to do all kinds of crazy asynchronous shit,
> both with DNS and other network traffic.
>

It's all dandy until the resolution path diverges :)


> Anyway, this (parallel A and ) is the main reason that people have
> always argued against combined A and  queries, and it seemed to
> make sense. However, since a resolver can remember which authoritative
> servers combine A and  answers, there should be a gain here (I mean,
> resolvers have to remember all kinds of stuff about authoritative
> servers anyway).
>
> > 3.  query doesn't offer A records
> >
> > That is a valid point. Long answer: I think the logic of clients asking
> for
> > IPv6 is flawed from the get-go. For a smooth protocol version upgrade,
> > authoritatives should have had a way to push IPv6 on clients instead of
> > waiting for them to ask for it. The A record is unfortunately defined as
> a
> > 32-bit Internet address. I think it should be redefined as "Internet
> > address". This way, if a client wants to ask a server about IP address,
> it
> > would _always_ use an A query and get a list of A,  and possibly
> > something new. It would be up to client's discretion to pick an address
> > version that it understands. The benefit of this is that it doesn't
> require
> > additional queries or major client-side changes. Somebody has said IPv6
> is
> > here to stay, I'd like to share this certainty. Meta-types (sort of what
> I
> > want an A to become) are considered bad, but DNS was built around name to
> > address translation so optimising for this case might be worth it.
> Offering
> > A records for  drags the need for backward compatibility (even more
> if
> > we ever have a newer address record) and more code exceptions.
>
> Maybe we just need a new RTYPE. It would be awesome if CloudFlare
> killed ANY and then gave us ANYA ("any address"). ;)
>
> Cheers,
>
> --
> Shane
>

Right, it sounds a bit ironic doesn't it? Semantics of ANY isn't really
great a differs per type of server,
more so it is expensive as DNS gravitates towards key-value type storage. I
was hoping to get away
with a simple semantic change for A as it keeps the original meaning (get
an IPv4 address) untouched, while
extending it with harmless "throw in any other IP addresses as well". I
could be wrong though.

Marek
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

On Tue, Mar 22, 2016 at 1:20 PM, Mark Andrews  wrote:

>
> In message 

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Shane Kerr]

Marek,

At 2016-03-22 12:12:08 -0700
Marek Vavruša  wrote:

> 2. Behavior of stubs is not explicit in the draft
> 
> I should have stated this explicitly, the draft doesn't update behaviour of
> stub resolvers. In my opinion, they should use the most basic form of DNS
> and work only over local or trusted network, hence no latency issues.

8.8.8.8 isn't local or trusted, and is the largest resolver in the
world. ;)

One other important issue is that that the resolver main bottleneck is
in packets/second, so reducing the total number of queries - potentially
by half, but conservatively by a quarter - seems like too big of a win
to ignore.

Specifying resolver behavior when answering queries would be more
difficult. Not impossibly so, but more complex.

> 2. Stubs and recursors during NS resolution issue parallel queries
> 
> That is correct, the draft expects software changes if accepted. Saying
> that it doesn't have any effect is not entirely true though. The latency is
> max(rtt_a, rtt_) in the best case and one of the queries time out or is
> blocked in the worst case. In addition, this doubles query rate on
> authoritatives and requires more logic on clients (which is error prone -
> see latest glibc bug), especially when one of the replies gets ratelimited,
> truncated or answered from different node. On the contrary, waiting for
> single answer is simple.

I don't think this makes things too much more complicated on the
client, especially with happy eyeballs being best practice these days.
We kind of expect clients to do all kinds of crazy asynchronous shit,
both with DNS and other network traffic.

Anyway, this (parallel A and ) is the main reason that people have
always argued against combined A and  queries, and it seemed to
make sense. However, since a resolver can remember which authoritative
servers combine A and  answers, there should be a gain here (I mean,
resolvers have to remember all kinds of stuff about authoritative
servers anyway).

> 3.  query doesn't offer A records
> 
> That is a valid point. Long answer: I think the logic of clients asking for
> IPv6 is flawed from the get-go. For a smooth protocol version upgrade,
> authoritatives should have had a way to push IPv6 on clients instead of
> waiting for them to ask for it. The A record is unfortunately defined as a
> 32-bit Internet address. I think it should be redefined as "Internet
> address". This way, if a client wants to ask a server about IP address, it
> would _always_ use an A query and get a list of A,  and possibly
> something new. It would be up to client's discretion to pick an address
> version that it understands. The benefit of this is that it doesn't require
> additional queries or major client-side changes. Somebody has said IPv6 is
> here to stay, I'd like to share this certainty. Meta-types (sort of what I
> want an A to become) are considered bad, but DNS was built around name to
> address translation so optimising for this case might be worth it. Offering
> A records for  drags the need for backward compatibility (even more if
> we ever have a newer address record) and more code exceptions.

Maybe we just need a new RTYPE. It would be awesome if CloudFlare
killed ANY and then gave us ANYA ("any address"). ;)

Cheers,

--
Shane


pgpAiQL5xBuXR.pgp
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Mark Andrews]

In message 

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

Thanks everybody for comments! It's a lot so I'll try to rephrase and
answer the questions below.

1. No signalling to client when  is unavailable

I didn't want to include it in the beginning but I see it has a merit.
DNSSEC has means to provide authenticated non-existence for free, so I
think it's worth for auth server to add either data or non-existence proof
for any applicable RR.
e.g. if it has , but not A, it would provide  RRs and NSECX for A;
if it has A but not , it would provide A RRs and NSECX for 

For legacy case of no DNSSEC, an SOA in the authority indicates that no
record matching QNAME+QTYPE exists, but can't effectively signalise
non-existence of the additional address records. Which is not great, but
I'm not in for legalising yet-another EDNS option, and it also would
require client to signalise that it can handle such option before an auth
server raises it in the answer. For this case specifically, I am okay with
client making additional  query to recheck.
To defense: resolvers keep track of auth functionality (ability to do EDNS,
IPv6 availability, ...), this is not any different. If the auth shows that
it either supports this (by at least one positive case) or not (this case),
resolver will remember it and act accordingly next time.

2. Behavior of stubs is not explicit in the draft

I should have stated this explicitly, the draft doesn't update behaviour of
stub resolvers. In my opinion, they should use the most basic form of DNS
and work only over local or trusted network, hence no latency issues.

2. Stubs and recursors during NS resolution issue parallel queries

That is correct, the draft expects software changes if accepted. Saying
that it doesn't have any effect is not entirely true though. The latency is
max(rtt_a, rtt_) in the best case and one of the queries time out or is
blocked in the worst case. In addition, this doubles query rate on
authoritatives and requires more logic on clients (which is error prone -
see latest glibc bug), especially when one of the replies gets ratelimited,
truncated or answered from different node. On the contrary, waiting for
single answer is simple.

3.  query doesn't offer A records

That is a valid point. Long answer: I think the logic of clients asking for
IPv6 is flawed from the get-go. For a smooth protocol version upgrade,
authoritatives should have had a way to push IPv6 on clients instead of
waiting for them to ask for it. The A record is unfortunately defined as a
32-bit Internet address. I think it should be redefined as "Internet
address". This way, if a client wants to ask a server about IP address, it
would _always_ use an A query and get a list of A,  and possibly
something new. It would be up to client's discretion to pick an address
version that it understands. The benefit of this is that it doesn't require
additional queries or major client-side changes. Somebody has said IPv6 is
here to stay, I'd like to share this certainty. Meta-types (sort of what I
want an A to become) are considered bad, but DNS was built around name to
address translation so optimising for this case might be worth it. Offering
A records for  drags the need for backward compatibility (even more if
we ever have a newer address record) and more code exceptions.

Marek

On Tue, Mar 22, 2016 at 8:55 AM, Shumon Huque  wrote:

> On Tue, Mar 22, 2016 at 7:41 AM, Tony Finch  wrote:
>
>> Marek Vavruša  wrote:
>> >
>> > there was an interest in reducing latency for address record lookups.
>> > Me and Olafur wrote a draft on adding  records to A answers and
>> > treating them as authoritative. This fixes latency issues with NS
>> > A/ discovery in resolvers and improves caching for clients (
>> > already cached by the time client comes asking for it).
>>
>> Regarding NS discovery, you should be aware that BIND queries for name
>> server A and  concurrently. So this draft would just make packets
>> bigger without helping latency.
>>
>
> It's worth noting that several "happy eyeballs" style APIs issue
> concurrent
> /A queries also, like the Apple connect-by-name APIs. Also getdns
> does this.  and A go out back to back, put typically  is put out
> on the wire first.
>
> --
> Shumon Huque
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Shumon Huque]

On Tue, Mar 22, 2016 at 7:41 AM, Tony Finch  wrote:

> Marek Vavruša  wrote:
> >
> > there was an interest in reducing latency for address record lookups.
> > Me and Olafur wrote a draft on adding  records to A answers and
> > treating them as authoritative. This fixes latency issues with NS
> > A/ discovery in resolvers and improves caching for clients (
> > already cached by the time client comes asking for it).
>
> Regarding NS discovery, you should be aware that BIND queries for name
> server A and  concurrently. So this draft would just make packets
> bigger without helping latency.
>

It's worth noting that several "happy eyeballs" style APIs issue concurrent
/A queries also, like the Apple connect-by-name APIs. Also getdns
does this.  and A go out back to back, put typically  is put out
on the wire first.

-- 
Shumon Huque
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Bob Harold]

On Tue, Mar 22, 2016 at 7:41 AM, Tony Finch  wrote:

> Marek Vavruša  wrote:
> >
> > there was an interest in reducing latency for address record lookups.
> > Me and Olafur wrote a draft on adding  records to A answers and
> > treating them as authoritative. This fixes latency issues with NS
> > A/ discovery in resolvers and improves caching for clients (
> > already cached by the time client comes asking for it).


I think the reverse should also be done: add "A" answers to  queries.

Some possible reasons, although these might not be the best reasons:
I thought that most dual-stack computers prefer IPv6 to connect, and thus I
assumed that they would do an  query first, in which case it would be
good to return an "A" record if the  query finds no answer, assuming
that the client is likely to fall back to "A".
There are probably also many clients where the stack thinks it might have
IPv6 connectivity, but it really does not, so it will have to fall back to
"A", even if an  answer exists.

I am almost certain someone will explain why I am wrong, but I at least
wanted this discussed.

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Tony Finch]

Marek Vavruša  wrote:
>
> there was an interest in reducing latency for address record lookups.
> Me and Olafur wrote a draft on adding  records to A answers and
> treating them as authoritative. This fixes latency issues with NS
> A/ discovery in resolvers and improves caching for clients (
> already cached by the time client comes asking for it).

Regarding NS discovery, you should be aware that BIND queries for name
server A and  concurrently. So this draft would just make packets
bigger without helping latency.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Cromarty, Forth, Tyne, West Dogger: Variable, mainly northwesterly, 3 or 4.
Slight. Mainly fair. Good.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Vixie]

George Michaelson wrote:

What did I mis-understand? The APNIC 1x1 is a random sample over
users, and it sees significantly more than 75% EDNS0. More like 93%.


by query volume, or by rdns ip?


By query volume. And, we're at authority where I suspect you see the edge.

Once the query is covered by a modern competent resolver, and gets
passed, it acquires. EDNS0


most middleboxes who think they know what a dns packet has to look like 
and willfully intercept or rewrite or drop them, are between the stub 
and the (desired) rdns. i am not sanguine about getting edns0-carried 
data to a stub often enough during my lifetime to say, let's solve the 
a-vs- problem using another protocol extension.


if the internet is a territory, then the dns, like bgp, is the map of 
that territory. since many commercial and government actors want to 
control access to the internet, they mostly do it by controlling access 
to the dns. and their incentives are misaligned such that they do not 
care what they break or what upgrade paths they deny.


note that solving a+ with an edns0 extension may be good enough, if 
we think that getting the  rrsets cached more often will mean that 
the stub's  query will less often lead to a cache miss, as long as 
the largest share of RTT for a stub query that leads to a cache miss is 
still on the rdns-to-auth path and not the stub-to-rdns path.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[George Michaelson]

On Tue, Mar 22, 2016 at 12:07 PM, Paul Vixie  wrote:
>
>
> George Michaelson wrote:
>>
>> I'm confused. DO bit implies EDNS0, and we think DO bit in the field
>> is north of 75%.
>>
>> What did I mis-understand? The APNIC 1x1 is a random sample over
>> users, and it sees significantly more than 75% EDNS0. More like 93%.
>
>
> by query volume, or by rdns ip?

By query volume. And, we're at authority where I suspect you see the edge.

Once the query is covered by a modern competent resolver, and gets
passed, it acquires. EDNS0

-George

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Vixie]

George Michaelson wrote:

I'm confused. DO bit implies EDNS0, and we think DO bit in the field
is north of 75%.

What did I mis-understand? The APNIC 1x1 is a random sample over
users, and it sees significantly more than 75% EDNS0. More like 93%.


by query volume, or by rdns ip?

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[George Michaelson]

I'm confused. DO bit implies EDNS0, and we think DO bit in the field
is north of 75%.

What did I mis-understand? The APNIC 1x1 is a random sample over
users, and it sees significantly more than 75% EDNS0. More like 93%.

-George

On Tue, Mar 22, 2016 at 11:55 AM, Paul Vixie  wrote:
>
>
> Mark Andrews wrote:
>>
>> In
>> 

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Vixie]

Mark Andrews wrote:

In 

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Wouters]

On Mon, 21 Mar 2016, Marek Vavruša wrote:


  What happens with the Answer Count for QTYPE=A when there are no A
  records and only  records? And can the examples also clarify this?

That's an example 5.3


The use case is, but I still have no idea what the ANCOUNT should
be. Neither the text nor the example list the ANCOUNT. I can only assume
based on the fact that the  is placed in the answer section, that
you would have ANCOUNT=1. I think that is wrong. I think ANCOUNT should
be 0, and the  record should be in the additional section.


The proposal is opt-in, if the authoritative decides to throw in  addresses
then client should accept them. If it doesn't then it should requery. This is 
of course
going to reduce the effectiveness in the transition period for names that have 
A, but don't have 
which is something I expect to change.


And I would assume QTYPE= with additional A records would become the
more common query. At least I hope we are still trying to transition to
IPv6 :)


The rationale is not to carry unnecessary payload when most authoritatives 
support it, but you make a good point
that it might be better to mandate denial of non-existence proof now, and amend 
the draft later.


If you want to do it your way, you need to add some signalling so the
client knows what happened and it can decide whether or not to query
again. I think it is important for the client to know whether the
answer that came back came from a server supporting this document,
as opposed to a server not supporting this document.


  What is SNAME? Did you mean QNAME?
 
SNAME as in RFC1034, either QNAME or CNAME chain terminal name.


Oh thanks. a quick google didnt give me much :)

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Mark Andrews]

In message 

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

I see the point but I don't really want to go down the EDNS route.
So presuming that this draft catches on and Alexa 1M NSs publish at least
one  record,
there would be no need for two queries in most cases and no need for
additional signalisation.
If they don't publish  records, then the resolver will still have to do
the same thing as today,
however that also means that IPv6 adoption is stalled and possibly
irrelevant.

TL;DR the draft optimises first case, if the second case proves to be valid
then we can always amend the draft but I don't want to overengineer it from
the start and it's always much easier to add than to remove.

Marek


On Mon, Mar 21, 2016 at 5:26 PM, Mark Andrews  wrote:

>
> Or we could defined the "aaa" (A and ) {E}DNS bit where the
> server guarantees that the response contains both the A and 
> answers for A or  queries if aaa=1 in the response.
>
> Recursive servers would lookup A/ records if cache is missing
> them before returning a response.
>
> If the A /  does not fit into the additional section then TC=1
> is set.
>
> NOERROR NODATA is valid for both types if aaa=1 in the response.
>
> This way you could signal that you want both A and  records and
> if you don't want both then the response does not have the other
> type added.
>
> Yes, we would have to nuke the stupid servers that reflect back
> {E}DNS flags.  We would also have nuke the stupid firewalls that
> block {E}DNS queries with a unknown flag bit set.
>
> Mark
>
> Mark Andrews writes:
> >
> > Well we really want to get rid of A lookups.   Why don't we just
> > recommend that we publish mapped A records in  RRsets and have
> > master servers update  RRsets if they are inconsitent with the
> > A RRsets.
> >
> > We also need a way to signal that there are no A records in the
> >  RRset.  :::255.255.255.255 or :::0.0.0.0 would be
> > sensible records to indicate this.
> >
> > Mark
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

On Mon, Mar 21, 2016 at 5:14 PM, Paul Wouters  wrote:

> On Mon, 21 Mar 2016, Marek Vavruša wrote:
>
> there was an interest in reducing latency for address record lookups. Me
>> and Olafur wrote a draft on adding  records to A answers and treating
>> them as authoritati
>> ve. This fixes latency issues with NS A/ discovery in resolvers and
>> improves caching for clients ( already cached by the time client comes
>> asking for it).
>>
>> Comments, feedback and snarky remarks would be great!
>>
>> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
>>
>
> I think this draft is a good idea. It does need some more writing out of
> the use case and the possible interaction with some of the answer
> sections. And some additional guidance with CNAME's with and without
> DNSSEC.
>

Agreed, thanks for taking time commenting.


> Some comments/questions:
>
>
> What happens with the Answer Count for QTYPE=A when there are no A
> records and only  records? And can the examples also clarify this?
>
>
That's an example 5.3


> What is the logic behind:
>
>However, if there is a direct answer to the original question, but no
>records for other address protocols, the authoritative DNS server
>SHOULD NOT prove their non-existence.  In this respect, they are
>treated as additional data.
>
> Are you just afraid of packet size to include the proofs? Because now
> a client cannot distinguish between an old auth server not supporting
> this draft and a new server supporting this draft (when no additional
> A/ exist to add). So if it wants to know about the other QTYPE,
> it will need to make another query, even for auth servers implementing
> this draft. Which is exactly what this draft is trying to prevent.
>

The proposal is opt-in, if the authoritative decides to throw in 
addresses
then client should accept them. If it doesn't then it should requery. This
is of course
going to reduce the effectiveness in the transition period for names that
have A, but don't have 
which is something I expect to change.

The rationale is not to carry unnecessary payload when most authoritatives
support it, but you make a good point
that it might be better to mandate denial of non-existence proof now, and
amend the draft later.


> What is SNAME? Did you mean QNAME?
>

SNAME as in RFC1034, either QNAME or CNAME chain terminal name.

I'm also a little confused that section 3 auth servers only talks about A
> and section 4 recursive servers only talks about . I like short
> documents but I think you need to write this out a bit more :)
>
>
>and it MUST reject any such records if the validation
>fails, and the zone is not provably secure.
>
> That's awkwardly written. If the zone is not provably secure (which is a
> term you should not use, and instead use Bogus, Indeterminate. Insecure
> or Secure) then there is nothing to validate - if you meant Insecure. If
> you meant Indeterminate or Bogus, other text is warranted.
>
> I think you mean to say if the zone _is_ secure, then any records in it
> must be proven secure too.
>

Fair enough!

   other IP address records
>
> You mean other QTYPE's for IP addresses :P
>
>
> I don't think the Security Considerations use case mentioned is worth
> mentioning. What is worth mentioning is if this involves CNAMEs,
> because that leads to out of bailiwick data. And complications with
> DNSSEC (chains to other zones?) and without (free Kaminsky attack)
>
> Paul
>

The CNAMEs should be covered by the SNAME part, owner has to either match
QNAME or terminal of CNAME chain just as a direct answer would. Maybe it
needs a clarification.

Thanks!

Marek
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Mark Andrews]

Or we could defined the "aaa" (A and ) {E}DNS bit where the
server guarantees that the response contains both the A and 
answers for A or  queries if aaa=1 in the response.

Recursive servers would lookup A/ records if cache is missing
them before returning a response.

If the A /  does not fit into the additional section then TC=1
is set.

NOERROR NODATA is valid for both types if aaa=1 in the response.

This way you could signal that you want both A and  records and
if you don't want both then the response does not have the other
type added.

Yes, we would have to nuke the stupid servers that reflect back
{E}DNS flags.  We would also have nuke the stupid firewalls that
block {E}DNS queries with a unknown flag bit set.

Mark

Mark Andrews writes:
> 
> Well we really want to get rid of A lookups.   Why don't we just
> recommend that we publish mapped A records in  RRsets and have
> master servers update  RRsets if they are inconsitent with the
> A RRsets.
> 
> We also need a way to signal that there are no A records in the
>  RRset.  :::255.255.255.255 or :::0.0.0.0 would be
> sensible records to indicate this.
> 
> Mark
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

Who wants to get rid of A lookups? "A" is going to be here for a while and
using it as a generic mean to get all addresses of given protocol
(regardless of version) gives servers a way to smoothly transition over
versions.
If the A was updated to have a variable address length, then it could be
used to hand out any address with different RDLEN instead of making new
type. I'm dreading of a day when somebody implements A,, and 
lookup in glibc stub in parallel.

On Mon, Mar 21, 2016 at 4:58 PM, Mark Andrews  wrote:

>
> Well we really want to get rid of A lookups.   Why don't we just
> recommend that we publish mapped A records in  RRsets and have
> master servers update  RRsets if they are inconsitent with the
> A RRsets.
>
> We also need a way to signal that there are no A records in the
>  RRset.  :::255.255.255.255 or :::0.0.0.0 would be
> sensible records to indicate this.


Do we need that? I'd be happy if clients use just A for IP lookups, and
then use
 if only  falls out of cache. Can't think of a good use case.


>
> Mark
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Wouters]

On Tue, 22 Mar 2016, Mark Andrews wrote:


Well we really want to get rid of A lookups.   Why don't we just
recommend that we publish mapped A records in  RRsets and have
master servers update  RRsets if they are inconsitent with the
A RRsets.

We also need a way to signal that there are no A records in the
 RRset.  :::255.255.255.255 or :::0.0.0.0 would be
sensible records to indicate this.


That's a terrible hack and error prone to implement.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Wouters]

On Mon, 21 Mar 2016, Marek Vavruša wrote:


there was an interest in reducing latency for address record lookups. Me and 
Olafur wrote a draft on adding  records to A answers and treating them as 
authoritati
ve. This fixes latency issues with NS A/ discovery in resolvers and 
improves caching for clients ( already cached by the time client comes 
asking for it).

Comments, feedback and snarky remarks would be great!

https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/


I think this draft is a good idea. It does need some more writing out of
the use case and the possible interaction with some of the answer
sections. And some additional guidance with CNAME's with and without
DNSSEC.

Some comments/questions:


What happens with the Answer Count for QTYPE=A when there are no A
records and only  records? And can the examples also clarify this?

What is the logic behind:

   However, if there is a direct answer to the original question, but no
   records for other address protocols, the authoritative DNS server
   SHOULD NOT prove their non-existence.  In this respect, they are
   treated as additional data.

Are you just afraid of packet size to include the proofs? Because now
a client cannot distinguish between an old auth server not supporting
this draft and a new server supporting this draft (when no additional
A/ exist to add). So if it wants to know about the other QTYPE,
it will need to make another query, even for auth servers implementing
this draft. Which is exactly what this draft is trying to prevent.

What is SNAME? Did you mean QNAME?

I'm also a little confused that section 3 auth servers only talks about A
and section 4 recursive servers only talks about . I like short
documents but I think you need to write this out a bit more :)


   and it MUST reject any such records if the validation
   fails, and the zone is not provably secure.

That's awkwardly written. If the zone is not provably secure (which is a
term you should not use, and instead use Bogus, Indeterminate. Insecure
or Secure) then there is nothing to validate - if you meant Insecure. If
you meant Indeterminate or Bogus, other text is warranted.

I think you mean to say if the zone _is_ secure, then any records in it
must be proven secure too.


   other IP address records

You mean other QTYPE's for IP addresses :P


I don't think the Security Considerations use case mentioned is worth
mentioning. What is worth mentioning is if this involves CNAMEs,
because that leads to out of bailiwick data. And complications with
DNSSEC (chains to other zones?) and without (free Kaminsky attack)

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Vixie]

Marek Vavruša wrote:

...

https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/


+1. we ought to have done this from the get-go.

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Mark Andrews]

Well we really want to get rid of A lookups.   Why don't we just
recommend that we publish mapped A records in  RRsets and have
master servers update  RRsets if they are inconsitent with the
A RRsets.

We also need a way to signal that there are no A records in the
 RRset.  :::255.255.255.255 or :::0.0.0.0 would be
sensible records to indicate this.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop