[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values

[Ray Bellis]

On 10/07/2024 14:27, Philip Homburg wrote:


So the question becomes, do we want some limits in an RFC that everybody
agrees on or do we want to keep the current informal system where limits
are not fixed and people can get unlucky if they exceed limits they didn't
know exist.


I'm all for a recommended limit.

But the rationale for the current one in the draft is bogus.  All the 
root NSset does is put a lower bound on any proposal.


Ray

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values

[Ray Bellis]

On 09/07/2024 11:06, Kazunori Fujiwara wrote:

Dear DNSOP,

I submitted new draft that proposes to consider "Upper limit value
for DNS". If you are interested, please read and comment it.



I disagree with the rationale for 13 name servers.

The root (and .com) have that because it was what would fit into packets
of a particular size given their naming scheme and that scheme's
efficient compressibility.

If there is to be a recommended limit, it should be specifically for
packet size reasons, and not just "because this is what the root does".

IIRC, Vixie et al wrote a draft on this, but it didn't reach RFC status.

Ah, there it is:

  https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-respsize-15.txt

Ray

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Side Meeting - DNS Load Balancing

[Ray Bellis]

On 28/06/2024 17:47, Ben Schwartz wrote:

Hi DNSOP,

The practice of DNS Load Balancing -- sending different answers to 
different resolvers to optimize latency and avoid overload -- has been 
around for at least 25 years, and remains as popular as ever.  It's 
never really been supported in the DNS standards though, and it 
particularly conflicts with the concepts of zone files, zone transfers, 
and offline signing.


I think it's time we did better on this front.  To that end, Shane Kerr 
and I will be hosting a side meeting at IETF 120 on DNS Load Balancing, 
tentatively scheduled for Wednesday afternoon:


https://wiki.ietf.org/en/meeting/120/sidemeetings#wednesday-24-july 



We hope to develop a strategy for standardization, discuss topics that 
should be in or out of scope, and possibly present a demo of what 
standards support for load balancing could look like.  Please join us 
(in-person or remotely) if you have an interest in this topic.


For  discussion in the next few weeks before the meeting, we'll be 
experimenting with the IETF's new Slack channels for collaboration.  If 
you have thoughts or questions, please join our channel (using your 
Datatracker account):


Can you please ensure that there's time on the agenda for discussion on 
why it remains a bad idea to use the internet's name to resource mapping 
scheme to perform what should be achieved in the routing layer?


The DNS was never designed intended to deliver different answers to 
different users.  DNSSEC solidified that and the practise IMNSHO should 
be discouraged, not standardised.


Ray

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Mahesh Jethanandani's No Objection on draft-ietf-dnsop-qdcount-is-one-03: (with COMMENT)

[Ray Bellis]

> So this is not just RFC1035. I *guess* this could be "DNS specifications" 
> instead of "DNS specification" 

That was going to be my suggestion. 

Ray

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: AD Review of: draft-ietf-dnsop-qdcount-is-one

[Ray Bellis]

On 28/05/2024 22:12, Warren Kumari wrote:

Hi there, authors (and WG),


Thank you for this document, I found it clear, useful, and an easy read.


I do have a few comments/nits; addressing these now should help the IETF 
LC and IESG evaluation go more smoothly.


Please SHOUT loudly once you've had a chance to address these, and I'll 
start IETF LC.


LOUDLY!


Questions / issues / comments:
1: Can you please update the Abstract to clarify *how* the document 
updates RFC1035?


I think that something like:
"This document updates RFC1035 by {clarifying|specifying} that the 
QDCOUNT parameter of a DNS Query must not be greater than one." or 
similar should work.


I've committed an update, albeit it it doesn't take the above verbatim 
because it would've ended up -mostly- repeating the text that was 
already there and in the title.


The abstract now reads:


This document updates RFC 1035 by constraining the allowed value of the
QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a maximum
of one, and specifies the required behaviour when values that are not
allowed are encountered.


If that suffices I'll actually upload that to the datatracker.

I also took the opportunity to incorporate a trivial editorial nit 
spotted by Tony Finch that was reported to us over the weekend.


cheers,

Ray

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Re: [DNSOP] Comment on Ranking data

[Ray Bellis]

On 05/04/2024 15:04, Willem Toorop wrote:

I also think the draft should be more explicit on what data is actually 
meant in those ranks (i.e. referral responses with "B: Data from the 
authority section of a non-authoritative answer, Additional information 
from non-authoritative answers." etc.) and I also agree that we should 
remove the ranks which are currently meaningless and would not occur in 
practice (like the BB ranks in the list). I furthermore agree with your 
recommendation for DNS software to discard all data which is not in the 
list.


Probably related - I'd be quite interested in info and/or guidance about 
how exactly recursive resolvers process and/or trust the value of the AA 
bit sent by authoritative servers.


Is that bit "informational only", or does it in fact still play a role 
in recursive resolvers' logic?


Ray

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

Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

[Ray Bellis]

I think this document gives an opportunity to explicitly clarify 
expectations regarding the NS records either side of the zone cut.


I get the impression with DELEG on the horizon that there's a shift 
towards the parent side data being considered more "authoritative" even 
though in protocol terms it explicitly isn't.


Even if that's not the case, discussion of when child-side NS records 
should be purged and then re-learned by following the parent-side 
delegation would be useful.


I also idly wonder what would happen if one were able to incorrectly put 
the DS records for a zone into the child zone...


cheers,

Ray

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

Re: [DNSOP] RFC 9460: ServiceParamKey for web integrity

[Ray Bellis]

On 28/11/2023 12:25, Ben Schwartz wrote:


I think DNS is simply the wrong tool for this job.


+lots

Ray

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

Re: [DNSOP] I-D Action: draft-bellis-dnsext-multi-qtypes-08.txt

[Ray Bellis]

On 17/11/2023 10:41, Paul Wouters wrote:


I think it would be unwise to make assumptions on how people will use
this feature. They might want to ask for many more records along with
A/ records. If we change a core DNS feature, it should not designed
for a specific DNSSD use case of HTTPS.


The extension is already limited to a maximum of 7 additional QTYPES, 
and some might argue that that's too many.  A consideration here is the 
opportunity for amplification.


The main DNSSD use case is TXT+SRV.  A++HTTPS was an example of a 
future use case that might be popular outside of DNSSD, and where NSEC 
bitmaps are not efficient.


I'd also say that this is an extension - it does not change any existing 
core DNS features.   It's 100% backwards compatible.


Ray

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

Re: [DNSOP] I-D Action: draft-bellis-dnsext-multi-qtypes-08.txt

[Ray Bellis]

On 16/11/2023 11:13, Paul Wouters wrote:

On Tue, 14 Nov 2023, internet-dra...@ietf.org wrote:


Internet-Draft draft-bellis-dnsext-multi-qtypes-08.txt is now available.


Last time this came around I also suggested instead of n times QT
entries, to use the same method as NSEC does for conveying which RRtypes
are covered using a single bitmap:

https://datatracker.ietf.org/doc/html/rfc3845#section-2.1.2


Speaking personally, I am not a fan of NSEC bitmaps when used to encode 
a small and possibly sparse list of QTYPES.   It's relatively 
complicated to encode / decode and is often inefficient.


I note, for example, that encoding HTTPS (type 65) this way requires 10 
octets.   Notwithstanding that asking for "" too would also fit 
within that 10 octet bitmap, in this draft's simpler model it would only 
take 2 octets to encode HTTPS, or 4 to encode  + HTTPS.


In any other use case where multi-qtypes is just used to request one 
single additional type then that singleton list takes two octets 
irrespecitive of what that type is, and that's smaller than the smallest 
possible NSEC bitmap (3 octets).


[I've excluded the QTCOUNT leading byte because it has been suggested 
that it's not necessary.  This should be a separate discussion].


Making HTTPS the primary QTYPE such that the EDNS option only needs to 
encode (A + ) would reduce an NSEC-style bitmap from 10 bytes to 6, 
but it'll be a long time before HTTPS becomes the most common response 
to A /  / HTTP.


cheers,

Ray

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-qdcount-is-one-01.txt

[Ray Bellis]

On 23/10/2023 16:01, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-dnsop-qdcount-is-one-01.txt is now available.


The only change relative to the -00 draft is slightly clearer wording in 
the paragraph about DNS firewall processing.


Ray

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

Re: [DNSOP] Cache refreshes like in DNS over CoAP

[Ray Bellis]

On 04/08/2023 00:29, Petr Menšík wrote:

What do you think, would such mechanism be useful even on classic DNS? 
Are there already deployed alternatives? How useful something similar 
might be? Does such mechanism contain significant drawback, why it would 
not be a good idea?


Something like it has been proposed before, around the time of the 
previous Yokohama IETF:


  draft-muks-dnsop-dns-opportunistic-refresh

IIRC, one problem with the proposal is that zone serials are only 
intended to be meaningful in the context of zone transfers, and servers 
generating dynamic answers may not even use "zones".


Ray


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

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

[Ray Bellis]

On 17/02/2023 20:58, Ted Lemon wrote:

OpenThread. It’s on GitHub.


Notwithstanding an implementation apparently getting by in the DNSSD 
space, I remain convinced that QDCOUNT > 1 has no place in the global 
DNS and that RFC 1035's ambiguity on the matter needs clarification.


To that end, Joe Abley and I have written draft-bellis-dnsop-qdcount-is-one



We hope that this (short) draft can quickly gain WG acceptance and 
consensus.


I have also revived my ancient multi-qtypes draft (-00 was in 2012!)



If the QDCOUNT draft is accepted I would propose to simplify some of the 
text in the Multi-Qtypes draft to refer to the former instead of laying 
out the whole problem statement again.


Ray

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

[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt

[Ray Bellis]

 Forwarded Message 
Subject: New Version Notification for 
draft-bellis-dnsop-qdcount-is-one-00.txt

Date: Fri, 17 Feb 2023 08:12:18 -0800
From: internet-dra...@ietf.org
To: Joe Abley , Ray Bellis 


A new version of I-D, draft-bellis-dnsop-qdcount-is-one-00.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:   draft-bellis-dnsop-qdcount-is-one
Revision:   00
Title:  In the DNS, QDCOUNT is (usually) One
Document date:  2023-02-17
Group:  Individual Submission
Pages:  6
URL: 
https://www.ietf.org/archive/id/draft-bellis-dnsop-qdcount-is-one-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/
Html: 
https://www.ietf.org/archive/id/draft-bellis-dnsop-qdcount-is-one-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-qdcount-is-one



Abstract:
   This document clarifies the allowable values of the QDCOUNT parameter
   in DNS messages with OPCODE = 0 (QUERY) and specifies the required
   behaviour when values that are not allowed are encountered.




The IETF Secretariat


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

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

[Ray Bellis]

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.


I can see why that was added, but I really wish it hadn't been...

Ray

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

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

[Ray Bellis]

On 16/02/2023 12:52, Dick Franks 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.



Good spot, Dick, and one I admit I'd forgotten about, which as a 
co-author of RFC 8490 is slightly embarrassing!


However for OPCODE 0 (QUERY) the assertion still remains valid.

Ray

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

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

[Ray Bellis]

On 09/02/2023 08:54, Ted Lemon wrote:


Thotz?


draft-bellis-dnsext-multi-qtypes-04

Ray

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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Ray Bellis]

On 23/08/2022 16:45, Peter Thomassen wrote:

I think their point is that the application (e.g. browser) may be 
agnostic of the resolution system (= accept the name), but resolution

 may fail because something switching layer like nsswitch would choke
on a non-DNS-style name, *even when* the downstream non-DNS resolver
would be available.

So, by making the non-DNS names DNS-style, one can allow for more 
agnostic intermediate layers in the process that make DNS-like

assumptions.


Yes, that's in part what I was trying to say, although it may also apply 
to stub-resolver-like functionality that is part of a userspace library.


Ray

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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Ray Bellis]

On 23/08/2022 17:14, Paul Hoffman wrote:


Is the suggestion that the non-DNS protocol follow the DNS wire
format and/or presentation format now an expectation? This seems like
a long jump.


The dot-separated form of a domain name _is_ a "presentation format", 
even if it's not precisely that of a zone file.


I don't care about the wire protocol, or how any "rdata" is presented
and/or encoded.

Ray

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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Ray Bellis]

On 23/08/2022 12:18, Schanzenbach, Martin wrote:


I think the notion that there is strict "format" of a name and that
if it is not in that format is not actually part of the same
namespace is already behind us.

If that were the case then we do not need .alt at all.

Arguably you do not, but unless there is some _other_ indicator that a
name is a GNS name (e.g. https+gns://) then we have a problem. 
non-GNS-aware clients will send all those queries to the DNS.


But if the carve-out is done using the rightmost one or two labels as 
proposed with ".alt", then existing code has to cope.  Any application 
that wants to parse a name _even if the nsswitch is .alt aware_ might 
need to be modified to allow these domain-style names to get as far as 
the system's resolver.


Conforming to a couple of (IMHO not particuarly onerous) restrictions on 
total length and label length would go a long way to mitigate that.



For example, GNS names are UTF-8. They are not LDH or any kind of DNS-compliant 
wire format.


DNS does not require LDH, or ASCII.


I think one way to look at is is that we try to solve a problem with the 
display/presentation of names in alternate name systems and how they can be 
confused by applications but also humans with DNS names.

Applications (to some degree) have to deal with malformed names anyway as part 
of the user input handling.
If they consider the given .alt-name malformed because they only expect DNS 
names, then that is within the expected behaviour.
If the application crashes because of such a name, it would also crash because 
of data corruption or faulty user input.
And that is a bug in the application, possibly even a security issue if it 
leads to a buffer overflow etc.


I am not so concerned with crashes.  I am concerned that there is a 
semantic difference in the errors generated when a name cannot be parsed 
vs when it does not exist.


Yes, the net result is that the resource cannot be found, but over the 
years there have been significant issues caused by misinterpretation of 
errors.


Ray

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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Ray Bellis]

On 23/08/2022 10:22, Andrew McConachie wrote:



The only restriction that seems reasonable to me is prohibiting zero 
length strings. This list convinced me other restrictions would be a bad 
idea.




There will be a very long tail of systems out there that do not know 
about ".alt".


How would those systems respond when passed a domain-style name that 
does not meet domain-style syntax rules (specifically those for total 
length and label lengths) ?


If the answer is that they return something other than EAI_NONAME (or 
HOST_NOT_FOUND for gethostbyname) then this needs to be considered further.


IMHO, if you want to be in a carve-out of the domain name space, you 
still need to play by the domain name space's technical rules, in a way 
that's backwards compatible with systems that don't know about the 
carve-out and will assume that veryverylonglabel.foo.alt _is_ a domain name.


Ray

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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Ray Bellis]

On 22/08/2022 18:42, Timothy Mcsweeney wrote:



Why would they do that? And why wouldn't they just serve up their
own root from within a subdomain they already have.  Maybe everyone 
should have their own root, I mean isn't that what this .Alt

registry is??


You can't have a "root" label in the middle of a domain-style name,
because the presence of the length == 0 byte for the root label is what
marks the _end_ of the name parsing sequence.

Ray

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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Ray Bellis]

On 22/08/2022 15:05, Paul Hoffman wrote:


I would prefer that they choose whatever is best for their own
non-DNS user community, which might still be ASCII.


Since this came up earlier in the thread(s), I would also strongly 
advise that users of .alt do not stray from the DNS standard of


- 255-octet maximum name length
- 63-octet maximum label length
- separated by period/dots (in presentation format)
- an empty root label.

To do otherwise might cause havoc with nsswitch mechanisms that expect 
to be given "domain-style names".


Ray

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

Re: [DNSOP] [Ext] On ALT-TLD, GNS, and namespaces...

[Ray Bellis]

On 17/08/2022 15:56, Timothy Mcsweeney wrote:


But this part is super-genius "These ".alt" names are defined by
protocol specification to be nonexistent" I had no idea you could
specify non-existance.  I'm going to have to try that!


I believe the intention was that the DNSSEC nsec records in the root
zone would deny that .alt exists, helping to enforce separation from the 
"DNS protocol namespace" and anything under .alt.


Ray

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Ray Bellis]

On 15/08/2022 19:17, Paul Vixie wrote:


of course i meant that each such namespace would get its own
"sub-domain" under .alt (e.g., .GNS.ALT).


Someone also gets to solve the problem of how you get a CA/Browser Forum
Approved TLS cert for any system not accessible via "normal" DNS...

Ray

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Ray Bellis]

On 15/08/2022 18:55, Paul Vixie wrote:



if IETF decides at this late (2022) date to reserve part of the domain 
style namespace for non-udp/53 non-tcp/53 uses, nothing will break. that 
helps me understand the open ended _effective_ intent of STD-13, which 
is to build roads not walls -- in the best tradition of the Internet.




I have no problem with ".alt" being carved out like that, it's the 
potential proliferation of a multitude of such carve-outs that bothers me.


I also suspect that those specs that need it will in pratice be unable 
to co-exist unless each such namespace then gets its own "sub-domain" 
under .alt (e.g. .gns.alt).


Maybe there'll be an opportunity for having "real" domain names that 
effect a namespace switch via a DNAME or CNAME record into .alt? ;)


Ray

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Ray Bellis]

On 13/08/2022 23:56, Paul Vixie wrote:

it's very much worth re-reading RFC 921 and RFC 952 to understand how it 
was that domain-style names (an RFC 952 term, which RFC 921 described as 
"structured names" or "hierarchical names") preceded what we today call 
the "domain name system."


I'm struggling slightly on the logic here, although I was not around at 
the time these documents were written so my perspective may be skewed.


RFC 952 and RFC 921, if I read them correctly, define "structured names" 
(or the synonymous "domain style names") as part of a _transition_ from 
a flat namespace to ("a" | "the") "Domain Name System".


STD 13 then effectively makes udp/53 and tcp/53 the de-facto wire 
protocols for interrogating that system, mostly surplanting the use of 
host files.


On that basis, I'm unable to separate the RFC 921 / 952 "Domain Name 
System" namespace from the STD-13 one embodied in the ICANN-managed root 
zone that we have now.  I think they're the same thing.


cheers,

Ray

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

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Ray Bellis]

On 02/08/2022 14:22, Schanzenbach, Martin wrote:


So, we mostly separated the technical protocol design from the
namespace issue.


No such separation is possible - the DNS is the Domain Name _System_.

That _system_ is the combination of:

- the wire protocol
- the authoritative servers (from the root down) that use the protocol
- the namespace defined in the ICANN-controlled root zone
- all of the recursive and stub resolvers that know how to query it.

Ray

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

Re: [DNSOP] IANA Policy for SVCB

[Ray Bellis]

On 22/03/2022 16:01, Murray S. Kucherawy wrote:

As to the options proposed, I agree that Expert Review can introduce 
delay, but given the above, so too can Specification Required (maybe 
worse, in aggregate).  So I recommend Expert Review.


I am concerned that the set of Expert Reviewers necessary to handle SVCB 
needs to have both expert DNS experience *and* detailed knowledge of the 
SVCB model for this to work.


I am not sure there's anybody who fits that criteria.

Ray [RRTYPE expert reviewer]

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

Re: [DNSOP] [Editorial Errata Reported] RFC8906 (6783)

[Ray Bellis]

On 14/12/2021 08:28, RFC Errata System wrote:

The following errata report has been submitted for RFC8906,
"A Common Operational Problem in DNS Servers: Failure to Communicate".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6783

--
Type: Editorial
Reported by: Mukund Sivaraman 

Section: 8.2.3

Original Text
-
as unknown EDNS options are supposed to be ignored by the
server (Section 6.1.1 of [RFC6891]).


Corrected Text
--
as unknown EDNS options are supposed to be ignored by the
server (Section 6.1.2 of [RFC6891]).


Notes
-
Reference to the section in RFC 6891 is incorrect. There's no information on 
what to do with unknown options in RFC 6891 section 6.1.1.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8906 (draft-ietf-dnsop-no-response-issue-23)
--
Title   : A Common Operational Problem in DNS Servers: Failure to 
Communicate
Publication Date: September 2020
Author(s)   : M. Andrews, R. Bellis
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG


The erratum is correct - the reference should be to 6.1.2, not 6.1.1

kind regards,

Ray

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

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Ray Bellis]

On 02/11/2021 20:00, Roman Danyliw wrote:

> I believe that if this draft is going to be the BCP to discuss DNS
> over TCP, all of the flavors of DNS over TCP need to be covered.

I disagree, strongly.

The properties of DNS over TCP are well understood, and DNS over TLS is
(to a first approximation) a simple TLS wrapper around that.

DoH is something, umm, else.

Ray

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

Re: [DNSOP] NSEC3 Guidance - zone size impact of opt-out

[Ray Bellis]

On 03/09/2021 08:32, Paul Wouters wrote:

> I myself think we have reached the point where memory on nodes is so
> cheap, it is not worth the security degradation to use opt-out.

Generic DIMMs are indeed cheap.

However, supported ones from server vendors such as Dell have a retail
price about 4x the consumer price (e.g. ~ $900 for 32GB).

If your nodes are staffed, by all means drop in cheap generic memory and
be prepared to swap it for the real stuff if you have a hardware issue
that needs warranty repair.  For remote nodes that's not practical.

Ray

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

Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld

[Ray Bellis]

On 30/07/2021 19:29, Paul Wouters wrote:

> We are seeing the WG dropping actual protocol work because of these
> discussions.
If only we had a working group for discussing DNS Extensions...

Ray

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

Re: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

[Ray Bellis]

On 19/04/2021 17:08, Lanlan Pan wrote:
> 
> 
> Ray Bellis mailto:r...@bellis.me.uk>> 于2021年4月16日
> 周五 下午4:19写道：
> 
> Many DNS proxies / ALGs don't inspect the packet contents at all, so a
> stronger generic requirement was not feasible.
> 
> 
> depends on use case ?
> enterprise dns proxies may inspect, but home gateway proxies may not.

Yes, of course, although the latter were the primary target audience for
RFC 5625.

kind regards,

Ray

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

Re: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

[Ray Bellis]

On 16/04/2021 09:18, Ray Bellis wrote:

> Yes, that was pretty much it.
> 
> Many DNS proxies / ALGs don't inspect the packet contents at all, so a
> stronger generic requirement was not feasible.

FWIW, I have formally requested that the authors withdraw the statement
in the paper's conclusion that infers that RFC 5625 is "too complex,
ambiguous or outdated".

They have utterly failed to comprehend that the scope and context of RFC
5625 was DNS Proxy / ALGs in home gateways and that it is not
appropriate to criticize it for not making normative requirements of
*every* DNS stack.  They simply were not in scope.

Ray

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

Re: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

[Ray Bellis]

On 14/04/2021 10:19, Stephane Bortzmeyer wrote:

> Regarding dnsop work, the same report suggests to modify RFC 5625 "DNS
> Proxy Implementation Guidelines" to replace the MAY in section 6.3 by
> a MUST. I think that the reason there is currently a MAY is not
> because RFC 5625 finds invalid compression pointers acceptable but
> simply because some proxies may not perform a full parsing of the RR
> in the sections.

Yes, that was pretty much it.

Many DNS proxies / ALGs don't inspect the packet contents at all, so a
stronger generic requirement was not feasible.

(The suggested SERVFAIL response is wrong, I think.  It should've been
FORMERR)

Ray

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

Re: [DNSOP] Various Thoughts on Catalog Zones (draft-ietf-dnsop-dns-catalog-zones-01)

[Ray Bellis]

On 09/02/2021 10:21, Willem Toorop wrote:


I am intrigued by your suggestion to use CSYNC RR to signal SOA Serial
numbers and to help out in. And indeed, the flags in CSYNC's flags rdata
field appear to have helpful names and meanings with respect to clashing
member zones and member zone transitions. What a good catch! How did we
miss that?


When I had the edit pen on an earlier version of this draft I went to 
some lengths *not* to abuse the semantics of existing RRs that just 
happened to have RDATA that was sorta kinda compatible.


IMNSHO, it's unnecessary, and confusing.  Getting new QTYPEs assigned is 
not hard these days.


Ray

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

Re: [DNSOP] Authoritative servers announcing capabilities

[Ray Bellis]

On 14/09/2020 15:32, libor.peltan wrote:
Let me leave some personal opnion/comments on this AUTHINFO idea, 
although I don't know the background here.


There are multiple kinds of "capabilities" of an authoritative server.

Some of them are properties of the zone, some are properties of the DNS 
server implementation, some are properties of the operational policy. 
For examples: DNS algorithm, EDNS version, network MTU, respectively.


While it seems reasonable to disclose some properties of the zone by an 
extra zone RR (although it would probably require extra query!), the 
properties of DNS server will often vary since implementation diversity 
is a general recommendation.


The initial drafts of what became DNS Stateful Operations (RFC 8490) 
included something akin to a server capabilities exchange / negotiation.


Personally I think EDNS is the wrong place for negotiating server 
properties because unless you're using TCP there's no guarantee that the 
server whose properties you've cached is going to be the one that 
answers the next query you send to that address.


The flip side is that RFC 8490 support is currently rare, and is perhaps 
one of those server capabilities one wants to find out about :p


Ray

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

Re: [DNSOP] Question regarding RFC 8499

[Ray Bellis]

On 24/07/2020 10:28, Martin Hoffmann wrote:

> Side note: Whenever using "upstream" and "downstream", I’ve pretty much
> always first had a half-hour discussion what each means and still later
> ran into issues a la "What was downstream again?"

Upstream is "towards the source".  This works both for rivers, and for
AXFRs.

Ray

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

Re: [DNSOP] Question regarding RFC 8499

[Ray Bellis]

On 23/07/2020 18:44, Tim Wicinski wrote:

> Actually, that does make sense. Though we also have to expect that these
> existing terminology will not be replaced in the lexicon overnight.
> 
> The Chairs plan on having a few slides on this whole topic, as we've
> been thinking about it for some time. 

Could I please throw into the mix a requirement that whatever terms we
come up with are also usable as verbs.

"master" and "slave" are both nouns and verbs.   It's very common to say
"this zone is slaved from " and it's completely gramatically
correct.

I have been trying to avoid those words in my own language recently, but
using "primary" and "secondary" ends up creating some very awkward
language constructs because those are only adjectives and nouns and
there's no such word as "secondaried".

Ray

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

Re: [DNSOP] unsolicited HTTPSSVC responses

[Ray Bellis]

On 27/05/2020 17:40, Eric Orth wrote:

> Maybe a better solution, but considering that the issue I'm dealing with
> is when the stub is unwilling to send additional queries or queries for
> new types out of concerns of middlebox ossificiation (especially from
> older home routers) on additional queries or unknown query types, does
> anybody have any data to show that the multiple qtype EDNS option won't
> cause similar issues?
> 
> But in other cases without as much ossifciation concern, especially when
> using DoH, I'm supportive of any effort to allow querying multiple types
> in the same request.  Would significantly help with some of the security
> concerns in ESNI/HTTPSSVC where an attacker could try to block ESNI by
> identifying and blocking the packets just for the HTTPSSVC records.  If
> A//HTTPSSVC are all in the same request/response, you can't block
> any of it without blocking all of it.  My one concern of that specific
> proposal is that if the client doesn't know that the server will respond
> for the additional queries, it still has to make separate queries for
> all three, leading to lots of redundant responses when the additional
> types are handled.

In traditional DNS, stub resolvers only talk to a limited set of
upstream resolvers, and they could learn (and cache) information about
their behaviours, in the same way that recursive servers do for
authoritative servers.

You only need to launch one "multi QTYPE" query at a server to learn
whether subsequent queries to that server can take advantage of that
feature.

Ray



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

Re: [DNSOP] unsolicited HTTPSSVC responses

[Ray Bellis]

On 27/05/2020 07:33, Petr Špaček wrote:

> I would much rather spent time on 
> https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03
> 
> That would bring benefit to broader set of clients and has advantage
> that server does not send back data nobody asked for (thus wasting
> resources on unnecessary work).

I'd be very happy to revive that work if there's interest.

Ray

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-delegation-only-00.txt

[Ray Bellis]

§8 of the draft says:

> Some TLDs have a requirement for certain Fully Qualified Domain Names
> (FQDN) within their TLD, such as "whois.example" or "nic.example".
> These usually appear as signed data of the TLD and not as a delegated
> child zone.  These names would have to be converted to delegated
> zones before enabling the DELEGATION_ONLY flag

Requiring such records to become delegations may be impossible if the
existing names (that might now become apex records) require a CNAME.

Another non-delegation record also commonly found in TLDs is
_nicname._tcp. SRV.

Ray


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

Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-no-response-issue-20: (with COMMENT)

[Ray Bellis]

On 08/04/2020 15:16, Éric Vyncke via Datatracker wrote:

> 
> Also, if the firewall is "protecting" the DNS server (cough cough), then as a
> security officer I would prefer to block all unknown opcodes/types at the
> firewall (possibly with a reply).
> 

See §4.

"with a reply" is fine, so long as that reply is consistent with what
the real server behind the firewall would have answered (including any
DNSSEC records asserting the non-existence of those types).

Dropping the queries on the floor with no reply is precisely what the
document seeks to prohibit, though.  It can cause an otherwise
functional server to be tagged by clients as non-responsive.

Ray



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

Re: [DNSOP] Last Call: (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice

[Ray Bellis]

On 25/02/2020 14:52, Tim Wicinski wrote:

> Any idea when will we see an updated version?

We're looking at it, but the BIND release schedule and Mark's TZ (he's
11 hours ahead of me) have been working against us.

Ray

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

Re: [DNSOP] Last Call: (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice

[Ray Bellis]

On 13/01/2020 14:48, Warren Kumari wrote:
> On Thu, Dec 19, 2019 at 8:28 PM Warren Kumari  wrote:
>>
>> [ Note: CC list edited ]
>>
>> Hi there authors,
> 
> Any idea when you might get a chance to get to address these comments?
> This is a useful document, and I'd like to see it progress.

Mark is on PTO - hopefully we'll get an update out soon!

Ray

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

Re: [DNSOP] port number in HTTPSSVC

[Ray Bellis]

On 03/01/2020 21:10, Christian Huitema wrote:
> Most of the early tests of QUIC were using port 4433, not 443. Using
> alternate ports for testing is very common.

Not just for testing - many people use alternate ports when port
forwarding to reach services inside a many-to-one NAT.

Ray


pEpkey.asc
Description: application/pgp-keys
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: [Editorial Errata Reported] RFC1035 (5915)

[Ray Bellis]

On 20/12/2019 15:08, Bob Harold wrote:

> But if we are updating it, could we consider a better word than
> "forward" ?  Actually "backward" would be correct, although I prefer
> "from the back to the front" as used elsewhere.

It's not possible to traverse the RRs in a raw DNS packet "backwards".
 You have to start at the beginning and remember the offset of each RR
found.

Ray




pEpkey.asc
Description: application/pgp-keys
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Consensus suggestion for EDE and the TC bit

[Ray Bellis]

On 21/11/2019 15:37, Ben Schwartz wrote:

> I would suggest adding a requirement to the EDE draft that EDE be
> the last option in OPT

And what if some other future option wants to lay claim to that requirement?

> Then as a client, I can easily detect this situation, because the 
> truncation point is in the middle of the EDE option.

A conformant server should never crop a packet in the middle of an RR
when truncating such that the resulting packet is unparsable (implied by
RFC 1035 §6.2)

Also, an EDNS conformant server MUST include an OPT RR in its
response to a query that contained an OPT RR, even when truncating.
(RFC 6891 §6.1.1, §7).

Ray



pEpkey.asc
Description: application/pgp-keys
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On painting the draft-ietf-dnsop-svcb-httpssvc bikeshed

[Ray Bellis]

On 19/11/2019 18:49, Petr Špaček wrote:

> Please keep RR type name as one lexical unit!

There's already one RR type with a hypenated name (NSAP-PTR).

> Constructing the name from multiple tokens ("SVCB" "-" "HTTPS")
> will trigger all sorts of bugs all over the place

I've looked for, but can't find, a formal grammar for the  field
in master file syntax.

That said (and given the existence of NSAP-PTR) if your lexer doesn't
already treat a hyphen as a legal character in a token rather than as a
token in its own right, that's probably already a bug.

Ray



pEpkey.asc
Description: application/pgp-keys
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt

[Ray Bellis]

On 06/11/2019 13:42, Matthew Pounsett wrote:
I still have a few comments.  There were a few comments from my review 
of -13 that weren't responded to in email, and haven't been updated in 
the text, so I'm repeating them here.


Hi Matt,

We sought advice from one of the Chairs as to whether in his reading 
such a significant restructuring of the document was warranted when only 
one participant was calling for it.


We have not yet had a clear steer on that.

kind regards,

Ray

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

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

[Ray Bellis]

On 12/09/2019 19:10, Viktor Dukhovni wrote:


That's the crux of the matter and, in short, *no*, that's not (or should
not be) the motivation.

SERVFAIL means,  and will continue to mean, I can't help you, better luck next
time (or elsewhere).

The new EDEs are *diagnostic* detail to aid in troubleshoots, but do not
override RCODEs.  They are not a more fine-grained RCODE one might "act on".
If we want more fine-grained *actionable* codes, there's plenty of room for
more values in the 12-bit EDNS RCODE.

[ I chatted off-list with Wes, the above appears to match his take, with a bit
   luck also rough WG consensus... ]


The very first two sentences of the draft are (to my reading) at odds 
with that:


"There are many reasons that a DNS query may fail, some of them
 transient, some permanent; some can be resolved by querying another
 server, some are likely best handled by stopping resolution.
 Unfortunately, the error signals that a DNS server can return are
 very limited, and are not very expressive."

Ray


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

Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext

[Ray Bellis]

On 23/08/2019 22:39, Joe Abley wrote:

People have always been able to anchor their non-DNS naming schemes 
to domain names they control in the DNS as a way to avoid collisions,

and nobody has seemed to think that's a good idea. Is it more likely
that someone would anchor their ARTICHOKE alternative naming scheme
under ARTICHOKE.ALT than it was for them to use (say) ARTICHOKE.NZ or
ARTICHOKE.GLOBAL or something? Even within the IETF we struggled
slightly to convince people to use HOME.ARPA instead of HOME, right?


For Homenet it wasn't an alternative naming scheme, it was a "locally 
scoped only" name but still using DNS protocol.


You also wrote:


I think it's clear that nobody has ever shown signs of wanting to
anchor anything like this under .ARPA if it's a name that a user
might ever have to see.


Homenet names are expected to be user visible, but we certainly did 
*not* want them to be under .ARPA.It was unfortunately the only
available option when the various I* bodies declined to attempt to set 
up the necessary processes and liaisons with ICANN.


Ray

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

Re: [DNSOP] responses to dnsop extended errors comments

[Ray Bellis]

On 10/08/2019 06:26, Wes Hardaker wrote:


8.2.2 DONE The biggest issue is of course to find out what to put in the 
extended
-

   error code. On some resolvers (at least on Knot), the place where the
   error is noticed can be quite far from the place where the answer is
   built, with its EDNS options. In practice, we had to add data to the
   request object, for the extended error information to be carried to
   the module that emits the extended error code EDNS option. So, the
   real difficulty is not in the draft, but in knowing and understanding
   your resolver.

   + Response: As agreed to in IETF105, we've removed the RCODE binding.


Consensus calls for WG documents are supposed to be made on the list.

I *like* the RCODE binding.

Ray

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

Re: [DNSOP] Fwd: HTTPSSVC record draft

[Ray Bellis]

On 08/07/2019 22:17, Erik Nygren wrote:


For DNSOP folks, and ANAME proponents in-particular,
I/we are especially interested in understanding if this would address
enough of the customer use-cases driving ANAME were major
browsers to implement support for HTTPSSVC, or would any
limitations here cause problems there?


I'm personally not aware of any specific use-cases for ANAME that aren't 
 "I want to use my CDN's hostname alias but CNAME's rules prevent it".


That's not to say there aren't any, but if there are, I don't know what 
they are.


kind regards,

Ray

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

[DNSOP] Fwd: HTTPSSVC record draft

[Ray Bellis]

For those not paying attention to the HTTP-bis working group, this DNS 
RR was proposed there last week.


It appears to subsume the ALT-SVC proposal and also covers the use case 
I had in mind with my HTTP Record draft (i.e. CNAME at the apex).


Given that it has someone from at least major browser vendor supporting 
it there's some hope that this will actually be implemented by them.  It 
therefore seems my draft is probably no longer required.  Hopefully 
ANAME will follow it the same way ;-)


Ray

 Forwarded Message 
Subject:HTTPSSVC record draft
Resent-Date:Wed, 03 Jul 2019 18:46:25 +
Resent-From:ietf-http...@w3.org
Date:   Wed, 3 Jul 2019 14:45:47 -0400
From:   Erik Nygren 
To: 	ietf-http...@w3.org Group , Mike Bishop 
, Erik Nygren , Benjamin 
Schwartz , Erik Nygren - Work 





Ben, Mike, and I have submitted the first version of a proposal for an 
"HTTPSSVC" DNS record.


TL;DR:  This attempts to address a number of problems (ESNI, QUIC 
bootstrapping, HTTP-to-HTTPS redirection via DNS, SRV-equivalent for 
HTTP, etc) in a holistic manner through a new extensible DNS record, 
rather than in a piecemeal fashion.  It is based on some previous 
proposals such as "Alt-Svc in the DNS" and "Service Bindings" but takes 
into account feedback received in DNSOP and elsewhere.


Feedback is most welcome and we're looking forward to discussing with 
people in Montreal.


Draft link:

https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-01



 From the abstract:

This document specifies an "HTTPSSVC" DNS resource record type to 
facilitate the lookup of information needed to make connections for 
HTTPS URIs.  The HTTPSSVC DNS RR mechanism allows an HTTPS origin 
hostname to be served from multiple network services, each with 
associated parameters (such as transport protocol and keying material 
for encrypting TLS SNI).  It also provides a solution for the inability 
of the DNS to allow a CNAME to be placed at the apex of a domain name.  
Finally, it provides a way to indicate that the origin supports HTTPS 
without having to resort to redirects, allowing clients to remove HTTP 
from the bootstrapping process.


By allowing this information to be bootstrapped in the DNS, it allows 
for clients to learn of alternative services before their first contact 
with the origin.  This arrangement offers potential benefits to both 
performance and privacy.


This proposal is inspired by and based on recent DNS usage proposals 
such as ALTSVC, ANAME, and ESNIKEYS (as well as long standing desires to 
have SRV or a functional equivalent implemented for HTTP).  These 
proposals each provide an important function but are potentially 
incompatible with each other, such as when an origin is load-balanced 
across multiple hosting providers (multi-CDN). Furthermore, these each 
add potential cases for adding additional record lookups in-addition to 
/A lookups.  This design attempts to provide a unified framework 
that encompasses the key functionality of these proposals, as well as 
providing some extensibility for addressing similar future challenges.


--

Some likely FAQs (with some others listed in an appendix):

Q: Why this is HTTP-specific?
A: This is because every protocol has different bootstrap requirements.  
This draft is concerned with improving the efficiency and security of 
bootstrapping HTTPS connections.  This proposal does offer room for 
non-HTTPS protocols, but the nature of DNS requires underscore prefixing 
to support protocol-keyed answers within a single RRTYPE. It's also 
unlikely that a single RR format would be the ideal bootstrap mechanism 
for every protocol, and there's no reason that multiple protocols should 
have to share an RRTYPE.

Q: Why is ESNI addressed directly?
A: This helps make a major motivation of this draft more clear.  
Splitting out those sections to a separate-but-associated "alt-svc 
attribute for ESNI keys" draft might make sense, but keeping it here 
helps work through some of the issues together.


Q: Why does this try to address the HSTS case?
A: This is a unique opportunity to fix HTTPS bootstrap and avoid 
providing insecure defaults.  We'd originally proposed a separate 
Alt-Svc attribute to indicate hsts-style behavior, but then realized 
that it would make sense to push on that as the default here.


Best, Erik

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

Re: [DNSOP] Deprecating the status opcode

[Ray Bellis]

On 16/05/2019 11:23, Petr Špaček wrote:


Personally I think it is not worth the effort, it will just add one more
RFC to read and does not help the protocol maintenance.

I would say that it is better to have one "cleanup" RFC instead of
one-off doc with one useful paragraph in it. With one bigger document we
could say to newcommers "this is list of things you can ignore when you
encounter them in pile of DNS RFCs".


Must as I like simple short documents, I'm inclined to agree.

I recently had an interesting debate with someone about the correct use 
of the flag bits for opcodes other than QUERY.


While some later docs do talk about uses of those bits for e.g. UPDATE, 
there's no place I could find that specifically says that header bits 
are opcode specific and MUST NOT be copied into the response without 
explicit (per-opcode) instruction.


Ray

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

Re: [DNSOP] ANAME high-level benefit question

[Ray Bellis]

On 11/05/2019 15:54, Dave Lawrence wrote:


I have a related question ... is allowing only targets on their own
infrastructure currently a limitation most such providers have?


I don't know about "most", but certainly some.   See e.g. the attached 
message posted here 2018/06/25.


Ray

--- Begin Message ---
On Mon, Jun 25, 2018 at 7:02 AM, Tony Finch  wrote:

> > Even that though requires that the authoritative server be capable of
> > waiting for an asynchronously retrieved value before it can respond.
> >
> > For some authoritative servers that might require a substantial redesign.
>
> That isn't required if the ANAME target records are fetched/updated by an
> out-of-band provisioning process. A server will want to do it this way if
> its query rate is bigger than the number of ANAME targetss divided by
> their TTLs.
>

A challenge with that is that many people now use geographic or latency
based DNS routing based on the resolver IP address or EDNS-client-subnet.
That's one of the reasons why Route53's ALIAS works only for targets that
Route53 is authoritative for.

-- 
Colm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--- End Message ---
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-01.txt

[Ray Bellis]

This update contains a few minor wording changes to try to make the 
applicability clearer.


We've also added Peter van Dijk from PowerDNS as a co-author.

Ray

 Forwarded Message 
Subject: New Version Notification for draft-bellis-dnsop-edns-tags-01.txt
Date: Mon, 25 Mar 2019 07:00:14 -0700
From: internet-dra...@ietf.org
To: Ray Bellis , Peter van Dijk 
, Alan Clegg 



A new version of I-D, draft-bellis-dnsop-edns-tags-01.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:   draft-bellis-dnsop-edns-tags
Revision:   01
Title:  DNS EDNS Tags
Document date:  2019-03-25
Group:  Individual Submission
Pages:  6
URL: 
https://www.ietf.org/internet-drafts/draft-bellis-dnsop-edns-tags-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-bellis-dnsop-edns-tags/

Htmlized:   https://tools.ietf.org/html/draft-bellis-dnsop-edns-tags-01
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-edns-tags
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsop-edns-tags-01


Abstract:
   This document describes EDNS Tags, a mechanism by which DNS clients
   and servers can transmit an opaque data field which has no defined
   semantic meaning other than as previously agreed between the client
   and server.

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Ray Bellis]

On 25/03/2019 16:08, Puneet Sood wrote:


you mean lots of changes or lots of agreement with the quoted text?
They mean very different things.


I was agreeing with the quoted text - I believe that any serving of 
stale records must be predicated on the presence of a valid delegation 
from the parent zone.


Serve stael must not become a vector whereby malware can keep its C&C 
systems artificially alive even if the parent has removed the C&C domain 
name.


Ray

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

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Ray Bellis]

On 25/03/2019 10:41, Patrick McManus wrote:


I've seen this confusion before, so I can clear it up!

Ray is (I believe) referring to the flexible re-ordering of DNS 
request-reply pairs of a TCP channel.. similar to HTTP/2 (though with 
less flexibility in granularity iirc). That addresses hol-blocking 
problems due to the time the server spends building replies.


Ian is (I believe) referring to head of line blocking problems related 
to TCP's in-order delivery semantic and packet loss. TCP packet loss 
will delay the delivery of received packets if there are outstanding 
unreceived lower-numbered packets. If the data in these packets are 
unrelated (e.g. different DNS request/reply pairs) - that causes head of 
line blocking to the application. That's true of http/2 and RFC7766 
(anything tcp based really). QUIC streams provide a mechanism for 
identifying which sequences actually need to have that dependency. DoH 
with H3 would use separate streams for separate requests (as different 
HTTP exchanges are inherently on different streams).


Its a shame that the term hol blocking is used for both scenarios - it 
has caused a lot of confusion.


hth


Yes, that dh :)

I was indeed talking about DNS message re-ordering, and wasn't aware of 
this particular distinction at the TCP layer itself when compared to QUIC.


thanks,

Ray

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

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Ray Bellis]

On 25/03/2019 09:28, Ian Swett wrote:
One way DoH may be faster than DoT in the near future is that DoH can go 
over HTTP/3 via QUIC and avoid head of line blocking like Do53.


Head of line blocking shouldn't happen on a modern Do53 server.

See RFC 7766 §6.2.1.1

Ray

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Ray Bellis]

On 24/03/2019 12:36, Paul Vixie wrote:

in other words, we'd be negotiating for the right to re-interpret 
existing signaling (the authority's TTL no longer purely governs the 
data's lifetime) by insisting that the parent zone's delegating TTL be 
given absolute power for revocation.


+lots

Ray

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

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Ray Bellis]

On 22/03/2019 08:33, Eric Rescorla wrote:

I'm not sure where you have attempted to clarify this point (I think 
we've been clear on this point at

https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/)

Regardless of what the default is, users will be able to disable DoH.


Regardless of that, Firefox is banned from my network until such time as 
I see an unequivocal statement that DoH will not be enabled without 
explicit and informed consent of the user and with their explicit choice 
of DoH resolver.


Ray

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

On 08/03/2019 18:33, 神明達哉 wrote:


For example, assume that an operator uses dnsdist as a DNS load
balancer and BIND 9 as backend servers with RRL, and the operator
wants to trust particular clients (identified by their IP addresses)
and bypass RRL for them.  How can we expect off-the-shelf dnsdist and
off-the-shelf BIND 9 support this operation with the only assumption
being that both of them support edns-tags?  Is there an implicit
assumption that:
- this version of off-the-shelf dnsdist happens to have a new
   configuration option so it will add an edns-tag with setting bit X
   when the client IP address matches a specified set of address list,


Yes, that's feasible (and from dicussions I've had with them I think 
it's not just feasible but extremely likely).



- this version of off-the-shelf BIND 9 happens to have a new
   configuration option to skip RRL if an incoming request contains an
   edns-tag option with bit X on ?


Yes, that is also completely feasible.  I would expect (at some point) 
that BIND would offer the ability to use a tag comparison as part of an 
`address_match_element` that could then be used like so:


  rate-limit {
exempt-clients { ... };
  };


At this moment I don't have a strong opinion on the proposal itself,
but the "off-the-shelf software" argument doesn't sound very
convincing or realistic.  Perhaps I miss some implicit assumptions, in
which case I'd like the draft to explain these in more detail.


The next version has this text:

"The intended mode of operation is that the value of a bit (or range of
bits) could be tested in access control lists or any other such policy
control mechanism."

I'm open to elaborating on this a little more in the draft, but it would 
be a shame for the draft to lose its current succintness.


Ray

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

On 08/03/2019 14:28, Paul Wouters wrote:


But assigned and left completely opague is not really suitable for
"heterogenous off-the-shelf software". These different vendors must
understand the meaning of the opaque data even if their functionality
can be non-standard.


No, it does *not* require that at all.

We very careful referred to the *operators* of the software in the 
draft, not the implementors.


The intention is that software operators can define rules in their 
configuration files such that *they* determine which values have what 
meaning.Just like how a BGP router can use BGP communities within 
routing policy maps.


In the load-balancer case, they might decide to use a few bits to select 
one of several RPZ feeds, or perhaps a view, without having to pass the 
client IP for the use a "source match" ACL to the backend.


They might decide to use another bit to indicate that the client is 
trusted such that the server doesn't need to apply RRL.


Granted this will need some form of representation in whatever 
configuration syntax is in use, but that would be implementation 
dependent.   The minimal implementation would just need to be able to 
test "tag & mask == value".


Ray

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

On 08/03/2019 03:58, Paul Wouters wrote:


If you have a specific use case, get a code point for that specific use
case. Than you know for sure what the blob means and that it will be
interpreted by all parties in the same standard RFC way.


I have some generic use cases in mind (subject to the existing cautions 
about bilateral agreements, consenting adults, etc) and also a very 
specific use case.


I have customers that want to tag a packet received by a DNS 
load-balancer and then on the back-end server use that tag to make 
decisions about the processing of that packet.


They want to do that with heterogenous off-the-shelf software, which 
means that implementations have to agree which code point to use.  This 
strongly suggests requesting an *assigned* code point.


Please also note that the requirements for assignment of an EDNS option 
is "Expert Review".  It does *not* require a Standards Track RFC.


It's therefore none of DNSOP's business what the values of those tags 
are, nor what the resulting packet processing decisions will be.  As far 
as the *protocol* is concerned, they're opaque.


It's not even any of DNSOP's business how large that blob is, but the 
current 16-bit limit is a concession (or some might say appeasement) to 
the perceived privacy concerns.


So while not requiring an RFC to obtain an assignment, the I-D is 
published for feedback on the design aspects of the option and to act as 
the reference specification for it.


Ray

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

On 07/03/2019 16:57, Petr Špaček wrote:


Like this one?
https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/


Have you perhaps got anything constructive to contribute to the 
discussion instead of pure hyperbole?


:p

Ray

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

On 05/03/2019 10:57, I wrote wrote:


(Just as BGP communities only have meaning between peers)


That should've been qualified "usually".

Ray

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

On 05/03/2019 10:54, Dick Franks wrote:


But that is not the case here. Even if the mechanism were to become
standardised and ubiquitous, each instance would be interoperable
only between two specific consenting parties. IMHO this falls into
the "local use" category.


I was talking interoperable with respect to implementations, not the
specific values of the tags chosen between a pair of systems.

(Just as BGP communities only have meaning between peers)

Ray



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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

On 05/03/2019 09:11, Shane Kerr wrote:

I don't see much value in this beyond the already-standardized EDNS 
range reserved for local/experimental use.


Shane,

The additional value is being able to use the feature in off-the-shelf 
DNS software.


Stretching the analogy to BGP communities slightly (the authors had 
already discussed this internally when working on the draft, and Wes has 
made that comparison too):


Folks *could* have decided to use some unassigned BGP Path attribute 
value to carry similar information, but each implementor would have had 
their own special version of it.   Making it _standardised_ is what 
allows support to be ubiquitous (and interoperable).


Ray

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

On 04/03/2019 23:03, Wes Hardaker wrote:


Hmmm..  very interesting idea, but I'm having a hard time seeing how
this will be used in the real world in a scalable and interoperable
way.


The use cases on the open internet are probably less interesting than 
those were client and server have a more tightly coupled relationship.



The problem with a generic mechanism like this for DNS is that the
number of clients per server are potentially gigantic.  And there is
often not a documented relationship or even a known contact mechanism to
signal changes taking place.  This all makes communication of agreed
upon semantics of bits not exactly impossible, but likely between
difficult to extremely difficult.  And misconfiguration could be
potentially be dangerous, depending on the meaning of the bits.  Imagine
if the new bit for some flipped software suddenly switched to "I trust
MD5, go ahead and believe MD5 DS records".


I suggest that I add a sentence or two about applicability, constraining 
it to those where the client has tight coupling (be that topologically 
or contractually) to a particular set of servers.


Ray

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

On 05/03/2019 01:44, Paul Wouters wrote:


This makes me very nervous. An edge ISP DNS server could use this to
mark DNS packets from certain users, and applications could use this as
another cookie to track users, especially in light of endusers talking
directly to open resolvers like the Quads, from within the application,
bypassing the operating system.


This is why the specification limits the data to a mere 16 bits.

Granted that this might permit more fine-grained "finger printing" when 
combined with other meta data but the intention is that _by itself_ it's 
insufficient to carry any PII (at least not unless your total number of 
clients is < 2^16).



Great. And once experimenting is done, submit a draft and get a real
EDNS code point. Do this as many times as you want. The idea of a
limited experimental space is that you cannot rely on it to be rolled
out into the wild word. That's a feature. 


It's not a feature, it's a bug.  These internal experiments almost never 
see the light of day, and as a result are unsupportable in e.g. BIND, 
instead relying on internal patches (which are fragile) or bespoke 
implementations (that are often protocol non-conformant).


Meanwhile we have customers who would like to deploy some kind of packet 
tagging but find that the only "blessed" option that kinda fits their 
needs is EDNS Client Subnet.   No thanks!


Ray

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

On 04/03/2019 18:06, Ted Lemon wrote:


Any reason not to use DNS Stateful Operations for this?


I expect there's plenty of reasons to define a DSO equivalent, but I can 
think of no reason to -constrain- this for use only with DSO.


Ray

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

[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

DNSOP,

This new draft describes a way for clients and servers to exchange a 
limited amount of information where the semantics of that information 
are completely unspecified, and therefore determined by bi-lateral 
agreement between the client and server operators.


There are known cases where bespoke implementations are using 
experimental EDNS option values for this purpose, for example for a 
front-end load-balancer to tell the server whether an incoming 
connection arrived over TCP or UDP (c.f. my XPF draft).


A goal of this draft is to assign a common EDNS code-point such that 
popular OSS implementations can support similar features interoperably.


Ray

 Forwarded Message 
Subject: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Date: Mon, 04 Mar 2019 08:14:24 -0800
From: internet-dra...@ietf.org
To: Ray Bellis , Alan Clegg 


A new version of I-D, draft-bellis-dnsop-edns-tags-00.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:   draft-bellis-dnsop-edns-tags
Revision:   00
Title:  DNS EDNS Tags
Document date:  2019-03-04
Group:  Individual Submission
Pages:  6
URL: 
https://www.ietf.org/internet-drafts/draft-bellis-dnsop-edns-tags-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-bellis-dnsop-edns-tags/

Htmlized:   https://tools.ietf.org/html/draft-bellis-dnsop-edns-tags-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-edns-tags



Abstract:
   This document describes EDNS Tags, a mechanism by which DNS clients
   and servers can transmit an opaque data field which has no defined
   semantic meaning other than as previously agreed between the client
   and server.

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

Re: [DNSOP] Review of draft-ietf-dnsop-rfc2845bis-02.txt

[Ray Bellis]

On 19/11/2018 13:45, Mukund Sivaraman wrote:


Soon after this TSIG authentication bypass attack was reported, during a
review of the BIND TSIG implementation by Ray Bellis and me, we found a
couple of other issues. One of them is not a real-world issue (to do
with under-specification of what to do with full MAC length having
non-integral number of octets - there are no such common HMACs
currently), and another that I'm not able to remember that had to do
with an off-by-1 (or something similar) on the fudge and time signed
fields. Do you have any recollection of it Ray?


I vaguely recall the discussion but not the detail of it.

ISTR it was something to do with using a <= comparison rather than <, or 
vice versa.


Ray

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

Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

[Ray Bellis]

On 09/11/2018 09:30, Paul Vixie wrote:

i regret not adding ANY as an RR type (not just a Q type) back when 
the DNS was small and i supported 90% of it. what we actually needed

 is a wildcard on types so that if there's no more-specific type you
 get that one, which would have an rdata of the target name, but act
 like PTR (which the DNS requester has to follow) rather than like 
CNAME (which the recursive has to follow.)


interesting... :)


i am loath to create per-service record types. that's why SRV. if you
really want every client of a service to query for something other
than /A, can you try to fix what's wrong with SRV regarding
wildcards, but avoid a new type code for every new thing like MX and
HTTP as they come along in the decades to follow?


Creating per-service record types is the IAB's preferred option (per RFC
5507).

Is fixing wildcards for SRV even possible without a major forklift 
upgrade to the DNS?


also, does SSH count as a service? what about FTP? Gopher? RSync? 
NNTP? IMAP(S)?


My line of thinking is that in this context a service is "a domain-wide
facility that's exposed to third parties where it is strongly preferred
that the third party use the bare domain name directly because that
domain name is used in end-user identities or to identify the endpoint".

For me, that would include:   SMTP, HTTP(s), SIP, XMPP

So, with respect to your list:

SSH - no, it's for managing a specific host

FTP - maybe, but is still well served by the "ftp." convention

Gopher - yes, if it still has any use?

Rsync - maybe - it's most often used for host-to-host transfers,
 but arguably a domain could offer file dist via rsync::,
 although again the "rsync." prefix would usually suffice.

NNTP - probably not, end users see the hostname in their config
 but "news." etc is fine.

IMAP - I believe there's already mechanisms for discovering IMAP
 servers via SRV, although AIUI it's usually a one-off
 configuration-time search, not per-session.

it may not be too late to think architectural thoughts like "what 
will the internet engineering community think, 50 years from now, 
that we should have done for them?"


I hope that's what I'm trying to do.  It would be real bad if some
alternative to "the web" comes along in 10 years time but we can't
differentiate it in the DNS because too many A and  records are
assumed (absent a service identifier) to be dedicated to "the web".

i don't think you mean "actual". anycasted addresses act like host 
addresses in all ways (answering UDP, answering TCP SYN, answering 
ICMP) but are not "actual" hosts. i think i know what you _mean_ here

and if so i agree with that. but 1.1.1.1 answers both HTTPS and DNS,
and would surely get an  and A in your model, but is not a 
"host", and its DNS owner would not be a "hostname". perhaps you mean

"effective host" which could be real or virtual?


Yes, indeed, that is a more accurate definition.

regards,

Ray

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

Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

[Ray Bellis]

On 09/11/2018 07:14, Tony Finch wrote:

But remember: the goal is to make the DNS easier to use for people
who don’t know about the restrictions on CNAMEs.


I'd say the goal is to make the DNS *possible* to use for people who
don't know about the restrictions on CNAMEs.

I concede that ANAME perhaps makes that easier than HTTP does, but it 
does so at the expense of significant complexity in authority servers by 
still requiring A and  lookups to be somehow "magic", and doesn't 
fix the architectural problem of lack of a service identifier.


My long-term goal would be to never have an A or  record appear in 
the DNS other than at the owner name of an actual hostname.


Ray

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

Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

[Ray Bellis]

On 08/11/2018 11:47, Dan York wrote:


For that reason, wouldn't all the resolvers (or at least an extremely high %) 
need to be upgraded to support the new record?


They don't _have_ to be, but performance is improved when they are 
(since only an upgraded resolver will include the A and  answers in 
the additional section).


The critical path is the browsers, since none of this works unless they
start looking up the HTTP record.

As a transition mechanism, site operators would still need to publish 
their existing A and  records by whatever means they currently do 
(even if that's e.g. a CNAME flattening on the authority server).


Ray

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

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

[Ray Bellis]

On 08/11/2018 04:13, Tim Wicinski wrote:


I can't stress this enough - when you see ALIAS records at zone cuts
 that point to a database server, already, then we've missed the
"server specific" ball.


This sounds like it ought to be a very unusual configuration.

Even with a zone cut, couldn't those DB servers have been addressed as 
'db.' instead?



And can someone show a significant number of SRV examples outside of
SIP and some gaming servers?


Kerberos and AD both use SRV records.  Bonjour uses SRV extensively.

Either way, SRV is only one of three different ways that services are 
differentiated (per 5507).


Ray



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

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

[Ray Bellis]

p.s. anyone thinking a new _generic_ resource record is required, please 
(re)read RFC 5507.


HTTP started off with a service identifying prefix, but it was merely by 
convention, and it was "www."


This whole mess started because folks wanted to get rid of that service 
identifier, but a) didn't recognise it as being one, and b) therefore 
didn't consider what would replace it.


Ray

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

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

[Ray Bellis]

On 07/11/2018 00:28, Tony Finch wrote:


   * General purpose (also works for ssh, databases, etc) vs HTTP-specific


I just wanted to address this particular point, again.

IMHO, any record that doesn't support a service selector isn't doing its 
job properly.


You _have_ to be able to say "if I want this service at this domain, I 
either prepend this prefix, or lookup this type", otherwise you're just 
forcing _all_ services to connect to the A and  found there.


A and  should be for connecting to the right _host_, once you've 
established from the _service_ which host that is.


Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 06/11/2018 20:51, Joe Abley wrote:


Ray has wider aspirations than just the apex. This may well be
sensible, but I think it's worth calling out the scope creep.


It's in the intro text:

"This document specifies an "HTTP" resource record type for the DNS to
 facilitate the lookup of the server hostname of HTTP(s) URIs.  It is
 intended to replace the use of CNAME records for this purpose, and in
 the process provides a solution for the inability of the DNS to allow a
 CNAME to be placed at the apex of a domain name"

Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 06/11/2018 20:44, Tony Finch wrote:


My understanding is that wildcards don't work for SRV because the
_prefixes are used to disambiguate which service you are asking for,
effectively to extend the RR TYPE number space. So if you wildcard a SRV
record then the target port has to support every possible protocol :-)


No, it's because you can't do:

_http._tcp.*.example.com IN SRV ...


If you are using an _prefix without any meaning of its own but only to
move a record away from the apex (so that it can be delegated or CNAMEd)
and also using a specific RR type or an RDATA prefix, then wildcards do
not conflict.


I believe they still do, e.g.

_domainkey.*.example.com IN TXT ...

Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 06/11/2018 20:58, Patrik Fältström wrote:


We should also remember that there is a different goal as well, and
that is to be able to delegate the zone within which "the records
dealing with web" is managed so that the administrative
responsibility is separated between the one which run the zone for
example.com and the ones that run for _http._tcp.example.com (or
_tcp.example.com).


That's an implicit non-goal of my draft.  I may have to make it more 
explicit.


You can have wildcard support, or you can have prefixes (hence
delegation), but you can't have both.

Ray

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

Re: [DNSOP] Minimum viable ANAME

[Ray Bellis]

On 06/11/2018 17:58, Matthijs Mekking wrote:

That's the crux: A solution that depends on upgrading the resolvers is 
considered not a (fast enough) deployable solution.


The HTTP record does not depend on resolvers being upgraded.   If the 
browser vendors implement the client side, it's not required.


Once they do fully implement it by serving the A and  records from 
cache, then it'll be fast, too.


That's why I like ANAME: It allows you to do CNAME-at-the-APEX 
processing without requiring resolvers to be updated, however resolvers 
can implement ANAME to optimize the behavior.


Also the ANAME in its current form does not require (but also does not 
prevent) the resolution to take place inside the name server, it can be 
a simple script that is part of your zone provisioning.


I think Tony Finch was suggesting that you could also do that with "HTTP".

Ray

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

Re: [DNSOP] Minimum viable ANAME

[Ray Bellis]

On 06/11/2018 17:17, Tim Wicinski wrote:


In doing some digging through my data, I have instances which I have an 
apex of a zone, sub zone, etc that are not HTTP but actually a dynamic 
database endpoint.


I also have solid number of instances where the apex is used mainly as 
an API endpoint, that serves not HTTP web content.


I think you're expressing a similar concern to those that Wes expressed 
at the mic.


However, if there was also an HTTP endpoint on that domain apex, how 
would you distinguish it from the non-HTTP one?   Clients don't connect 
to "hosts", they connect to "services" on those hosts.


Recalling Mark's message from last night which indirectly referenced RFC 
5507:



People ... want a pointer to a server for a service at the apex.
CNAME provided a pointer to a server when the prefix was www. 


This can be done a number of ways.

1) Prefix  + name in rdata.
2) Service specific type + name in rdata > 3) Generic type + service and name 
in rdata.


#1 is what SRV does, but HTTP has issues with that
#2 is what my proposed HTTP record does
#3 is what SPF etc uses - TXT records with a prefix in the RDATA

These methods are not mutually exclusive - a prefixed SRV record can 
co-exist with an SPF TXT record and an HTTP (or other record) all at the 
same point in the DNS.


Turning my proposal into a supposedly "future proof" RR type as was 
suggested yesterday that covers non-HTTP "future services" won't work 
unless it uses a service prefix (#1) or something else in the RDATA 
(subtyping, #3) to identify the service.


Ray

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

Re: [DNSOP] Minimum viable ANAME

[Ray Bellis]

On 06/11/2018 16:15, Matthijs Mekking wrote:
As nice and clean the HTTP record draft is, without specifying how to do 
expansion of the record into address records it is not going to solve 
the CNAME-at-the-apex problem that DNS providers have, and we will stick 
with the proprietary solutions (this may solve a different use case 
though).


They're supposed to be expanded either in the client, or in the 
recursive resolver, as described in the draft.


If we're misunderstanding each other, please let me know!

Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 06/11/2018 04:07, Joe Abley wrote:


Specifically, I s the wildcard owner name a real problem in the grand
scheme of things? I understand that wildcards are used by some people
for names that feature in HTTP URIs, but I'm struggling to imagine
using a wildcard at a zone cut; [...]


You're not wrong, because most often the wildcard is indeed a label 
below that cut.


However, the intent is that this record would eventually replace *all* 
use of CNAME for web redirection regardless of whether at the zone cut 
or not.


This isn't a wildcard example, but here's a re-post of a currently 
impossible zone configuration from one of my emails Sunday:


$ORIGIN example.com
@IN SOA   ...
 IN NS...
company-division IN MX
company-division IN CNAME 

Replacing that CNAME with HTTP makes this configuration possible.


To be clear, the rules are clear and you should feel as empowered as
anybody to apply for an early assignment of an RRTYPE and start
writing code. If I sounded like I was arguing against that I
definitely apologise!


No worries! :)


However I think that a more coordinated approach that involves people
from both web and DNS communities to understand the problem space is
more sensible, though, and more likely to be productive for this
working group. It's not clear to me that either community has a great
track record just guessing at what the other one wants.


I've been actively socialising this with web people since Saturday even 
before the draft was submitted.  I'm going to be talking about it 
briefly at HTTP-bis this morning.


This draft is IMHO not so much a "guess", but a "starting point" based 
on what web folks said at the side meeting in Montreal.


Yes, it'll require browser implementors to update their code, but the 
alternative is breaking the camel's back.


cheers,

Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 06/11/2018 00:36, Paul Vixie wrote:

second reply, on a more general topic:

the "HTTP URI" will require a change to bert's teaching resolver (tres), 
which correctly handles unrecognized code points and thus would need no 
changes at all if the additional data weren't mandatory. i think in 
modern terminology, if your proposed addition to the DNS protocol 
requires a change to "tres", it's (a) not "cheap", and (b) part of "the 
camel". we are adding state, logic, and signal. (ouch.)


The additional data is not mandatory.

more broadly: most ideas are bad, including mine, and especially when 
DNS is the subject area. self-deception about how cheap they will be 
looks wretched on us. let's not be that. if a change is to be made, let 
it be because there is _no_ existing way within the standard to 
accomplish some vital task. SRV's lack of wildcard support is adequate 
cause. two RTT's on a cache miss is not. apparent cheapness is not.


Ack, except on that very last point (see previous message) where I think 
we need to consider the relative cost-benefit-analysis of the alternatives.


Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 06/11/2018 00:32, Paul Vixie wrote:

please don't think this way, and don't do the right thing for the wrong 
reasons. the paragraph above is how the camel came to be -- one draft at 
a time, all well-meaning.


The front running alternative (ANAME) shifts the entire and far more 
considerable complexity entirely into the DNS, and affects both 
authoritative and recursive servers.  Even then, I don't think it'll 
work properly with geo-locating CDNs nor with DNSSEC.


ANAME is less complex for the browsers (zero cost, even), but it's close 
to another whole hump's worth of complexity for The Camel.


I accept that the cost of the HTTP RR is not zero, but if it does 
succeed, that cost will be far far lower than any of the alternatives.


cheers,

Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 05/11/2018 18:55, Joe Abley wrote:

2. Find a client-side solution to this, and try really hard not to 
invent something new that is really just SRV with a hat and a false 
moustache.


There *is* a big failing of SRV that's independent of the CNAME apex use 
case, and that is its lack of support for wildcards.  Since my proposal 
doesn't use underscore prefix labels, wildcards will work, and this is 
an important requirement for some large website operators.


The cost to the DNS community of *trying* my proposed HTTP record is 
pretty negligible.  Worst case, as Brian put it, is we burn a code 
point, add a trivial amount of code to DNS servers, but the browsers 
don't adopt it.  It wouldn't be the first time, it won't be the last.


However, it only takes one of the big browser vendors to decide they'll 
support it and I think the rest will shortly thereafter follow suit.


NB: this proposal currently satisfies the criteria for assignment via
expert review per RFC 6895.

Ray

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

Re: [DNSOP] Minimum viable ANAME

[Ray Bellis]

On 05/11/2018 12:51, Brian Dickson wrote:

It's a lot better than ANAME, and I think we do a disservice to 
ourselves as a DNS community, if we do anything other than put our 
collective support into it, preferably unanimously.


Thank for you the support!

I see getting http adopted and deployed, and fixing the single major 
web-specific deficiency in DNS, as critical to attempting to head off 
DoH, which is the biggest bugbear at the moment.


But please, let's not get into that argument.  The only way to stave off 
adding complexity in the DNS to fix the CNAME at apex problem is with 
the cooperation of the browser vendors (and as Tim notes, the major 
authoritative operators).  We need their help, just like they need ours.


Ray

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

[Ray Bellis]

On 05/11/2018 09:56, Dave Crocker wrote:


Clever suggestion.  Seems like obvious benefit with no obvious detriment.

So I immediately went to add it and then realized that doing this 
cleanly will take an entry for each RR...


Why not this?

++--++
| RR Type| _NODE NAME   | REFERENCE  |
++--++
| *  | _example | [TBD]  |

Ray


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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 04/11/2018 23:02, Paul Ebersman wrote:


Have you confirmed with the large CDNs doing geo-ip, load-balancing, etc
that this is what they want, since they are largely driving all of this?

I'd guess that they would prefer this in the auth layer, where they own
or have contractual relationship with the zone owner.

Yes, as DNS software folks, we'd like to keep auth doing auth and have
only recursive doing lookups but I'm not sure that solves the problem in
a way that will be accepted.


My expectation is that this would work for them exactly the way a CNAME 
does (i.e. via EDNS Client Subnet or similar) but without the restrictions.


Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 04/11/2018 18:16, Brian Dickson wrote:


Is the apex thing an optimization only (i.e. is it acceptable that
the mechanism for apex detection not be 100% effective)? I think
that's the input needed before it makes sense to go down any
particular branch of design work, by either the http folks or the dns
folks.


It's not a question of apex *detection*, it's that DNS simply doesn't
allow for the *provisioning* of a CNAME record at the apex.

Nor can you put a CNAME alongside any other "useful" DNS records, so you 
can't, for example, have a zone that looks like this:


$ORIGIN example.com
@IN SOA   ...
 IN NS...
company-division IN MX
company-division IN CNAME 

[I should perhaps put that as an example in the draft]


Is knowing when something is (or is at least expected to be) the
apex, one of the fundamental drivers on this issue?


No, the mechanism is general purpose and could be used for any
domain name that requires redirection (at the DNS / hostname level) to a
hostname that does not match the domain name in the URI.

[snipping irrelvant stuff about effective TLD lists]


Related, follow-on question: If that new record type were pointing to
the owner name (i.e. itself), or otherwise signaled that an A/ at
the owner name should be used, would having the authority server
return the A/ records as well fix the multiple-lookups issue,
i.e. not require the lookup of the A/ records if the new record
type was not present?


Although it's not documented as such yet (and I should, because it's an
important clarifaction) an HTTP record that points to itself would be an
error, in the same way that a CNAME loop would be.

Architecturally, the important part of my proposal is that resolution of
the A and  records is done *at the recursive layer* of the DNS, with
no interference with how authoritative resolution works.

[the only exception is if EDNS Client Subnet is in use, but that's a
case where the authoritatives already know how to generate the right
answer for any particular subnet]


[snippage]



I anticipate both the new record type and additional processing,
would be less problematic on authority operators than ANAME.


The new record type has *no* implications at all for authority operators
other than in their provision systems, and since it uses the same RDATA
format as a PTR or CNAME record the implications there should be minimal.

It adds more additional processing, but does not change the general 
model of mostly-static zone data, which plays nice with DNSSEC.


There's *no* additional processing done in authoritatives.  I suppose
theoretically if the target happens to be on the same server as the
owner name than an authority might also include the A and  records,
but it's not specified that way at the moment.
For the recursives, the incremental change is the same additional 
processing as authority servers (additional data if empty/self-ref, 
possibly with extra queries, or CNAME-type processing.)


Roughly, except per above, this is the *only* incremental change in the
DNS infrastructure.   The other necessary change is in the HTTP clients
themselves, which IMHO is how it should be.


Also: would this new record type (and query/response logic) make
sense to use everywhere, not just at a zone apex?


Yes, per above.


I think there would be nothing implicitly difficult in making it
universal, on both the authority and recursive servers. For the
recursive servers, I don't think they even have the ability to
distinguish whether a name is apex or not (!!). For authorities, I
don't think there's anything intrinsically apex-ish about what is
required, so it would probably be less work to support the new record
type anywhere.


It's not apex specific at all, but its design is specifically intended 
to address the CNAME at the apex issue.


kind regards,

Ray


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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 04/11/2018 18:31, Patrik Fältström wrote:


The semantics is exactly like a CNAME + HTTP Redirect.


The latter part is what I expected, and why I think it's a non-starter.

HTTP Redirects cause the URI in the address bar to be changed.  A lot of 
the whole "CNAME at the Apex" issue arises because lots of marketing 
people don't want end users to have to type *or see* the www prefix.


Those folks aren't going to stand for their nice clean "example.com" URL 
getting replaced with the real CDN address in the address bar.


Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 04/11/2018 15:05, Paul Vixie wrote:


as evidenced by RFC 8484, the web community seems to regret basing
their work on the Internet System, and is now moving independently.
this may mean that offering them something like "HTTP RR" which can't
work better than SRV or URI already works, because they speciously
refuse to embrace these working technologies, will buy you nothing.


Members of both communities had what I felt was a very productive side
meeting during the Montreal IETF, at which I also believe there was an
acceptance that both "sides" need to come together for a mutually
agreeable solution.

I don't think that either SRV or URI are usable for the primary use
case, i.e. allowing a domain owner to put a record at the apex of
their zone that points at the hostname of the web provider they want to
use.   I personally don't think that ANAME is a good solution either.

Hence my draft which I hope is a move towards that middle ground that we
can all work with.  I have already had positive feedback from some HTTP 
people, but antagonising them won't help.


Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 04/11/2018 12:53, Patrik Fältström wrote:

On 3 Nov 2018, at 23:32, Måns Nilsson wrote:


_http._tcp.example.org. IN URI  10 20   
"https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/";

We already have this. We need not build a new mechanism.


+1


-1

What are the semantics of this?

- What appears in the user's UI when the URI record completely replaces 
the site name entered by the user?


- Which domain name is the SSL cert validated against?

- Which domain name appears in the HTTP Host: header?

- What is the HTTP "Origin" of the resultint content,
  and which domain's cookies are accepted / sent?

- What if there's also a URI record for 
'example-lb-frontend.hosting.namn.se' ?


- How do I provision a wildcard record for this?

I see absolutely zero chance of the web community embracing this.

Ray

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

Re: [DNSOP] Minimum viable ANAME

[Ray Bellis]

On 04/11/2018 08:05, Ray Bellis wrote:

AFAIK, BIND does not currently do this.  That said, MarkA has a patch 
that supports it, so we do know it's possible.


Correction - BIND *does* do this, but only for address records that are 
already in the cache.   If the  for the target is in the cache, but 
the A record isn't, that's all you'll get.


Mark's patch forces BIND to pre-fill the cache with the A and  
records for the SRV target before replying.


Ray

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