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

From: Ralf Weber <[email-masked]>
Date: Tue, 22 Mar 2022 14:02:30 +0100

Moin!

So to follow up on my comment in the working group on registries not having anything to do with it. I understand that this drafts is for authoritative name server implementers, however I think that we should make clear that an authoritative name server not answering correct by this draft might do so because it does not have sufficient data.

So we currently have in the introduction:

Note that this document only clarifies requirements of name server
software implementations.  It does not place any requirements on data
placed in DNS zones or registries.

how about adding:

However missing data might make it impossible for a name server to answer with the correct (referral) glue data.

And maybe add some encouragement or referral ;-) to work that has to be done elsewhere.

So long
-Ralf
——-
Ralf Weber

---

From: Petr Špaček <[email-masked]>
Date: Tue, 22 Mar 2022 14:33:46 +0100

> And maybe add some encouragement or referral ;-) to work that has to be done elsewhere.

Sounds reasonable to me.

-- 
Petr Špaček

---

From: Hugo Salgado <[email-masked]>
Date: Tue, 22 Mar 2022 10:43:25 -0300

> And maybe add some encouragement or referral ;-) to work that has to be done elsewhere.

The problem is with SIBLING glue records. The in-domain glues are of
course required and included in the zone.

Hugo

---

From: Ralf Weber <[email-masked]>
Date: Tue, 22 Mar 2022 15:45:23 +0100

Moin!

> course required and included in the zone.
No, the problem with missing data is general. The (referral) glue records are required, but it is possible to not supply them and break resolution. I think in general a name server can only serve what it is given. So if you have a zone example.com that has

sub.example.com. IN NS ns.sub.example.com.
sub.example.com. IN NS ns.example.org.

that is valid data even if you check in zone glues (and not all servers check that on load and the ones that do usually just issue a warning). It is very easy to create wrong zone data that will lead to resolution errors, and there is nothing an authoritative name server can do once it has accepted that data. I actually just loaded the above example in Akamai AuthServe, ISC bind and NLNetLabs NSD and all of them loaded it, and I could also load them even without ns.example.org line on all of them.

So if we say that we don’t put requirements on data or data generators (registries) than we have to spell out that even a server that follows this draft/RFC might not be able to serve answers according to the draft/RFC when the data is not correct.

So long
-Ralf
——-
Ralf Weber

---

From: Hugo Salgado <[email-masked]>
Date: Tue, 22 Mar 2022 12:03:56 -0300

> sub.example.com. IN NS ns.example.org.

Yes, we agree that a zone must include the essential records for the
resolution to work. What I am trying to say is that records that are
not required, like some kind of siblings, should be optional even at
the zone data level, and of course can't be included in the nameserver
answer requirements. There are some registries that do not have
siblings that are not in-domain of the referred domain. More
information:
  https://mailarchive.ietf.org/arch/msg/dnsop/h0_6iEUIDWb4FyvrpDnDN1BRqBE/

> So if we say that we don’t put requirements on data or data generators (registries) than we have to spell out that even a server that follows this draft/RFC might not be able to serve answers accor…

Agree.

Hugo

> So long
> -Ralf
> ——-
> Ralf Weber
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Mar 2022 09:04:32 +1100

> On 23 Mar 2022, at 01:45, Ralf Weber <[email-masked]> wrote:
> 
> Moin!
> 

Well for BIND missing glue on zone load was supposed to be made fatal with the BIND 9.5.0 release
See lib/dns/zone.c:zone_check_glue

                        /* XXX950 make fatal for 9.5.0. */
                        /* answer = false; */

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Ralf Weber <[email-masked]>
Date: Wed, 23 Mar 2022 07:05:23 +0100

Moin!

>                         /* XXX950 make fatal for 9.5.0. */
Well maybe the out of the box 9.16.1-Ubuntu that my distribution (Ubuntu 20.04 LTS) gave me either patched these or changed the default configuration to not fail as I did nothing else then adding a zone to the config and it loaded.

So long
-Ralf
——-
Ralf Weber