Re: [dns-operations] Google ECS caching issue, looking for contact
Replied off-list. W On Wed, Jan 6, 2021 at 6:25 PM Jeff Westhead via dns-operations wrote: > > > > > -- Forwarded message -- > From: Jeff Westhead > To: "dns-operati...@dns-oarc.net" > Cc: > Bcc: > Date: Wed, 6 Jan 2021 23:17:38 + > Subject: Google ECS caching issue, looking for contact > > Hello! We are seeing some misrouting impact because a CNAME that we intended > to be cached at /24 is being cached at global scope by 8.8.8.8. Anyone here > from Google who could look into the specifics for me? > > > > > -- Forwarded message -- > From: Jeff Westhead via dns-operations > To: "dns-operati...@dns-oarc.net" > Cc: > Bcc: > Date: Wed, 6 Jan 2021 23:17:38 + > Subject: [dns-operations] Google ECS caching issue, looking for contact > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Wed, Jan 06, 2021 at 06:10:58PM -0500, Viktor Dukhovni wrote: This is a mistake that confuses input processing with output processing. Not necessarily. I think the implementor could decide that you're either doing IDNA or you're not, and if you expect non-IDNA stuff to be returned you should turn off IDNA (which is presumably why it's off for non-TTYs). I can easily imagine an implementation of a tool that simply will not return things to you if it's not IDNA-conforming. (I can see an argument also why that might be surprising, but that's a different matter.) This is in some ways akin to the browser rule that it won't show you a U-label unless it happens to be "in your configured language" (which, FWIW, I think has its own surprises). When converting the first label to presentation form, which does not since it does NOT start "xn--", applying IDNA rules makes no sense at all. I don't think that's what 5890 says. It says 'For IDNA-aware applications, the three types of valid labels are "A-labels", "U-labels", and "NR-LDH labels",' so a label starting with - is just invalid, no matter what. You're arguing, I think, that for a tool like dig, taking a domain name off the wire and restricting that domain name to IDNA is wrong. I think it's an implementation choice regarding what one is supposed to do with invalid data coming from the wire, but it's pretty clear it's surprising to at least some people in this context. Note that IDNA2008 does expect implementations to do local processing on domain names, and it's an interesting question whether that includes things that come back from resolution: the entire thing is written as though there's user input that is then converted for lookup, but this particular case seemed originally to crop up in the context where IDNs are probably unexpected but where IDNA was turned on. The point of IDNA was supposed! to be not just "least surprise" but also "internationalize LDH", and non-LDH labels just automatically violate that. Another way to say it is, if there's no eyeballs who need to read the identifier then you shouldn't use IDNA at all. The implementation is correct, but the context is wrong. The implementation is still not correct in any case, because it takes some NON-LDH labels and not others when IDNA is turned on, and that's bound to be incorrect under IDNA2008. (It strikes me that there might be another possibility, which is that dig is also attempting to work for IDNA2003, in which case this might still a bug but not in the way I was arguing.) Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Google ECS caching issue, looking for contact
--- Begin Message --- Hello! We are seeing some misrouting impact because a CNAME that we intended to be cached at /24 is being cached at global scope by 8.8.8.8. Anyone here from Google who could look into the specifics for me? --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Wed, Jan 06, 2021 at 03:59:04PM -0500, Andrew Sullivan wrote:
> So, I think what it means is that, with the IDN support turned on, dig
> is IDNA-aware and therefore shouldn't accept any NON-LDH label. As it
> happens, it accepts some NON-LDH labels but not others, which maybe
> _is_ a bug, but not the one people were complaining about. ;-)
This is a mistake that confuses input processing with output processing.
In the case in question, dig(1) is NOT reading textual labels to
interpret as domain names, it has a *wire* domain name inside a DNS
packet, that it needs to display to the user. That wire domain name
(with prefixes) is:
<1>-<5>house<3>gov<0>
When converting the first label to presentation form, which does not
since it does NOT start "xn--", applying IDNA rules makes no sense at
all. The ONLY correct thing to do there is escaping of special
characters ("\" escape or "\DDD" encoding).
The implementation is correct, but the context is wrong. Doing the
wrong thing correctly is still a bug.
--
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
Geez, it's a long time since I had to take a lot of care on IDNA and non-IDNA protocol cases. But here's my take. On Wed, Jan 06, 2021 at 01:38:43PM -0500, Dave Lawrence wrote: I'm not really following your logic, Andrew (or Mark), for how applying IDNA rules is relevant to interpreting the labels in question. My reading of the dig man page leads me to believe that IDN support basically turns domain name slots in dig (see 5890 §2.3.2.6) into IDNA-aware domain name slots. Now, 5890 §2.3.2.1 says, 'For IDNA-aware applications, the three types of valid labels are "A-labels", "U-labels", and "NR-LDH labels",' and that constrains what labels are permitted. 5890 §2.3.2.2 says an NR-LDH label can be neither an IDN, nor a reserved LDH label (R-LDH), but it can be otherwise anything permitted by §2.3.1. But §2.3.1 defines LDH label according to what is in RFC 952, and RFC 1034 §3.5 as modified by RFC 1123. Most assuredly, that does not permit a label that begins with "-". So, I think what it means is that, with the IDN support turned on, dig is IDNA-aware and therefore shouldn't accept any NON-LDH label. As it happens, it accepts some NON-LDH labels but not others, which maybe _is_ a bug, but not the one people were complaining about. ;-) I think there is good reason to blame the reviewers of 5890 for this being as confusing as it is in the text. In my defence, I will say it was worse in earlier drafts! Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
In article <20210106032410.ga6...@isc.org> you write: >I wonder aloud if dig's default behavior should be to try IDN and >silently fall back to conventional output formatting if it fails. >I imagine there are situations where you'd want the rules strictly >enforced, but I'm not sure if there was a good reason to do that by >default. Given that there is no reason to assume that any particular query or result in dig will be a hostname as opposed to a generic DNS name, that sounds right to me. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] IDNA vs. dig vs. non-IDN labels.
> On Jan 6, 2021, at 2:01 PM, Andrew Sullivan wrote: > > Because if you're doing IDNA you have to permit only A-labels and NR-LDH > labels, according to RFC 5890. NR-LDH labels are defined in §2.3.2.2, but > refer to §2.3.1. In there is this text: > > [An LDH label] is the classical label form used, albeit with some additional > restrictions, in hostnames [RFC0952]. Its syntax is identical to > that described as the "preferred name syntax" in Section 3.5 of RFC > 1034 [RFC1034] as modified by RFC 1123 [RFC1123]. Briefly, it is a > string consisting of ASCII letters, digits, and the hyphen with the > further restriction that the hyphen cannot appear at the beginning or > end of the string. Like all DNS labels, its total length must not > exceed 63 octets. That mostly makes sense on *input*. But on *output*, when one has a wire-form DNS name, and is computing a prentation form, if the wire-form label does not start with "xn--" it makes no sense at all to apply IDN conversion, or apply rules that pertain to hostnames for a name that is not a hostname. So while I acknowledge that one can always specify "+noidnout", I strongly concur that this is a "dig" bug. Not a showstopper by any means, but something worth fixing. -- Viktor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
I'm not really following your logic, Andrew (or Mark), for how applying IDNA rules is relevant to interpreting the labels in question. Yes, I read your cited text from RFC 5890, but still am not grokking how it is relevant for dig choking on -.house.gov just because IDN output is enabled. It seems to me it would just get categorized as "NON-LDH labels" per the diagram in 2.3.1, and should then just be ignored as far as IDNA output processing is concerned. Though, in fairness, I will also admit that I don't have much more support for that position, in that "NON-LDH" appears nowhere beyond that diagram, and there's seems to be no explicit statement covering that category in the rest of 2.3.2. Where are you seeing the incorporating text that indicates that encountering them they should attempt to be interpreted as IDNA for output? Why is the unitary hyphen being handled specially there but not, say, # which also appears in the NON-LDH label category? (Which I just tested with no problems.) I'll go back to my earliest assertion that even if isn't properly a bug, boy is it surprising. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Jan 6, 2021, at 10:26 AM, Evan Hunt wrote:
>
> On Wed, Jan 06, 2021 at 03:24:10AM +, Evan Hunt wrote:
>> I wonder aloud if dig's default behavior should be to try IDN and
>> silently fall back to conventional output formatting if it fails.
>> I imagine there are situations where you'd want the rules strictly
>> enforced, but I'm not sure if there was a good reason to do that by
>> default.
>
> Ondrej has just reminded me that IDN conversion is disabled by
> default if stdout isn't a TTY, so the use of dig in scripts should
> be unaffected by this problem. (For example, it works fine if you
> use "dig +dnssec whatever.house.gov | cat".)
For this experiment, dig was being run in a Python script using subprocess.run.
I do not know why dig would think that was a TTY.
r = subprocess.run("dig @8.8.8.8 +dnssec +yaml {} A".format(this_name),
shell=True, capture_output=True, encoding="utf-8", check=True)
Given the errors, I had to add the +noidnout option.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Wed, Jan 06, 2021 at 03:24:10AM +, Evan Hunt wrote: > I wonder aloud if dig's default behavior should be to try IDN and > silently fall back to conventional output formatting if it fails. > I imagine there are situations where you'd want the rules strictly > enforced, but I'm not sure if there was a good reason to do that by > default. Ondrej has just reminded me that IDN conversion is disabled by default if stdout isn't a TTY, so the use of dig in scripts should be unaffected by this problem. (For example, it works fine if you use "dig +dnssec whatever.house.gov | cat".) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Tue, Jan 05, 2021 at 10:11:48PM -0500, John Levine wrote: If it's validating IDNs it makes sense to complain about something like xn--1234 which has an IDN prefix but isn't an A-label. But a label that is just a hyphen isn't a hostname just like _foo isn't a hostname. Why does it complain about one but not the other? Because if you're doing IDNA you have to permit only A-labels and NR-LDH labels, according to RFC 5890. NR-LDH labels are defined in §2.3.2.2, but refer to §2.3.1. In there is this text: [An LDH label] is the classical label form used, albeit with some additional restrictions, in hostnames [RFC0952]. Its syntax is identical to that described as the "preferred name syntax" in Section 3.5 of RFC 1034 [RFC1034] as modified by RFC 1123 [RFC1123]. Briefly, it is a string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets. The restriction on the hyphen not appearing at the beginning is actually not new: RFC 952 says a hostname has to begin with a letter, and 1123 relaxed that to allow either a letter or a digit (what Bob Braden once told me he called "the 3Com exception", apparently due to the reason for the change). The "preferred name syntax" never permitted a hyphen-minus in the initial position of a label, though of course DNS does in principle. So, if dig is in the mode of not doing IDNA, it's reasonable it can return anything; but if it _is_ in the mode of doing IDNA, it has to follow all the other rules too. Best regards, A (as usual, only for myself.) -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
