[{"author": "Anders K\u00f6lligan", "text": "

Especially the remote participants.

", "time": "2025-07-21T07:30:42Z"}, {"author": "Anders K\u00f6lligan", "text": "

.. need to look serious.

", "time": "2025-07-21T07:31:11Z"}, {"author": "\u00c9ric Vyncke", "text": "

Is there a note taker ? mainly for Q&A and action items

", "time": "2025-07-21T07:34:03Z"}, {"author": "Brian Haberman", "text": "

Tommy is taking notes

", "time": "2025-07-21T07:34:18Z"}, {"author": "\u00c9ric Vyncke", "text": "

Thank you Tommy ;-)

", "time": "2025-07-21T07:34:26Z"}, {"author": "Tommy Jensen", "text": "

But I'll never turn down assistance!

", "time": "2025-07-21T07:34:32Z"}, {"author": "Warren Kumari", "text": "

I'll point out that we could avoid all of the downgrade concerns by just having a flag day, deprecating legacy DNS and moving to deleg... :-p

", "time": "2025-07-21T07:39:32Z"}, {"author": "Andrew Campling", "text": "

Make the DNS Great Again?

", "time": "2025-07-21T07:40:15Z"}, {"author": "Peter van Dijk", "text": "

DEprecating LEGacy

", "time": "2025-07-21T07:40:28Z"}, {"author": "Warren Kumari", "text": "

Ok soon, too soon...

", "time": "2025-07-21T07:40:41Z"}, {"author": "Warren Kumari", "text": "

Indeed!

", "time": "2025-07-21T07:40:46Z"}, {"author": "Brian Haberman", "text": "

Will that comment make Warren flex??

", "time": "2025-07-21T07:43:51Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Yes Paul! Now I can see why bunch of people got confused.

", "time": "2025-07-21T07:46:05Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Another argument in favor is: Adding a name which does not mean anything/has different semantics than ordinary DNS name is confusing.

", "time": "2025-07-21T07:49:24Z"}, {"author": "Michael Richardson", "text": "

Everyone sing: Been to a Web Site via a DELEG with no Name.

", "time": "2025-07-21T07:49:29Z"}, {"author": "Warren Kumari", "text": "

\"I've been through the DNS on a nameserver with no name...\"

", "time": "2025-07-21T07:49:33Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Heh right, you can always go for 192-0-2-1.ns.example. DELEG ip4=192.0.2.1, LOL.

", "time": "2025-07-21T07:50:17Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

I mean, DELEG 192-0-2-1.ns.example. ip4=192.0.2.1

", "time": "2025-07-21T07:50:42Z"}, {"author": "Shane Kerr", "text": "

If we only need to do critical things that are absolutely needed then we should shut the working group down and go home!

", "time": "2025-07-21T07:54:16Z"}, {"author": "Benjamin Schwartz", "text": "

Note that this business of \"what if the NS name doesn't actually exist?\" is not new with DELEG. It's exactly the same as today.

", "time": "2025-07-21T07:54:31Z"}, {"author": "Erik Nygren", "text": "

nit: it probably makes sense to call the attributes ipv4= and ipv6= rather than ip4/ip6 for consistency with the existing ipv4hint and ipv6hint svcparams.

", "time": "2025-07-21T07:56:11Z"}, {"author": "Paul Hoffman", "text": "

+1 to Erik on naming

", "time": "2025-07-21T07:56:37Z"}, {"author": "St\u00e9phane Bortzmeyer", "text": "

@Michael Richardson Which music theme?

", "time": "2025-07-21T07:57:34Z"}, {"author": "Martin Pels", "text": "

Regarding attributes, it would perhaps be helpful to call the key \"nshint\" for cases where the name is not required (and will not be used by the resolver)

", "time": "2025-07-21T07:57:38Z"}, {"author": "Shane Kerr", "text": "

Was Joe arguing that we should only have IP addresses or that we should only work exactly like NS do today (no addresses unless it is needed for glue)? :stuck_out_tongue_closed_eyes:

", "time": "2025-07-21T07:59:22Z"}, {"author": "Jim Reid", "text": "

... and deprecate DNSSEC too Warren? :-)

", "time": "2025-07-21T07:59:23Z"}, {"author": "Erik Nygren", "text": "

for that \"not required\" case there's no reason not use the existing ipv4hint/ipv6hint if they have the same semantics. Agreed that for the case where this is nameless that dropping out the \"hint\" from them and having them be separate SvcParams since the semantics are different

", "time": "2025-07-21T08:00:04Z"}, {"author": "Michael Richardson", "text": "

St\u00e9phane Bortzmeyer said:

\n
\n

@Michael Richardson Which music theme?

\n
\n

Been Through the Desert on a Horse with No Name.

", "time": "2025-07-21T08:00:58Z"}, {"author": "Tommy Jensen", "text": "
\n

there's no reason not use the existing ipv4hint/ipv6hint

\n
\n

Noting RFC 9460 (or 9461?) says you really shouldn't depend on these fields, so this needs specified

", "time": "2025-07-21T08:01:18Z"}, {"author": "Shane Kerr", "text": "

Yeah I thought ipv4hint/ipv6hint were basically worthless? :thinking:

", "time": "2025-07-21T08:01:50Z"}, {"author": "Philip Homburg", "text": "

For fake names, if you have multiple addresses what would the fake name be, something that includes all addresses?

", "time": "2025-07-21T08:01:51Z"}, {"author": "John Levine", "text": "

We already have the problem that glue might disagree with in-zone names, fake names just reiterate it.

", "time": "2025-07-21T08:02:10Z"}, {"author": "John Levine", "text": "

so if we want fake names, put them in a reserved name like gl--192-0-2-1.ns.example

", "time": "2025-07-21T08:02:39Z"}, {"author": "Erik Nygren", "text": "

oh, sorry, I misread Martin's comment above (as \"when address isn't required\" vs \"when name isn't required\"). So agreed.

", "time": "2025-07-21T08:02:52Z"}, {"author": "Erik Nygren", "text": "

For fake names, it will be important to support dual-stack names which we should be planning to be the norm/default.

", "time": "2025-07-21T08:04:18Z"}, {"author": "Benjamin Schwartz", "text": "

@Petr \u0160pa\u010dek To be clear, you're suggesting that we remove support for names in DIRECT?

", "time": "2025-07-21T08:04:37Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Guys, don't overthink if. If you want fake can you also sort IP addresses and then hash it :trollface:

", "time": "2025-07-21T08:05:02Z"}, {"author": "Ray Bellis", "text": "

IIRC, NOTIMP is intended for use with invalid opcodes, not rrtypes.

", "time": "2025-07-21T08:06:14Z"}, {"author": "Shane Kerr", "text": "

\" 4 Not Implemented - The name server does
\n not support the requested kind of query.\"

\n

Seems vague enough!

", "time": "2025-07-21T08:07:12Z"}, {"author": "Shane Kerr", "text": "

But I have no strong feelings one way or the othre.

", "time": "2025-07-21T08:07:31Z"}, {"author": "John Levine", "text": "

@Erik Nygren if the fake names for the V4 and V6 addresses are different, would that be bad?

", "time": "2025-07-21T08:08:18Z"}, {"author": "St\u00e9phane Bortzmeyer", "text": "

@Michael Richardson Thanks

", "time": "2025-07-21T08:08:54Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

@Philip I think you misunderstood. I'm saying we can also point to anything else than SVCB for INCLUDE mode.

", "time": "2025-07-21T08:09:07Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Say new type, 'DELEGINCLUDE' to make a name up on spot.

", "time": "2025-07-21T08:09:27Z"}, {"author": "David Lawrence", "text": "

As someone who has previously been vociferous about losing my nxdomains thanks to dnssec lies, I'm not crazy about nxdomain here either and would definitely prefer a better signal to legacy resolvers. I'll continue to argue against servfail though

", "time": "2025-07-21T08:09:58Z"}, {"author": "Philip Homburg", "text": "

Okay, that's fine. Then we need a maybe more protocol spec for this. I'm not against DELEGINCLUDE but that would open the floor to more redesign.

", "time": "2025-07-21T08:10:56Z"}, {"author": "Shane Kerr", "text": "

I know it doesn't help, but presumably there would be an EDE thingy assigned for this error too.

", "time": "2025-07-21T08:11:06Z"}, {"author": "Warren Kumari", "text": "

@ben: Yes, exactly what I was hoping to say :-) thanks for being
\nmore clear than me...

", "time": "2025-07-21T08:11:10Z"}, {"author": "Philip Homburg", "text": "

Maybe we need a draft for DELEGINCLUDE where there are no names at all.

", "time": "2025-07-21T08:11:41Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

I'm just saying we MUST define semantics first, and then we create records which can represent it.

", "time": "2025-07-21T08:12:04Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Doing it backwards (going from records to semantics) might force bad decisions.

", "time": "2025-07-21T08:12:26Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Essentially what Paul is saying.

", "time": "2025-07-21T08:12:33Z"}, {"author": "Erik Nygren", "text": "

@John: You'd need to expand from the one record to two names then (so potentially from one record to two records). While it is just expanding rrsets, it's also introducing a new way of doing things which could have more breakage, especially if the RRsets are already large and are getting doubles. It is far more common to have dual-stacked names pointed to by NS records than to have a name per address family.

", "time": "2025-07-21T08:13:53Z"}, {"author": "Shane Kerr", "text": "

Did Paul just propose a new format? I was just hearing Michael Richardson talk about how much he loves YAML this morning... :smiling_devil:

", "time": "2025-07-21T08:14:16Z"}, {"author": "Warren Kumari", "text": "

Yah, what John said. To me, and I suspect most users, this removes the potential to get confused by, and screw up, glue...

", "time": "2025-07-21T08:14:53Z"}, {"author": "David Lawrence", "text": "
\n

'DELEGINCLUDE' to make a name up on spot

\n
\n

Separately, I'm wondering how everyone feels about the mnemonic \"INCLUDE\" in general. Personally I'm not crazy about it, but if that's what sticks, I'll adapt

", "time": "2025-07-21T08:15:29Z"}, {"author": "Ray Bellis", "text": "

@Q NOTIMP is a server level response code, not a data driven error. It says \"this server cannot service this type of query\".

", "time": "2025-07-21T08:15:47Z"}, {"author": "David Lawrence", "text": "

Ja, we want a return code that stops a legacy resolver from asking other servers.

", "time": "2025-07-21T08:16:31Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

And only NXDOMAIN will do that, because that's the only answer which will validate on a legacy resolver.

", "time": "2025-07-21T08:16:56Z"}, {"author": "Shane Kerr", "text": "

Oh. Then it's NXDOMAIN only, right?

", "time": "2025-07-21T08:16:59Z"}, {"author": "Roy Arends", "text": "

only rcode3 and 0 do that

", "time": "2025-07-21T08:17:00Z"}, {"author": "Erik Nygren", "text": "

The NS2 draft had proposed using NS2T rather than SVCB. It does seem like having a different RR type (eg, DELEGINCLUDED, or some shorter variant, rather than SVCB) for the target of an INCLUDE does make some things a little cleaner than using SVCB. This is even if we keep most of the SVCB and its registry.

", "time": "2025-07-21T08:17:08Z"}, {"author": "Roy Arends", "text": "

or NODATA

", "time": "2025-07-21T08:17:11Z"}, {"author": "Roy Arends", "text": "

(rcode0+empty answer)

", "time": "2025-07-21T08:17:35Z"}, {"author": "John Levine", "text": "

@Erik Nygren I take your point but I worry that fake names that are not directly related to the IP addresses will be confusing might cause some other kind of breakage

", "time": "2025-07-21T08:17:41Z"}, {"author": "Shane Kerr", "text": "

NODATA will only stop queries for a given type though, right?

", "time": "2025-07-21T08:17:42Z"}, {"author": "Roy Arends", "text": "

that is correct shane

", "time": "2025-07-21T08:18:13Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

NODATA will not validate.

", "time": "2025-07-21T08:18:28Z"}, {"author": "Jim Reid", "text": "

Why not use a new response code? We have 64K to choose from?

", "time": "2025-07-21T08:18:46Z"}, {"author": "David Lawrence", "text": "

Right. So you ask X.gtld-servers.com about deleg-only.com, the resolver will stop for that qtype (A?) but still ask for others

", "time": "2025-07-21T08:19:04Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Sure we can, but how do they stop _legacy clients_ from retrying?

", "time": "2025-07-21T08:19:06Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Not even speaking about non-EDNS stubs, which are still in existance ...

", "time": "2025-07-21T08:19:20Z"}, {"author": "David Lawrence", "text": "

(new response code) Because we're expecting this to only be applicable to legacy resolvers

", "time": "2025-07-21T08:19:30Z"}, {"author": "Ray Bellis", "text": "

and a non-EDNS stub can't handle extended RCODEs...

", "time": "2025-07-21T08:19:37Z"}, {"author": "David Lawrence", "text": "

They can't. They're dead in the water on the deleg-only name regardless.

", "time": "2025-07-21T08:20:08Z"}, {"author": "Shane Kerr", "text": "

Why wouldn't you just incluce the SOA from the parent in your SOA response? I'm confused...

", "time": "2025-07-21T08:20:13Z"}, {"author": "David Lawrence", "text": "

I think you could, Shane

", "time": "2025-07-21T08:20:39Z"}, {"author": "Benjamin Schwartz", "text": "

Petr \u0160pa\u010dek said:

\n
\n

NODATA will not validate.

\n
\n

Why not? There's no zone cut as far as this resolver is concerned...

", "time": "2025-07-21T08:21:05Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

qname=www.test.
\ntest. DELEG DIRECT ... whatever ...

\n

How do you arrive to NODATA?

", "time": "2025-07-21T08:21:34Z"}, {"author": "Roy Arends", "text": "

nodata requires a matching nsec record

", "time": "2025-07-21T08:21:38Z"}, {"author": "Philip Homburg", "text": "

There is one, unless you ask for DELEG specifically

", "time": "2025-07-21T08:22:15Z"}, {"author": "Philip Homburg", "text": "

Are we discussing the reponse to someting that requires delegation or just query for DELEG?

", "time": "2025-07-21T08:22:58Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

There is an NSEC, but it says there's no delegation (from the legacy clients perspective), so the correct rcode is NXDOMAIN.

", "time": "2025-07-21T08:22:58Z"}, {"author": "Roy Arends", "text": "

the query for bla.example.com has no NSEC record that matches bla, only example.com

", "time": "2025-07-21T08:23:00Z"}, {"author": "Philip Homburg", "text": "

if bla.example.com has a DELEG record then there should an NSEC with DELEG

", "time": "2025-07-21T08:23:32Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

You know? There's this wonderful table with 80 lines. Send line number we are discussing here.

", "time": "2025-07-21T08:24:07Z"}, {"author": "Philip Homburg", "text": "

do you have the url at hand?

", "time": "2025-07-21T08:24:25Z"}, {"author": "David Lawrence", "text": "

Ja, sec

", "time": "2025-07-21T08:24:34Z"}, {"author": "Roy Arends", "text": "

that is true, but I was refering to the come zone, that has a deleg record for example.com

", "time": "2025-07-21T08:24:41Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

https://github.com/ietf-wg-deleg/draft-ietf-deleg-base/blob/main/query-answer-combinations-table-gen.csv

", "time": "2025-07-21T08:24:55Z"}, {"author": "Roy Arends", "text": "

and no information (including nsec) for bla.example.com

", "time": "2025-07-21T08:24:57Z"}, {"author": "Philip Homburg", "text": "

Right. And that proxes NXDOMAIN

", "time": "2025-07-21T08:25:22Z"}, {"author": "Benjamin Schwartz", "text": "

\"NS .\" feels very clever.

", "time": "2025-07-21T08:25:33Z"}, {"author": "Shane Kerr", "text": "

example.com NS example.com

", "time": "2025-07-21T08:25:35Z"}, {"author": "Roy Arends", "text": "

@philip that is correct

", "time": "2025-07-21T08:25:43Z"}, {"author": "David Lawrence", "text": "

Is that effectively any different from bla.foo.bar.baz.example.com in the current system?

", "time": "2025-07-21T08:26:00Z"}, {"author": "David Lawrence", "text": "

Oh nm, I see that it is in at least a few ways. Dur.

", "time": "2025-07-21T08:26:43Z"}, {"author": "Benjamin Schwartz", "text": "

@Petr \u0160pa\u010dek I believe we're talking about \"legacy\" resolvers that don't recognize this EDE code. We are trying to come up with a response that makes \"legacy\" resolvers do something useful.

", "time": "2025-07-21T08:26:58Z"}, {"author": "Shane Kerr", "text": "

There is precedent for something like \"NS .\". \"MX 0 .\" means \"I don't take e-mail\" right?

", "time": "2025-07-21T08:27:01Z"}, {"author": "St\u00e9phane Bortzmeyer", "text": "

For many years, working domains will need to have NS records. So, Mark Andrews' proposal (forbid delegations without NS) is reasonable.

", "time": "2025-07-21T08:27:23Z"}, {"author": "Roy Arends", "text": "

@shane, we had \"root referrals\" in the past :-)

", "time": "2025-07-21T08:27:34Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

They can still happen, I have seen it two weeks ago somewhere.

", "time": "2025-07-21T08:27:51Z"}, {"author": "Ray Bellis", "text": "

extended error codes were badly designed. If you don't do EDNS you can't tell the difference between RCODE 1, RCODE 17, RCODE 33, etc.

\n

We should have defined e.g. RCODE15 to mean \"unspecified, but see EDNS\" instead of using the EDNS fields as \"extra bits\".

", "time": "2025-07-21T08:28:58Z"}, {"author": "Shane Kerr", "text": "

I just checked a couple weeks ago and we have hundreds of CNAME to root in our sytsem.

", "time": "2025-07-21T08:29:01Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Me neither, sorry. No time.

", "time": "2025-07-21T08:29:02Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

@Stephane that sounds like job for provisioning system, not the DNS server ....

", "time": "2025-07-21T08:29:54Z"}, {"author": "Michael Richardson", "text": "

Ray is saying that he gets to see all the really really bad ideas.

", "time": "2025-07-21T08:31:43Z"}, {"author": "Ray Bellis", "text": "

and write some of them :p

", "time": "2025-07-21T08:31:56Z"}, {"author": "Michael Richardson", "text": "

St\u00e9phane Bortzmeyer said:

\n
\n

For many years, working domains will need to have NS records. So, Mark Andrews' proposal (forbid delegations without NS) is reasonable.

\n
\n

working public domains. Let's not force this in software. the marketing.internal.example.com delegation from internal.example.com could be DELEG-only I think.

", "time": "2025-07-21T08:34:02Z"}, {"author": "Philip Homburg", "text": "

The requirement to have NS is an operational requirement. There no need to consider the existence of NS when designing DELEG.

", "time": "2025-07-21T08:35:26Z"}, {"author": "St\u00e9phane Bortzmeyer", "text": "

@Michael In such an environment, you typically control everything, so you can be sure all resolvers understand DELEG.

", "time": "2025-07-21T08:35:39Z"}, {"author": "\u00c9ric Vyncke", "text": "

BTW, I hate to be the bad guy wanting to follow the charter

", "time": "2025-07-21T08:40:29Z"}, {"author": "Erik Nygren", "text": "

I'd worry about splitting this out to a separate draft making readability harder, vs just reserving the range in the deleg draft and defining the semantics for the range.

", "time": "2025-07-21T08:40:38Z"}, {"author": "Ray Bellis", "text": "

current RR range reservations are documented in RFC 6895

", "time": "2025-07-21T08:42:12Z"}, {"author": "Willem Toorop", "text": "

I'm not really fond of the consequence that an NSEC/NSEC3 is always required in referral responses, if not all parent authoritative types are present on the delegation point

", "time": "2025-07-21T08:43:24Z"}, {"author": "Willem Toorop", "text": "

It would make all referral responses always one NSEC/NSEC3 RR + signature bigger

", "time": "2025-07-21T08:43:58Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Willem, it will happen no matter if we have single DELEG or not because as soon as software supports DELEG - because there will be no DELEG RRs at that point.

", "time": "2025-07-21T08:44:42Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

So all delegations will get extra NSEC :shrug:

", "time": "2025-07-21T08:44:52Z"}, {"author": "Willem Toorop", "text": "

Only for non-DELEG referrals with DE=1, right?

", "time": "2025-07-21T08:45:17Z"}, {"author": "Tommy Jensen", "text": "

thank you to whoever is fixing my keyboard's inefficiency in inserting non-ASCII characters :)

", "time": "2025-07-21T08:45:31Z"}, {"author": "Ray Bellis", "text": "

as one of the RR reviewers I am in favour of reserving such a range. It gives an opportunity for any authoritative implementation to know that any RR in that range is authoritative on the parent side of a zone cut, and that it should be signed (unlike e.g. NS). This would avoid future piecemeal implementations that need to decide this on a per-RR basis.

", "time": "2025-07-21T08:46:27Z"}, {"author": "Benjamin Schwartz", "text": "

\u00c9ric Vyncke said:

\n
\n

BTW, I hate to be the bad guy wanting to follow the charter

\n
\n

This seems like a good time to say the obvious: most of DNSOP's work is outside of its charter. This draft is more reasonably in charter for DELEG than for DNSOP, under the current charters.

", "time": "2025-07-21T08:46:30Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

@Willem Sure, that's the same for range as well. There's no material difference.

", "time": "2025-07-21T08:47:31Z"}, {"author": "Michael Richardson", "text": "

This (allocating a range of parent RR) is future proofing for new ideas that require parent-side RRs. Having done this, we'll probably never need it, but Murphy's Law applies the other way too... if we don't do it, we'll need it. I don't care if we do this here or in dnsop. It is probably easier to explain it to this WG, assuming that there are actually people who listen to only one.

", "time": "2025-07-21T08:47:44Z"}, {"author": "Suzanne Woolf", "text": "

Please don't base a roadmap here on assumptions about future consensus on the existence or charter of a new WG. Decide what needs to be done and make the administrative structures fit the work that has to be done.

", "time": "2025-07-21T08:48:07Z"}, {"author": "Ray Bellis", "text": "

I also think it would be reasonable to request that the IANA assignment for DELEG be made from the start of a new block of 256 codes in anticipation of a _future_ allocation of such a range.

", "time": "2025-07-21T08:48:12Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Well, we have 64k and used about ~ 100 in 40 years, so ...

", "time": "2025-07-21T08:48:50Z"}, {"author": "Michael Richardson", "text": "

Agreed: we not need 1000s of type codes, but 256 is affordable and generous. I can live with 5^W8.

", "time": "2025-07-21T08:49:19Z"}, {"author": "Willem Toorop", "text": "

@petr there is for DELEG delegations I think. Because currently when there is DE=1, the referral will include DELEG and DS, but no NSEC is needed. With a range, an extra NSEC/NSEC3 will always be added, unless all ADT types are present at the delegation point.

", "time": "2025-07-21T08:49:28Z"}, {"author": "Ray Bellis", "text": "

the RR review panel has also had requests for RRs that appear to require parent side semantics, but since that currently requires auth code changes they are not eligible for expert review. If there's a pre-defined range that requirement could be relaxed.

", "time": "2025-07-21T08:49:28Z"}, {"author": "Ond\u0159ej Sur\u00fd", "text": "

I agree with what Ben said.

", "time": "2025-07-21T08:49:34Z"}, {"author": "Ray Bellis", "text": "

a start of a 256 boundary is useful for NSEC bitmaps

", "time": "2025-07-21T08:49:46Z"}, {"author": "Ond\u0159ej Sur\u00fd", "text": "

@Ray I would suggest that anything that\u2019s in this range would be excluded from any expedited review and would require full document.

", "time": "2025-07-21T08:50:39Z"}, {"author": "Jim Reid", "text": "

Ben, dnsop has just been rechartered. A new WG is likely to take over the protocol work from dnsop.

", "time": "2025-07-21T08:50:56Z"}, {"author": "Michael Richardson", "text": "

If DELEG2 does not fit, fine. But maybe there will be other parent-side RRs.

", "time": "2025-07-21T08:51:17Z"}, {"author": "Ray Bellis", "text": "

@Ondrej perhaps. The primary criteria for whether expert review is permitted is whether server code has to change to accommodate the RR.

", "time": "2025-07-21T08:51:32Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Agreed, perhaps there will be some other use-cases than delegation.

", "time": "2025-07-21T08:51:35Z"}, {"author": "Erik Nygren", "text": "

For doing DANE for DELEG DIRECT are we also going to potentially need an additional parent-side RRtype?

", "time": "2025-07-21T08:51:39Z"}, {"author": "Michael Richardson", "text": "

Jim Reid said:

\n
\n

Ben, dnsop has just been rechartered. A new WG is likely to take over the protocol work from dnsop.

\n
\n

Let's go as far as possible in DELEG with this WG, and when this new WG is alive, we can pass the document over to it, if the AD decrees.

", "time": "2025-07-21T08:52:02Z"}, {"author": "\u00c9ric Vyncke", "text": "

As an AD I do not mind this discussion here, but adoption should not be here. DELEG has a very narrow scope on purpose.

", "time": "2025-07-21T08:54:16Z"}, {"author": "Willem Toorop", "text": "

Maybe there could be a better option for indicating support than DE=1. Maybe something in which the resolver indicates which parent side authoritative types it supports, so that the extra NSEC/NSEC3 + signature(s) is not needed.

", "time": "2025-07-21T08:57:16Z"}, {"author": "Brian Haberman", "text": "

I think the two questions for the WG are: 1) Do we see a need for allocating such a range, and 2) if so, how big should the range be. Those are questions for us to discus on the mailing list.

", "time": "2025-07-21T08:58:37Z"}, {"author": "Ray Bellis", "text": "

@Brian I don't think the size of the range should be decided here. IMHO that's currently a DNSOP question.

", "time": "2025-07-21T08:59:56Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

@Willem are you suggesting multi-qtype extension? :grin:

", "time": "2025-07-21T08:59:57Z"}, {"author": "Benjamin Schwartz", "text": "

@Petr \u0160pa\u010dek Could you repeat why this doesn't increase response size for DELEG?

", "time": "2025-07-21T09:00:31Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

@Ben I'm saying that 99.9 % zones will not have DELEG RR on it any time soon, so the NSEC will have to there anyway even if we use only single number instead of a range.

", "time": "2025-07-21T09:01:23Z"}, {"author": "Brian Haberman", "text": "

@Ray We can't decide the size, but we can make suggestions based on the DELEG use case.

", "time": "2025-07-21T09:01:28Z"}, {"author": "Philip Homburg", "text": "

Then it is either DELEG or NSEC. With a range it will be DELEG and NSEC

", "time": "2025-07-21T09:01:58Z"}, {"author": "Ray Bellis", "text": "

@Brian IMHO the only sensible size (irrespective of the DELEG use case) is 256. Anything smaller would increase the size of NSEC bitmaps.

", "time": "2025-07-21T09:02:21Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

FTR draft https://github.com/PowerDNS/draft-dnsop-parent-side-auth-types/blob/master/draft-peetterr-dnsop-parent-side-auth-types.md proposes 0xFA00-0xFDFF.

", "time": "2025-07-21T09:02:50Z"}, {"author": "Willem Toorop", "text": "

Responding to @Petr's response to @Ben, but only if the resolver does DE=1. If DE=0, then having no DELEG (but DS), will not induce an extra NSEC/NSEC3

", "time": "2025-07-21T09:02:58Z"}, {"author": "Philip Homburg", "text": "

Isn't the requirement that it starts at a multiple of 256. The size doesn't really matter

", "time": "2025-07-21T09:03:06Z"}, {"author": "Jim Reid", "text": "

@Michael, I think our AD has already decreed.

", "time": "2025-07-21T09:03:28Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

@Willem yes, and that's no different for a range. Was there a suggestion to the contrary?

", "time": "2025-07-21T09:03:39Z"}, {"author": "Warren Kumari", "text": "

SVCD FTW! :-p

", "time": "2025-07-21T09:04:31Z"}, {"author": "Ray Bellis", "text": "

@Philip strictly, yes, but if other purposes use the remaining parts of the 256 that's when you get bitmap bloat.

", "time": "2025-07-21T09:04:43Z"}, {"author": "Shane Kerr", "text": "

I mean... HTTPS was just SVCB with a different owner name. So not including \"_dns\" is not weird.

", "time": "2025-07-21T09:04:59Z"}, {"author": "Willem Toorop", "text": "

@Petr No, just the omission of mentioning this special condition (resolver sends DE=1) for the 99.9% of delegations returning an extra NSEC

", "time": "2025-07-21T09:05:10Z"}, {"author": "Ray Bellis", "text": "

happy to help with that draft - it's something I started thinking about a couple of years ago

", "time": "2025-07-21T09:05:14Z"}, {"author": "Tommy Jensen", "text": "

Easy: new ALPN, nobody will object I'm quite confident /s

", "time": "2025-07-21T09:05:41Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

That draft is already older than my two sons, so yeah, no rush :grin:

", "time": "2025-07-21T09:05:52Z"}, {"author": "Warren Kumari", "text": "

@Shane : HTTPS feels \"closer\" to the original than this -- there feel like more changes needed for DNS/DELEG...

", "time": "2025-07-21T09:06:23Z"}, {"author": "Philip Homburg", "text": "

HTTPS is meeded because it has to be possible at apex. Otherwise _html. would have been fine.

", "time": "2025-07-21T09:07:09Z"}, {"author": "Shane Kerr", "text": "

@Warren: for sure. I rage quit a PR I started against a Go DNS library because of these differences.

", "time": "2025-07-21T09:07:12Z"}, {"author": "Erik Nygren", "text": "

When following a AliasMode record (the equivalent of a INCLUDE) the record name to be resolved is SVCB with the name of TargetName (ie, you should NOT be modifying TargetName by adding a _servicename).

", "time": "2025-07-21T09:09:05Z"}, {"author": "Shane Kerr", "text": "

So we like key:value, but not any particular parameters. That's not weird, IMHO.

", "time": "2025-07-21T09:10:35Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Well we also possibly dislike having mandatory priority field, and possibly mandatory name field ... so that leaves us with generic key=value structure and nothing else.

", "time": "2025-07-21T09:11:16Z"}, {"author": "Shane Kerr", "text": "

@Petr that's fair.

", "time": "2025-07-21T09:11:50Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

(and almost no overlap with existing defined keys, to spice it up)

", "time": "2025-07-21T09:12:11Z"}, {"author": "Tommy Jensen", "text": "

ALPN: DOFT (fifty three) to make it more fun to pronounce

", "time": "2025-07-21T09:13:08Z"}, {"author": "Warren Kumari", "text": "

Forking this sounds less it will lead to less confusion -- \"Use SVBC exactly as defined, other than [long list of not supported things]. Oh, and these KV do/do not apply...\"

", "time": "2025-07-21T09:13:44Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Sorry for repeating myself... I think we should first define semantics and then decide on format. So far we don't have the semantics - like (name)less delegations, priorities or not, etc.

", "time": "2025-07-21T09:14:38Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

In other words, I think we are bikeshedding here.

", "time": "2025-07-21T09:14:52Z"}, {"author": "\u00c9ric Vyncke", "text": "

@peter, I agree with your first part

", "time": "2025-07-21T09:15:12Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

That's different type than DELEG, isn't it? Roy rejoyce!

", "time": "2025-07-21T09:15:47Z"}, {"author": "Shane Kerr", "text": "

I'm just excited that we may invent another way to have DNS RDATA. :melting_face:

", "time": "2025-07-21T09:16:48Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Oh definitelly. We should reuse key=value machinery/format/code otherwise developers will eat us alive.

", "time": "2025-07-21T09:18:18Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Chasing ... well ... I will wait with conclusion until it is defined. With multiple-target INCLUDE it is not directly applicable.

", "time": "2025-07-21T09:18:48Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

I agree with Philip. A rare occurrence!

", "time": "2025-07-21T09:19:36Z"}, {"author": "Shane Kerr", "text": "

I had to look up what \"isomorphic\" means. Wikipedia claims:

\n

\"In mathematics, an isomorphism is a structure-preserving mapping or morphism between two structures of the same type that can be reversed by an inverse mapping.\"

\n

I'm not sure I am any better informed...

", "time": "2025-07-21T09:21:02Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Thank you!

", "time": "2025-07-21T09:23:05Z"}, {"author": "Erik Nygren", "text": "

There also seem to be different interpretations of \"priority\": whether it is intended for fallback, for introducing service bindings that may not be compatible with some clients, or for weighting. They are explictly NOT for weighting in SVCB (which is what there had been good concerns about)

", "time": "2025-07-21T09:24:00Z"}]