Hi Tobias,
On 03-Apr-25 21:05, Tobias Fiebig wrote:
Moin,
Good point. So maybe we do need a stand-alone BCP for this? Or
perhaps it should be added to section 7 of draft-ietf-6man-rfc8504-
bis?
"IPv6 addresses for DNS servers SHOULD be preferred over IPv4."
This is pretty close to the 3901bis discussion in DNSOP atm; I would
personally recommend not making this a stand-alone BCP;
I agree.
Things to consider (also for the proposed algorithm in the ticket at:
https://github.com/timchown/rfc8504-bis/issues/20 ):
- There is no HE for DNS; The proposed text basically creates that for
stubs
- RFC3901 (currently) covers authoritative and recursive servers, the
issue here is about stubs
Technically, the language planned for 3901bis makes v4 and v6 equal
citizens, i.e., both SHOULD. The translation point is similar to:
https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/
Fair enough. It seems to me that "host requirements" is the logical place
to specify a preference for IPv6 over IPv4, so personally I now prefer
the 8504bis option, but I wouldn't object to putting it in 3901bis either.
Brian
Even though that draft is again resolver specific.
I see three options for this:
- Add the language independently in 8504bis as planned in the ticket
- Integrate the part about resolution address selection from the draft
above into 3901bis and also add stubs to the text
- Move stubs and recursive servers (or maybe even each) into their own
documents and bind them via BCP91 (which can also hold other DNS
transport related things, including transport protocol selection,
and technically 9715 (The 'big' solution i had mentioned before)
Not arguing for any of the options atm; Just putting them out there to
see what people think.
With best regards,
Tobias
_______________________________________________
v6ops mailing list -- v6...@ietf.org
To unsubscribe send an email to v6ops-le...@ietf.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
