Nameserver status paradox

[bemasc]

If a DNS server is

• Unconditionally authoritative for example.com, AND
• authoritative for foo.example.com via DELEG, but not via NS

what should it serve to a query for foo.example.com/A?

A non-DELEG-aware resolver requires a referral response to the nameserver that is authoritative via NS. A DELEG-aware resolver needs an answer to the question. The authoritative server doesn't know which kind of resolver is asking the question.

This distinction is especially apparent if we imagine that DELEG has overridden the DS record, using a different DS from the one that applies to the NS delegations.

[RoyArends]

Ben, if foo.example.com/A exist, return it. If not, return NXDOMAIN if foo doesn't exist, else return NODATA.

If the resolver is a legacy resolver, it will ask for DS, and the authoritative server will return NODATA for it. The zone appears unsigned.

If the resolver is DELEG aware, ask for DELEG, as it is missing a referral response. It may contain DS information. If not, it still needs to ask for DS (as per RFC4035).

It is important to educate the operator of the authoritative server and zone owner the need for transitioning between legacy and DELEG world, that is, either deploy both DELEG and NS+DS, or use a feature that automagically generates NS (and generates and signs DS).

[bemasc]

If the resolver is a legacy resolver, it will ask for DS, and the authoritative server will return NODATA for it. The zone appears unsigned.

How does this help? If the zone is signed, the legacy resolver can't get the DS or the NS.

[RoyArends]

I have misread, apologies.

The server is authoritative for both parent and child, correct?
There is a DS, but referrals from the parent zone are occluded by the presence of the child zone.

A legacy resolver asks for foo.example.com/A, the server response with an answers (exist, doesn't exist, nodata) plus a signature

The legacy resolver asks for foo.example.com DS. The authoritative server will respond with the DS (assuming it was present).

Is that what you meant?

Thanks,

Roy

[vttale]

authoritative for foo.example.com via DELEG, but not via NS

I don't think it is a paradox. It is an explicit signal that the subzone is not accessible for legacy resolvers. The DELEG-aware authority simply returns the NS-less DELEG-full delegation as it should, and the legacy resolver interprets it as noerror/nodata for the qtuple because it didn't get a record that answered the question either directly or indirectly. Not ideal as far as NXDOMAINs that might be served by the child, but the net effect is largely the same.

Edit: Okay, so I guess I do see the paradox now that I thought on it a little more. What's weird here is that a non-validating legacy resolver still ends up getting a usable (presumably correct) answer in a circumstance where a validating legacy resolver wouldn't get one, or where no legacy resolver would get an answer if the subzone were on a different server.

I'm still not sure that the problem is worth solving though, just recognizing that it exists and describing it.

[bemasc]

I agree that this issue can be resolved by documenting it (although it's sufficiently complicated to reason about that this is not straightforward), or by adjusting behavior slightly (e.g. returning the answer and a referral in cases where the query is ambiguous). However, I think the emergent complexity here is a strike against the current designs, and we ought to look for ways to reduce complexity. For example, this entire category of concerns, including the "parent DS chasing" behavior, could be eliminated in DELEG by adding an EDNS query option that echoes the operative DELEG record in queries that are using it. This would tell the server exactly who the resolver thinks it is talking to, and under what parameters, allowing the server to provide appropriately tailored answers.

[fl1ger]

EDNS is hop to hop - long term we will have deleg aware forwarders which then would have to have special EDNS0 processing. History shows this never worked and the DS code paths already exists and just need to be applied to DELEG. I think that complexity is manageable as it is understood and not a wildcard like EDNS0 option forwarding.

[bemasc]

Is there a supported configuration involving a forwarder between the resolver and authoritative? I've never seen that.

[pspacek]

Define "supported"... There are TLDs which are run exactly like this - but to the best of my knowledge this is being done for political reasons, not technical.

Anyway, I think this 'paradox' is a broader problem:
"Inconsistent configuration between legacy-NS and DELEG will lead to inconsistent resolution."

I think this can be solved by documenting this...

“The patient says, "Doctor, it hurts when I do this."
The doctor says, "Then don't do that!”

🧌

[bemasc]

There's no inconsistency in the "zone contents" here. There is an inconsistency between the NS and DELEG records as to which nameservers exist for the zone, but I expect that DELEG intends to support that kind of deviation.

It's possible that this problem largely disappears if DS and "sharedds" are declared incompatible as discussed in #42.

[pspacek]

There's no inconsistency in the "zone contents" here.

...

There is an inconsistency between the NS and DELEG records as to which nameservers exist for the zone, ...

That's what I meant by zone content inconsistency - on the parent side, to be specific.