IPv4hint, glue and address mismatches

[RoyArends]

Assume a signed DELEG record for example.com, with TargetName ns1.example.com and IPv4hint=192.0.2.1
Assume a delegation point NS record for example.com, with an NSDNAME ns1.example.com
Assume a glue address record (served by the server authoritative for .com) for ns1.example.com with address 192.0.2.2
Assume a hostname ns1.example.com with A record 192.0.2.3, in the example.com zone.
example.com is not a signed zone.

The DELEG record contains a signed binding between ns1.example.com and address 192.0.2.1.
All other records can be spoofed by an adversary.

The SVCB specification specifies that when A records for TargetName are locally available, the client SHOULD ignore these hints.

In short, the SVCB instruction here is to "trust" the unsigned "192.0.2.3" or "192.0.2.2" over "192.0.2.1". Experience tells me that there will be mismatches between parent and child records.

The same is true for IPv6, but have left this out to not convolute this example. We need clear instructions and rationale for developers.

[bemasc]

I don't think we need to worry too much about the trustworthiness of address records. In our usual threat models, the adversary can rewrite IP addresses in the network anyway. Or to put it another way: if your adversary can't intercept network traffic, then how did they rewrite example.com/AAAA?

We can offer some guidance about relative trustworthiness, but ultimately I think the resolver should be free to use whatever heuristics it wants during IP selection, just like how parent-centric and child-centric resolution are both permitted today, and NS revalidation is optional.

I do think we have an interesting question about what to say about glue in a DELEG world (see #13 (comment)). It seems like folks are leaning toward a position of "glue is legacy", i.e. DELEG will bundle everything it needs into the record and not rely on any glue. I'd be interested to know if that makes sense to you.

[RoyArends]

I'm not referring to an on-path adversary or a model where traffic is intercepted. A kaminsky-style spoofing where glue is spoofed, but hint is real (since it is signed) works, since RFC9460 states that glue should be trusted over signed hints.

I also do not want to convolute trustworthiness with IP selection. I'm more than happy with resolvers selecting addresses based on latency or randomness, but not with resolvers trusting signed and unsigned things equally.

Glue is indeed a necessary legacy evil. I'm more than happy with binding addresses to target names in the deleg record.

[bemasc]

I'm fine with a "hint supersedes glue" rule. I'm more suspicious of a rule that a signed parent hint overrides an unsigned child record. This runs counter to the "NS revalidation" work, and the general rule that the child controls its own record contents. I'm also not convinced that it benefits security: any adversary who could override this address record in the child zone could also override the other records that the resolver is actually trying to resolve.

Ideally, this will largely be moot, because DELEG will enable more usage of DoT/DoQ, which prevents these attacks even if the child is unsigned.

[fl1ger]

I would prefer to not have discussions here, but this is an important one, so I comment. One of the whole points of DELEG and a core design feature is that there is no ambiguity between child and parent. The parent has the DELEG record and if that is hints that's it. If there is an alias the child can use its SVCB to do hints. NS revalidation tries to make all resolver child centric which usually is the wrong decisions as parent centric resolvers usually can resolve more as a child can not shoot itself in the foot. The ambiguity of having NS in the parent and child is one of the major problems we have and a design failure we would like to avoid with DELEG.

[RoyArends]

We are in violent agreement. I pointed out that having yet another place to have an address leads to ambiguity, so in the presence of all that, there needs to be a clear and unambiguous instruction to developers.

Where would you prefer to have discussions?

[shane-ns1]

I think that we should create a new name and not use IPvXHints at all, so we can have different semantics.

For example, IPv6Glue and IPv4Glue?

[vttale]

I'm not clear on what different semantics to expect from iphints versus ipglue.

Resolvers already have a notion of the trust level of data even with just glue and auth data. They can already differ. So what if they do? I agree that we should be clear on what address source a resolver should prefer, yes, when DELEG is through into the mix.

As for Roy's scenario, If example.com is fine with being unsigned, the owner/operator has already accepted that ns1.example.com could possibly be spoofed and will live with that risk. They've also accepted that any non-DELEG resolver will first use the parent additional section glue for ns1 and, if they learn ns1 from explicit query to example.com auth then use that.

So, for me: a DELEG resolver should use DELEG hints, but like glue still give it a lower trust level than a direct response from a query to the auth, independent of the DNSSEC around parent and child. (I mean, insecure vs secure of course, not invalid.)

[Philip-NLnetLabs]

A difference could be that hints should have a name. The hint just speeds up connecting if the name needs to be resolved.

We could define a new glue type that by definition doesn't have a name and where the glue is the only source of the address. That avoids the question of which one to prefer

[vttale]

Hmm, https://www.rfc-editor.org/rfc/rfc9460.html#name-ipv4hint-and-ipv6hint is pretty clear that ip*hint are addresses, not names. It'd be super weird to have them be a name when TargetName is fulfilling that role.

[Philip-NLnetLabs]

The point is, for *hint there has to be a name. Typically, SVCB refers to a name. Then *hint are addresses associated with that name but included in the SVCB as a kind of prefetching operation. This has a high risk that the hints and the actual addresses associated with the name will go out of sync, and the users of the record are supposed to generate A and AAAA query for the name, because *hint are only a hint.

This is probably not what we want for a DNS delegation.

[fl1ger]

This is exactly what we want. If you want to have something in the child you can use the alias mode and refer to that this way (has to be out of domain though). Anything else aka service mode DELEG is defined in the parent and in the parent only. It can never get out of sync as there is nothing to get out of sync to.

[RoyArends]

This is exactly what we want. If you want to have something in the child you can use the alias mode and refer to that this way (has to be out of domain though). Anything else aka service mode DELEG is defined in the parent and in the parent only. It can never get out of sync as there is nothing to get out of sync to.

There will be a need for NS records at delegation points to cater for legacy resolvers. NS' NSDNAME and DELEG's target name and address information can mismatch. If that is okay, it needs to be clear. If not, we need to give clear instructions on how to handle that. That was one of the points of raising this issue.

[Philip-NLnetLabs]

That can be solved by instructing a DELEG-aware resolver to ignore NS (both parent and child) and DS if a DELEG record is present.

[pspacek]

That can be solved by instructing a DELEG-aware resolver to ignore NS (both parent and child) and DS if a DELEG record is present.

I definitely agree. If it is present just ignore the legacy stuff.