Re: [DNSOP] Extended CNAME (ENAME)

[Mark Delany]

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 easier
than inventing CNAME support at the apex?

No reason to think either approach would get better or less
adoption-rates over time.

Or are there other uses for ENAME beyond what the HTTP/CDN crowd do
with CNAMEs today?


Mark.

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

Re: [DNSOP] Extended CNAME (ENAME)

[Mark Delany]

> 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 work here so most clients are
going to perform at the rate of negative cache lookups for the
foreseeable future. In aggregate I would expect this will slow clients
a bit.

You're also ensuring that the global query rate will substantially
increase on the assumption that HTTP/2.0 becomes as popular as
HTTP/1.0.

Generally speaking, the challenge is that SRV is likely acceptable to
commercial CDN providers that have thus far relied on CNAME - with
it's intrinsic level of indirection - but will be less welcome by
those who are using every trick to squeeze latency out of HTTP.

The latter - who are well represented in http-wg - will probably not
welcome a parallel SRV even if the latency impact is mostly zero.

If you want to make everyone happy, you need to invent a single
round-trip resolution that supports indirection...


These are just observations - not judgments.


Mark.

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

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

[Mark Delany]

> 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 modest than people seem
to think.

The original intent was to merely document a relatively standard
operating procedure that mail admins routinely deploying. Up to that
point it was trade-craft that sometimes surprised and confused new
mail admins. We wanted to reduce that surprise and confusion. Nothing
more.

There was no original intent to try and change the practice nor to
pass judgment on it. It was deemed that that would be covered by some
future activity if warranted. Maybe "NULLMX considered harmful" if
enough IETF wonks were keen on an admonition or driving an
alternative.

It's been nearly ten years since the original draft was posted, and it
has travelled just about the full length of the IETF digestive
tract. I can readily understand why the original goal may no longer be
apparent.

Importantly, in the intervening decade there has been zero evidence of
sufficient energy to pursue alternatives, yet alone pursue them to
completion. And of course the practice has become far more entrenched
since then.

I encourage folk to consider the doc in that context if they can.


Mark.

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

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

[Mark Delany]

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 does not required any code
changes and never has. It's simply recognizing a (to me at least)
serendipitous confluence of existing attributes of DNS and SMTP.

No new protocols are being invented and no deviation from those two
standards is being suggested.

Remember, considerate receivers have been adding this MX to their
zones for many years and senders, whether they know it or not, having
been automatically reaping the benefits as a consequence.

This is about as close as it gets to a free lunch on the Internet.


Mark.

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

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

[Mark Delany]

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 they could see the auth TTL you'd have to worry about domains
that just happen to have very large TTLs in place today for whatever
reason. How do you differentiate those domains?

As far as standardizing such an idea, I'd hazard a guess that the IETF
would not look kindly on encoding semantics into TTL values. Your
rationale for this approach would need to be pretty compelling.

> I've never written an MTA, but it seems like an 
> obvious optimization to me.

It's surprising how hard it is to get the TTL out of most DNS client
libraries. None of the gethostby* family return it. Even fancy
libraries like c-ares are hit and miss with making the TTL available
for different RR types.

And of course the whole thing implies changing every SMTP client on
the planet to recognize these large TTLs. That's a bit of work.

All in all it's hard to see what this approach achieves compared to
nullmx which works today with no code changes and does not require any
special interpretation of DNS data.


Mark.

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

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Mark Delany]

> 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 NETMASK should have a bigger impact beyond how
the reply is cached?

Specifically, if an auth returns a SCOPE NETMASK that is more
fine-grained than the SOURCE NETMASK, should that granularity
influence the SOURCE NETMASK of future queries from that cache to that
auth/domain?

If you think about it, SCOPE NETMASK is the auth communicating its
knowledge of the client network back to the cache. And, in the cases
where the client-subnet option is most useful (CDN-like applications),
it is commonly the case that auths do indeed have better knowledge
than the cache/resolver.

By way of example if a cache issues a query with a default SOURCE
NETMASK of /24 to a well-managed CDN auth, it is entirely possible
that the auth has greater knowledge of the SOURCE network and may
return a SCOPE NETMASK of, say, /25 because it knows that that /24 is
distributed topologically from the auth's perspective.

As it stands today, this cache will continue to issue queries to that
auth/domain with a /24 SOURCE NETMASK even though the replies coming
back indicate that the client network is divided on /25 basis as far
as the auth is concerned. In effect the auth has no way to correct the
erroneous assumptions of the cache.

I'm primarily concerned that client implementations of client-subnet
will hard-code a minimum or default SOURCE NETMASK which may not be
granular enough in the future. As we approach v4 exhaustion I can
easily imagine a corp network dividing a /24 up on a regional basis
and who knows what will happen to public routing as we really do get
close to v4 exhaustion?

If caches allow returned SCOPE NETMASKs to influence future SOURCE
NETMASKs (modulo privacy policy of course) then as networks get more
granular, auths - which have the greatest incentive to adapt - can
dynamically influence caches as the Internet changes.

(Admittedly this may not help if caches adopt a default privacy mask
that matches their default SOURCE NETMASK - which I expect many will).


b) 11.2 - Whitelist

   "Only a few Recursive Resolvers will need to use edns-client-subnet"

Does "few" refer to implementations or deployments? If the later, then
I wonder whether that estimate is accurate?

I would think that any enterprise or ISP with multiple ingress points
is a candidate user. Maybe that's still a "few" in the grand scheme of
things but the number of relevant operators goes well beyond the tiny
population of public caches and giant eyeball networks.

Has "few" been quantified? Are we talking about 1,000 deployments,
10,000? What is the threshold at which "few" no longer applies?

I'm also thinking of medium sized corporates which could easily run
regional networks with internal caches and auths. Maybe this isn't a
concern here because it's not the "Internet", but generally they will
want to use the same technology.

My ulterior motive is to revisit the whole notion of whitelisting. Why
have it at all? I worry that the desire to make a manageable
Internet-wide whitelist (if that's not an oxymoron) is driving some of
the assumptions and text in the spec.


Apologies if this is a rehash of earlier discussions, ignore anything
that has been previously settled.


Mark.

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

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

[Mark Delany]

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 understand
out-of-order" be enough? Once seen in a TCP session it would hold true
until closed. The non-presence of such an option could then entrench
the in-order assumptions that may exist in the installed base.


> i expected that DNS-over-HTTP would work the same as WWW-over-HTTP,
> which is to open multiple parallel TCP/80 (or TCP/443) sessions if
> parallelism is required.

If DNS over HTTP is really being considered, would it be better to
start with HTTP/2.0 as the base protocol rather than 1.* then you get
parallel for "free".


Mark.

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

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

[Mark Delany]

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 reasonable.

>   Only if you want 8% of your queries to fail.
>   http://users.isc.org/~marka/ts/alexa.optfail.html
> 
> 
> That's harm on the initiator side.

But the harm should be a lot less than the proportion of servers
exhibiting the problem, yes?

First off there is the matter of proportion of queries that actually
go to failing servers. Even with the top 1,000 domains, most of it is
long tail.

Second the cost should be amortized across all queries, not just the
first few to a given server.

I'm assuming that these yet-to-be-implemented out-of-order initiators
may well have heuristics that determine whether a TCP connection is
worth it or not. I'm also assuming that they'll have to track their
currently active TCP connections. With this sort of machinery in place
it's not a huge additional burden to track failed connections of
high-occurrence servers for a reasonably long time period.

In other words, the cost of detecting a non-compliant server could
reasonably be amortized across many queries. The net harm will never
be zero, but it should be approaching it.

Also, the motivation to improve the situation resides with the person
most capable of making changes - the owner of the domain. That's a
nice alignment of interests.


Mark.

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

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

[Mark Delany]

> 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 the SMTP QUIT path (and all the
flammage that produced). TCP FIN communicates intent just fine.

(As an aside, I've always wonder what a client should do if a server
responds 5XX to QUIT? Issue a SUDO QUIT command?).


Mark.


pgpMzjYnNRrXk.pgp
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Mark Delany]

On 24Dec14, Mark Delany allegedly wrote:
> > 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 NETMASK should have a bigger impact beyond how
> the reply is cached?

Tap tap tap. Is this thing turned on?

I think 3-4 people made some well-considered feedback on this draft,
but there has been zero discussion or author feedback for some six
weeks now.

Does that mean there is insufficient interest in progressing this draft?

I ask because in my dayjob we've been recently approached by some
large eyeball providers who are now willing to invest in upgrading
their resolver infrastructure to support client-subnet now that they
see the benefits.

It'd be a pity if this died on the vine just as others are starting to
come around to the idea.


Mark.


pgpGZBF5mZcRH.pgp
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Mark Delany]

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 my biggest bugbear actually. All my other comments are
nice-to-haves. I hear that Google now adaptively whitelist which is a
nice strategy but I'd really like to see the whitelist approach
deprecated as much as possible. (And yes, I understand MarkA's stats
that show some small percentage of auth queries will break).

I've been in other conversations lately where it was all about how do
we get "pick some larger resolver" to whitelist us? We all know that
doesn't scale. So interest appears to be growing.

> Its probably already more widely deployed than IPv6...

On the auth side I think you're right. It's the client side that's the
missing link. But this is a classic alignment-of-interest problem. The
relatively small number of auths who care implement, but there is
little incentive on the resolver side.


Mark.


pgpJYRF8Ef4iY.pgp
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Mark Delany]

On 15Feb15, Paul Hoffman allegedly wrote:
> 
> 
> On Feb 15, 2015, at 4:49 AM, Suzanne Woolf  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: 
> https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-00
> > It now needs reviewers to review and authors to revise. 
> > If you agreed to review it earlier, or even if you didn't but you're 
> > interested, please do.
> 
> FWIW, according to , 
> four people (including me) agreed to review. It probably needs more.

And I might add that at least some of us (even though not named in
that list) did post review comments after the call and we've yet to
hear from the authors on some of the issues raised. That was my point
in prodding a day or so ago.


Mark.


pgpI65R5ccboM.pgp
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Seeking edns-client-subnet implementers

[Mark Delany]

On 26Mar15, David C Lawrence allegedly wrote:
> At IETF this week it was decided to refocus the effort on the
> edns-client-subnet draft on only documenting the existing behaviour of
> deployed implementations.

That's disappointing and somewhat at odds with the theme of the
on-list discussions since the last draft was posted. Oh well.

> To clarify some areas that were un/under-specified I am looking for
> implementers of both recursive and authoritative servers at the

Given that the major public caches have all adopted a whitelist
approach to participating auths, one presumes that their whitelists
represent all deployed implementations.


Mark.


pgpxt6u0oNj8s.pgp
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Small review of draft-ietf-dnsop-edns-client-subnet-00

[Mark Delany]

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 corporations and research networks
that have a national or global footprint and multiple ingress points
into their network.

If you're a Comcast or a Verizon or an AARNet serving potentially vast
numbers of customers over a large footprint, how different is that
from a public resolver in the context of this draft?


Mark.


pgpk1b6bAUlyi.pgp
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-02.txt

[Mark Delany]

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
> Authors : Carlo Contavalli
>   Wilmer van der Gaast
>   David C Lawrence
>   Warren Kumari
>   Filename: draft-ietf-dnsop-edns-client-subnet-02.txt
>   Pages   : 27
>   Date: 2015-07-06

I was under the (perhaps mistaken) impression that there was a plan to
rewrite this spec in light of actually implementation experiences. Is
this draft that rewrite? I ask as this seems to be more a clean-up of
the original draft.

If it is the former then one issue I raised with the previous draft
remains undiscussed and unchanged. That being the notion of
caches/resolvers using white lists to constrain which servers should
be sent the ECS option.

We all know a white-list doesn't scale for an internet protocol and my
limited experience of hunting down owners, exchanging emails and
agreeing on a white list format is pretty broken and brittle.

I would think that if we're to proceed with this protocol then the
white list requirement should be removed from the spec.


Mark.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-02.txt

[Mark Delany]

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
> capitalization, so it's even softer than usual.  If there is a
> statement in there that you think mandates whitelists

True, there is no mandate, but all implementations that I'm aware of,
have implemented a white list. While the language is softer in -02, is
it necessary at all as it will only continue to encourage white list
behavior just as the previous language did.

IOWs, why not remove 11.2 completely?


Mark.

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

Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

[Mark Delany]

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.

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

Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

[Mark Delany]

On 17Dec15, Paul Vixie allegedly wrote:

> > 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
> 
> i think this is opaque to the dns-over-http specification. that is, while 
> http may under 
> its covers do all kinds of asynchronous things

I may not be being very clear or I may misunderstand. As far as
implementation is concerned you are of course correct. As far as the
semantics of the order of responses over HTTP, not so much.

What I was getting at is that a dns-over-http client can pipeline send
request id=1 then request id=2 and get back pipelined response id=2
then response id=1 over a single connection:

ClientServer
 Request id=1  >
 Request id=2  >

.. time passes

 < Response id=2
 < Response id=1

That is, a dns-over-http client has to do more elaborate
request/response matching with id (+query RR) rather than rely on
submit order for matching.

This re-ordering of responses is not allowed in regular HTTP 1.* and
would almost certainly break common HTTP clients that expect pipeline
order to be maintained.

I'm not saying this is good or bad, just saying it's an important
topic for any dns-over-*stream* protocol to discuss. Least surprise
and all that.


Mark.

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

Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

[Mark Delany]

On 20Dec15, Paul Vixie allegedly wrote:

> since DNS-over-HTTP does not call for out-of-order HTTP responses

But at least according to dpriv:

"Since pipelined responses can arrive out-of-order, clients MUST
match responses to outstanding queries using the ID field, query
name, type, and class."

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
then I would think that those semantic variations should at least be
highlighted in shane-review.


Mark.

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

Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

[Mark Delany]

> > 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 document.

Pipeline stalling due to forced in-order queries/responses is quite a
performance limitation and some implementations could readily provide
out-of-order.


Mark.

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

Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)

[Mark Delany]

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 ago.

Apart from the web-panels I'd say that the biggest bugbear is CPE such
as DSL/cable modems. Having conducted some experiments recently, my
observation is that some of these** have pretty atrocious cache/proxy
implementations. I had to drop the idea of using PTR for a particular
application because one implementation of dnsproxy assumes that PTR is
only ever valid in in-addr.arpa space (it had plenty of other bugs
too, but that's another story).

I see now that some newer CPE defaults to 8.8.8.8 - at least that
eliminates the local implementation bugs...


Mark.

** The irony won't be lost on you, Mark, that your neighbours are
   probably running with that bug since I found it in a popular DSL
   modem sold in Australia/SE Asia.

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

Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)

[Mark Delany]

> > 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 fancy) tests.

I eventually went for a try-this-fall-back-to-that strategy. I won't
say which RR I used as the guaranteed-to-work fallback as I might get
a public flogging :-)


Mark.

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

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Mark Delany]

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).  However,
>   unlike standard DNS messages, the question section, answer section,
>   authority records section, and additional records sections are not
>   present.  The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT,
>   ARCOUNT) MUST be set to zero on transmission.

If we're looking for more counterexamples, there's also RFC7873#5.4

   For servers with DNS Cookies enabled, the QUERY opcode behavior is
   extended to support queries with an empty Question Section (a QDCOUNT
   of zero (0)), provided that an OPT record is present with a COOKIE
   option.  Such servers will send a reply that has an empty
   Answer Section and has a COOKIE option containing the Client Cookie
   and a valid Server Cookie.


Mark.

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

Re: [DNSOP] Meaning of lame delegation

[Mark Delany]

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 the terminology for 
the various
errors that can occur is rather lacking and the use of "lame" to cover a 
multitude of sins
is perhaps, erum, lame itself.

The term is certainly unhelpful in the sense that all it can convey with any 
certainty is
that "something is wrong" without any guidance as to where to start looking to 
correct
matters.


> There are three possible situations in which this might be considered a lame 
> delegation:

(4) What if NS.EXAMPLE.ORG does respond to EXAMPLE.NET queries but claims that 
the correct
name server is NS.EXAMPLE.COM?

Does that make the delegation NS "lame" since resolvers will generally 
ignore
NS.EXAMPLE.ORG henceforth for resolution of EXAMPLE.NET?

(5) Same thing as above excepting with in-domain name servers. If NET. says the 
name
server for EXAMPLE.NET is NS1.EXAMPLE.NET, but when you query 
NS1.EXAMPLE.NET it says
NS2.EXAMPLE.NET is authoritative.

(6) The delegation and auth agree on the NS name, but disagree on the IP 
addresses. Does
that make the IP addresses supplied as glue "lame"?

(7) Is there a differentiation between a "lame" delegation which makes 
resolution
impossible vs. one which makes it more difficult vs. one which risks 
inconsistent
answers?

I mostly ended up with the catchall "inconsistent" with the only benefit above 
and beyond
"lame" being that it has a plain meaning understood by generalist admins.


Mark.

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

Re: [DNSOP] Meaning of lame delegation

[Mark Delany]

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 
with the
consequences. Conversely, the cause of a lame delegation is an administration 
error by the
domain owner or their authoritative minions.

That seems like two sides of the same coin.

I like the notion of "non productive" or no progress being made. Ignoring 
transient errors
and things like RRL, if a resolver makes a query which doesn't move it closer 
to resolving
the QNAME then that seems to be the most general definition of "lame".

In other words, "lame" means nothing more than an imperfect configuration which 
causes
resolver angst.

Do we have anything more precise than that?


Mark.

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

Re: [DNSOP] Meaning of lame delegation

[Mark Delany]

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 situation *always* requires a configuration 
change
somewhere in the resolution path, yes?

Conversely, does it follow that there are no configuration errors which are not 
lame?
Perhaps mild inconsistencies such as SOAs differing or TTLs differing are 
considered not
to be lame.

So de-laming always requires adding/subtracting/editing one or more NS/A/ 
RRs, yes?


Mark.

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

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

[Mark Delany]

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 imply lameness.

Lameness is that subset of configuration errors detected in a response returned 
during the
normal course of resolution which directly stalls or thwarts resolution.

Point being that there are many mis-configurations which do not stall or thwart 
resolution
such as a missing  from one NS or mis-matched SOAs. These are not 
considered lame.

And there are some mis-configurations which *indirectly* stall or thwart 
resolution which
are also not considered lame.

The scenario I have in mind is the classic zone transfer failure due to ACLs. 
The new zone
has a changed address for one of the auths. The result being that the 
un-updated auth
continues serving the old address record which no longer has anything listening 
for DNS
queries.

Since authoritativeness or otherwise of answers from this old address cannot be
ascertained due to unresponsiveness, this is not considered a lame scenario 
which I find
unfortunate but understandable.

In summary, lameness appears to be a very specific set of resolution symptoms 
due to a
subset of configuration errors.


Mark.

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

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

[Mark Delany]

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 good point.

I confess my perspective is that of the DNS admin/serving side focussed on "why 
it is"
whereas lameness is most often observed as a "what it is" from the 
resolution/client-side
perspective. To use your useful terms.

I have one last question. Regardless of whether we agree precisely on what 
"lame" means,
what is the call to action when a zone or its name servers are declared lame?

And how is that different from any other form of miscreant auth behaviour such 
as
inconsistency?

I mean if "lame" is a precious historical term that warrants considered 
clarification,
surely it has a very specific value that we can all act on, right? So what is 
that
very specific value?


Mark.

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

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Mark Delany]

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 may
have a bit if a chicken and egg problem. Some processes may prefer to
configure the parent first while others may wish to configure the
delegated name servers first.

More specifically, I have a no-configuration reverse server which
deduces its NS details from the delegation (the goal being to minimize
duplication of configuration information). It's impossible for it to
be configured and serve correctly without first gaining information
from the delegating parent.


Mark.

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

Re: [DNSOP] QNAME minimization is bad

[Mark Delany]

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 an underscore in their base zone name to trigger
> the special casing in 9156? That would not require a new RFC and
> perhaps might not require code updates?

That doesn't help ip6.arpa tho.

I must admit I was a bit surprised when I first spun up a custom reverse auth 
to find that
nearly 80% of ip6.arpa queries were qmin walking with only 20% asking for the 
ultimate
PTR. Here's a typical log entry for one query:

q=A/4.3.2.1.0.0.0.0.0.2.2.5.e.c.f.f.f.f.f.f.f.ip6.arpa. 
p=36142 id=27861 sz=198/1232 C=0/1/1 Trunc-qmin
  q=A/1.0.0.0.0.4.3.2.1.0.0.0.0.0.2.2.5.e.c.f.f.f.f.f.f.f.ip6.arpa. 
p=53007 id=34561 sz=208/1232 C=0/1/1 Trunc-qmin
q=A/1.0.0.0.2.1.0.0.0.0.4.3.2.1.0.0.0.0.0.2.2.5.e.c.f.f.f.f.f.f.f.ip6.arpa. 
p=62639 id=57771 sz=218/1232 C=0/1/1 Trunc-qmin
  q=A/3.1.0.0.0.2.1.0.0.0.0.4.3.2.1.0.0.0.0.0.2.2.5.e.c.f.f.f.f.f.f.f.ip6.arpa. 
p=9742 id=43025 sz=220/1232 C=0/1/1 Not PTR
q=PTR/3.1.0.0.0.2.1.0.0.0.0.4.3.2.1.0.0.0.0.0.2.2.5.e.c.f.f.f.f.f.f.f.ip6.arpa. 
p=34942 id=48483 sz=211/1232 C=1/0/1 DB:autoreverse

In effect qmin causes this server to see 5 times as many queries as it might 
otherwise get.


Mark.

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

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01

[Mark Delany]

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 duplicates checks for
> > QDCOUNT!=1 is staggering, and that just in the Golang eco-system.
> 
> Well now I'm really a lot more curious about this.

As always, the truth is likely somewhere in the middle.

Nearly two years ago on this very list I asked
(https://lists.dns-oarc.net/pipermail/dns-operations/2022-March/021595.html) 
about the
presence of QD=0 server cookies in the wild as I'd not seen any with a "from 
scratch" auth
server I was implenting and was wondering whether it was worth adding support.

I didn't get any positive responses but went ahead anyway since RFC7873 is 
Standards
Track. This server is written in go and uses Miek's excellent dns package
(github.com/miekg/dns) so I consider it part of the Golang eco-system. It's 
open source so
if anyone wants to verify the following, I can send a link.

As an exercise I just removed the QD=0 feature to see how much extra work it 
cost in the
original implementation. Here's the SLOC counts according to 
github.com/boyter/scc:

QD=0   Prod   Tests
Not supported  42524181
Supported  42884182
   
Diff 36   1
   

This is somewhat misleading because with QD=0 support the defaultMsgAcceptFunc 
has to be
replaced with a custom function which is an exact clone of 
defaultMsgAcceptFunc() with one
change:

   - if dh.Qdcount != 1 {
   + if dh.Qdcount > 1 {


So if we don't count this clone as *new* code, say if miekg/dns supported QD=0 
with a
feature flag, the actual SLOC changes to the server reduce to:

QD=0   Prod   Tests
Diff 36   1
Clone   -32
   
  4   1
   

That is, 4 lines of production code and one additional row in a test-case 
table. In terms
of just the code related to validating and processing the inbound query, those 
4 lines
represent 1% of the ~430 lines of relevant code which itself represents 10% of 
the
complete server implementation.

It's also the case that the implementation worried about QD=0 from day one 
which gave it a
structural advantage of incorporating QD=0 into a standard logic flow. Existing
implementations which have to retrofit may incur larger structural costs.

You can spin this any way you want, so I'll let others draw their own 
conclusions. Before
doing so though, I'll finish with one other stat of interest. In those 
aforementioned ~430
lines of query validation, over 20% consists of conditionals! So on one hand, 
dealing with
QD=0 cost this implementation just one conditional; on the other hand, that one 
"if" lives
in a sea of other conditionals due to DNS complexity.


Mark.

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

Re: [DNSOP] Do we need new draft that recommends number limits ?

[Mark Delany]

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 background rather than
> polluting caches with chains of CNAMES.

Absolutely. It's always struck me as a copout that some CDN providers 
externalize their
infrastructure costs onto every DNS cache on the planet.

Is there any fundamental reason why a CDN provider can't make their external 
facing DNS do
all that CNAME resolution internally and just forward the final answer? Not 
only would
that likely speed up client resolution time, it'll also reduce the amount of 
thrashing in
DNS caches around the world.

But sadly, that ship has well and truly left port, and now we're deciding 
whether any
reasonably limit can be set and how it would be enforced.

And "enforcement" is probably the biggest benefit of a central document which 
spells out
limits, that cache implementors at least have somewhere to point when a limit is
exceeded. But that would imply that said document has more "MUSTs" than 
"SHOULDs" or
"RECOMMENDEDs" in it. Is that what people are prepared to do? Otherwise a 
document which
merely suggests a limit is likely to be of, ahem, limited value.


Mark.

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

Re: [DNSOP] Why would a v4 client send AAAA query?

[Mark Delany]

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 all the requests arriving to a root server in
> the DITL data for 2019-04-10 and found:

> So you can see that of all the ipv4 clients, 53% were asking for A

Ahh. But are you both talking about the same "clients"?

I assume Naveen is asking about clients as in applications on end-point
devices whereas your data is talking about clients as in recursive resolvers
asking on behalf of applications on end-point devices.

Your data is showing which transports the recursive resolvers prefer not which
transports the end-point devices have available to them. Even if there was a
correlation between the two (which I don't believe there is in general) it
still doesn't tell you whether that end-point device has both transports
available or not - it only shows which they prefer.

I think the answer is two-fold. First there is no standardized or easy way for
an application or a stub library to determine which transports are available
without actually trying them. As a consequence programmers, being a naturally
indolent mob, gravitate to the simplest and easiest thing to do which is to
ask for all addresses then iterate over them until they find one that
works. Using 'getaddrinfo' in perl tends to produce that outcome as does
net.Dial("tcp") in Go.

Second, as others have pointed out, almost all systems these days have at
least a loopback ipv6 address so well-written applications really must ask for
both types just in case ::1 comes back as an answer (or the only answer!).

What would be telling from those stats is how many clients are still only
asking for v4 addresses when they presumably have an interface with a v6
address as that probably indicates legacy code using pre-ipv6 APIs (or poorly
written modern code) which specifically asks for v4-only addresses.

Having said all that, there are still a scary number of IoT-type devices that
are v4-only; webcams and VOIP phones come to mind. But code in those things
are so poorly cobbled together that expecting rational DNS behavior is
probably asking too much.


Mark.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[Mark Delany]

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 implying that the resolver 
should first
consider a larger edns0 bufsize before resorting to TCP?

Or are you suggesting that responses with TC=1 should include as much of the 
answers as
will fit and then the resolver can decide whether enough is enough?

That is, what do they look at to avoid a "blind requery"?


Mark.

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