Moin,
i just gave draft-sst-dnsop-probe-name-00 a read, and would like to
bring some wood for the bike shed. ;-)
I think that the draft is in general a good idea; However, I'd also
argue that there would be merit in just setting up a whole range of
'probe' domains, especially to enable further testing of resolver
behavior (here comes the bike shed; Handle with a grain of salt, but
wanted to float the idea). This of course would need some additional
effort in actually setting up that test environment (and finding an org
to do/maintain that).
The key issue I see with (expanding|the draft) is the zone-cut
limitation. As far as I read the document, a resolver should synthesize
for probe.resolver.arpa; This essentially takes resolver.arpa out of
the picture as well. However, that is necessary for the performance
improvements from NXDOMAIN synthesis.
This, however, limits options for further probe types (esp. concerning
resolver behavior), OR needs some special handling. Assuming the latter
to be OK, I would suggest that the following might be useful:
resolver.arpa
- SLD for delegation, supporting $all_the_things
probe.resolver.arpa
- Synthesize NXD, no recursion performed
echo.resolver.arpa
- returns base64 + human readable query received by
authoritative in an additional TXT
(AFI)-((Transport)0*)-(DNSSEC)-(MTU-behavior)-(ExpRESP).resolver.arpa
- AFI:
ds : Normal dual stack resolution
ds.ds-only : Only resolvable via Dual-Stack
v4-only : Only resolvable via v4
v6-only : Only resolvable via v6
- Transport (to authoritative for the zone, multiple, delimit
with 0):
dou : DNS over UDP
dotcp : DNS over TCP
dotls : DNS over TLS
doh : DNS over HTTP
- DNSSEC:
nodnssec : no DNSSEC
brokendnssec : Broken DNSSEC
dnssec : valid DNSSEC
(Option for dnssec$algo exists, of course, as well)
- MTU behavior
mtu1500pmtud : mtu1500 with PMTUD working
mtu1280pmtud : mtu1280 on-path with PMTUD working
mtu1280nopmtud : mtu1280 on-path with PMTUD working
-Exp(ected)RESP
up to 32b of data that correspond to the ANSWER the
authoritative should provide (to test for
interception)
Would need a list of default answers for each query
type
While I'd say that _technically_ this would be a standard AS112 thing,
making this really useful would require an authoritative implementation
that supports some of the features (except echo, i'd assume LUA records
in PowerDNS should already be able to do this, though).
So... well, not sure how actionable this would be. However, this would
enable clients to figure out things about resolvers that go beyond
their own connection to the resolver.
Thoughts?
With best regards,
Tobias
--
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M [email protected]
Pronouns: he/him/his
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
