Joe Abley <[email protected]> wrote: > I presented today in Montréal about our proposal > draft-jabley-dnsop-zone-cut-to-nowhere.
> https://datatracker.ietf.org/doc/draft-jabley-dnsop-zone-cut-to-nowhere/
Interesting.
I think that this is useful work, and we should do something here.
In places where I have deployed "internal.example.com"/"corp.example.com",
(and I significantly prefer this over split-horizon DNS)
with the authoritative name servers only accessible from "inside",
I have intentionally used unrouted IPv6 (GUA) for the NS.
People's VPN clients are then configured to bring up the VPN when there is
traffic so that prefix. Thus, the act of asking for
www.internal.example.com attempts to bring up the VPN to get there.
If the VPN fails, then the name does not resolve, but it's not unknown.
(I find this much better than using RFC9704)
So I just want text explaining that zone-cut-to-nowhere is probably not
appropriate if you expect it to work for clients with variable
connectivity.
> Mark's Concern
> Consider a zone cut to nowhere published in the EXAMPLE.COM zone for
> CORP.EXAMPLE.COM. Then consider a stub resolver sending the query
> (QNAME = CORP.EXAMPLE.COM) to a resolver A on the public Internet where
> the private namespace CORP.EXAMPLE.COM is not available, which is
> configured to process cache misses by sending queries to resolver B. So
> this is an example of a chained resolver processing a query.
I'm not familiar with such a configuration; I guess it's a forwarders thing?
> 2. Change signalling in zone data. Mark suggests a better response from
> the authoritative server would be to return a referral from for the
> child that includes the same NS set as the parent. This is clearly
That smells like something that could easily happen by mis-configuration,
(usually by some enterprise DNS administrator).
> 3. Change resolver behaviour. Resolver B SHOULD return a more useful
> signal than SERVFAIL, maybe with an EDE or something. Resolver A SHOULD
> avoid retrying if it receives such a signal. This would avoid the
> behaviour Mark is concerned about in this draft, but would also clean
> up other uses of the hostname ".". The camel is slightly sad, but
> perhaps it's worth it to avoid the cost of retries for all the cases
> where "." is used in place of a real hostname to mean "not provided".
Can we do both?
Return NS ., but also EDE?
> 4. This isn't a big enough problem to care about, all of 1 through 3
> are horrible, let's forget the whole idea.
I might fall into this camp, if there isn't something obvious/simple we can do.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
