3.4. Presentation Format
Since this is a "meta" RR that cannot appear in master format zone files no presentation format is defined.

Could you please define a Presentation Format so that "dig" and similar tools use a consistent format?

--
Bob Harold

A v4-only server might see v6 addresses in the XPF packet and should be prepared to deal with it. We should spend a few words on that. Thanks @zeha

3.2 says

If the length of the IP addresses contained in the RR are not
consistent with that expected for the given IP version then the
server MUST return a FORMERR response.

but we can't actually check that, we can only see if we 'run out of RDATA too soon' or 'have some RDATA left over', maybe we can word this better. Thanks @mind04

We use '4' and '6' to indicate v4 and v6. These numbers do not appear like that in any registry. edns-client-subnet and clientid use https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml. @arjenz noticed during wireshark implementation that our deviation makes his code longer as he cannot rely on the already present IANA list.

How do we encode 'question received over QUIC'? Discussion split from #9:

Habbie: In related news there is no way for us to currently indicate that the query came in over QUIC and we should probably do something about that..

rgacogne: Since we have the original destination port, it should be possible to use that to infer whether the query was received over TLS (port 853) or QUIC (port TBD AFAIK).

Habbie: the QUIC port could be 80 or 443 as far as I know, but perhaps that's good enough, yes. But what do we put in the protocol field then? UDP?

raybellis: QUIC is a pseudo-L4 protocol, which is currently encoded by the 8-bit
"protocol" field but for which no defined value exists in the IANA
protocol registry.
Nor does QUIC exist in the AF registry (since it uses IP for its L3
protocol). Arguably a meta-value should be defined in the protocol
registry that wouldn't be used on-the-wire (because QUIC uses UDP) but
might be used to otherwise indicate that QUIC had been used ?

Habbie: Yes, indeed. Shall I take this question to quic@ietf?

Since doing some digging on the IETF data tracker it seems the draft has been expired, and no more activity has been taken to push it through. I'm curious if there was a resolution, be it good or bad. I have some interest in making this record type available in other DNS servers when/if it's approved and assigned a RRType code.

The HTTP header we are emulating is called X-Forwarded-For, not X-Proxied-For. Unsure we need to do anything with this insight.

3.1 says proxies strip XPF (unless), 3.2 says servers say REFUSED on XPF (unless). This behaviour should be identical for both (whichever choice we make) because a difference exposes details of the internals of a setup. I'm leaning towards 'strip' for both, but I'm fine with REFUSED for both too.

Thanks @mind04

suggested by @fanf2

Is multi-tier XPF stacking actually required?

If there are multiple proxy tiers, wouldn't the server be more likely to be more interested in the original XPF packet, not the last one?

@enygren wrote:

Have you considered modelling XPF after the HAProxy protocol?

https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

There was some discussion at an HTTP workshop as to whether it would be worth getting the HAProxy protocol IETF-standardized, perhaps also adding some things like encryption. (eg, having a shared key and doing AES-SIV encryption+authentication might address some of the privacy concerns). Having a shared format/payload across HTTP, DNS, and other protocols might be useful and might be BOF-worthy?

Erik

PowerDNS

In PowerDNS/pdns#6220:

• XPF type support (configurable codepoint)
• XPF-sending support in sdig (./sdig 127.0.0.1 53 example.com A xpf 65422 4 17 1.2.3.4:4660 5.6.7.8 4660 22136')

tcpdump

With thanks to @job, https://github.com/the-tcpdump-group/tcpdump/compare/master...job:dns_xpf?expand=1

wireshark

with thanks to @arjenz, arjenz/wireshark@06afdc4

Rather than use the protocol field to tag things like QUIC (see #10) should we consider using a couple of the reserved bits to indicate meta-properties of the original inbound query, e.g.

1. packet originated from an unspoofable source (US flag)
2. packet was encrypted (EN flag)

on the basis that policy decisions might be made based on those meta-properties rather than on the specific ports or protocols in use, hence:

• UDP - nothing
• UDP + cookies - US
• TCP - US
• TLS - US + EN
• QUIC - US + EN